Golden SAML: Detection, Containment, and Recovery

Golden SAML forges identity with a trusted signing key

Golden SAML detection asks whether a validly signed assertion was actually issued through the expected identity-provider authentication path. If an attacker obtains the private token-signing key—or adds a malicious trusted federation key—they can choose subject, groups, authentication context, audience, and lifetime within what the relying party accepts.

MITRE ATT&CK forged SAML token guidance distinguishes forged assertions from stolen session tokens: the adversary creates new credentials using trusted signing material. Signature validation succeeds because cryptographic trust is genuine even though the identity claim is false.

Scope includes federation servers, hardware or software key stores, configuration databases, service accounts, backup copies, trust metadata, relying parties, cloud federation, administrative identities, and sessions created from assertions. Password and MFA controls cannot compensate for a compromised issuer key.

Preserve assertion fields without spreading a reusable credential

Capture the assertion only in a restricted evidence store. Record a hash, issuer, subject, NameID format, assertion ID, issue instant, conditions, audience, recipient, authentication context, session index, attributes, certificate thumbprint, relying-party request ID, and resulting session identifiers. Redact or omit the signature value from ordinary case notes.

This is an authored, abbreviated claim record—not a valid SAML assertion:

{"issuer":"https://fs.example/adfs/services/trust","assertion_id":"_a73...",
 "subject":"[email protected]","audience":"urn:example:cloud",
 "issue_instant":"2026-11-10T14:52:11Z","not_on_or_after":"2026-11-10T15:52:11Z",
 "authn_context":"urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport",
 "signing_thumbprint":"9F42...","assertion_sha256":"c1a8..."}

XML canonicalization and signature validation are easy to misimplement. Use the relying party’s supported tooling or a maintained SAML library; do not build an ad hoc validator during an incident.

Correlate relying-party success with issuer-side absence

Join every federated sign-in to identity-provider authentication and assertion issuance using assertion ID, subject, relying party, issue time, request correlation, and source context. High-confidence gaps include a relying-party session with no corresponding issuer event, impossible claim values, abnormal lifetime or audience, privileged groups inconsistent with the directory, or authentication context inconsistent with MFA policy.

Monitor access and changes to token-signing keys, certificate rollover configuration, federation metadata, trust objects, service accounts, backups, and AD FS administration. Microsoft AD FS auditing guidance should be implemented with retention independent of the federation servers.

Missing issuer evidence can also result from logging gaps, latency, clock drift, or an alternate federation node. Apply identity token and session detection and prove telemetry completeness before concluding an assertion was forged.

Rotate trust and invalidate sessions in the right order

Treat the federation service and signing key as compromised until evidence shows otherwise. Isolate administrative access, preserve federation hosts and configuration, stop unauthorized key use, and coordinate relying parties before changing metadata. Rotation can cause widespread authentication outages if applications do not ingest the new certificate correctly.

Microsoft AD FS token-signing certificate guidance explains certificate renewal mechanics. In a confirmed key compromise, follow vendor incident guidance for emergency rollover; relying parties may need rapid metadata refresh and removal of older trusted keys. Invalidate sessions and refresh mechanisms at every relying party, not only the identity provider.

Rebuild compromised federation infrastructure from trusted sources, rotate service and backup credentials, review trust changes, and investigate every assertion or session in the exposure window. Password resets remain appropriate when passwords may also be exposed, but they do not revoke forged assertions by themselves.

Protect the signing tier as identity root infrastructure

Isolate federation servers and key operations, restrict administration to privileged workstations, apply the principle of least privilege, protect signing keys with hardware-backed controls where supported, secure backups, and monitor all export or rollover operations. Separate daily administration from key custody.

Export issuer logs to an independently administered destination, synchronize time, retain assertion correlation fields, and inventory every relying party and accepted certificate. Test emergency rollover and session revocation before an incident. Federation availability is business-critical, so use staged exercises rather than unplanned production key changes.

Reduce overpowered claims and long sessions at relying parties. Require step-up authentication for consequential actions when the application can obtain fresh independent context, and do not let one broad group claim silently become universal administration.

Prove federation events reconcile end to end

Next step: select one non-production SAML application and authenticate with a test user. Link the application session to assertion ID, issuer event, authentication method, directory claims, signing thumbprint, and relying-party decision. Measure which join keys are missing.

Then conduct an authored tabletop in which a validly signed assertion lacks issuer evidence—do not forge or replay a real credential. Walk the incident response lifecycle through key containment, application coordination, session invalidation, and recovery proof. The durable control is independently observable issuance plus a rehearsed trust-replacement path.