up:: In the Protocols MOC

SAML

SAML (Security Assertion Markup Language) is the XML-based standard that lets one system vouch for a user’s identity to another, and its quantum exposure is that the digital signatures protecting those identity assertions rest on RSA or ECDSA, which a large quantum computer can forge. Where TLS is a confidentiality problem you can harvest today and decrypt later, SAML is the opposite kind of problem: an attacker who can forge the signature on a SAML assertion can mint a valid-looking claim that a user is authenticated, log in as anyone, or impersonate a trusted identity provider outright. That makes SAML a Non-HNDL trust-forgery risk, not a deferred-decryption one, and the fix is to move the assertion and metadata signing off classical algorithms and onto a post-quantum signature like ML-DSA.

The short version:

• SAML is federated single sign-on: an identity provider (IdP) tells a service provider (SP) “I verified this user, here’s who they are” using a signed XML assertion.
• The security of that hand-off rests on an RSA or ECDSA signature over the assertion, applied with XML Signature. Both signature families are breakable by Shor’s Algorithm.
• The risk is live trust forgery. A forged signature lets an attacker fabricate assertions and impersonate users or IdPs on the spot, so SAML is a Non-HNDL problem with nothing to harvest and no deferred payoff.
• The signing keys often belong to the identity or IAM team, or to a SaaS vendor, rather than the certificate/PKI team, so a certificate-focused inventory routinely misses them.
• The migration is to re-sign assertions and federation metadata with a post-quantum signature (ML-DSA), and its blast radius is high because one IdP trust relationship fans out to every SP that trusts it.

Think of SAML like a notary’s stamp on a letter of introduction. The service provider never met you and never checks your credentials itself. It trusts the letter because it recognizes the notary’s seal, verifies the seal is genuine, and lets you in on that basis. The quantum problem isn’t that someone reads your old letters. It’s that a quantum computer can counterfeit the notary’s seal well enough to fool every door that trusts it, so the attacker writes their own letters of introduction and walks in as whoever they like. The fix is to give the notary a seal that can’t be counterfeited, which means changing the math behind the signature.

What is SAML?

SAML is an XML-based framework for exchanging authentication and authorization information between security domains, and in enterprise practice it’s the backbone of federated single sign-on. OASIS describes it as a standard that “defines an XML-based framework for describing and exchanging security information between on-line business partners.” Instead of every application authenticating users itself, SAML lets one trusted authority do the authentication and pass a signed statement of the result to the applications that rely on it.

Three roles do the work:

1. Identity provider (IdP). The asserting party, what OASIS also calls a “SAML authority”, that authenticates the user and issues assertions about them. This is the corporate login system.
2. Service provider (SP). The relying party, “a system entity that uses assertions it has received.” This is the application the user is trying to reach, typically a SaaS app.
3. User agent. Usually the browser, which carries the messages between the IdP and the SP.

The unit of information SAML moves is the assertion, a signed XML package of statements about a subject. SAML defines three kinds of statement an assertion can carry:

1. Authentication statements (“this user authenticated, at this time, this way”).
2. Attribute statements (“this user has these attributes”, such as group, role, or email).
3. Authorization decision statements (“this user may access this resource”).

An assertion also carries conditions that bound its validity, a time window (“not before” and “not on or after”) and an audience restriction that names which SP the assertion is meant for, so it can’t be replayed elsewhere. SAML 2.0, the version in near-universal enterprise use, was ratified as an OASIS Standard on 15 March 2005.

SAML is not a cipher, not a public-key primitive, and not a transport protocol. It’s a federation framework that leans on other standards for its actual cryptography: XML Signature to sign assertions and metadata, X.509 certificates to distribute the signing keys, and TLS underneath for transport protection. Its closest modern counterpart is the JSON-and-token world of JWT, OAuth, and OpenID Connect, which solves the same federation problem with a different serialization and the same underlying dependence on classical signatures.

Source: N. Ragouzis et al., “Security Assertion Markup Language (SAML) V2.0 Technical Overview,” OASIS Committee Draft 02, 25 March 2008, docs.oasis-open.org.

