up:: In the Protocols MOC

The Token-Key Question

The token-key question is a single question, asked of whoever runs the identity provider, in these words: “which algorithm do we sign our tokens with, and who holds that key?” It exists because the identity provider’s signing key, the one credential that can mint a valid login for any user in the company, almost never appears in a cryptographic inventory, since the team that owns single sign-on is rarely the team that owns the certificates most inventories are built to find.

The question comes with a built-in self-check: an OpenID Connect identity provider publishes its signing keys at a public well-known address (the JWKS endpoint), with the key type and often the algorithm named right inside the document. What you walk away with is 3 things: the algorithm, the key’s owner, and an honest answer to whether that owner is a team down the hall or a vendor you can only email.

The short version:

• The question is asked verbatim of whoever runs the identity provider: “which algorithm do we sign our tokens with, and who holds that key?”
• It works because the IdP signing key systematically escapes inventories. SSO belongs to the identity team, inventories are built by the PKI team, and the key sits in the gap between them.
• The stakes are total. One signing key underwrites every SAML assertion, OIDC token, and downstream trust decision, so a forgeable key forges every identity at once.
• The self-check is public. The .well-known/openid-configuration document points to the jwks_uri, and the keys published there carry their type (kty) and often their algorithm (alg), so you can verify part of the answer yourself before anyone answers.
• It’s a targeted application of 2 of the four questions (which algorithm, who controls it), aimed at the one key that most reliably slips through the other 2.

Picture a facilities log that lists every door key, badge reader, and lock cylinder in the building, kept meticulously. The grand-master key that opens every door is missing from the log, because it hangs on a keyring at the property-management company across town, and since their name is on the lease, nobody on your side ever handled it or thought to list it. The token-key question is the tenant finally asking the property manager 2 things: what kind of blank is the grand master cut on, and whose keyring is it on? The awkward part, and the useful part, is that the property manager pins the key’s spec sheet in the lobby for anyone to read, so you can learn the answer to the first half yourself, and the fact that your own team had to go look is a finding all by itself.

What is the token-key question?

The token-key question is a named diagnostic for the identity layer of a post-quantum migration, and it has 3 components:

1. The question itself, asked in these words of whoever operates the identity provider: “which algorithm do we sign our tokens with, and who holds that key?” Both halves are load-bearing. The algorithm decides whether the key is quantum-exposed, and the owner decides whether fixing it is an internal ticket or a vendor negotiation.
2. The self-check. An OIDC identity provider publishes its signing keys at a public JWKS endpoint, discoverable through a standardized well-known address, so part of the answer is verifiable from a browser without asking anyone. The walkthrough is below.
3. The output. The algorithm’s name, the key’s owner as a person or accountable function, and an honest classification of that owner: a team down the hall you can task, or a vendor whose migration schedule you can only ask about.

It applies wherever an identity provider issues signed tokens or assertions that downstream systems trust: workforce single sign-on, customer identity, B2B federation, and machine-to-machine token issuance. It’s the right first move in the identity layer precisely because it costs one conversation and returns the location of the highest-consequence key in the estate.

It stops applying, or rather degrades into something gentler, when the signing key is already inventoried, owned, and inside your own HSM, which happens with well-run self-hosted identity providers. That case is covered under where the question breaks, and the short answer is that the question still pays for itself as a confirmation.

Structurally, the token-key question is 2 of the four questions of cryptographic inventory (which algorithm, who controls it) compressed into one sentence and aimed at a single key, because that key is the one an inventory built around certificates most reliably misses.

Why does the IdP signing key escape cryptographic inventories?

Because inventories inherit the org chart, and the org chart splits the identity layer from the certificate layer. A cryptographic discovery effort that starts from “find our TLS certificates and our PKI” gets scoped to, and staffed by, the PKI and network teams. Token-signing keys live somewhere else entirely: inside the identity provider, the authorization server, or an API gateway, managed by identity and platform engineers who think of what they run as “the auth config” rather than as cryptography. The JWT note carries the full mechanics; the structural facts that matter here are these:

