Golden SAML Defense: AD FS Signing Key Risks and October 2026 DKM ACL Changes

The hardening protects the key going forward. It does nothing about a key that was already stolen. AD FS administrators need to treat those as two separate problems with two separate fixes.

Golden SAML in one paragraph​

Golden SAML is an attack where someone forges a SAML response and signs it with a stolen AD FS token-signing private key. Because the signature is genuine, any relying party that trusts the identity provider accepts the token as authentic. The attacker can then impersonate any user in the federated environment.

Incident response firm Sygnia, in its July 2021 analysis, says CyberArk first described the technique in 2017. The SolarWinds supply chain compromise was the first known use of it in the wild. In that campaign, the attackers used their Active Directory privileges to compromise the SAML signing certificate and then minted valid tokens for hosted services such as email.

Summary: the attacker isn't faking a login. They're faking the identity provider's signature, and relying parties are built to trust that signature.

How the attack chain works​

Sygnia compares the normal on-premises AD FS sign-in with the forged one.

Legitimate flow:

1. A user tries to open a service, such as Office 365 or AWS.
2. The service redirects the user to AD FS.
3. AD FS authenticates the user according to domain policy, which may include MFA.
4. AD FS returns a signed SAML response.
5. The user presents that response to the service and gets access.

Golden SAML flow:

1. The attacker first gets administrative privileges on the AD FS server, usually through lateral movement and privilege escalation.
2. The attacker extracts the token-signing certificate and its private key.
3. The attacker skips AD FS authentication entirely, signs a forged SAML response with the stolen key, and presents it to the target service.

The MFA "bypass" happens because the forged flow never reaches the authentication step. MFA isn't broken in general. It just never gets asked. Sygnia also points out that once the attacker has the key, they can forge tokens from anywhere, without any further access to the victim's network.

Where the DKM container fits, and CVE-2026-56155​

The private signing key doesn't sit unprotected. 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 weakness is in who can read that container: 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 tracks this as an elevation-of-privilege issue. Its KB5121391 documentation says the hardening addresses an elevation of privilege (EOP) that can arise from the vulnerability documented in CVE-2026-56155. Earlier WindowsForum coverage reported that the flaw carries a CVSS 3.1 score of 7.8 and is rated Important. Per that same coverage, Microsoft describes it as exploitable by an authorized local attacker with low privileges.

So this is not an anonymous, internet-facing hole. As one third-party SMB checklist from ITECS puts it, the flaw matters most after an initial breach: it is not usually the way in, it is the way an intruder converts a foothold into total, durable control of your federated identity.

Summary: Golden SAML is what an attacker does with a stolen signing key. CVE-2026-56155 is one way they could get that key: a loose ACL on the container that protects it.

The hardening timeline: audit in July, enforcement now​

Microsoft's KB says that after installing, the AD FS service will audit the DKM container ACL each time the service starts and every 24 hours thereafter. Microsoft says enforcement starting with the October update behaves as if RemediateDkmAcl were set to 1, even if the value isn't present. The KB also warns that further hardening will follow in future updates, so October may not be the last change.

KB5121391 applies to Windows Server 2012 and 2012 R2 with Extended Security Updates, Windows Server 2016, Windows Server 2019, Windows Server 2022, Windows Server version 23H2, and Windows Server 2025.

What the ACL looks like after remediation​

According to Microsoft, remediation leaves only four principals with access:

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

Inheritance is disabled, inherited entries are discarded, and every other explicit Allow entry is removed. If a backup agent, monitoring tool or delegated admin group had read access to the container, that access is gone after remediation.

The event IDs to watch​

Everything is logged in the AD FS/Admin event log:

• 1132 (Warning): the ACL doesn't match the expected secure state.
• 1133 (Information): the ACL is in the secure state, and nothing needs to be done.
• 1134 (Error): the detection task failed, for example because of an LDAP connectivity problem.
• 1135 (Information): remediation succeeded. The event includes the previous ACL in SDDL format.
• 1136 (Error): remediation failed. The service retries on the next cycle, within 24 hours.

As earlier WindowsForum coverage suggested, the practical routine is to patch every AD FS node, restart or cycle the service during a controlled window, and review Events 1132 through 1136 across the farm.

Practical steps by platform​