Source: S. Cantor, J. Kemp, R. Philpott, E. Maler, eds., “Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0,” OASIS Standard saml-core-2.0-os, 15 March 2005, docs.oasis-open.org.

Where does cryptography live in SAML?

The cryptography that matters in SAML lives in one place: the signature that proves an assertion or a piece of federation metadata really came from the trusted party and wasn’t altered on the way. Everything else in a SAML exchange is plumbing; the signature is the trust.

SAML uses XML Signature (the W3C XMLDSig standard) to sign messages. When an IdP issues an assertion, it computes a digital signature over the XML and embeds it as a <ds:Signature> element. When the SP receives the assertion, it verifies that signature against the IdP’s known public key, which it holds through the federation’s trust configuration. The SAML core specification’s Section 5, “SAML and XML Signature Syntax and Processing,” is what governs this, and the Technical Overview is blunt about when it’s mandatory: when an assertion is delivered through the user’s browser, “it is mandated that the response message be digitally signed using XML Signature.”

Two related trust artifacts are also signed, and both are quantum-relevant:

1. The assertion (or the response wrapping it). This is the live claim about the user. Its signature is what the SP checks on every login.
2. The federation metadata. SAML partners exchange metadata files that declare their entity IDs, endpoints, and, critically, the certificates each side uses to sign. Signed metadata is how a federation distributes and rotates trust anchors. If metadata signing is forgeable, an attacker can substitute their own signing certificate into the trust configuration.

The signature algorithms XML Signature specifies are exactly the ones the quantum threat targets. The W3C XML Signature 1.1 Recommendation lists structured formats for “DSA (REQUIRED), RSA (REQUIRED) and ECDSA (REQUIRED) public keys,” so a compliant SAML deployment is signing with RSA or ECDSA. TLS sits underneath for transport confidentiality, but transport encryption does nothing to stop a forged assertion signature, because the forgery is valid XML that the SP is supposed to accept.

Source: D. Eastlake, J. Reagle, D. Solo, F. Hirsch, T. Roessler, eds., “XML Signature Syntax and Processing Version 1.1,” W3C Recommendation, 11 April 2013, w3.org.

Source: S. Cantor et al., “Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0,” OASIS Standard saml-core-2.0-os, §5 (SAML and XML Signature Syntax and Processing), 15 March 2005, docs.oasis-open.org.

Which parts of SAML are quantum-vulnerable?

The quantum-vulnerable part of SAML is the signature, and only the signature. XML Signature signs assertions and metadata with RSA or ECDSA, and both of those are broken by Shor’s Algorithm, which efficiently solves the integer-factorization problem behind RSA and the elliptic-curve discrete-log problem behind ECDSA on a large enough quantum computer. Once those signatures are forgeable, the entire trust model of the federation is forgeable with them.

Here’s what an attacker who can forge SAML signatures can actually do:

1. Forge assertions. Mint a valid-looking assertion that says any user authenticated, without ever touching the real IdP.
2. Impersonate users. Sign an assertion naming a privileged account and hand it to an SP, which accepts it as a genuine login.
3. Impersonate the identity provider. Because the SP’s trust rests on recognizing the IdP’s signature, a forged signature lets an attacker stand in for the IdP itself.
4. Tamper with federation metadata. Forge signed metadata to swap in an attacker-controlled signing certificate, quietly redirecting the federation’s trust.

The AES symmetric encryption and the hashing used elsewhere in and around SAML aren’t the story here. Grover’s Algorithm only weakens symmetric security by a manageable amount, defeated by a larger key, and the dominant post-quantum problem in SAML is squarely the certificate-and-signature trust.

SAML element	The cryptography today	Quantum threat	Exposure class	What a break enables
Assertion signature	RSA / ECDSA via XML Signature	Forged by Shor’s	Non-HNDL, live trust forgery	Fabricated logins, user impersonation
Metadata signature	RSA / ECDSA via XML Signature	Forged by Shor’s	Non-HNDL, live trust forgery	Swapped trust anchors, IdP impersonation
Transport (TLS)	ECDHE key exchange	HNDL on the channel	Separate TLS problem	Recorded traffic, not assertion forgery
Any symmetric use	AES	Weakened by Grover’s	Retain and strengthen	Use a larger key, no swap