1. The signing key sits outside the certificate estate. A token-signing key is frequently a raw key published as a JSON Web Key at a JWKS endpoint rather than an X.509 certificate in a certificate store, so tooling that enumerates certificates walks right past it. (SAML is the partial exception: its signing keys do travel as certificates, distributed inside federation metadata, and they’re still owned by the IAM team or a SaaS vendor rather than by whoever runs the inventory.)
2. The architectural fact is visible while the cryptographic fact is buried. A team can tell you an application “uses SSO” or “uses bearer tokens” while having no idea which alg the issuer signs with, because knowing the architecture never required opening a token header or reading the JWKS.
3. The owner is often outside the company. For a large share of enterprises the identity provider is a cloud service, so the key is the vendor’s, generated on their infrastructure, rotated on their schedule, migrated on their roadmap. A vendor-controlled surface appears in your inventory only if someone deliberately puts it there.

Source: M. Jones, “JSON Web Key (JWK),” RFC 7517, May 2015, datatracker.ietf.org.

The result is a precise and repeatable blind spot: the crypto map covers the estate and has a hole exactly where the most powerful credential sits. Ownership of the token layer has to be assigned deliberately, and the token-key question is the sentence that starts that assignment.

What happens if the identity provider’s signing key becomes forgeable?

Every identity the provider vouches for becomes forgeable with it, at the same moment. When an employee signs into an application through single sign-on, the identity provider issues a signed statement that the person is who they claim to be: SAML calls it an assertion, OpenID Connect calls it an ID token, and underneath both is a classical digital signature (RSA or ECDSA today) that every downstream application verifies locally and trusts completely. Shor’s algorithm on a cryptographically relevant quantum computer recovers a private key from its public counterpart, and the IdP’s public key is published at a well-known address by design.

Source: P. W. Shor, “Polynomial-Time Algorithms for Prime Factorization and Discrete Logarithms on a Quantum Computer,” SIAM J. Comput. 26(5), 1997, arxiv.org. Elliptic-curve instantiation, M. Roetteler, M. Naehrig, K. Svore, K. Lauter, “Quantum resource estimates for computing elliptic curve discrete logarithms,” arXiv:1706.06752, 2017, arxiv.org. Shor’s 1997 paper covers factoring and discrete logarithms in multiplicative groups and does not address elliptic curves.

An attacker holding the recovered private key mints tokens saying whatever they want, and the damage runs in 4 directions at once:

1. Sign in as anyone. A forged ID token or assertion names the CFO, a domain administrator, or a service account, and every relying application accepts it, because the signature verifies.
2. Assert anything. Roles, groups, scopes, and entitlements are claims inside the token, and a forger writes the claims.
3. Bypass the login ceremony entirely. The attacker never touches the real IdP, never trips a failed-login alert, and never faces the MFA prompt, because they present the finished product, a valid signed token, directly to the applications that trust it.
4. Cross every boundary the IdP federates. One authorization server underwrites every API and SaaS integration that trusts it, so the blast radius of this single key is routinely the entire organization.

This is the identity-layer twin of the worst case in the certificate world, where breaking one root certificate authority’s key makes every certificate beneath it forgeable at once (PKI Collapse). One key, total reach, which is exactly why a key with this consequence profile being absent from the inventory is the finding the question exists to surface.

How do you run the JWKS self-check?

For any OpenID Connect identity provider, the signing keys are published at a public, standardized address, and reading them takes about 2 minutes. The chain has 3 steps:

