CVE-2026-56155 (CVSS 7.8): ADFS DKM Zero-Day Hands Attackers Your Identity Signing Keys — CISA Deadline Is July 28

If your enterprise uses Active Directory Federation Services (AD FS) — and statistically, most medium-to-large Indian enterprises do — there is an actively exploited zero-day sitting inside your identity infrastructure right now. CVE-2026-56155, patched by Microsoft on July 14, 2026, allows an attacker with a low-privilege foothold anywhere on your network to silently steal the cryptographic keys that sign every authentication token your federation service issues. With those keys in hand, they can forge identities. Not just one identity. Any identity. For any application trusting your AD FS server — Microsoft 365, your VPN, your cloud workloads, every internal app, and every SaaS platform — without a password, without MFA, and without triggering your usual auth alarms.

CISA added this flaw to the Known Exploited Vulnerabilities (KEV) Catalog on July 14, 2026 and set a federal remediation deadline of July 28, 2026 — four days from today. If you haven’t patched yet, the clock is not ticking. It has already run out.

What Is AD FS — and Why Does It Matter to Every Enterprise?

Active Directory Federation Services is Microsoft’s on-premises identity broker. Organisations that haven’t fully migrated to Microsoft Entra ID (formerly Azure AD) still rely on AD FS to issue Security Assertion Markup Language (SAML) tokens and WS-Federation assertions, allowing users to authenticate once and access dozens — sometimes hundreds — of downstream applications.

In the Indian enterprise context, AD FS remains deeply embedded in banking, government-adjacent services, manufacturing, and any organisation still running a hybrid Active Directory environment. Many of these deployments are years old, configured once by an integrator, and never audited since. That’s exactly the kind of environment where CVE-2026-56155 thrives.

The token-signing certificate is the crown jewel of any AD FS deployment. It is the cryptographic proof that says “this authentication assertion came from a legitimate source.” When a relying party — an application trusting your federation server — receives a SAML token, it validates the signature against the public half of this certificate. That’s it. There is no other verification layer. If the signature validates, access is granted.

Technical Breakdown: The DKM Container ACL Flaw

To understand CVE-2026-56155, you need to understand the Distributed Key Manager (DKM) container. AD FS does not store token-signing certificate private keys on disk in plaintext. Instead, it encrypts them using symmetric keys stored in a dedicated Active Directory container — the DKM container. Think of it as a locked vault inside your AD directory, specifically designed so that even local access to the AD FS server doesn’t directly expose the certificate’s private key.

The intended ACL for the DKM container is strict: access should be limited to Domain Admins, Enterprise Admins, SYSTEM, and the AD FS service account. Microsoft’s secure baseline explicitly disables ACL inheritance on this container to prevent any bleed-through from broader directory permissions.

The problem? Many real-world deployments inherit permissions from parent containers. Legacy service accounts, backup agents, migration identities, and monitoring tools often accumulate read rights through inherited ACLs that nobody ever cleaned up. When a low-privilege attacker — say, a compromised helpdesk account or a phished workstation user — can enumerate AD objects with Get-ADObject, they can check whether their identity has read access to the DKM container. If they do, they can retrieve the encrypted key material and decrypt it to recover the actual token-signing certificate private key.

The exploitation sequence, documented by Penligent AI’s research team, follows this pattern:

1. Initial foothold — A low-privilege account is obtained through phishing, credential stuffing, or lateral movement.
2. Federation discovery — The attacker queries Get-AdfsProperties to locate the DKM container’s distinguished name in Active Directory.
3. ACL evaluation — The attacker checks whether their current identity can read the DKM object (Event ID 4662 in the Security log records this access).
4. Key-material recovery — The encrypted symmetric key is read from the DKM container and the signing certificate’s private key is decrypted.
5. Golden SAML — The attacker uses the private key to sign arbitrary SAML assertions, forging tokens for any user and any relying party.

Microsoft classifies this as CWE-1220: Insufficient Granularity of Access Control. The vulnerability isn’t in the cryptography — the DKM design is sound in principle. The failure is in access-control enforcement in the real-world deployments that Microsoft’s own AD FS installer often leaves with inherited ACLs intact.

Golden SAML: From One Key to Every Door

The downstream impact is what elevates this beyond a typical EoP bug. Once an attacker possesses the token-signing private key, they can execute Golden SAML attacks — classified under MITRE ATT&CK T1606.002 (Forge Web Credentials: SAML Tokens).

A forged SAML token created with a valid signing key is cryptographically indistinguishable from a legitimate token. The relying party — Microsoft 365, your corporate VPN, your cloud ERPs, your partner-facing portals — validates the signature, finds it valid, and grants access. There is no password check. MFA is not invoked. Session logs will show a successful authentication event.

This is not a theoretical attack. It is the same technique that NOBELIUM (the SolarWinds attackers) used in 2020 to silently access US government email environments for months without triggering alerts. They had compromised the token-signing key through the SolarWinds supply-chain breach, then forged SAML tokens at will. CVE-2026-56155 provides a direct path to the same capability — but through a misconfigured ACL that exists in countless AD FS deployments worldwide, not a sophisticated supply-chain implant.

The persistence implication is critical: patching does not undo a theft that has already occurred. If an attacker read your DKM container before you applied the July 14 update, they still hold your signing key. The patch closes the door; it does not change the lock.

India-Specific Risk Context

Indian enterprises — particularly those in BFSI, IT/ITES, pharma, and government-adjacent sectors — have a specific exposure profile that warrants immediate attention:

