DKM ACL Hardening Is Scheduled. The Evidence It Worked Is Not.

DKM ACL hardening for AD FS moves from audit to enforcement with the October 2026 update. Microsoft’s page, KB5121391, first published July 14, 2026, says that on Windows Server 2016 and later the update “will automatically remediate insecure ACLs” by October 13, 2026 unless the registry value says otherwise. Windows Server 2012 and 2012 R2 are different: enforcement auto-remediation does not apply, and the work is manual.

That is a schedule. It is not evidence. This note is about what proves the ACL ended up in the expected state, who can read that proof, and how long it exists.

What the DKM ACL Hardening Schedule Actually Promises

AD FS relies on the Distributed Key Manager container to store the symmetric keys that protect the private keys of its token-signing and token-encryption certificates. Microsoft’s stated risk: 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. The page frames this as an elevation of privilege, CVE-2026-56155. It does not report exploitation, and neither does this note. The control sits in the governance layer of modern infrastructure architecture: state declared by a vendor, held by something else.

The mechanics, as the page documents them:

• Audit, from the July 14 update. Detection runs one minute after the AD FS service starts, then every 24 hours. No changes are made to the ACL. A mismatch logs event 1132.
• Opt-in remediation. Set RemediateDkmAcl (DWORD) to 1 under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ADFS on any one AD FS server in the farm. Remediation runs at the next detection cycle, or on a service restart.
• Enforcement, from the October 2026 update. Remediation “runs by default without requiring the registry key,” equivalent to RemediateDkmAcl = 1. Setting the value to 0 opts out, and the page is blunt that opting out “leaves your DKM container vulnerable.”

The page also says further hardening will follow in future updates. Microsoft published the dates in July, so there is no confirmation lag to manage; Patch Visibility Debt covers the opposite problem, where confirmation lags the event. An announced date does not establish that the October update is deployed everywhere, or what the ACL looks like afterward. That is what the announcement leaves open.

The Closure Signal Is an Update. The State Is One AD Object.

Analysis, mine and not Microsoft’s: in most change records the closure signal for this item will read “October update installed.” The Architecture of Premature Closure names that shape: a closure signal fires on execution, not on the verified state it was meant to represent. DKM ACL hardening is one more instance of it, not a new pattern.

What makes the instance specific is where the state lives. The ACL is not on an AD FS server. Every event the page defines carries a single “Container DN,” and the page tells you to “Ensure the AD FS service account has access to the DKM group container in Active Directory.” AD FS servers run the detection and one of them performs the change, but the thing changed is a permission on an Active Directory object.

In many organizations that splits ownership: the AD team owns the container’s ACL and the AD FS team owns the service and the event log. Your actual owners have to be identified, not assumed. Remediation is an AD FS service action that rewrites a permission the AD team may believe is theirs, and the evidence of it lands in a log the AD team may never read. Who is accountable for the declared state of that ACL is the question configuration drift ownership addresses in general; DKM supplies a specific container to ask it about, and the governance and drift stage of the Modern Infrastructure learning path maps where that question sits.

What Each Event Proves, and What It Cannot

All five DKM ACL hardening events are written to the AD FS/Admin log on the AD FS server that logged them. What each one establishes is narrower than the label suggests.

Event	Proves	Cannot prove
1132 (Warning)	At check time the ACL did not match the expected secure state. Carries the container DN, an inheritance flag, and the current ACL as SDDL.	Who changed it, or that anyone reviewed it. In audit mode, nothing was changed.
1133 (Information)	At check time the ACL matched the expected state. Carries only the container DN.	That remediation ever ran, or that the previous ACL was preserved.
1134 (Error)	The detection task failed, for example on LDAP connectivity.	Anything about the ACL, in either direction.
1135 (Information)	Remediation succeeded and the previous ACL is recorded as SDDL.	That the SDDL still exists tomorrow.
1136 (Error)	Remediation was attempted and failed. Carries the current SDDL and the exception. The service retries within 24 hours.	That the failure is resolved. The page points to manual hardening with ADSI Edit or PowerShell if it persists.

The row that matters operationally is 1135. It records the previous ACL in SDDL as part of the success event, so its retention is the operational risk: Microsoft’s own note says that event logs can roll over due to size limits and that an overwritten event means the previous SDDL “will be permanently lost.” The page’s recommendation is to save the message immediately on the AD FS server, using Get-WinEvent -FilterHashtable @{LogName='AD FS/Admin'; Id=1135} -MaxEvents 1 and writing $event.Message to a file. Microsoft frames this as a recommended precaution, not a requirement. Treat it as the change evidence.

A caution on the page itself. As of October 10, its sample commands carry transcription defects: the property name in the 2012 steps is cut off after “CertificateSharingContaine,” the save command’s output string is missing its closing quote, and the restore block mixes straight and curly quotes. This note describes the sequence; it is not a runbook. Copy from Microsoft’s page, lint, and test in a lab before running anything.

One inference, labeled as such: the 1135 text notes that auto-remediation will not run again while the ACL matches the baseline. If the ACL drifts later and remediation runs again, a second 1135 would record the drifted ACL as “previous.” Keep the first one.

The Server 2012 and 2012 R2 Path

For these platforms DKM ACL hardening is a manual sequence, per the page, run on any one AD FS server in the farm before the registry value is enabled: identify the DKM container DN, identify the AD FS service account, and grant that account explicit Allow ACEs for WriteOwner and WriteDacl on the container. Then set RemediateDkmAcl to 1, creating the ADFS key first if it is absent. Skip the grant and the page says remediation attempts will fail, which would surface as event 1136, retried every 24 hours. Microsoft’s KB5099445, the July 14 Windows Server 2012 ESU monthly rollup, carries the same DKM item: detection plus an opt-in remediation mechanism. The same page gives October 13, 2026 as the final date for Windows Server 2012 ESUs. That date is stated for Server 2012 on that page, and this note does not extend it to 2012 R2. Analysis: for a 2012 farm, the manual path and the end of the ESU stream share a date.

For Server 2012 and 2012 R2, the October enforcement mode does not automatically enable remediation. Administrators must follow the platform-specific procedure: grant the required permissions to the AD FS service account, then explicitly opt in to remediation. The page does not describe how a farm containing both generations behaves, and this note makes no claim about it. Analysis: that is the case where “update installed” is most reliably true and the ACL is most likely unchanged. These are ESU platforms; Compatibility Is Not The Same Thing As Support is the argument that “still receives updates” and “still has an owner” are separate facts.

What the Hardened ACL Removes

After DKM ACL hardening completes, per the page, only these principals have access to the container:

Principal	Access rights
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 disabled and all inherited ACEs are discarded. Any other explicit Allow ACE not in that list is removed.

The page does not say who might be on the “other” side of that line. Analysis: any non-standard principal on the container, whether older service accounts, delegated groups or third-party tooling, loses access without the page naming it, and the inventory of who they were is the SDDL in event 1132 or in the previous-ACL field of 1135. If neither was captured, nobody can answer the question afterward.

A second inference, labeled the same way: the page describes tightening access going forward. It makes no statement about key material that was readable before the change, and this note makes none either. Whether that question applies to your farm is a review for you to run; Rotating Credentials Is Not Revoking Them covers why rotating and revoking are different operations.

Before DKM ACL Hardening Enforces

Additional Resources

View 1 more resource ↓

>_ External Reference

July 14, 2026 — KB5099445 (Monthly Rollup), Windows Server 2012 ESU

the 2012 ESU rollup carrying the DKM detection and opt-in item.