On July 14, 2026, Microsoft released a security update that quietly starts auditing access controls on a sensitive Active Directory Federation Services container. For the next three months, Windows Server administrators will see warnings if the Distributed Key Manager (DKM) container—which holds the keys to the kingdom for token-signing certificates—is too open. Then, on October 13, 2026, that audit turns into automatic enforcement, locking down permissions whether you’re ready or not.

What the July Update Actually Changes

The July update, delivered through KB5121391, addresses an elevation-of-privilege vulnerability tracked as CVE-2026-56155. It introduces a new background task in the AD FS service that inspects the ACL on the DKM container one minute after service startup and every 24 hours thereafter. No changes are made to the ACL during this audit phase.

Instead, the service logs one of four event IDs to the AD FS/Admin log:

  • 1132 (Warning): The DKM container ACL does not match Microsoft’s new secure baseline.
  • 1133 (Information): The ACL is already compliant.
  • 1134 (Error): The detection task failed, possibly due to LDAP connectivity issues.
  • 1135 (Information): Logged after successful manual or opt-in remediation, containing the previous ACL in SDDL format.

Administrators can opt in to remediation now by setting a registry key—HKLM\SOFTWARE\Microsoft\ADFS\RemediateDkmAcl to DWORD 1—on any one AD FS server. This triggers an automatic ACL reset during the next detection cycle, or sooner if the AD FS service is restarted.

When remediation runs, it disables inheritance on the container, discards all inherited access-control entries, and removes any explicit Allow permissions except those for Domain Admins, Enterprise Admins, SYSTEM, and the AD FS service account. The service account itself retains Read, Write, Create Child, Write Owner, and Delete Tree rights—nothing more.

The impact is obvious: any custom delegations, service accounts, or automation that relied on broader access to the DKM container will break.

For Windows Server 2016, 2019, 2022, version 23H2, and 2025, the October 2026 security update will enable this remediation by default. An admin can explicitly opt out by setting RemediateDkmAcl to 0, but Microsoft warns that doing so leaves the vulnerable configuration in place, and the 1132 warnings will persist.

Windows Server 2012 and 2012 R2 follow a different path. Automatic enforcement won’t touch them in October. Instead, administrators must first grant the AD FS service account WriteOwner and WriteDacl permissions on the DKM container—using a provided PowerShell script—before they can set RemediateDkmAcl=1. Without that extra step, the remediation attempt will fail.

What It Means for You

This isn’t just a routine security update. It’s a fundamental permission change for a critical authentication component. Here’s who’s affected and how.

Enterprise AD FS administrators: If you run a federation farm, start by installing the July update on every server. Look for event 1132. Don’t ignore it. It tells you the current ACL is too broad. You need to understand why: check the current ACL (you can pull it from the event’s SDDL data or use Active Directory tools). Identify any non-standard entries. Are there monitoring tools, backup accounts, or delegated administrators that require access to the DKM container? If so, you need to redesign those dependencies before October because they will lose access.

Smaller shops and IT generalists: You might not know what your AD FS DKM ACL looks like. This update forces the issue. The good news: if you’ve never customized it, the remediation will likely be painless. Just set the registry key to 1, restart the service, confirm event 1135, and move on. But if someone in the past opened up permissions for easier management, you’ll want to test now.

Compliance and security teams: The audit event 1132 creates a paper trail of insecure configurations. Use it to track which servers are noncompliant and drive remediation. Save the event 1135 SDDL as a rollback safety net—event logs can roll over, and if you later discover a problem, that SDDL is your only way to restore the original permissions without rebuilding them from scratch.

Developers and third-party ISVs: If you have products that interact with AD FS’s DKM container directly, validate them against the new baseline now. The reduced permissions are likely to break any tool that expects to read or modify the container without running as one of the four permitted principals.

How We Got Here

The DKM container has long been an obscure but essential part of AD FS. When a federation server generates token-signing and token-encryption certificates, the private keys don’t reside in a local certificate store—they’re wrapped with symmetric keys stored in the DKM container in Active Directory. This design allows multiple AD FS servers in a farm to share keys securely.

But if an attacker gains even read access to that container, they can extract the symmetric keys and decrypt the private keys for token signing. With those keys, an attacker can forge tokens that impersonate any user in the organization—a devastating elevation-of-privilege scenario.

Microsoft disclosed the underlying vulnerability as CVE-2026-56155, but didn’t release an instant patch that changes the ACL. Instead, the company is following a phased hardening approach: audit, then enforce. This is a pattern Microsoft has used for other security changes (like LDAP channel binding and signing) to avoid breaking critical services without warning.

The July 2026 update is the first broad notification to admins that the existing, often over-permissive, ACL is no longer acceptable. By October, the company will enforce the stringent baseline unless admins deliberately postpone it.

What to Do Now

Step 1: Install the July 14, 2026 security update on all AD FS servers. This is a prerequisite. The update does not change any ACLs automatically, so it’s safe to deploy widely.

Step 2: Monitor the AD FS/Admin event log for event 1132. Use your existing server monitoring tools, or manually check a few servers. The event includes the container DN and the current ACL in SDDL format. Examine that SDDL: are there permissions beyond Domain Admins, Enterprise Admins, SYSTEM, and the AD FS service account? Document them.

Step 3: If your farm runs Windows Server 2016 or later, plan a test remediation. Pick a non-production server or a maintenance window. Set RemediateDkmAcl = 1 in HKLM\SOFTWARE\Microsoft\ADFS (create the ADFS key if needed). Restart the AD FS service. Check for event 1135 to confirm successful hardening. Then test all federation functions: user logons, application integration, claims transformation, and any custom scripts that touch AD FS configuration.

Step 4: Immediately save the event 1135 data. Microsoft’s guidance provides PowerShell to export the previous SDDL to a file. This is your rollback plan if something critical breaks later. Don’t count on the event log retaining it.

Step 5: If you have Windows Server 2012 or 2012 R2, run the extra PowerShell commands from Microsoft to grant WriteOwner and WriteDacl to the AD FS service account on the DKM container. Then set RemediateDkmAcl=1. These servers won’t auto-enforce in October, but you should manually remediate to close the vulnerability.

Step 6: Prepare for October 13. If you’ve tested successfully, you can simply leave the registry key at 1, or remove it—the October update will perform the same remediation automatically. If you’ve identified a legitimate need to delay, plan to set RemediateDkmAcl=0 before the October patch is installed, but understand you’re accepting the risk and the 1132 warnings won’t go away. More importantly, plan to address the underlying compatibility issue so you can eventually harden the container.

Step 7: Communicate with your team. This change touches identity infrastructure. Make sure all stakeholders—security, operations, application owners—know that DKM permissions are tightening.

Outlook

The October enforcement is just the next milestone, not the end. Microsoft’s advisory hints at “further hardening” in future updates. AD FS, while still critical, is seeing fewer feature additions as cloud identity gains momentum, but security tightening around legacy components will likely continue. Administrators who build a practice of proactively testing these security baselines will face fewer fire drills. For now, the message is clear: use the three-month audit window wisely. Check your logs, test the changes, and save your rollback data. October 13 will arrive faster than you think.