Identity providers exist to solve a concrete problem. Without them, every application manages its own authentication — separate credentials, separate policies, and separate security controls for each service a user needs to reach. Federated identity replaces that fragmentation with delegation: authenticate once at a central identity provider, carry that credential to every application that trusts it. Single sign-on reduces password sprawl, enforces consistent policies like MFA from a single control point, and removes the friction of repeated logins. The tradeoff is deliberate: trust becomes concentrated.

SAML is the protocol that makes this federation work across heterogeneous environments. When a user authenticates, the identity provider produces a SAML assertion — a cryptographically signed document stating who the user is and what they’re authorized to do. Each downstream application validates the signature and grants access without re-prompting the user. The signature comes from the identity provider’s private key, and every relying application trusts that key unconditionally. This is what makes SSO function at enterprise scale. It is also what makes the Golden SAML attack so consequential: whoever can sign assertions with that key can manufacture identity for any user, across every federated application, without a password, without triggering MFA, and without leaving a trace in the authentication logs.

One Key Signs Everything — That Is the Entire Trust Model

Modern enterprises don’t verify identity at every door. They verify it once, at a central identity provider, and then issue a credential that other applications accept as proof. This consolidation — single sign-on — is the correct architectural decision. It reduces password sprawl, enables consistent MFA enforcement, and gives security teams a single control point instead of dozens. Every major enterprise identity strategy of the past fifteen years has pointed toward it.

The mechanism that makes SSO work across heterogeneous application environments is the SAML assertion: a structured, cryptographically signed XML document in which the identity provider states who the user is and what they’re permitted to do. The user authenticates to the IdP once; the IdP produces an assertion; the assertion is presented to each application; the application validates the signature and creates a session. The user never re-enters credentials for each service.

The assertion’s authority comes entirely from one thing: the identity provider’s private signing key. Every application that trusts the IdP is pre-configured with the corresponding public certificate. When an assertion arrives, the application validates that it was signed by the expected key. If the signature is valid, the user gets access. The content of the assertion — who the user is, what groups they belong to, what roles they hold — is accepted without further verification.

The entire security of this model rests on one operational assumption: only the identity provider ever possesses that private key. Violate that assumption and the protocol doesn’t fail gracefully. Every application that trusts the key remains fully functional — accepting assertions, granting sessions, authorizing actions — while an attacker operates it from outside.

The Default Installation Path Left the Key on the Server

Active Directory Federation Services was Microsoft’s on-premises SAML identity provider for over a decade, and for most of that period it was the default choice for enterprises federating on-premises Active Directory to cloud and SaaS applications. Microsoft formally deprecated ADFS in 2024 — Windows Server 2025 is the last version to include it — and has been pushing organizations to migrate to cloud-native Entra ID authentication. Many have. But the installed base remains substantial, ADFS remains active in a significant share of hybrid environments, and the signing key management failure it exposed is not unique to ADFS. Any on-premises or customer-managed SAML identity provider faces the same fundamental question: where does the private signing key live, and who can reach it? The default implementation of ADFS illustrates the answer most organizations arrived at. It installs the private token-signing certificate on the same server running the identity provider. This is a direct consequence of how ADFS is designed to work: it needs access to the signing key at runtime to produce signed assertions. The deployment documentation walks through a path that puts that key in the Windows certificate store on the ADFS server itself.

A more sophisticated implementation uses a hardware security module. With an HSM, the key never leaves the dedicated hardware. Signing operations happen inside the HSM, and the ADFS server requests signatures from it rather than accessing raw key material. This architecture makes direct key extraction significantly harder. It is also operationally complex to get right — HSM integration with ADFS involves additional infrastructure, configuration dependencies, and failure scenarios that most organizations aren’t prepared to manage on first deployment. The result, in most environments, is the default: the key on the server, accessible to anyone who reaches it with sufficient privileges.

The extraction paths are well-documented and well-tooled. The most common: the ADFS configuration database contains the encrypted token-signing certificate in its ServiceSettings table. An attacker with ADFS service account privileges or domain admin rights extracts that blob and separately retrieves the Distributed Key Manager master key — stored as a thumbnailPhoto attribute on an AD contact object in a container created when the ADFS farm was first configured. That DKM container requires only read access to query; it doesn’t require ADFS service account context. The encrypted certificate and the DKM key together reconstruct the private signing key. Mandiant’s ADFSDump tool and Nestori Syynimaa’s AADInternals suite both automate this. A second path: NOBELIUM deployed FoggyWeb in 2021, a memory-resident DLL backdoor installed directly on ADFS servers that continuously monitored and exfiltrated token-signing certificates over time — not a one-time key theft but persistent exfiltration infrastructure. A third: direct extraction from the Windows certificate store on a fully compromised ADFS host. Windows Event ID 4662 fires when the DKM container is accessed; Event ID 1007 fires on certificate export. Both require deliberate audit configuration to surface.

