October 2026 Updates Enforce AD FS DKM ACL Hardening: CVE-2026-56155 Admin Guide

This is the second phase of a plan Microsoft announced in July. It's also one of the rare Patch Tuesday changes that edits Active Directory permissions in your environment instead of only patching a binary. If you run AD FS, this one deserves your attention.

What's being locked down and why it matters​

Microsoft describes the issue in KB5121391. AD FS relies on the DKM container to store the symmetric keys used to protect token-signing and token-encryption certificates for private keys. The risk is simple: if the container's ACL is overly permissive, an attacker with read access to the DKM key material can decrypt the token-signing private keys. Microsoft classes this as an elevation of privilege (EOP) that can arise from the vulnerability documented in CVE-2026-56155.

Forkast, which reported today's enforcement date, puts the worst case bluntly. An attacker holding the token-signing private key can forge Golden SAML tokens that federated relying parties will accept, which skips the sign-in page and any MFA attached to it. Microsoft's KB doesn't use the term "Golden SAML," so treat that as Forkast's description. The logic holds, though. If someone has the key that signs your tokens, they can sign tokens too.

How serious is it in practice? Earlier WindowsForum coverage reported that the flaw carries a CVSS 3.1 score of 7.8 and is rated Important, and that it is not a pre-authentication remote-code-execution flaw that an anonymous internet user can trigger directly against an AD FS endpoint. An attacker must already have some authorized access in the affected environment. Writing for SMBs, ITECS adds that CISA added it to the Known Exploited Vulnerabilities catalog the same day Microsoft disclosed it. Its summary of the real danger: the flaw is not usually the way in, it is the way an intruder converts a foothold into total, durable control of your federated identity.

Section summary: The DKM container holds the keys that unlock your token-signing keys. If too many accounts can read it, anyone who already has a foothold can end up forging federation trust.

The timeline: three months of audit, now enforcement​

Microsoft rolled this out in two phases:

• July 14, 2026 (audit mode): Hardening against this vulnerability begins with the Audit mode, which introduces automatic detection of insecure DKM container ACL configurations. An additional opt-in remediation mechanism helps administrators strengthen DKM container permissions. Per the KB, AD FS made no automatic ACL changes during this phase.
• October 13, 2026 (enforcement mode): Microsoft's message-center reminders said Windows updates released in October 2026 will begin Enforcement mode for AD FS Distributed Key Manager (DKM) container ACL hardening. This hardening change is designed to address the elevation of privilege vulnerability documented in CVE-2026-56155 by automatically remediating insecure DKM container ACL configurations on supported Windows Server versions.

Microsoft's KB says that starting with the October update, remediation runs by default without the registry key. That behaves the same as setting RemediateDkmAcl to 1. Microsoft also says further hardening will follow in future updates, so October may not be the last change.

Who gets automatic enforcement and who doesn't​

The 2012-era split is the part admins are most likely to miss. The KB lists both 2012 ESU editions as affected, but enforcement doesn't run on them. On those servers, you have to grant the AD FS service account explicit Allow permissions for WriteOwner and WriteDacl on the DKM container first. Without those rights, Microsoft says remediation attempts will fail. Microsoft's procedure, run on any one AD FS server in the farm:

1. Get the DKM container's distinguished name from (Get-AdfsProperties).CertificateSharingContainer.
2. Find the AD FS service account from the StartName of the adfssrv service.
3. Translate that account to a SID and add an Allow access rule for WriteOwner and WriteDacl on the container. The full PowerShell is in KB5121391.
4. Create the DWORD RemediateDkmAcl with a value of 1 under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ADFS. If the ADFS key doesn't exist, create it first.
5. Wait up to 24 hours for the next detection cycle, or restart the AD FS service to trigger it sooner.

If your farm is still on 2012 R2, today's update won't fix anything for you. That doesn't mean your ACL is fine. It means nobody has fixed it yet.