Source: P. Shor, “Polynomial-Time Algorithms for Prime Factorization and Discrete Logarithms on a Quantum Computer,” SIAM J. Computing, 1997, quant-ph/9508027.

Why is SAML a Non-HNDL problem and not a harvest-now-decrypt-later one?

SAML is a Non-HNDL problem because there’s nothing worth harvesting and no deferred payoff. A recorded SAML assertion from last year is useless to a future attacker: it was valid only inside its narrow time window and its audience restriction, and it authorizes nothing once it expires. The value of the attack is entirely in the present tense, forging a fresh assertion that an SP will accept now.

That’s the clean line between SAML and a protocol like TLS key exchange. TLS key exchange is a harvest-now-decrypt-later problem: an attacker records today’s encrypted traffic and waits for a quantum computer to unlock it, so the exposure is open the moment the data is captured, years before the machine exists. A SAML signature is the reverse. The attacker needs a working quantum computer at the moment of the forgery, because a forged assertion only matters live. There’s nothing to capture and sit on.

This changes the shape of the clock but not the seriousness. Because the threat is live forgery rather than stored data, SAML doesn’t carry the “you’re already too late” urgency that harvestable confidentiality does. What it carries instead is enormous reach: SAML sits at the authentication front door, so the day signatures become forgeable is the day an attacker can walk through it as anyone. It’s a slower fuse on a bigger charge.

What does migrating SAML actually look like?

Migrating SAML means changing the signature algorithm inside XML Signature from RSA or ECDSA to a post-quantum signature, and the practical difficulty is that this touches a trust web spread across teams and vendors rather than a single codebase. The replacement target is ML-DSA, NIST’s standardized general-purpose lattice signature, with SLH-DSA available where a conservative hash-based signature is preferred. Several features define the real shape of the work:

1. The blast radius is high because trust fans out. One IdP signs assertions that dozens or hundreds of SPs trust. Change the IdP’s signing algorithm and every SP that validates its signatures has to understand the new algorithm too, or the login breaks. A single trust relationship is a hub, so the reach of any change, and of any compromise, is wide.
2. The signing keys often live outside the PKI team. SAML signing certificates are frequently owned by the identity or IAM team, or held entirely inside a SaaS vendor’s platform, rather than by whoever runs the enterprise certificate authority. A cryptographic inventory that only walks the PKI team’s certificates routinely misses them, which is why SAML signing keys are a classic blind spot.
3. Validators and the XML Signature ecosystem have to catch up. A post-quantum SAML signature only works if the verifying SP recognizes the new algorithm identifier and its library can process it. Until XML Signature toolkits and the SP populations that depend on them support ML-DSA, an IdP can’t unilaterally switch. This is a crypto-agility problem: deployments hard-wired to one signature format have to be re-architected before they can negotiate a new one.
4. Parallel-signing carries the overlap. During the transition, an IdP can sign assertions and metadata with both a classical and a post-quantum signature so that old SPs validate the one they understand and upgraded SPs validate the other. Dual-signed metadata and staged trust upgrades are how a federation moves without a flag-day cutover, the same overlap pattern that composite certificates provide in the PKI world.
5. Vendors gate the timeline. A large share of SAML endpoints are surfaces the enterprise doesn’t control, SaaS applications acting as SPs and managed identity platforms acting as IdPs. For those, post-quantum support arrives when the provider ships it, so the schedule depends on vendor roadmaps as much as on internal engineering.

The underlying dependency chain is worth naming plainly. SAML trust rides on X.509 certificates and the signatures over them, so SAML’s post-quantum path is bound to the broader PKI transition; the federation can only be as quantum-safe as the certificate and signature ecosystem it’s built on.

Source: NIST, “Module-Lattice-Based Digital Signature Standard,” FIPS 204, August 2024, csrc.nist.gov.

Common misconceptions