Windows Server 2016 and later​

1. Install the October 2026 update, or the July 14, 2026 update at minimum, on every AD FS server.
2. Restart the AD FS service, or wait up to 24 hours for the next detection cycle.
3. Look for Event 1135 (success) or 1133 (already secure).
4. Save the SDDL from Event 1135 right away. Microsoft warns that event logs can roll over. If the event is overwritten, the record of your previous ACL is permanently lost, and you'd need it to roll back in a compatibility emergency.
5. If you see Event 1136, find out what's blocking remediation before the retry cycle hides the problem.

To harden before enforcement, or to confirm the setting explicitly, Microsoft documents a DWORD named RemediateDkmAcl under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ADFS, set to 1 on any one AD FS server in the farm.

Windows Server 2012 and 2012 R2 (ESU)​

Admins are most likely to miss this part. 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. Only then can you set RemediateDkmAcl to 1. Microsoft says remediation attempts will otherwise fail.

The KB includes the PowerShell for finding the container's distinguished name and the service account and for granting those rights. Run it exactly as Microsoft publishes it rather than retyping it from memory.

If you're still running AD FS on 2012-era servers, October changes nothing for you unless you act. The audit warnings will keep coming, and the ACL will stay as it is.

Opting out (carefully)​

Setting the same DWORD to 0 turns off automatic remediation. The opt-out leaves detection enabled, so Event ID 1132 can continue warning that the ACL is insecure. Microsoft says plainly that opting out leaves the DKM container vulnerable, and it should be used only for a specific compatibility requirement backed by a manual hardening plan.

Summary: on 2016 and later, verify the result and keep the old SDDL. On 2012 and 2012 R2, grant the permissions and opt in manually. Use opt-out only as a temporary exception, never as a way to make the problem go away.

What the October hardening can't fix​

Tightening the ACL controls who can read the key material from now on. It doesn't revoke anything. If an attacker copied your token-signing private key before you hardened the container, through this ACL weakness or through admin access to the AD FS server, they can still forge tokens with it.

Sygnia says this kind of access persists until the existing AD FS private key is invalidated and replaced. It calls that a difficult process that requires altering or terminating connectivity to all federated systems and re-creating them. Neither Microsoft's KB nor any other source here says that remediating the ACL removes an attacker or makes a stolen key unusable.

So a clean Event 1135 tells you about your ACL, not about past compromise. The ACL problem goes to your patching team. A suspected stolen signing key goes to incident response, and probably means rotating the certificate and rebuilding federation trusts.

Hunting for forged tokens​

If you have reason to think you've been compromised, Sygnia's detection guidance for on-premises AD FS still holds up:

• Correlate logins. A legitimate sign-in leaves AD FS Security log events 1202 (a credential was validated) and 1200 (a token was issued), plus a Kerberos service-ticket request (4769) on a domain controller with the AD FS server as the source. A Golden SAML sign-in often leaves only the login record at the service provider. Look for SAML logins that have no matching 1200, 1202 and 4769 events.
• Allow for the exception. Sygnia notes that an attacker can generate a Kerberos ticket request and leave a 4769 event behind. Missing AD FS events are the stronger signal. The absence of all three is not a universal rule.
• Look for export traces. Event 1007 in the CertificateServicesClient-Lifecycle-System log, PowerShell script-block logging of Export-PfxCertificate, command-line use of certutil -exportPFX, and evidence of tools such as Mimikatz or ADFSDump can all point to key theft.
• Watch for rogue trusts. An attacker with AD FS admin rights may add a new trusted issuer instead of stealing the key. Sygnia recommends checking configuration-change events 307 and 510 for unfamiliar issuance authorities.

Sygnia limits this analysis to a standard on-premises AD FS setup. Hybrid deployments and those with multiple identity providers need each identity-provider/service-provider pair checked separately.

Bottom line​

The October enforcement fixes a real weakness in how AD FS protects its most important key. On Windows Server 2016 and later, it mostly happens on its own. Check for Event 1135 and save the old ACL. On 2012 and 2012 R2 it doesn't happen unless you do it manually. In every case, a hardened ACL is not evidence that your signing key is safe. If there's any chance it was taken, the only fix is to replace the key and rebuild your federation trusts.