The audit-only period is over. Effective today, October 13, 2026, the October Windows security update hardens the access control list on the Distributed Key Manager (DKM) container in Active Directory Federation Services (AD FS), the change documented in Microsoft’s KB5121391 documentation. For most enterprise environments the hardened state is now the default. The historically permissive configuration is no longer the quiet path.
The DKM container is the vault for the symmetric keys that protect the private keys of token-signing and token-encryption certificates. If the container’s ACL is overly permissive, an attacker with read access to the DKM material can decrypt those private keys. The issue, tracked in the CVE-2026-56155 record, is classified by Microsoft as an elevation of privilege. Once an attacker holds the token-signing private key, they can mint Golden SAML tokens – forgeries that every federated relying party accepts, which puts the front door and its MFA out of the conversation.
AD FS joins the pattern Forkast keeps documenting: the default was insecure, and the fix arrives later as forced remediation. Ships Without Auth covered four control planes that shipped that way, among them the SonicWall SMA 1000 and Splunk Enterprise Patroni. AD FS’s version is subtler. Not a missing login – an authorization model broad enough to hand the crown-jewel cryptographic material to the wrong principals.
Hardening began on July 14, 2026, in audit mode. The AD FS service checks the DKM container ACL at startup and every 24 hours after, logging Event ID 1132 when the ACL does not match the expected secure state and 1133 when it does. Nothing changed automatically through the audit window. That window closed today: the October 2026 security update remediates insecure ACLs by default, equivalent to setting the RemediateDkmAcl registry value to 1 under HKLM\SOFTWARE\Microsoft\ADFS.
The secure state it enforces is narrow. Four principals keep access: Domain Admins, Enterprise Admins, SYSTEM, and the AD FS service account. Inheritance gets disabled, inherited entries discarded, every other explicit Allow ACE stripped. Microsoft also documents saving the previous ACL in SDDL format from Event 1135 – a rollback path, because a tightening this broad can break whatever was leaning on the old permissions.
The platform split is where operators get caught. Automatic remediation covers Windows Server 2016, 2019, 2022, 23H2, and 2025. Windows Server 2012 and 2012 R2 get nothing automatic: those shops must grant the AD FS service account WriteOwner and WriteDacl on the DKM container by hand, then opt in. On a deadline day, that split is the kind of detail that decides whether Tuesday stays quiet.
The update ships an opt-out, and the opt-out is the interesting part. Setting RemediateDkmAcl to 0 stops the automatic hardening. Microsoft is blunt about what that buys:
“Opting out leaves your DKM container vulnerable. Only use this if you have a specific compatibility requirement and plan to manually harden the ACL.”
Event 1132 keeps firing either way, so the insecure state at least stays visible to whoever is watching the log.
Read as a mechanism, the registry key is a formalized admission: the hardened state may break legacy integrations, and some operators will choose a known exposure over an unknown breakage. That is why the door is propped open on purpose. It is also why the warning sits in the body of the documentation – the escape hatch is itself the vulnerability, named as such.
What changes today is mechanical. On Server 2016 and later, unhardened DKM ACLs get remediated whether or not anyone planned for it. The practical list: confirm AD FS service health after the update, watch Event 1132 on anything excluded, and treat any opt-out as a decision someone will have to defend. The July disclosure left the fix optional for three months. Today the hardened state is the default – and the only way to refuse it is an option whose own documentation leads with a warning.