The TRUST post ended with a promise: PKI next, because it’s the clearest case of one technology serving both TRUST and CRED. The CRED post sharpened that into two claims: short-lived agent credentials have a quantum advantage, and SAML has no migration path at all.
Both claims are true. This post is where they land.
PKI serves TRUST by making accountability chains verifiable: a certificate authority is a trust anchor, and the act of signing a certificate is a vouching assertion. PKI serves CRED by providing a credential with a different character than a password or a bearer token: the certificate doesn’t just assert an identity, it binds that assertion to a key pair and signs it with an authority whose trust level is known. A password makes a claim. A PKI-issued certificate proves one, and the strength of that proof is traceable back through the issuing CA to a trust anchor the relying party has explicitly accepted. One infrastructure, two dimensions, and when post-quantum cryptography forces a migration, both sides move at once, but not in the same direction, and not on the same timeline.
Two failure modes, two timelines
The quantum threat to identity infrastructure has two distinct shapes.
The first is Harvest Now, Decrypt Later (HNDL). Adversaries are collecting encrypted IAM exchanges today (authorization codes, token acquisitions, SAML assertions, SCIM provisioning payloads, privileged API traffic) and storing them for decryption once a cryptographically relevant quantum computer (CRQC) exists. This threat is active right now. The harvesting is already happening. The decryption is what’s future. When it arrives, the consequence isn’t just that old sessions get exposed. An adversary who can decrypt a harvested SAML assertion or authorization code from 2026 can reconstruct the identity claims, session context, and access grants that were live at that moment. For long-lived governance records, the exposure window is measured in years, not sessions.
The second is signature forgery. Digital signatures underpin every trust assertion in the identity control plane: JWT signatures that authenticate tokens, SAML assertion signatures that enable federation, X.509 certificate signatures that establish PKI trust chains, signatures on device attestations, firmware measurements, and audit records. A CRQC capable of breaking RSA or ECC signatures would let an adversary forge any of these: impersonating identity providers, manufacturing valid tokens, fabricating compliant device attestations. This threat is later but more consequential.
HNDL maps primarily onto CRED, but it touches every encrypted data flow (business data, communications, operational traffic), not just identity infrastructure. The artifacts being harvested aren’t just credentials in isolation; they’re the exchanges that establish what a principal is authorized to do, and everything encrypted downstream of them.
Signature forgery maps primarily onto TRUST. TRUST governance records (who vouched for whom, which model version underlies this agent, which sponsor authorized this deployment) are meant to be read months or years from now. They don’t expire. If their signatures can be forged retroactively, the entire evidentiary foundation of the governance record collapses: an adversary can rewrite what an agent was, who authorized it, and what it was permitted to do at the moment it took a consequential action.
Both dimensions are at risk. The migration timeline and the right algorithms differ by dimension.
What PKI does for TRUST
On the TRUST side, PKI is the infrastructure that makes accountability chains verifiable. A certificate authority is a trust anchor: it says, by signing a certificate, that it has vetted the principal receiving that certificate. In the four-dimensions framework, PKI sits at the boundary between TRUST and CRED: it establishes the authority that TRUST relies on, and issues the credentials that CRED presents.
For agents, this relationship is more complicated than it was for humans or traditional non-person entities. The TRUST post established that an agent’s identity attributes (the underlying model, system prompt, tool manifest) are as much a part of its identity as a human’s suitability determination. A model provenance attestation is the signed record that a given agent is running model version X with system prompt Y. Those records may be referenced in audit trails and governance proceedings months or years after they were created.
That long time horizon is exactly the HNDL problem for TRUST. If a model provenance attestation is signed with a classically vulnerable algorithm, an adversary can harvest it today and forge it in the post-CRQC era, rewriting the governance record to say an agent ran a different model, with a different system prompt, at the time it took a consequential action. The evidentiary value of the record is destroyed retroactively.
This calls for two signing layers, not one. ML-DSA (FIPS 204) is the right algorithm for the attestation itself: it is stateless, handles frequent signing at deployment, and is the standard migration target for all operational signatures. But ML-DSA is a newer cryptographic assumption than organizations need for records that have to hold up for decades. For the archival layer, the right choice is stateful hash-based signatures: LMS or XMSS, per NIST SP 800-208. These rest on hash functions alone, the most conservative security assumption available, and Shor’s algorithm does not threaten them.
Because LMS and XMSS are stateful, each one-time key must never be reused, and SP 800-208 requires signing inside a hardware module that does not allow the private key to be exported. That rules out signing every MAR record individually. The practical pattern is batch anchoring: sign each attestation with ML-DSA at deployment, add it to an append-only log, and sign the log’s Merkle root once per period with LMS or XMSS. Every record gets hash-based long-horizon integrity while consuming only one stateful signature per cycle. This is the same pattern underlying Merkle Tree Certificates, discussed below in the context of agent credential verification.
SLH-DSA (FIPS 205) is worth naming as an alternative for the archival layer. Like LMS and XMSS, it rests only on hash functions, but it carries no state to manage. The tradeoff is larger signatures and slower signing, which matter little at batch anchoring volume.
System integrity attestations (firmware measurements, TPM boot records) belong in the same archival category. They should be anchored with LMS, XMSS, or SLH-DSA and transmitted over ML-KEM-encrypted transport.
The infrastructure for making these attestations verifiable over time is taking shape at the IETF. SCITT (Supply Chain Integrity, Transparency, and Trust) is defining a standard for transparency logs of signed statements about supply chain artifacts: a signed attestation goes into a SCITT ledger, and a receipt proves it was there at a given point. That is exactly the tamper-evidence model that model provenance records need. SCITT is not yet an RFC and not yet deployable as a standard, but it is the direction this is heading and worth tracking. Its transparency log architecture also connects to the Merkle tree certificate work discussed below.
What PKI does for CRED
On the CRED side, PKI does something different: it provides the credential itself. An X.509 certificate is both a binding (this key belongs to this principal) and a credential (here is the proof of that binding, signed by someone you trust). For agents, the operational equivalent is a SPIFFE SVID, a short-lived, cryptographically attested workload identity document issued by a SPIFFE trust domain’s root CA.
The migration path here involves two distinct layers.
Transport first. The HNDL threat to credential exchanges is active today. Every IAM endpoint (SSO flows, federation, agent tool call traffic) must adopt hybrid key establishment at the TLS layer: ECDH combined with ML-KEM (FIPS 203). This renders harvested session data mathematically useless to a quantum adversary even while classical algorithms remain in use at the message layer during the transition period. This is the first migration priority, and it should be underway now.
Token signing next. JWT signatures on access tokens and ID tokens, and the signing of SPIFFE SVIDs, must migrate to ML-DSA (FIPS 204). This is harder than transport migration for a structural reason that Vikram Kalekar’s MV-QRIAM framework names clearly: IAM is a mesh of trust boundaries where few authoritative signers (IdPs, token services, SPIFFE trust domains) feed many distributed verifiers (resource servers, API gateways, relying parties). Upgrading the signer does not provide quantum resilience until the verifier ecosystem catches up. That coordination gap, not algorithm availability, is the binding constraint on migration timelines.
The practical approach is a dual-track strategy: publishing dual-algorithm JWKS endpoints that serve both classical and ML-DSA keys simultaneously, upgrading internal verifiers in waves before deprecating classical algorithms at federation boundaries. CISA has formally classified ICAM as transitioning, meaning that many IAM products support ML-KEM for key establishment but ML-DSA adoption for digital signatures remains limited. Transport-layer progress is not authentication-layer progress. Organizations must not mistake one for the other.
PKI last, and longest. CA infrastructure migration is the longest horizon in the entire playbook. Deploying PQC-capable issuing CAs, re-issuing mTLS certificates with ML-DSA or SLH-DSA signatures, updating trust stores across the verifier ecosystem: this is not a quick upgrade. For agentic systems specifically, the SPIFFE trust domain’s root CA and the signing keys for SVIDs must be included in the PKI migration plan from the beginning. Treating agent credential infrastructure as an afterthought to human PKI migration guarantees a second pass.
FIDO2 is public key without PKI. That changes the migration path entirely. There is no CA to upgrade and no trust store to update. The dependency is on authenticator hardware: the device must generate and store a PQC key pair, and the relying party must be able to verify it. No production FIDO2 authenticator supports a PQC algorithm today. NIST and the FIDO Alliance are working toward it, but hardware refresh cycles mean this will lag every other part of the migration. Passkeys are the strongest credential form available today and, for now, alongside SAML, one of two credential technologies with no PQC migration timeline. Plan for that gap and govern it explicitly.
SAML is a forcing function, not a migration target
The OASIS Security Services (SAML) Technical Committee closed on 08 July 2023. There is no active standards body to define a PQC migration path for XML Signature, and SAML’s architecture has no clean ML-DSA migration path even if one existed. This is not a gap that will be filled.
For federal agencies, M-26-15’s Phase 4 signature migration deadline (2031) is the forcing function: every SAML-dependent system must migrate to OIDC/JWT before that deadline or face an authentication layer that cannot be made quantum-resistant. That is an architectural requirement, not just a cryptographic preference.
OIDC is not simply the PQC-compatible alternative to SAML; it is architecturally superior. A SAML assertion tells you who authenticated and when. An OIDC token carries posture signals, step-up context, risk scores, and agent-specific claims, everything a policy enforcement point needs to make a calibrated response rather than a binary deny. For agents authenticating to enterprise services via SAML federation today, there is no migration path and no standards body working on one. That belongs in your agent inventory.
Ephemeral agents have a quantum advantage
One counterintuitive result of applying post-quantum analysis to agent credentialing: the credential model that agentic AI demands for least-privilege reasons is also better positioned for quantum resilience.
An agent that receives a short-lived, task-scoped workload identity credential and discards it at task completion has a much smaller HNDL exposure than a human identity with a long-lived session token or a service account with a static API key. The JIT/JEA (just-in-time, just-enough-access) model, issue on demand, scope to the task, discard on completion, means an adversary harvesting that credential today has a narrow window in which a future decryption produces anything useful.
This matters when making the case for workload identity inside organizations that are still running on service accounts with static API keys. The PQC argument reinforces the least-privilege argument: short-lived tokens are lower-value harvest targets, and short credential lifetimes reduce the window during which a harvested credential remains actionable even if later decrypted. Getting CRED right for agents isn’t just governance hygiene. It’s also the right PQC posture, and those two things are rarely the same answer.
Merkle tree certificates and the verification overhead problem
One practical challenge that PQC introduces for agent credentialing is signature size. ML-DSA signatures are significantly larger than RSA or ECC equivalents (approximately 3,309 bytes versus 256 bytes for RSA-2048). For a multi-agent pipeline where dozens of short-lived workload identity SVIDs are being issued and verified in rapid succession, that difference compounds quickly into a bandwidth and processing burden.
Chrome and Cloudflare, working with the IETF PLANTS working group, are developing Merkle Tree Certificates as an efficiency mechanism. MTCs allow a verifier to confirm a certificate’s inclusion in a transparency log with a compact proof, without downloading the entire log. For high-frequency agent credential verification, the kind that occurs when an orchestrator is spawning and authenticating sub-agents at task speed, Merkle tree-based structures are a promising path. They are not yet a standard, but Cloudflare and Google’s adoption signals strong industry direction. Practitioners deploying high-frequency agent credential verification architectures should track the PLANTS working group output.
What this means for the Master Agent Record
The TRUST and CRED posts each added elements to the Master Agent Record. PKI and PQC add a column to most of them: cryptographic posture.
For TRUST-side record elements:
- Governance record signing: the algorithm used to sign MUR and MAR entries, whether it has migrated to LMS or XMSS, and last rotation.
- Model provenance attestation: the attestation itself (model version, system prompt hash, tool manifest hash) signed with ML-DSA at deployment; archival integrity provided by anchoring a periodic Merkle root over the attestation log with LMS, XMSS, or SLH-DSA.
- System integrity: whether TPM-backed PQC attestation is in place, with firmware measurements signed under LMS or XMSS.
For CRED-side record elements:
- Workload identity: whether the SPIFFE trust domain’s root CA has been migrated to PQC-capable signing.
- Token signing: whether the IdPs and token services the agent relies on are publishing ML-DSA keys, and what algorithm the agent’s own SVID is currently signed with.
- SAML dependency: whether the agent authenticates to any enterprise service via SAML federation, a flag that identifies an unresolved quantum risk.
- Cryptographic posture summary: classical-only, hybrid, or post-quantum, tracked per credential type.
The MAR schema in the white paper’s Section 8.2 includes a migration phase field and target completion dates aligned to M-26-15’s federal timeline. For non-federal organizations, the same fields serve as a reference architecture for tracking PQC migration state per agent.
The migration sequence
OMB M-26-15 structures the migration across five phases, with hard deadlines for federal agencies. The identity-specific sequence within those phases follows a logic that applies regardless of whether you’re bound by M-26-15:
-
Inventory first (Phase 1, 2026–2027). Cryptographic inventory of all IAM infrastructure: PKI, token issuance, directory services, federation endpoints. Agent inventory runs in parallel: same governance motion, different principal type. This is also when SAML dependencies surface. The Phase 1 deadline for submitting a PQC Migration Plan to OMB/ONCD is approximately October 22, 2026 (next week for federal agencies).
-
Transport before signatures (Phase 2, 2027–2028). Hybrid TLS at all IAM endpoints. Dual-algorithm JWKS endpoints for IdPs. WIMSE-based workload identity for agents. The key establishment migration protects in-flight credential exchanges from HNDL. Signature migration comes next.
-
Verifier ecosystem before deprecating classical (Phase 3, 2028–2030). Upgrade internal verifiers to accept ML-DSA-signed tokens before cutting over. The signer-verifier asymmetry Vikram’s MV-QRIAM framework describes is the binding constraint. Migrate the SPIFFE trust domain root CA and re-issue agent SVIDs under PQC-signed trust domain.
-
SAML out, signatures in (Phase 4, 2031). The hard deadline for ML-DSA signature migration at all High Value Assets. Every remaining SAML assertion flow must be replaced with OIDC/JWT by this point. Migrate MUR and MAR anchoring to LMS/XMSS for long-horizon governance record integrity.
-
Continuous cryptographic posture (Phase 5, 2035). Classical algorithms deprecated at all IAM enforcement points. BEHAVE monitoring extended to detect PQC transition-specific attack patterns: algorithm confusion vulnerabilities, downgrade attempts, implementation flaws in PQC libraries.
Where TRUST and CRED meet the Access side
Both the TRUST and CRED posts noted that their dimensions reach across the Identity/Access split. PKI and PQC sharpen that observation.
The PQC migration is not confined to the Identity quadrant. Policy stores (OPA policy bundles, Cedar policy sets) must migrate to PQC-signed artifacts to prevent quantum-era tampering. That’s PRIV infrastructure. Audit logs require long-term signature integrity. That’s BEHAVE infrastructure. The post-quantum migration is a full-stack IAM problem, and framing it as a PKI project misses most of the work.
That’s the next two posts: PRIV and BEHAVE on the Access side, and what agents do to each.
For the full framework, see the Framework page. For the complete PQC migration playbook, including the five-phase timeline and the MAR schema, see the white paper.