KB5127648's Two Open Issues: Is Administrator Protection Putting Your Remote Desktop Hosts at Risk?

Watch this post — YouTube walkthrough

RDP and USB AUDIO Error 0xC000000D Still Open in KB5127648 — Check Your Exposure

Endpoint Weekly

Prefer YouTube? Open it there Subscribe at @EndpointWeekly

Most Patch Tuesday advice ends at "install the update". For KB5127648 that is not enough, because two problems that arrived with September's updates are still open, and Microsoft's own fix for one of them is to turn a security feature off.

This post goes through both issues using only what Microsoft has published. It separates what Microsoft states from what I observed on a real device, and it flags the details that tend to get lost when the advice is copied from one team to another.

The problem: two open issues that patching does not fix

KB5127648 (13 October 2026) lists a long set of fixes. It also has a Known issues in this update section, and two entries in it are still open. Both are listed on the Windows release health pages with the status Mitigated, which means a workaround exists but the underlying fault is not fixed.

The release health page for the USB audio issue lists a wide range of affected platforms, not just current Windows 11: Windows 11 26H2, 26H1, 25H2, 24H2 and 23H2, Windows 10 22H2 and 21H2, two Windows 10 LTSC versions, and Windows Server 2012 through 2025. The Remote Desktop issue is specific to Windows 11 because Administrator protection is a Windows 11 feature.

Three details that are easy to get wrong

When this advice is passed around, three things tend to be copied inaccurately. Each one can send an admin to the wrong setting or the wrong KB, so they are worth stating up front.

1. The policy to reset is not just "Admin Approval Mode". Microsoft's exact names are "User Account Control Type Of Admin Approval Mode" in Intune and "User Account Control: Configure type of Admin Approval Mode" in Group Policy. Other UAC settings have similar names, and changing one of those alters your normal UAC behaviour. The change also needs a restart.
2. KB5124012 is the wrong KB for 24H2 and 25H2. The KB5127648 page names KB5124012 as the update that introduced the USB audio problem. Microsoft's own list shows KB5124012 is a Windows 11 26H1 update (build 28000.2954). The release health record gives the originating update for 24H2 as KB5124008. Treat release health as correct for your devices.
3. "Switch to 2-channel mode" is not the workaround for Code 10. Microsoft says some customers restored audio that way, and it was for the 8-channel and 3D symptom that KB5129195 has already fixed. For the symptoms still open, Microsoft's stated route is to contact Microsoft Support for Business.

Why it happens: a security feature turning on by default

What Administrator protection is

Normally, when you are an administrator, Windows keeps a standard token for everyday work and a full admin token it can use after a UAC prompt. Administrator protection changes that. Microsoft describes it as requiring you to verify your identity with Windows Hello before any action that needs admin rights.

Microsoft lists four design points. Elevation is just-in-time, and the admin token is thrown away after use. It uses hidden, system-generated, profile-separated accounts to build isolated admin tokens. There are no automatic elevations. And it is integrated with Windows Hello.

Microsoft has not published a root cause for the 0xC000000D failure, so I will not guess at one. What it does publish is the condition under which it happens, and that is enough to plan around.

It is off by default, until your baseline turns it on

Microsoft's Administrator protection page says the feature is off by default, supported on Windows 11 Home, Pro, Enterprise and Education, and available since KB5120998 (the 27 August preview). Then it adds a note that changes the picture for managed fleets:

The KB5127648 page words it slightly differently: it is enabled by default in the 24H2, 25H2 and 26H2 baselines published through the Microsoft Security Compliance Toolkit, "unless your organization has configured the policy differently." Neither page says exactly how the default reaches a device, so the reliable test is to look at a device after it has the October update, not to reason from the documentation alone.

Put together, the Remote Desktop failure needs all of these to be true at once:

If any one of those is false, you are not hit by this particular failure. That is why a blanket "we are likely exposed" is less useful than a per-device answer.

The build numbers that matter

"KB5124010 or later" sounds vague, but build revisions only go up, so it can be turned into a number. These are the 24H2 and 25H2 builds from the KB pages:

So a device on revision 9550 or higher has the update the Remote Desktop issue starts from. A device on 9457 does not yet. Windows 11 26H2 (build 26300) is numbered the same way: its KB5124010 build is 26300.9550 and its KB5127648 build is 26300.9711, so the same cutoff works there.

If you use hotpatching, the cutoff still holds. Microsoft's hotpatch calendar lists October 2026 as a baseline (restart) month, so hotpatch-enrolled devices also install KB5127648 and land on 9711, the same as everyone else. Hotpatch builds can sit below the standard update in the same month (August's hotpatch was 9106 against 9168 for the standard update), so check the calendar rather than assuming. November and December are listed as hotpatch months.

What Microsoft says not to do with it

The same page has a list headed "When not to enable this feature". It matters because a baseline default can switch the feature on in exactly these situations without anyone deciding to.

Microsoft also documents behaviour you will see on devices where it is on. Application settings data does not carry over between the standard and elevated profiles. Single sign-on credentials from the standard session are not available inside an elevated session, so domain or cloud authentication has to be repeated there. Network drives and resources can be unreachable from elevated apps. Two earlier problems, a missing Start menu icon and Edge extensions asking for elevation, were fixed in KB5124010.

How to verify: are you actually exposed?

You need three facts per device: its build, whether Remote Desktop is enabled on it, and whether Administrator protection is on. Then you need to know which policy is responsible, so you can tell a baseline default from a deliberate setting.

Step 1: where Microsoft documents the setting

Microsoft documents Administrator protection in four places. Use the one that fits how you manage the device.

The Configuration service provider page adds two facts worth knowing. Changing the policy needs a restart, and it is supported on Windows desktop only, not Server.

Step 2: read the state on a device

The Intune and Group Policy settings tell you what you assigned. They do not tell you what a particular device ended up with after policy conflicts and timing. For that, read the device.

Microsoft's pages do not name the registry value behind this setting. On the Windows 11 25H2 device I tested, a value called TypeOfAdminApprovalMode sits under the UAC policy key and held 1, which matches the Configuration service provider meaning of "Legacy". Treat the name as something I observed, not something Microsoft documents. Confirm it on a device where you have deliberately set 2 before relying on it across the fleet.

The same applies to Remote Desktop. Microsoft documents the fDenyTSConnections setting (false means Remote Desktop connections are enabled, true means denied, and denied is the default). On the test device the registry value of that name held 1, meaning denied.

Step 3: classify each device

The function below turns those three facts into a single answer. It deliberately has four outcomes beyond "exposed", because "I could not read it" must never be reported as "not exposed".

function Get-AdminProtectionRdpExposure {
    param($Build, $Revision, $RdpDeny, $AdminMode)

    # KB5124010 (22 Sep 2026) and every later update is revision 9550 or higher on these builds
    if ($Build -notin 26100, 26200, 26300) { return 'OUT OF SCOPE - not Windows 11 24H2, 25H2 or 26H2' }
    if ($null -eq $RdpDeny -or $null -eq $AdminMode) { return 'UNKNOWN - a value could not be read' }
    if ($AdminMode -ne 2)   { return 'NOT EXPOSED - Administrator protection is off' }
    if ($RdpDeny -ne 0)     { return 'NOT EXPOSED - Remote Desktop is not enabled on this device' }
    if ($Revision -lt 9550) { return 'WATCH - exposed once it installs KB5124010 or later' }
    return 'EXPOSED - Remote Desktop host with Administrator protection on'
}

Then a short wrapper reads the device and calls it:

$cv  = Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion'
$rdp = (Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server' -Name fDenyTSConnections -ErrorAction SilentlyContinue).fDenyTSConnections
$aap = (Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System' -Name TypeOfAdminApprovalMode -ErrorAction SilentlyContinue).TypeOfAdminApprovalMode

'{0,-25}: {1}.{2}' -f 'Build', $cv.CurrentBuildNumber, $cv.UBR
'{0,-25}: {1}' -f 'fDenyTSConnections', $(if ($null -eq $rdp) { '(absent)' } else { $rdp })
'{0,-25}: {1}' -f 'TypeOfAdminApprovalMode', $(if ($null -eq $aap) { '(absent)' } else { $aap })
'{0,-25}: {1}' -f 'Result', (Get-AdminProtectionRdpExposure -Build ([int]$cv.CurrentBuildNumber) -Revision ([int]$cv.UBR) -RdpDeny $rdp -AdminMode $aap)

Here is a real run on the test device. It is a 25H2 laptop that has not taken the October update, with Remote Desktop disabled and Administrator protection off:

Build                    : 26200.9457
fDenyTSConnections       : 1
TypeOfAdminApprovalMode  : 1
Result                   : NOT EXPOSED - Administrator protection is off

"This is what good looks like" on that device: every value was readable, and the answer is a clear NOT EXPOSED with a reason. A tester handed this result knows exactly why the device is safe today.

Before trusting a classifier, test every branch of it, including the awkward ones. Mine passes all eleven cases, including a Windows 10 build, a 26H1 build (a different update stream), and missing values:

ok    exposed host on October build        -> EXPOSED - Remote Desktop host with Administrator protection on
ok    exposed host on the preview itself   -> EXPOSED - Remote Desktop host with Administrator protection on
ok    exposed host on 26H2                 -> EXPOSED - Remote Desktop host with Administrator protection on
ok    host not yet on KB5124010            -> WATCH - exposed once it installs KB5124010 or later
ok    host on Sept 8 build                 -> WATCH - exposed once it installs KB5124010 or later
ok    admin protection off                 -> NOT EXPOSED - Administrator protection is off
ok    RDP disabled                         -> NOT EXPOSED - Remote Desktop is not enabled on this device
ok    value absent: admin mode             -> UNKNOWN - a value could not be read
ok    value absent: rdp                    -> UNKNOWN - a value could not be read
ok    Windows 10 build                     -> OUT OF SCOPE - not Windows 11 24H2, 25H2 or 26H2
ok    26H1 build (different KB stream)     -> OUT OF SCOPE - not Windows 11 24H2, 25H2 or 26H2

11 of 11 cases behave as expected

Step 4: baseline default or deliberate setting?

To answer "does our baseline leave it on or override it", find which policy sets this one value. In Intune, open the policy that contains "User Account Control Type Of Admin Approval Mode" and check its per-setting status and any conflict with a second policy. For Group Policy, run gpresult /h report.html on a representative device and look for "Configure type of Admin Approval Mode" under Security Options.

On the test device no Intune policy was setting this node at all, which is what you would expect where nothing has assigned it. A device where a baseline sets it will look different, and that is the group you need to list.

The USB audio check

For USB audio, the first question is whether any device is actually failing. Code 10 is visible to Windows, so this query finds it without needing to know which headsets you own. Here is a real run on the test device:

$bad = @(Get-CimInstance Win32_PnPEntity | Where-Object { $_.ConfigManagerErrorCode -eq 10 })
if ($bad.Count -eq 0) {
    'No devices reporting Code 10 ("This device cannot start").'
} else {
    "$($bad.Count) device(s) reporting Code 10:"
    $bad | Select-Object Name, PNPClass, Status | Format-Table -AutoSize
}

No devices reporting Code 10 ("This device cannot start").

Whether a particular device is Class 1.0 is a property of the device itself, so it comes from the manufacturer's specification, not from Windows. Microsoft's USB Audio Class system driver page, linked in the references, is the place to start.

The fix: mitigations, and what to decide

Remote Desktop: Microsoft's mitigation

Microsoft's mitigation is to temporarily turn Administrator protection off on affected devices, by resetting the policy through Intune or Group Policy. There is no fix yet. Be clear about what that means: it is a security regression you are choosing to accept for a time.

With Intune:

1. Sign in to the Intune admin center and go to Devices › Configuration.
2. Open the policy that sets User Account Control Type Of Admin Approval Mode. If your baseline sets it, note which policy it is before changing anything.
3. Set it to the legacy option, which is value 1 in the Configuration service provider.
4. Assign it to a device group that contains only your Remote Desktop hosts, not the whole fleet.
5. Restart the hosts. Microsoft says a restart is required for the change to take effect.
6. Run the check script on a host and confirm it now reports Administrator protection is off.

With Group Policy:

1. Open gpmc.msc and edit the GPO that applies to your Remote Desktop hosts.
2. Go to Computer Configuration › Windows Settings › Security Settings › Local Policies › Security Options.
3. Open User Account Control: Configure type of Admin Approval Mode and set it to Legacy Admin Approval Mode (Default).
4. Restart the hosts, then confirm with the check script.

Decisions that are yours to make

Microsoft offers one mitigation. The decisions around it are judgement calls, and these are mine, not Microsoft's:

• Scope it narrowly. Only Remote Desktop hosts are affected, so only they need the reset. Leave Administrator protection on everywhere else.
• Give it an owner and a review date. "Temporarily" has no meaning without one. Tie the review to Microsoft's fix, which is promised for a future update.
• Check who actually connects. The failure is for non-admin users. If a host is only ever used by administrators, test that before you spend effort on it.
• Do not assume a clean test on an unpatched host. Test as a non-admin user on a host that has KB5124010 or later, with Administrator protection on. Anything else tests a different situation.

USB audio: what to do

1. Find out whether any device is failing, using the Code 10 query above. If none, you can note it as monitored.
2. Make sure affected devices have KB5129195 or later. That resolves the 8-channel and 3D audio symptoms.
3. For Code 10, no sound or unresponsive volume, there is no self-service fix yet. Microsoft says administrators who need a workaround should contact Microsoft Support for Business.
4. For a user who needs to work now, a different audio device (for example one that is not Class 1.0) avoids the issue. That is a practical suggestion, not a Microsoft statement.

Proof it worked: what a defensible result looks like

A result is defensible when someone reading it in three months can tell what was checked, what was found, and what was accepted. For these two issues that means a per-device classification, a before-and-after on the pilot ring, and an explicit list of accepted risk.

KB5127648 exposure sign-off                 Ring: Pilot
-------------------------------------------------------
Before the update (Administrator protection)
Devices checked                          40
  NOT EXPOSED - protection off           36
  NOT EXPOSED - Remote Desktop not on     2
  UNKNOWN - value could not be read       2   # chased and fixed, not ignored

After the update
  EXPOSED - RDP host, protection on       4   # baseline default flipped it
  WATCH - not yet on KB5124010 or later   0

Mitigation applied to the 4 exposed hosts
  Reset to legacy (value 1), restarted     4/4
  Non-admin RDP test after restart         4/4 connect, no 0xC000000D

Accepted risk, signed by change owner
1. Administrator protection is OFF on 4 Remote Desktop hosts.
   Reason: Microsoft status Mitigated, fix due in a future update.
   Review: when Microsoft ships the fix. Baseline adjusted, not just devices.
2. 1 USB Audio Class 1.0 headset shows Code 10. Replaced.
   Microsoft Support for Business case opened.

The numbers are fictional and the block is labelled illustrative, but the shape is the point. The "before" and "after" lines are what make it evidence: the four exposed hosts exist only because the update flipped the default, and the sign-off records that rather than hiding it.

For Remote Desktop specifically, success has two parts, and you need both. The check script must report that Administrator protection is off on the host, and a non-admin user must then connect without 0xC000000D. A script result alone proves the setting, not the behaviour.

References

• KB5127648: October 13, 2026 update, known issues and improvements
• KB5129195: September 14, 2026 out-of-band update (8-channel and 3D audio fix)
• KB5124010: September 22, 2026 preview, where the Remote Desktop issue starts
• Administrator protection: configuration, baseline default, when not to enable it
• LocalPoliciesSecurityOptions policy CSP (UserAccountControl_TypeOfAdminApprovalMode)
• Windows 11, version 24H2 known issues and notifications
• Windows 11, version 25H2 known issues and notifications
• Windows 11, version 26H2 known issues and notifications
• fDenyTSConnections: whether Remote Desktop connections are enabled
• USB Audio Class system driver (usbaudio.sys)
• Related: the pre-rollout QA test plan for KB5127648
• Related: the CVE side of this update, with the full list of fixes and open issues