How does Golden SAML Attack work?

How Golden SAML Actually Succeeds

A golden saml attack is a trust-break attack against federated authentication. The attacker steals the identity provider’s signing material, then uses it to mint SAML assertions that downstream services accept as genuine. Once the assertion is accepted, the attacker can impersonate legitimate users without needing their passwords or MFA at the service provider.

The core failure is not SAML itself, but the trust placed in the issuer’s signature. When an attacker controls the signing key or certificate, they can create assertions with whatever subject, role, audience, or expiry the relying service is prepared to trust. That is why the blast radius is often broad: one compromised federation component can unlock many connected applications at once.

For SAML-specific hardening and the mechanics of forged assertions, SAML Security Guide is the most direct reference. The practical lesson is that federation security depends on the integrity of the IdP signing path, not just on login UX or MFA policy at the application layer.

What Changes When the Signing Key Is Exposed

golden saml becomes possible only after the attacker obtains the signing material used by the identity provider. At that point, the attacker can issue assertions that look authentic to any service trusting that IdP, including applications that never expose their own passwords or sessions directly.

This is why key protection and certificate rotation are central controls. If the signing material is long-lived, broadly accessible, or poorly monitored, the attacker can continue forging assertions until the trust relationship is broken and the compromised key is fully replaced. In practice, the risk is strongest where federation components are treated as infrastructure rather than as high-value authentication assets.

Identity Provider and SSO Security Guide covers the surrounding controls that matter here, including admin protection, session and token security, and federation monitoring. That matters because the attacker often needs only one foothold near the IdP to turn signing material into organisation-wide access.

What Defenders Should Verify First

The first practical check is whether the IdP signing keys are tightly controlled, auditable, and rotated on a defensible schedule. Next, confirm which applications trust the IdP, whether the federation trust is still required, and whether older or redundant trust paths can be removed. Finally, validate that logging can distinguish normal SAML sign-ins from unusual successful authentications that deserve investigation.

In environments with multiple identity technologies, review whether federation can be narrowed or modernised. If the IdP is weakly protected, every relying party inherits that weakness. The safest posture is the one that reduces both the number of trust relationships and the number of people or systems that can touch signing material.

IAM and Identity Provider Buyer’s Guide is useful where teams are deciding how to structure or replace the IdP estate, while OpenID Connect Core 1.0 is the relevant standard when evaluating migration away from SAML-heavy trust models.

Risk and Threat Considerations

Golden SAML is high impact because it turns a single signing compromise into durable, hard-to-distinguish fraudulent access across many federated services. The attacker does not need the victim’s password or a live interactive session, and successful assertions can bypass ordinary user-facing authentication controls.

Failure mechanism: The IdP signing material is stolen, then used to forge assertions that trusted service providers accept as valid, allowing impersonation until the trust chain is revoked or the key is replaced.

Impact: The attacker can access multiple applications as an authorised user, escalate privileges if roles are asserted in the token, and maintain access across services that all rely on the same federation trust.

Practitioner Guidance

What to verify: Treat IdP signing keys as tier-zero assets. Verify who can access them, where they are stored, how quickly they can be rotated, and whether emergency revocation procedures have actually been tested.

Decision rule: If a federated application can accept assertions signed by a long-lived key that is broadly accessible, prioritise key protection and trust reduction before relying on downstream detection alone. Detection helps, but it is not a substitute for removing the ability to mint trusted assertions.

Practitioner takeaway: Golden SAML is a federation trust compromise, so the decisive control is protecting and rapidly replacing the signing material that makes assertions believable in the first place.

Related resources from NHI Mgmt Group

• Guide: Identity Threat Detection and Response (ITDR) Guide
• Golden SAML Attack
• Why are Golden SAML attacks so difficult to detect?
• What is the difference between a normal Kerberos ticket issue and a Golden Ticket attack?
• How should security teams use attack path analysis to prioritise resilience work?