1. Fetch the discovery document. Take the issuer URL (the iss value your tokens carry) and append /.well-known/openid-configuration. OpenID Connect Discovery requires providers that support discovery to serve a JSON document at exactly that path.
2. Follow jwks_uri. Inside the discovery document, the jwks_uri field is REQUIRED, and it’s the URL of the provider’s JWK Set. The same document also carries id_token_signing_alg_values_supported, a REQUIRED list of the JWS signing algorithms the provider supports for ID tokens, which names the algorithm family even before you open the key set.
3. Read the keys. The JWK Set is a JSON object whose keys member is an array of keys. Each key MUST carry a kty (key type) field, RSA or EC for the classical families, and often carries alg (the specific algorithm, like RS256 or ES256) and kid (the key ID that matches the header of the tokens it signed).

Source: OpenID Foundation, “OpenID Connect Discovery 1.0,” §4 (obtaining provider configuration, the /.well-known/openid-configuration path) and §3 (provider metadata, jwks_uri and id_token_signing_alg_values_supported, both REQUIRED), openid.net.

Source: M. Jones, “JSON Web Key (JWK),” RFC 7517, §4.1 (kty MUST be present), §4.4 (alg is OPTIONAL), §5.1 (the keys array), May 2015, datatracker.ietf.org.

One precision detail keeps the check honest: alg is optional in a JWK, so a key set may tell you only that the key is RSA or EC without naming the exact algorithm. When that happens, the algorithm is still readable in 2 other places, both authoritative. The discovery document’s id_token_signing_alg_values_supported list is required to be there, and the header of any live token names the algorithm actually used in its alg field, which the JWS specification requires.

Source: M. Jones, J. Bradley, N. Sakimura, “JSON Web Signature (JWS),” RFC 7515, §4.1.1 (the alg header parameter), May 2015, datatracker.ietf.org.

What the check tells you, and what it deliberately leaves for the human: reading RS256 or ES256 in the JWKS tells you the signature is RSA or ECDSA, both quantum-forgeable, which as of 2026 describes essentially every production deployment. What the endpoint can never tell you is the second half of the question, who holds the key, and that half is why the question is asked of a person rather than typed into a browser. The sharpest version of the finding is the combination: if nobody on the team can name the algorithm without going to look it up at the public address, then nobody has been watching the one credential that authenticates the entire workforce.

For SAML-only environments the same check exists at a different address: the IdP’s signing certificate is published in its federation metadata, the signed XML document partners exchange, so the algorithm is readable from the certificate inside it.

Source: N. Ragouzis et al., “SAML V2.0 Technical Overview,” OASIS Committee Draft 02, March 2008, docs.oasis-open.org.

Which parts of the identity stack does the question cover?

The question targets token and assertion signing, and it lands differently across the 4 big authentication surfaces, because they run different cryptography in different places. The table is the coverage map.

Auth surface	What signs it	Where the signing key usually lives	Quantum exposure
OIDC ID and access tokens (JWTs)	RS256 / ES256 (RSA / ECDSA)	The IdP or authorization server, very often a cloud vendor	Forgeable by Shor’s; Non-HNDL trust forgery
SAML assertions	XML Signature, RSA / ECDSA	The IdP, owned by the IAM team or a SaaS platform	Forgeable by Shor’s; Non-HNDL trust forgery
Kerberos tickets	Symmetric AES encryption	The domain controllers (the KDC)	Largely resistant; Grover only trims the margin
PKINIT / smart-card logon + AD CS	RSA / Diffie-Hellman certificates	Active Directory Certificate Services (your CA)	Broken by Shor’s; the exposed edge of Kerberos
Passkeys (WebAuthn assertions)	ES256 / EdDSA / RS256 per credential	The user’s authenticator; trust anchored at the relying party	Forgeable at CRQC arrival; Non-HNDL, covered in FIDO2, WebAuthn, and Passkeys

The Kerberos row deserves the precision, because it’s where reassuring and exposed sit closest together. The Kerberos core is symmetric: tickets are encrypted with AES keys per RFC 3962, and Grover against AES-256 leaves an effective 128-bit margin, so the ticket machinery is a strengthen-in-place surface with no algorithm swap needed.