In nearly every enterprise that deployed ADFS without specifically hardening key storage, one or more of these paths is viable for any attacker who has reached domain admin or ADFS service account context — access levels achievable in most breach scenarios given sufficient dwell time. The typical response when this is raised as a finding in an identity security assessment: we followed the standard deployment model, and yes, the key lives on the server. The awareness is usually there. The remediation isn’t, until something happens.

Whoever Has the Key Can Be Anyone, with Access to Everything

A Golden SAML assertion isn’t a stolen credential — it’s a manufactured one. Once an attacker has the signing key, they construct SAML assertions from scratch, selecting every field: the target user identity, the group memberships, the role attributes, the validity window, the audience. They sign the assertion with the stolen key. The resulting signature is cryptographically indistinguishable from one the identity provider produced legitimately.

The service provider receives the assertion, validates the signature using the public certificate it already trusts, confirms the audience and timestamp, and creates a session. This is normal SAML behavior. The application is not behaving incorrectly — it is doing exactly what federated identity is designed to do: trust assertions signed by the configured identity provider. There is no mechanism available to the application to distinguish a forged assertion from a legitimate one. Both carry a valid signature from the trusted key. Both pass every check the SP was built to perform.

The attacker is not constrained to impersonating existing accounts at their actual privilege level. They can set the subject to any user in the directory. They can set the group membership and role attributes to anything the application evaluates for authorization. If the application grants administrative access to users in a specific security group, the forged assertion claims that membership regardless of the real user’s actual directory attributes. Authentication and authorization both collapse under a signing key compromise — not just authentication, both.

Standard SAML assertions carry validity windows, but an attacker constructing assertions from scratch sets the NotBefore and NotOnOrAfter timestamps to whatever serves them operationally. Assertions can be crafted to remain valid indefinitely, or new ones can be generated on demand. Combined with the fundamental limitation of SAML as a protocol — once a token is issued, there is no revocation channel from the IdP to the service providers holding active sessions — access persists until the signing certificate is rotated and every relying party is updated.

This is why Golden SAML operates as a persistence mechanism, not merely an access mechanism. Password resets are irrelevant because the attacker never used a password. MFA offers no protection at the service provider layer because the application believes authentication already occurred at the identity provider. Resetting the compromised account doesn’t help because the attacker simply constructs an assertion for a different account. There is no individual account to revoke, no session to invalidate, no single artifact to remediate. The only remediation is rotating the signing certificate and updating every relying party — an operation disruptive enough that organizations often delay it, extending the exposure window in the process.

One Key, Every Application, No Per-Application Controls Remaining

This is the compounding factor that distinguishes a signing key compromise from any other credential theft. When an attacker steals a user’s credentials, they gain access to what that user can reach. When they compromise a service account, they gain what that service account can reach. A Golden SAML attack doesn’t have that constraint. Every application that trusts the compromised identity provider is simultaneously exposed — not sequentially, not through further lateral movement, but immediately and in parallel. The attacker doesn’t need to discover individual applications, enumerate accounts, or locate separate credentials for each service. They generate an assertion for whatever target is operationally relevant and present it.

In the SolarWinds intrusions, APT29 used this to access email archives of senior officials across nine US government agencies. The same mechanism would have worked with identical technical effort for SharePoint, HR systems, financial applications, development tooling, or any other service federated to the same ADFS infrastructure. The signing key signs assertions without regard for the target application — each service receives a correctly signed assertion, validates it, and grants access.

Lateral movement in the traditional sense implies progression: compromising one system, using it to reach the next. That progression is what defenders detect — anomalous internal connections, service account reuse, credential relay patterns. A Golden SAML attack eliminates the progression entirely. The entire federated application estate is accessible from the moment the key is extracted. The concept that normally constrains attackers — each additional target requires additional effort — doesn’t apply. One key, every application, no intermediate steps required.

