Golden SAML and federation trust: the attack path your audit must cover

EntraGUARD·2026-09-01·8 min

Golden SAML forges the proof of identity itself. Once an attacker holds the signing key, they can mint that proof for anyone — silently, without touching the cloud sign-in logs. Any serious identity audit has to cover it.

Most identity attacks are noisy — a password sprayed, an MFA prompt bombed. Golden SAML is different: it forges the assertion that proves who you are, and once an attacker holds the signing key, they can mint that proof for anyone, silently, without ever touching Entra ID's sign-in logs. Any serious Microsoft identity audit has to cover the federation trust that makes this possible.

How the path works

When a tenant federates authentication to an on-premises identity provider — historically AD FS — Entra ID trusts SAML assertions signed by that provider's token-signing certificate. Compromise the server that holds the private key, and you can forge an assertion for any user, including a Global Administrator, with any claims you like. Entra ID accepts it because the signature is valid. There is no failed sign-in, no MFA prompt, no anomaly in the cloud logs, because from the cloud's point of view nothing went wrong. This is MITRE ATT&CK technique T1484.002, domain trust modification, and its cousin the forged SAML token.

What the audit looks for

Federation configuration — which domains are federated, to what issuer, and whether federation is still needed at all.
Unexpected federated domains — an attacker who already has privilege can add a federated domain with their own signing key, creating a backdoor. A new or unrecognised federated domain is a red flag.
Token-signing certificate hygiene — rotation, and whether the signing infrastructure is isolated and monitored.
The move to cloud authentication — tenants that have migrated to Password Hash Sync or Cloud Authentication remove the AD FS attack surface entirely.

The best fix is removal. If federation is legacy and no longer required, migrating to cloud authentication eliminates the Golden SAML path rather than hardening it. Where federation must stay, the signing infrastructure has to be treated as Tier 0 — as sensitive as a domain controller.

Why read-only simulation matters here

You cannot safely "test" Golden SAML by forging a token in production. What an audit can do is evaluate whether the path would succeed: is there a federated trust, is the signing surface exposed, is a rogue domain addition possible with current privilege? EntraGUARD's attack simulator scores exactly this kind of exposure without attempting the attack — it reports whether the path is viable, so you fix the trust before someone exercises it.