The quantum-exposed edges of a Windows estate are the public-key attachments: PKINIT (RFC 4556), the certificate-based pre-authentication that smart-card logon runs on, and Active Directory Certificate Services, the internal CA whose classical signing keys issue those certificates. So the token-key question, pointed at an AD estate, correctly skips the ticket keys and lands on the AD CS signing keys and any federation service (like SAML or OIDC issuance bolted onto the domain) that signs with classical algorithms. The full split lives in PQC in Kerberos and Active Directory.

Source: IETF, “Advanced Encryption Standard (AES) Encryption for Kerberos 5,” RFC 3962, February 2005, datatracker.ietf.org; IETF, “Public Key Cryptography for Initial Authentication in Kerberos (PKINIT),” RFC 4556, June 2006, datatracker.ietf.org.

The OAuth flow layer adds surfaces beyond the token itself (DPoP proofs, mTLS-bound tokens, client assertions, signed requests), each carrying its own classical signature; PQC in OAuth 2.0 and OIDC maps them. The token-key question is the entry point, and the OAuth note is where the answer fans out for estates that use the sender-constrained patterns.

When does the forgery risk actually start?

The identity layer runs on the forgery clock, and the timing is counterintuitive in both directions, so it’s worth stating plainly before anyone sequences the work. A login is a live event: the system signs a fresh challenge or issues a fresh token in the moment, and a recorded login from 2026 is worthless to an attacker in 2033, because that session ended years earlier and can’t be replayed. So authentication traffic is accumulating no risk today, which is genuine relief, and it separates the identity layer from the stored-data surfaces racing the harvest clock.

The same fact removes the grace period. Because the exposure arrives through forgery rather than through decrypting a backlog, there’s no gradual onset: the day forgery becomes possible, every classical signing key still in service is exposed at once, simultaneously, with the IdP key’s total blast radius attached. Being slightly late on this surface means being fully exposed on it.

That’s the whole timing argument this note needs, because the full layer, the lanes, the pacing discipline, and why a deliberate track still has to start early, is The Two-Lane Split: token signing sits in the deliberate lane, and that lane ends at a cliff rather than a runway. The mechanics of why nothing recorded in advance speeds the attacker up live in Forge-Later Attack and Non-HNDL, and this note leans on all 3 rather than re-deriving them.

What the migration lands on, once the question has located the key: ML-DSA is the standardized post-quantum signature, and RFC 9964 registers the JOSE and COSE algorithm identifiers (ML-DSA-44, ML-DSA-65, ML-DSA-87) that let a token, proof, or credential name a post-quantum alg. The deployment friction is size: an ML-DSA-65 signature is 3,309 bytes where an ES256 signature is a small fraction of that, and tokens ride in HTTP headers and cookies with hard limits, which is the sizing work the JWT note walks through.

Sources: M. Prorock, O. Steele, “ML-DSA for JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE),” RFC 9964, May 2026, datatracker.ietf.org, for the JOSE and COSE registrations and the Table 1 signature sizes; NIST, “Module-Lattice-Based Digital Signature Standard,” FIPS 204, August 2024, csrc.nist.gov, which is where RFC 9964 takes those sizes from.

What does running the token-key question look like on a real estate?

Take a generic mid-sized company: a cloud identity provider for workforce SSO (OIDC to most apps, SAML to a few older ones), an on-prem Active Directory domain, passkeys freshly rolled out for workforce login, and an API platform that mints its own service tokens. Here’s the question, run end to end.