Sector	Typical AD FS Exposure	Risk Factor
BFSI / NBFCs	Core banking integration via SAML SSO	Critical
IT/ITES Outsourcers	Multi-tenant AD FS for client SAML federation	Critical
Manufacturing / Pharma	Hybrid AD with legacy on-prem AD FS	High
Government / PSUs	Windows Server 2016-era AD FS, rarely updated	Critical

The combination of old AD FS deployments, complex inherited ACL hierarchies from years of organisational changes, and limited AD security auditing makes this a high-priority issue for Indian IT teams. CERT-In’s existing guidance on patching critical CVEs within 6 hours of disclosure also applies here — though as I wrote about in the DigiCert signing certificate breach, the identity layer is increasingly the target of choice for sophisticated threat actors.

What You Should Do Right Now

Here is the prioritised action list, in the order I would execute it if I were managing your AD FS environment today:

1. Patch immediately. Deploy the July 14, 2026 cumulative update to all Windows Server instances running AD FS. On Windows Server 2016+, the patch also ships the DKM ACL remediation engine — but the fix is not automatic.
2. Enable the registry remediation key (Server 2016+). After patching, set HKLM\SOFTWARE\Microsoft\ADFS\RemediateDkmAcl = 1 (DWORD value). AD FS will audit and correct the DKM container ACL. Watch for Event ID 1135 (successful remediation) and Event ID 1133 (healthy state) in the AD FS Admin event log. Microsoft will enforce this automatically in October 2026 — but waiting 3 months when exploitation is active is not an option.
3. Hunt for historical DKM access before you patch. Query your Security event log for Event ID 4662 (object-access audit) on the DKM container’s distinguished name. Any unexpected identity reading that object is a critical indicator of compromise. If you don’t have object-level auditing enabled on your AD FS servers, enabling it now and reviewing what you find should be your immediate next step.
4. Review the DKM container ACL manually. Run Get-Acl "AD:\CN=ADFS,CN=Microsoft,CN=Program Data,DC=yourdomain,DC=com" and compare the Allow list against the expected principals: Domain Admins, Enterprise Admins, SYSTEM, and the AD FS service account. Any extras need to be removed — not just flagged.
5. If compromise cannot be ruled out, rotate immediately. Follow Microsoft’s two-certificate rotation procedure: generate a new token-signing certificate, add it as a secondary, wait for AD FS to promote it, then remove the compromised certificate and update all relying parties (Microsoft Entra, SAML applications, partner federations). This is operationally disruptive, but a stolen signing key that remains trusted is worse.
6. Review all AD FS relying party trust configurations. Correlate token-issuance events (Event ID 1200) with access logs from Microsoft 365, your VPN gateway, and cloud applications. Look for authentications for privileged accounts (Global Admins, Service Accounts) from unexpected locations or at unusual hours.
7. Enable AMSI integration on AD FS servers. As a secondary mitigation, Microsoft recommends enabling AMSI (Antimalware Scan Interface) on AD FS servers and setting Request Body Scan mode to Full. This won’t prevent key theft, but it adds a detection layer.

From a zero-trust perspective, CVE-2026-56155 is a stark reminder that identity infrastructure is not exempt from the principle of least-privilege. The DKM container should have had an inheritance-disabled, explicitly scoped ACL from day one. If your AD FS deployment was stood up by an integrator and never audited, the same inherited-permission problem almost certainly exists in other places in your directory.

Frequently Asked Questions

My organisation uses Microsoft Entra ID (Azure AD), not on-premises AD FS. Am I affected?

No. CVE-2026-56155 affects on-premises AD FS deployments only. Microsoft Entra ID uses a different, cloud-managed key infrastructure that is not exposed through the DKM container mechanism. However, if you run a hybrid environment where Entra ID syncs with on-premises AD and you also maintain AD FS for legacy relying parties, those AD FS servers are still in scope.

The CVSS score is only 7.8. How is this a critical-priority item?

CVSS scores do not capture business impact. A 7.8-scored local privilege escalation that grants access to the token-signing key for your identity provider is categorically more dangerous than a 9.8-scored RCE in an isolated system. The blast radius here is every application in your enterprise that trusts your AD FS server — potentially hundreds of systems. CISA’s decision to add it to the KEV catalog with a mandatory federal deadline makes the operational priority clear regardless of the numerical score.

We patched on July 14. Are we safe?

Patching eliminates the ACL misconfiguration pathway going forward, but it does not invalidate a private key that may have already been copied. You must also: (a) enable the registry remediation key to correct the DKM ACL, (b) hunt for historical DKM read events (Event ID 4662) to determine whether access occurred pre-patch, and (c) rotate the token-signing certificate if any anomalies are found. Patch + remediate + investigate is the complete response — patching alone is not sufficient.

Is there a public proof-of-concept exploit available?

As of July 24, 2026, Microsoft has not published a complete exploitation procedure, and no CVE-specific proof-of-concept has appeared in public repositories. However, exploitation is confirmed by CISA’s KEV listing and Microsoft DART’s incident investigations. The absence of a public PoC does not mean the technique is unavailable to determined attackers — it means you should not wait for a PoC to appear before acting.

---

CVE-2026-56155 is not a story about a CVSS number. It is a story about the fragility of the one system that every other system trusts — your identity provider. A forged SAML token looks identical to a real one. Your firewall won’t catch it. Your endpoint agent won’t flag it. Your SIEM won’t alert on it. The only defences are a correctly scoped ACL on the DKM container, a clean token-signing certificate, and the awareness that your identity infrastructure needs to be treated with the same rigour as your perimeter.

With the federal deadline landing on July 28, there is no rationale for further delay. If you need help auditing your AD FS ACLs, hunting for pre-patch compromise indicators, or building a zero-trust roadmap that removes reliance on federated identity as a single point of failure, reach out for a security assessment. The conversation is free. A Golden SAML attack is not.