Identity evidence that stays verifiable after the quantum transition.
Every verifiable credential and passkey session attestation PasskeyBridge issues is dual-signed by default: a classical signature for today's verifiers, ML-DSA-65 (NIST FIPS 204; ML-DSA-87 on the add-on) for the decade your audit evidence has to survive. No IdP migration, no token-format change.
- Ship post-quantum-signed identity credentials now.
- Answer the question your auditor will ask about long-lived identity artifacts: can the signature be forged once a quantum computer exists?
- Keep classical verifiers working: the classical signature is a standard JWS, and the post-quantum proof travels beside it.
- Upgrade signing strength per tenant: ML-DSA-65 by default, ML-DSA-87 as an Enterprise add-on.
Why identity is first in line for PQC
Most PQC roadmaps start with TLS, because harvest-now-decrypt-later targets encrypted traffic and that is where the tooling is. Signatures face a different threat: once a classical signature scheme can be broken, evidence signed with it can be forged. The long-lived artifact is what that exposes: audit logs that must stand up in seven years, verifiable credentials with multi-year validity, and signed authentication evidence referenced in disputes long after the session ended.
NIST finalized FIPS 204 (ML-DSA) in August 2024. CNSA 2.0 sets expectations for quantum-resistant signatures well before 2035, and long-lived evidence signed classically between now and then is the gap. Identity systems produce exactly that class of evidence, continuously.
What hybrid signing means here
Every verifiable credential, Security Event Token and passkey session attestation PasskeyBridge issues carries two signatures over the same JWS signing input, with a quantum-seeded nonce appended for the post-quantum signature: a classical ES256 (or ES384) JWS that today's infrastructure verifies natively, and a detached ML-DSA-65 signature (3,309 bytes, FIPS 204 security category 3; ML-DSA-87 on the add-on) designed to stay sound against a cryptographically relevant quantum computer.
Both signatures must cover the same input, or the two layers can diverge and the stronger one becomes unverifiable exactly when you need it. Nothing is re-serialized between them: the ML-DSA signature covers the same JWS signing input the classical signature covers, with a quantum-seeded nonce appended, so both layers attest the same facts.
- ML-DSA-65 on every credential by default.
- ML-DSA-87 (security category 5), the parameter set CNSA 2.0 specifies, available per tenant as an Enterprise add-on and paired with an ES384 (P-384) classical key.
- The ML-DSA public key is published in the tenant's DID document, so the post-quantum layer can be checked independently.
Signatures stored beside your credentials
PasskeyBridge sits beside your IdP as a verification layer, which is what makes the PQC story adoptable: your Okta, Entra, Ping, or OneLogin deployment keeps working unchanged while the credentials and attestations PasskeyBridge issues carry a quantum-resistant signature.
When your verifiers are ready to check ML-DSA directly, the signatures are already beside the credentials you have been storing. Crypto-agility here comes from the evidence format.
The PasskeyBridge approach
Dual-signed by default
Classical plus ML-DSA-65 (NIST FIPS 204) over the same JWS signing input, with a quantum-seeded nonce appended for the post-quantum signature, on every verifiable credential and passkey session attestation by default, so the evidence verifies today and after the transition.
Whitepaper →Verifiable with public keys only
The classical key (ES256, or ES384 on the add-on) and the ML-DSA key are published as verification methods in the tenant's DID document. Any JOSE library checks the classical layer and any FIPS 204 implementation checks the post-quantum one, with no PasskeyBridge secret: once the DID document is fetched, nothing else is needed from us.
Whitepaper →Nothing worth decrypting
Signal identifiers are stored only as keyed HMAC-SHA-256 digests under a server-held pepper, and anything reversible as AES-256-GCM ciphertext. A copy of those tables harvested today holds no plaintext identifier to decrypt later.
Privacy architecture →How PasskeyBridge differs from a PQC library
PasskeyBridge is a verification layer: it checks carrier state, passkeys, DPoP bindings and verifiable credentials, and the credentials and attestations it issues carry a post-quantum signature beside the classical one. If your team wants to build hybrid signing into your own stack, our engineering posts document the pitfalls.
Frequently asked
- Do I actually need post-quantum signatures for identity today?
- For session security alone, arguably not yet. For long-lived identity evidence, the math changes: audit records, signed authentication attestations, and verifiable credentials routinely need to remain trustworthy for five to ten years. Anything classically signed today and still relevant when a cryptographically relevant quantum computer exists becomes disputable retroactively. Signing hybrid now means evidence issued today does not depend on a classical scheme alone surviving that long.
- Why ML-DSA and not SLH-DSA?
- ML-DSA-65 offers a practical balance for high-volume signing: 3,309-byte signatures, fast verification, and NIST FIPS 204 standardization at security category 3. SLH-DSA (FIPS 205) has more conservative security assumptions but much larger signatures and slower signing, which matters at per-request attestation volume. Our published comparison covers when the more conservative choice is warranted; for per-tenant programs that require category 5, ML-DSA-87 is available as an Enterprise add-on.
- Does hybrid signing add latency to authentication?
- Not to the signal decision: the path from an incoming signal to its decision does no ML-DSA work. Signing happens where a credential or attestation is issued, and a passkey session attestation is requested after login, never on the login path. We have not published a timing for the signing step.
- Do we have to replace our IdP or change token formats?
- No. PasskeyBridge sits beside Okta, Entra, Ping, OneLogin, or a homegrown stack as an assertion source and verification gate. The classical layer is a standard compact JWS and the post-quantum proof travels beside it, so your existing sessions, tokens, and flows are untouched. Verifiers that only understand classical signatures keep working on the classical layer.
- How do we independently verify the ML-DSA layer?
- The ML-DSA public key is published as the #mldsa-1 verification method in the tenant's DID document. The detached proof signs the credential's JWS signing input with a quantum-seeded nonce appended, so any FIPS 204 implementation can check it against that key with no PasskeyBridge secret. The security documentation gives the exact signed input.
Guides for this
Talk to us
One reply gets you a 2-page architecture brief and a real latency probe against production.