1. Before the meeting, run the self-check. The issuer URL plus /.well-known/openid-configuration resolves in a browser; jwks_uri leads to a key set whose first key reads "kty": "RSA" with "alg": "RS256". 2 minutes in, half the answer is already on screen: workforce tokens are RSA-signed, which is quantum-forgeable.
2. Ask the question in the IAM team’s channel, verbatim. “Which algorithm do we sign our tokens with, and who holds that key?” The reply arrives a day later: “RS256, I think, and the key is managed by the IdP, it’s in their cloud.” The delay and the “I think” are data. Nobody had been watching this key, which the self-check already suggested.
3. Classify the owner honestly. The workforce signing key is the vendor’s: generated on their infrastructure, rotated on their schedule, migrated when their roadmap says so. That’s the “vendor you can only email” outcome, and it converts the follow-up from an engineering ticket into a written vendor question about which of their migration milestones covers token signing.
4. Let the question fan out, because one issuer is never the whole answer. The API platform turns out to run its own issuer, ES256, key in a configuration file that hasn’t been rotated since the platform launched, owned by a platform engineer who never considered it cryptography. The AD estate contributes its own row: ticket encryption is symmetric AES and fine, while AD CS signs certificate logon with classical RSA keys that are squarely in scope. The passkey rollout contributes per-credential ECDSA signatures, real but lower blast radius than the central issuers.
5. Write down the output. 3 lines per issuer: the algorithm, the named owner, and the owner classification. For this estate that’s 4 issuers, 2 of them vendor-controlled, 1 of them previously invisible, and a ranked follow-up list that starts with the highest-blast-radius key (the workforce IdP) rather than the most visible one.

The question cost 1 conversation and a browser tab, and the estate now knows where its most dangerous credential lives, which is the entire point. Sequencing what happens next is the job of The Two-Lane Split and the inventory disciplines in The Four Questions.

How do you use the token-key question in the boardroom?

One level up, the question converts from a diagnostic into an accountability instrument, because it’s short enough to ask in a leadership meeting and specific enough that the answer can’t stay vague. The deployable version: “there is one key that can sign in as any of us. Which algorithm is it, and who holds it?” Any room can follow that sentence, and it forces the 3-part output into the open: an algorithm, an owner, and an honest statement of whether the owner works for you.

2 boardroom dynamics make it land:

1. The answer is checkable in advance. Running the JWKS self-check before the meeting means you already know whether the answer you’re given is right, which changes the conversation from asking for information into verifying stewardship. An answer that has to be looked up live makes the governance gap visible to the whole room without anyone saying it.
2. The vendor finding reframes the budget conversation. When the answer is “a cloud vendor holds it,” the room learns that its most dangerous credential is the one it has the least authority over, and the follow-up becomes contractual rather than technical: which of the vendor’s published migration milestones covers token signing, in writing. For calibration, the federal government’s own binding deadlines put post-quantum signatures on high-impact federal systems by December 31, 2031 under Executive Order 14412, which is a citable anchor when a director asks why identity signing deserves a date at all.

Source: Executive Order 14412, “Securing the Nation Against Advanced Cryptographic Attacks,” 91 FR 38483, June 25, 2026, federalregister.gov.

Common misconceptions