Nation-state adversaries targeted ADFS signing keys specifically because signing keys are worth more than any individual credential. A compromised user account enables access to what that user can reach. A compromised signing key enables access to what anyone can reach, as anyone, indefinitely. The asymmetry between the effort required to extract the key and the access it grants is what made it a weapon of choice for APT29 across the most significant identity attacks of the past decade.

Twenty Confirmed Attacks, Fewer Than Ten Organizations — and That Count Is Wrong

In June 2025, Microsoft disclosed that their incident response teams had confirmed 20 Golden SAML attacks across fewer than ten unique customers over the preceding 24 months. That number is almost certainly an undercount — not because Microsoft is misrepresenting it, but because the detection problem is severe enough that confirmed incidents substantially lag actual incidents.

The core challenge: a forged SAML assertion is cryptographically valid. From the service provider’s perspective, it passed every check the application was designed to perform. Standard authentication monitoring — failed login attempts, MFA anomalies, suspicious credential patterns — doesn’t fire because the attacker never participated in an interactive authentication flow. There may be no authentication event at the identity provider at all, even though the service provider recorded a successful sign-in. The systems are behaving correctly. What is broken is the assumption about who controls the signing key, and neither the SP nor the IdP has visibility into that assumption having failed.

The most reliable detection signal is an absence pattern: a valid Entra sign-in event with no corresponding ADFS Event IDs 1200 or 1202 — the events that fire when the Federation Service issues or validates a token during a legitimate authentication flow. A legitimate SAML authentication generates both events. A forged assertion is constructed offline; the ADFS server never touched it. The absence of the issuance event for a confirmed application login is the primary indicator that something is wrong. Building a SIEM correlation that alerts on Entra sign-ins with no matching ADFS 1200/1202 within the expected window is the most direct hunting approach currently available.

Earlier in the kill chain, Event ID 4662 on the DKM container in Active Directory fires when that container is accessed. Reading the DKM container is not a normal operational activity; it happens during the key extraction phase, before any forged assertion has been produced. A 4662 on that specific object is a strong signal that key material retrieval is in progress. Event ID 1007 on the ADFS server indicates certificate export. Neither surfaces unless Active Directory auditing is specifically configured to capture object access events on the DKM container — a configuration step that requires deliberate setup and is absent in most default deployments.

MITRE ATT&CK documents this as T1606.002 (Forge Web Credentials: SAML Tokens). The detection data sources — Windows Security event logs, IdP audit logs, cloud application sign-in logs — are correct. The gap is that most security operations teams treat ADFS audit logs and Entra sign-in logs as separate data streams rather than as two halves of the same authentication event. Until they are correlated, the absence-of-event signal doesn’t surface, and Golden SAML remains effectively invisible in the monitoring layer.

The Attack Surface Didn’t Shrink When Organizations Moved to Cloud

The natural response to Golden SAML’s ADFS-specific prerequisites has been migration toward cloud identity: move to Entra ID, decommission ADFS, eliminate the on-premises attack surface. Microsoft’s incident response team now recommends exactly this path. The attack surface didn’t disappear — it shifted, and in some respects expanded.

In February 2024, Semperis researchers disclosed Silver SAML: a variant that targets Entra ID directly with no ADFS infrastructure required. The vulnerability exists when organizations configure Entra ID enterprise applications for SAML SSO using an externally generated signing certificate — one created outside of Entra, imported manually, with the private key potentially stored on a workstation, transmitted over email with the password in the same message, or present on a web server in exportable form. If an attacker obtains the private key of that external certificate, they can forge SAML responses that Entra ID accepts as valid, sometimes without Entra being contacted at all, because the service provider trusts the certificate directly. Microsoft assessed Silver SAML as “by design” and declined to issue a patch. The mitigation is specific: use only Entra-generated certificates for SAML signing in enterprise applications, never externally imported ones. Organizations that haven’t audited their enterprise application federation configurations for externally managed certificates are exposed to this variant regardless of whether they’ve decommissioned ADFS.

APT29 has largely moved beyond ADFS-dependent Golden SAML toward cloud-native identity abuse. FoggyWeb (2021) installed persistent backdoors on ADFS servers for certificate exfiltration. MagicWeb (2022) replaced a legitimate ADFS DLL to manipulate claims in-process, without key theft at all. By the Midnight Blizzard intrusion in January 2024 — when APT29 breached Microsoft’s own corporate environment — the initial vector was password-spraying against a legacy non-production test tenant account, followed by OAuth application abuse to access senior leadership’s Exchange Online mailboxes. No ADFS. No token-signing certificate. The same strategic objective — persistent authenticated access to cloud services — achieved through cloud-native identity primitives. CISA’s February 2024 advisory AA24-057A documented this evolution explicitly: SVR actors adapting from ADFS-focused techniques toward service principal abuse, dormant account takeover, and OAuth application permission manipulation.

