AD FS DKM ACL Hardening Enforcement Starts October 13, 2026: What CVE-2026-56155 Follow-Up Means for You

We covered CVE-2026-56155 itself when it was disclosed, the AD FS privilege escalation flaw tied to insecure Distributed Key Manager (DKM) container permissions. What that earlier post didn’t cover, because it hadn’t happened yet, is this: starting October 13, 2026, Microsoft’s auto-remediation for this flaw switches from opt-in to on-by-default. If you haven’t reviewed your DKM container ACLs since the July 2026 update shipped, your AD FS servers are about to have their permissions changed automatically, whether you’ve looked at it or not.

This is specifically about what changes this month and what to check before it happens, not a repeat of the original vulnerability explainer.

Quick recap: what the DKM container actually is

AD FS stores its token-signing and token-decryption certificates’ private key material in a Distributed Key Manager container in Active Directory, shared across every AD FS server in the farm. If the access control list on that container is misconfigured (broader than Domain Admins, Enterprise Admins, SYSTEM, and the AD FS service account), any account with that excess access can retrieve the key material and mint valid tokens for your federation trust, effectively bypassing authentication entirely for anything relying on that AD FS instance.

The timeline, concretely

• July 2026 (KB5121391): Audit mode begins. After installing this update, AD FS checks the DKM container ACL at service start and every 24 hours afterward. If it finds excess permissions, it logs Event ID 1132 in the AD FS Admin event log. No changes are made automatically at this stage.
• Opt-in remediation (available since July): setting the registry value RemediateDkmAcl to 1 under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ADFS turns on remediation immediately, rather than waiting for enforcement mode.
• October 13, 2026: enforcement mode. If the registry value isn’t explicitly set, the update behaves as if RemediateDkmAcl = 1, remediation runs by default. To opt out and keep audit-only behavior, you now have to explicitly set the value to 0, the default has flipped.

What remediation actually changes

After successful remediation, the DKM container’s access list is reset to exactly these principals, nothing broader:

• Domain Admins, Generic All / Full Control
• Enterprise Admins, Generic All / Full Control
• SYSTEM, Generic All / Full Control
• The AD FS service account, Read, Write, Create Child, Write Owner, Delete Tree

Inheritance is disabled on the container and all previously inherited ACEs are discarded. If you had a legitimate reason for a broader ACL (a custom management tool, a delegated admin group, a monitoring service account reading the container), that access gets removed, and it is on you to re-add it deliberately after remediation runs, not before.

Step 1: check for Event ID 1132 right now

Get-WinEvent -LogName "AD FS/Admin" -FilterXPath "*[System[(EventID=1132)]]" -MaxEvents 10 -ErrorAction SilentlyContinue |
  Select-Object TimeCreated, Id, Message

If this returns results, your DKM container currently has excess permissions, and enforcement mode will change them automatically on October 13 unless you’ve set the opt-out key. Run this on every AD FS server in your farm, not just one, the container is shared but it’s worth confirming consistent results across the farm rather than assuming.

Step 2: decide deliberately, don’t just let the default happen to you

Three real options, pick one on purpose:

1. Let enforcement run (the new default as of October 13): do nothing, confirm you don’t depend on any access beyond the four standard principals listed above.
2. Opt in early and control the timing: set RemediateDkmAcl = 1 yourself before October 13, so remediation happens on your schedule (right after a change window, for instance) rather than automatically whenever the next 24-hour check lands.
3. Opt out deliberately, with a real plan to fix it manually: set RemediateDkmAcl = 0 only if you have a documented reason to keep the current ACL for now, and a real timeline to clean it up yourself, not as a way to ignore the warning indefinitely.

# Set explicitly, either value, don't leave it unset past Oct 13 by accident
New-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\ADFS" -Name "RemediateDkmAcl" -Value 1 -PropertyType DWord -Force

Step 3: after remediation runs, save the old ACL

Successful remediation logs Event ID 1135, which includes the previous ACL in SDDL format. Save that event’s content before it ages out of the log, it’s your only easy record of what access existed before remediation reset it, which you’ll need if something that depended on the old permissions breaks and you need to understand exactly what changed.

Get-WinEvent -LogName "AD FS/Admin" -FilterXPath "*[System[(EventID=1135)]]" -MaxEvents 5 |
  Select-Object TimeCreated, Message | Format-List

One platform exception

Windows Server 2012 and 2012 R2 are not covered by the automatic enforcement change at all. If you’re running AD FS on either of those (itself worth flagging as a separate problem, both are long past mainstream support), remediation has to be done manually, following Microsoft’s documented steps for those specific versions, enforcement mode will not do it for you.

Quick guide

1. Check every AD FS server for Event ID 1132 today.
2. If you have a documented reason for broader DKM container access, decide now whether to opt in early, let the October 13 default run, or opt out with a real remediation plan.
3. Set the RemediateDkmAcl registry value explicitly, don’t leave it to the implicit default if you have a preference.
4. After remediation runs (by you or automatically), save the Event ID 1135 record with the previous ACL in SDDL format.
5. If you’re on Windows Server 2012/2012 R2, plan manual remediation, enforcement mode skips those versions entirely.

FAQ

What happens if I do nothing before October 13?

If you haven’t set the RemediateDkmAcl registry value at all, the behavior becomes equivalent to it being set to 1, remediation runs automatically on the next 24-hour check after the October update applies. This is a deliberate default flip by Microsoft, not an opt-in you need to trigger.

Can remediation break something that currently works?

Yes, if anything beyond the AD FS service account and the standard admin groups currently has access to the DKM container (a custom monitoring tool, a delegated support team, a backup agent), that access is removed and will need to be re-added deliberately afterward. This is exactly why checking Event ID 1132 before the 13th matters, so you know in advance rather than finding out when something breaks.

Does this affect AD FS farms using Azure AD Connect or Entra Connect?

The DKM container and this hardening change are specific to AD FS’s own token-signing key storage, not Entra Connect/Cloud Sync’s provisioning agent. If you run both AD FS and a sync agent in the same environment, check them separately, they’re different components with different update paths.

Is the original CVE-2026-56155 still relevant if I’ve already patched?

Patching gives you the audit capability and the opt-in remediation option, but it doesn’t by itself fix an already-misconfigured ACL, that requires either enforcement mode actually running or you remediating manually. Patched but never remediated is still exposed, which is exactly the gap enforcement mode closes by default starting this month.

Sources

• Microsoft Support, KB5121391, CVE-2026-56155 AD FS DKM container ACL hardening