1. “We went passwordless, so we’re ahead on quantum.” Passwordless is a real improvement, and it solves the harvest problem for logins, because a signature is verified live and no shared secret crosses the wire. The quantum risk is relocated rather than removed: every passkey signs with classical ECDSA, EdDSA, or RSA, so the credential got stronger while the math underneath stayed exactly as breakable. FIDO2, WebAuthn, and Passkeys carries the full picture, including the standardized ML-DSA path forward.
2. “Our auth is fine because Kerberos and AD are symmetric.” The core is, and the reassuring half hides the exposed half. PKINIT certificate logon and the AD CS certificate authority are classical public-key surfaces, and they’re exactly where the token-key question points in a Windows estate.
3. “Authentication is a harvest-now problem like our data.” It runs on a different clock. There’s nothing to harvest in a login, so no risk is accumulating today, and there’s also no grace period: the day forgery becomes possible, every classical signing key is exposed at once. Treating identity signing as “HNDL with extra steps” gets both the present and the deadline wrong.
4. “Our tokens expire in an hour, so we’re fine.” Expiry bounds the life of a stolen token, and a quantum attacker holding the signing key steals nothing. They mint fresh tokens, each with whatever expiry they choose, for as long as the key stays classical. Short token lifetimes are good hygiene against theft and do nothing against forgery.
5. “MFA protects us from quantum attacks.” MFA hardens the login ceremony, and a forged IdP token skips the ceremony entirely. The attacker presents a finished, validly signed token directly to the relying application, claims included (OIDC tokens can even carry a claim asserting which authentication methods were used, and a forger writes the claims). MFA is worth having and sits on the wrong layer to help here.
6. “Key rotation protects the signing key.” Rotation replaces one classical key with another classical key, which resets nothing that matters to Shor’s algorithm, since each new public key is published at the same JWKS address. Rotation is operational hygiene; the quantum fix is the algorithm changing, which is visible in the same JWKS as an ML-DSA-* entry.
7. “The IdP is the vendor’s problem.” The key is the vendor’s; the blast radius is yours. A vendor migrates token signing on their schedule, and the accountability for knowing that schedule, in writing, stays with whoever owns identity risk internally. The question’s third output, the owner classification, exists precisely so this line lands on the record.

Pro tips

1. Run the JWKS check before you ask the question. 2 minutes in a browser means you walk into the meeting already knowing the algorithm, so you’re verifying the answer rather than requesting it. A confident wrong answer, and you’ll get some, is a sharper finding than a slow right one.
2. When the JWK omits alg, read the other 2 addresses. The alg field is optional in a JWK (RFC 7517 §4.4), so a key set that only says "kty": "RSA" hasn’t named the exact algorithm. The discovery document’s id_token_signing_alg_values_supported list is required to be present, and any live token’s header carries the alg actually in use. Between the 3, the algorithm is always readable.
3. When the answer is a cloud vendor, the follow-up is a written milestone question. Ask which of the vendor’s post-quantum migration milestones covers token signing specifically, and get the reply in writing. A roadmap that mentions “post-quantum support” without naming token signing has answered a different question, and the written reply becomes an audit artifact either way.
4. Ask for the owner as a name, and keep asking past “it’s managed.” “The platform team” and “it’s managed by the IdP” are where accountability goes to rest. The productive follow-ups are concrete: where does the private key material physically reside, and who can execute a rotation? Whoever can rotate it holds it.
5. Run the question once per issuer, because the IdP everyone names first is rarely the only one. API gateways, service meshes, internal developer platforms, and legacy apps each mint their own tokens with their own keys. The workforce IdP is the highest blast radius; the forgotten internal issuer with the key in a config file is the one the inventory was never going to find.
6. Put the 3 outputs in the risk register, per issuer. Algorithm, owner, owner classification. Written that way, the finding survives staff turnover, feeds the CBOM a row it structurally lacked, and gives the vendor-controlled entries a place where their milestone answers get tracked.

Where does the token-key question break?

Published limits, because a diagnostic you can’t break is a diagnostic you haven’t tested:

1. Self-hosted IdPs with the key already inventoried. An estate running its own identity provider, key generated in an HSM, listed in the CBOM, owned by a named engineer, has already answered the question. There it degrades gracefully into a confirmation, and it still earns its 2 minutes: the algorithm half of the answer is almost certainly RS256 or ES256, so the key being found says nothing about it being migrated, and confirming the owner can actually execute an algorithm change (rather than just a rotation) is the agility question hiding inside the confirmation.
2. HMAC-signed internal tokens. Issuers signing with HS256 run on a shared symmetric secret, which Shor’s never touches, so the algorithm half of the question returns a genuinely reassuring answer. The ownership half still matters, because a shared secret’s risk is sprawl (every verifier holds it), and that’s a classical problem the question surfaces without the quantum urgency attached.
3. Estates with dozens of issuers. The question is built for the conversation where one key is being located. At 30 issuers it stops being a question and becomes a census, which is inventory work: The Four Questions applied across the token layer, with the token-key question surviving as the per-issuer row format.
4. The question locates; it never migrates. The output is a found key, a named owner, and a classification. Sequencing the migration it triggers belongs to The Two-Lane Split, and executing it belongs to whoever the owner turned out to be, which is exactly the information the question was built to produce.