Section summary: Server 2016 and later get hardened automatically. Server 2012/2012 R2 stay exactly as they are until someone does the manual steps.

What the hardened ACL looks like​

After remediation, Microsoft's secure state allows only four principals:

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

Inheritance is turned off, inherited entries are discarded, and any other explicit Allow entry is removed. Rack2Cloud summed it up this way: Four principals stay. Everything else explicit is removed without being named. That second sentence is the operational risk. If a backup tool, monitoring agent, delegated admin group or old migration script relied on read access to that container, it will lose it, and no event will tell you which entry belonged to which tool.

How to read the event log​

Detection runs one minute after the AD FS service starts and every 24 hours after that. Check AD FS/Admin for these events:

Event 1135 is the one to act on quickly. It contains your previous ACL in SDDL format, and it's your only built-in rollback record. Microsoft warns that event logs roll over, and if the event is overwritten before you save the SDDL, it's gone for good. The KB includes a short Get-WinEvent snippet that writes the latest 1135 message to a file. Run it right after remediation.

If you see event 1136 repeatedly, the event text says you can harden the ACL by hand with ADSI Edit or PowerShell. Once remediation succeeds, it won't run again while the ACL still matches the baseline.

The opt-out: an exception, not a fix​

To stop automatic remediation after the October update, set RemediateDkmAcl to DWORD 0 under HKLM\SOFTWARE\Microsoft\ADFS. Microsoft's KB says this disables remediation while detection keeps logging event 1132. It also adds a warning: only use this if you have a specific compatibility requirement and plan to manually harden the ACL. The sentence just before it says opting out leaves your DKM container vulnerable.

Forkast calls the opt-out "the escape hatch" and argues it is itself the vulnerability. That goes a bit far. The vulnerability is the permissive ACL. The registry value only means Microsoft won't fix that ACL for you. The practical point still stands: an opt-out is a choice to keep a known exposure, and whoever made that choice should own it on paper.

Rolling back if something breaks​

If a dependency fails after remediation, Microsoft documents a restore path. You apply the saved SDDL back to the container with SetSecurityDescriptorSddlForm, from an elevated PowerShell session on a domain-joined machine, using an account that holds SeSecurityPrivilege (normally Domain Admins). Then set RemediateDkmAcl to 0 so AD FS doesn't re-harden the ACL on its next cycle.

Treat a rollback as a short-term measure. Microsoft notes the old ACL shouldn't be needed in most cases because it was insecure to begin with. The better long-term fix is to give the broken integration its own narrow access, not to put the broad access back.

Today's checklist for AD FS admins​

1. Inventory your farms by OS version. Note which servers will auto-remediate and which need manual work.
2. Patch all AD FS servers. Microsoft's guidance is to install the July 14, 2026 security update or a later Windows update on all AD FS servers.
3. Check AD FS/Admin for 1132 through 1136 after the October update.
4. Save the SDDL from event 1135 immediately.
5. Test the integrations that touch AD FS: token issuance, relying-party sign-ins, certificate rollover, and any third-party tools that read the container.
6. Do the manual steps on 2012/2012 R2 if your farm still runs on them.
7. Document every RemediateDkmAcl=0 exception, with an owner and a date for manual hardening.
8. Don't treat a clean 1133 as proof you were never compromised. Earlier WindowsForum coverage noted that finding an overly broad ACL does not establish that the environment was compromised, but organizations should review historical access to the DKM container, unexpected changes to AD FS service accounts, certificate activity. If you have real doubts, rotating token-signing certificates is a sensible precaution. That last suggestion is general incident-response practice, not something the KB requires.

Bottom line​

Microsoft gave admins three months to audit their DKM ACLs and opt in early. As of today, Server 2016 and later get the hardened ACL by default. Server 2012/2012 R2 shops still have to do the work themselves, and the only way to refuse the fix is a registry value Microsoft's own documentation warns against. For most admins, today's job is to check the event log, save the 1135 data, and confirm sign-ins still work.