Microsoft Ships AD FS Fix, But Automatic Remediation Is Months Away — Here’s How to Secure Your Keys Now

Microsoft shipped a security fix on July 14, 2026, for a dangerous elevation-of-privilege flaw in Active Directory Federation Services (AD FS) that attackers are already exploiting. But any administrator who thinks installing the patch is the end of the story is in for a surprise. The update doesn’t automatically close the vulnerability — it only starts a three-month audit period, giving organizations until October to manually lock down their federation keys. If you wait, Microsoft will do it for you, potentially breaking integrations in the process.

The Patch That Doesn’t Seal the Door

The vulnerability, tracked as CVE-2026-56155, carries a CVSS 3.1 score of 7.8 and has been rated Important by Microsoft. It resides in the Distributed Key Manager (DKM) container that AD FS uses to protect the private keys for token-signing and encryption certificates. The container’s access control list (ACL) can be excessively permissive, allowing a low-privileged user on the same server to read key material. From there, an attacker could forge tokens that appear to come from your trusted federation service, potentially escalating to domain-wide compromise.

Microsoft’s advisory KB5121391 makes clear that the company has seen active exploitation, though it hasn’t named the threat actor or described the attack chain. The Cybersecurity and Infrastructure Security Agency (CISA) added the flaw to its Known Exploited Vulnerabilities (KEV) catalog on the same day, imposing a July 28 remediation deadline for U.S. federal agencies. According to a Tenable analysis of July’s Patch Tuesday, the issue was reported to Microsoft by its own Detection and Response Team (DART).

So what does the July update actually do? It plants a detection engine inside AD FS. Roughly one minute after the AD FS service starts and every 24 hours thereafter, the system checks the DKM container’s ACL against a newly established secure baseline. It writes events to the AD FS/Admin log, summarized in the table below.

During the July phase, the update makes no changes to ACLs on its own. For Windows Server 2016 and newer, you can opt into automatic remediation by creating a registry key: set RemediateDkmAcl to 1 under HKLM\\SOFTWARE\\Microsoft\\ADFS, applied to just one server in the farm. Then restart the AD FS service or wait for the next 24-hour cycle. Windows Server 2012 and 2012 R2 require an extra manual step: first grant the AD FS service account WriteOwner and WriteDacl permissions on the DKM container, or the remediation will fail.

Your Federation House in Order

If you manage AD FS, this vulnerability is not theoretical. Active exploitation means you’re on the clock. Home users aren’t affected; this is strictly an enterprise Windows Server issue.

For IT administrators, the July update must be installed across all AD FS nodes immediately. After patching and restarting the service, check the AD FS/Admin event log for Event ID 1132. If it appears, your DKM container ACL is too broad and you have a decision to make.

Microsoft’s automated remediation strips inheritance and removes all access control entries except those for Domain Admins, Enterprise Admins, SYSTEM, and the AD FS service account. That sounds clean, but years of operational additions — backup agents, monitoring tools, delegated management accounts — may rely on the old permissions. If you choose the automated path, set the registry key, restart, and after remediation succeeds, capture the Event ID 1135 SDDL output immediately. That old ACL backup can be a lifesaver if a critical integration breaks.

Manual remediation gives you control but demands a deep understanding of who and what needs DKM access. You’ll need to audit your current ACL, identify every non-standard entry, and decide whether it can be removed or replaced with a narrower permission. This route requires careful testing, but it may be the only option if your environment has unique dependencies that the automated cleanup would erase.

For Windows Server 2012/2012 R2 shops, the extra step of granting WriteOwner/WriteDacl to the AD FS service account is non-negotiable for automation. Without it, the process will fail silently, leaving your ACL unchanged and your logs still spitting out 1132 events.

For security teams, the active-exploitation designation is a prompt for incident hunting. An insecure ACL doesn’t prove compromise, but it does mean you should dig deeper. Examine historical access to the DKM container, look for unauthorized changes to the AD FS service account or its group memberships, review certificate issuance and expiration events, and inspect AD FS audit logs for unusual token-request patterns or anomalous authentications. A stolen token-signing key can create Golden SAML-style tokens, so any sign of such activity demands immediate key rotation.

How Permissions Crept Open

The root cause is insufficient access control granularity (CWE-1220) in the DKM container’s design. Over years of AD FS operations, administrators often added permissions for legitimate purposes — backup software that needs to read the container, a script that rotates certificates, a monitoring service that checks health. Microsoft’s original guidance didn’t forbid these additions, and the service itself didn’t enforce a strict baseline. The result was a gradual expansion of access that, in many environments, went unnoticed until a vulnerability turned it into a weapon.

Microsoft’s DART likely discovered the flaw during incident investigations. The phased remediation approach — audit first, enforce later — mirrors strategies the company has used for other sensitive security improvements, like LDAP signing and channel binding. The goal is to give organizations time to adapt without breaking critical services.

What to Do Right Now

1. Patch everything. Apply the July 14 security update to all AD FS servers. Verified build thresholds include:
   - Windows Server 2016: build 14393.9339
   - Windows Server 2019: build 17763.9020
   - Windows Server 2022: build 20348.5386
   - Windows Server 2025: build 26100.33158
   Windows Server 2012 and 2012 R2 must have Extended Security Updates installed.

2. Check your logs. After patching, restart the AD FS service and examine the AD FS/Admin event log. Look for Event ID 1132. If you see it, your DKM container ACL is too broad.

3. Decide on remediation strategy.
   - Automated (opt-in): On one AD FS server, add the RemediateDkmAcl = 1 registry key. Restart AD FS or wait 24 hours. After remediation succeeds, capture the Event ID 1135 SDDL output — you may need to revert if something breaks.
   - Manual: Design your own secure ACL that matches Microsoft’s principle of least privilege while preserving any operational dependencies. This demands a deep understanding of who and what needs access.
   - For Server 2012/2012 R2: Before automated remediation, issue WriteOwner and WriteDacl rights to the AD FS service account on the DKM container. Test in a lab first.

4. Prepare for October 13. The October security update will switch Windows Server 2016 and later into Enforcement mode, automatically applying Microsoft’s secure baseline unless you explicitly opt out by setting RemediateDkmAcl to 0. The opt-out leaves detection running, with Event ID 1132 still warning you, but your keys remain vulnerable. Only choose this if a critical compatibility blocker exists and you have a documented manual hardening plan.

5. Hunt for signs of abuse. Whether or not you find an insecure ACL, investigate your AD FS environment for past tampering. Key areas: DKM container modification timestamps, AD FS service account changes, anomalous authentication events in the AD FS audit logs, and the issuance of any unexpected tokens.

The Road After October

When October 13 arrives, most organizations running modern Windows Server will find their DKM containers forcibly corrected. That’s a positive step for security posture, but it may also surface long-hidden dependencies. Expect a flurry of support calls as monitoring tools, backup jobs, and delegated administration scripts start failing.

Windows Server 2012 and 2012 R2 will not get automatic enforcement. They remain a special case, and their administrators must either complete the manual process or accept the risk. With those platforms nearing end of support, the safest path is to migrate to a supported version of Windows Server as soon as possible.

Microsoft may refine the baseline or release additional guidance if the audit window reveals widespread compatibility issues. For now, the message is clear: patch today, audit your DKM ACL, and take control before October does it for you.