Questions people ask

What exactly do I ask, and who do I ask? Ask whoever operates your identity provider, in these words: “which algorithm do we sign our tokens with, and who holds that key?” In most organizations that’s the IAM or identity team for workforce SSO, plus the platform team for any internal token issuers. Ask it once per issuer.

What is a JWKS endpoint and how do I find mine? It’s the public URL where an OIDC identity provider publishes its signing keys as a JSON Web Key Set. Take your issuer URL, append /.well-known/openid-configuration, and follow the jwks_uri field in the document that comes back. Both the path and the field are required by the OpenID Connect Discovery specification.

What does a good answer look like? A named algorithm, a named owner who can execute an algorithm change, and no surprise between what they said and what the JWKS shows. As of 2026 the algorithm will almost certainly be classical (RS256 or ES256), so “good” means the key is known, owned, and on a migration path, rather than already post-quantum.

What if the key in the JWKS has no alg field? That’s allowed, since alg is optional in a JWK. Read the algorithm from the discovery document’s id_token_signing_alg_values_supported list, which is required to be present, or from the alg header of any live token the issuer signed.

What replaces RS256 and ES256? ML-DSA, the NIST post-quantum signature standard. RFC 9964 registers ML-DSA-44, ML-DSA-65, and ML-DSA-87 as JOSE algorithm identifiers, so a post-quantum issuer publishes an ML-DSA key at the same JWKS address and names the new alg the same way. The migration mechanics, including the kilobytes-larger signatures against header and cookie limits, live in JWT.

Does the question work for SAML, where there’s no JWKS? Yes, at a different address. A SAML IdP’s signing certificate is published in its federation metadata, so the algorithm is readable from the certificate there, and the ownership half of the question is identical. SAML carries the full signing and migration picture.

Are Kerberos tickets part of this? The tickets themselves aren’t, because they’re encrypted with symmetric AES, which survives the quantum era with its margin trimmed rather than broken. The question’s targets in a Windows estate are the public-key edges: AD CS signing keys, PKINIT certificate logon, and any federation service issuing signed tokens on top of the domain. PQC in Kerberos and Active Directory draws the exact line.

When does this have to be fixed? Before a cryptographically relevant quantum computer exists, with lead time for a migration that touches every verifier that trusts the issuer. There’s no accumulating exposure today, and there’s no partial exposure at the end: the day forgery is possible, the key’s whole blast radius arrives at once. For a federal calibration point, EO 14412 requires post-quantum signatures on high-impact federal systems by December 31, 2031. The sequencing logic lives in The Two-Lane Split.

My IdP is a major cloud provider. Isn’t this their job? Executing the migration of their signing infrastructure is their job. Knowing their timeline for it, in writing, at the granularity of “token signing” rather than “post-quantum support,” is yours, because your entire workforce’s identity rides on their schedule. That asymmetry is the third output of the question, and it’s the finding most estates walk away with.

Is this the same as running a cryptographic inventory? It’s a targeted extraction from one. The token-key question applies 2 of the four questions to the single key that most reliably escapes inventories, so it pays off in one conversation instead of one program. The full inventory still matters, and this question is how the token layer gets into it.

---

Everything here is the map, given freely. The token-key question answered across your own estate, every issuer located, every owner named, every vendor milestone pinned down in writing, is the work I do. Request the workshop.

Last verified 2026-07-26 · Updated 2026-08-25 · Maintained by Addie LaMarr, LaMarr Labs.