The protocol substitution doesn’t change the threat model. OpenID Connect uses JSON Web Tokens signed with the IdP’s private key in an architecturally equivalent way. A compromised OIDC signing key enables analogous token forgery across OIDC-federated applications. The specific extraction path and the specific tooling change between ADFS and cloud environments. The underlying dynamic — one signing key controls access to every application that trusts it — holds across every protocol implementation built on this trust model.

Governing the Key Is the Entire Problem

The defensive response to Golden SAML is fundamentally a key management problem, not a detection problem. Detection coverage for post-compromise activity is limited by design — forged assertions are valid, and the absence-of-event correlation is difficult to build and easier to miss than to catch. Prevention controls are substantially stronger.

Hardware security modules remain the strongest preventive control for ADFS environments that can’t yet migrate. A properly configured HSM prevents direct extraction of the private key even when the ADFS server is fully compromised — signing operations happen inside the HSM and raw key material never enters software processes. This is a real and significant improvement over the default installation path, and it should be implemented wherever the operational complexity is manageable.

There is an important limit to what an HSM protects. It prevents key extraction; it does not prevent an attacker who has fully compromised the ADFS host from using the HSM to sign arbitrary assertions at runtime. The attacker can’t copy the key and take it elsewhere — but they can call the signing API from the compromised server and produce as many forged assertions as they need while that access persists. HSMs substantially raise the bar and are the correct architectural choice. They are not a substitute for controlling access to identity infrastructure itself.

The single highest-impact operational control is configuring MFA to be satisfied at the Entra Conditional Access layer rather than delegated to the on-premises ADFS server. A forged SAML assertion can claim that MFA was completed at the IdP, because the IdP is supposed to assert this. If MFA is enforced as a separate, independent requirement at the Entra CA layer, a forged assertion cannot satisfy it — the attacker would need to defeat Entra’s own MFA challenge in addition to having forged the assertion. This control is available in hybrid environments today and is the most direct mitigation against Golden SAML access to cloud applications.

Certificate rotation frequency governs blast radius. ADFS token-signing certificates default to one-year validity. A 30-day rotation cycle limits a stolen key’s average useful window to approximately 15 days. Every relying party must update its trusted certificate metadata on rotation, which creates real operational burden in environments with many federated applications. It is a significantly better posture than operating with 365-day exposure windows, and in environments with high-consequence applications — cloud administration consoles, financial systems, privileged access management tooling — the rotation cost is worth paying. Organizations running a single signing key for all federated applications should also consider per-application or per-group key segmentation: a single compromise exposes everything simultaneously; separate keys bound the blast radius to the applications trusting that specific key.

The long-term architectural direction is migration away from ADFS and toward cloud-native Entra ID authentication, which eliminates the on-premises signing key extraction paths entirely. IPSIE — launched in October 2024 by the OpenID Foundation, Okta, Microsoft, Ping Identity, and others — addresses the fundamental limitation that SAML can’t revoke tokens after issuance. IPSIE’s Shared Signals and Events mechanism enables identity providers to push revocation signals to all relying applications in near real-time: detection flags a suspicious assertion, the IdP signals the applications, the sessions terminate. This is a direct architectural response to the fire-and-forget weakness that Golden SAML exploits. IPSIE is in active working group development and represents a five-to-ten year transition horizon, not an immediate remedy. Organizations building net-new federation architecture today should be designing with it in mind.

The organizations that followed the standard ADFS deployment path know what they did. The deployment documentation showed the easier path, the faster path, the path that works immediately without additional infrastructure. The signing key ended up on the server. It’s accessible to anyone who reaches the environment with sufficient privileges — which, given enough dwell time, describes most breach scenarios.

What makes Golden SAML significant beyond any individual incident is what it reveals about the design assumption embedded in single sign-on. Federated identity concentrates trust deliberately. One authentication event unlocks access to everything, and one signing key makes that possible. Nation-state adversaries identified this before most defenders did — signing keys are worth more than any individual credential, because they don’t just steal access, they manufacture it. The key is on the server. The server is reachable. The question organizations should be asking isn’t whether the architecture is theoretically sound. It’s whether someone has already found it.