1. “SAML is just login, so quantum doesn’t really touch it.” SAML is a signature-based trust system, and signatures are exactly what a quantum computer forges. The whole federation model depends on the assertion signature being unforgeable, so quantum touches its core, not its edges.
2. “It runs over TLS, so it’s protected.” TLS protects the channel from eavesdropping. It does nothing about a forged assertion, because the forgery is valid signed XML that the service provider is designed to accept. Transport security and assertion-signature security are separate problems.
3. “SAML is a harvest-now-decrypt-later risk like everything else.” It’s the opposite. Old assertions are worthless once expired, so there’s nothing to harvest. The risk is live forgery with a quantum computer present, which makes SAML a Non-HNDL trust problem.
4. “Our IdP vendor will handle the whole transition for us.” The vendor handles their side. The service-provider validators, the internal apps, the metadata trust configuration, and any self-hosted IdP are still yours, and a federation is only as strong as its weakest validator.
5. “We use SSO, so our cryptography is well understood.” Knowing an app “uses SAML” says nothing about which signature algorithm signs its assertions, how its certificates roll over, or whether its metadata is signed. Those details are what actually determine the exposure.
6. “Modern JWT-based SSO isn’t exposed the way SAML is.” JWT, OAuth, and OpenID Connect solve the same federation problem and lean on the same classical signature families (RSA and ECDSA) to sign their tokens. The serialization is different; the quantum exposure is the same.

Questions people ask

What exactly is quantum-vulnerable in SAML? The digital signature over the assertion and over the federation metadata. XML Signature applies those with RSA or ECDSA, and both are forgeable by Shor’s algorithm on a large quantum computer. The XML format and the rest of the protocol aren’t the cryptographic problem.

Is SAML a harvest-now-decrypt-later risk? No. A SAML assertion is short-lived and useless once it expires, so there’s nothing worth recording for later. The threat is forging a fresh, valid assertion once a quantum computer exists, which makes it a Non-HNDL trust-forgery problem rather than a confidentiality one.

What replaces the vulnerable signatures? ML-DSA (FIPS 204) is the standardized general-purpose post-quantum signature and the primary target; SLH-DSA (FIPS 205) is the conservative hash-based alternative. SAML itself isn’t replaced by a NIST standard. Its signing and certificate mechanisms are what get modernized.

Do I have to replace SAML entirely? Not for quantum reasons. SAML stays workable if its assertion and metadata signing moves to a post-quantum algorithm. Whether an organization eventually shifts toward JWT-based OpenID Connect is an identity-architecture choice, not a cryptographic standard swap.

Why is SAML’s blast radius considered high? Because one identity provider’s signature is trusted by every service provider federated to it. A forged IdP signature, or a botched signing-key change, propagates to every downstream application at once, and those applications often gate privileged access to HR, finance, and admin systems.

Where do SAML signing keys usually live, and why does that matter? Often with the identity or IAM team, or entirely inside a SaaS vendor’s platform, rather than with the certificate/PKI team. A cryptographic inventory scoped to the PKI team’s certificates tends to miss them, so SAML signing keys are a recurring blind spot in migration planning.

How is this different from the TLS quantum problem? TLS key exchange is harvestable today and decryptable later, so it’s an urgent confidentiality clock. SAML signatures can’t be harvested and need a live quantum computer to forge, so it’s a slower-fuse trust problem, though a high-reach one because it sits at the authentication front door.

Is SAML the same problem as JWT and OpenID Connect? Cryptographically, yes. All of them authenticate federated identity with digital signatures over RSA or ECDSA keys, so all of them face the same forgery exposure and the same move to ML-DSA. SAML is XML; JWT is JSON; the signature dependency is shared.

---

Everything here is the map, given freely. When your team needs its SAML federation found, its assertion- and metadata-signing exposure prioritized across every IdP, SP, and vendor surface, and a post-quantum signing transition sequenced defensibly for your board and your auditor, that’s the work I do, and there’s an alignment briefing for it.

Last verified 2026-07-09 · Maintained by Addie LaMarr, LaMarr Labs.