Identity evidence that stays verifiable after the quantum transition.
Every PasskeyBridge attestation is dual-signed: a classical signature for today's verifiers, ML-DSA-65 (NIST FIPS 204) for the decade your audit evidence has to survive. No IdP migration, no token-format change.
- Ship post-quantum-signed identity attestations now, not after a rewrite.
- Answer the harvest-now-decrypt-later question your auditor will ask about long-lived identity artifacts.
- Keep classical verifiers working: both signatures ride the same attestation.
- Upgrade signing strength per tenant—ML-DSA-65 baseline, ML-DSA-87 as an Enterprise add-on.
Why identity is first in line for PQC
Most PQC roadmaps start with TLS because that is where the tooling is. But the long-lived artifact, more than the session, is what harvest-now-decrypt-later 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. An attacker recording that traffic today is betting the signature scheme breaks before the artifact stops mattering.
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 attestation PasskeyBridge emits carries two signatures over the same JCS-canonicalized payload: a classical signature that today's infrastructure verifies natively, and an ML-DSA-65 signature (3,309 bytes, FIPS 204 security category 3) that remains sound against a cryptographically relevant quantum computer.
Canonicalization is the part most hybrid designs get wrong. Both signatures must cover byte-identical input, or the two layers can diverge and the stronger one becomes unverifiable exactly when you need it. We canonicalize with RFC 8785 JCS before either signature is computed, so the classical layer and the PQ layer attest the same facts.
- ML-DSA-65 on every attestation by default—not a premium flag, the baseline.
- ML-DSA-87 (security category 5) available per-tenant as an Enterprise add-on for CNSA-aligned programs.
- Public verification key published, so the PQ layer can be checked independently.
A migration path, not a migration project
PasskeyBridge sits in front of 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 identity evidence it relies on becomes quantum-resistant at the attestation layer.
When your verifiers are ready to check ML-DSA directly, the signatures are already in the payloads you have been storing. Crypto-agility here is a property of the evidence format, not a forklift upgrade scheduled for 2029.
The PasskeyBridge approach
Dual-signed by default
Classical plus ML-DSA-65 (NIST FIPS 204) over a JCS-canonicalized payload on every attestation, so the evidence verifies today and after the transition.
Whitepaper →No latency line item for PQC
The hybrid signature rides the same verification request. Warm ML-DSA-65 signing is sub-millisecond, so post-quantum assurance costs no measurable latency.
Run a live probe →Nothing worth decrypting
Identifiers are stored only as keyed HMAC-SHA-256 digests under a server-held pepper. Harvest-now-decrypt-later needs plaintext worth harvesting; the data model does not keep any.
Privacy architecture →We are not a PQC library
PasskeyBridge does not sell you liboqs bindings or a crypto toolkit to integrate. It is a verification layer that emits post-quantum-signed identity attestations as a side effect of doing its actual job: checking passkeys, carrier state, DPoP bindings, and verifiable credentials in one request. If your team wants to build hybrid signing into your own stack, our engineering posts document the pitfalls. If you want PQ-signed identity evidence in production this quarter, that is the product.
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 removes that entire class of future dispute at near-zero marginal cost.
- 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?
- Warm ML-DSA-65 signing is sub-millisecond, so the hybrid signature adds no measurable time; the latency is dominated by the same network and signal-fetch costs as any verification call. You can measure it yourself from the playground, which runs against production.
- Do we have to replace our IdP or change token formats?
- No. PasskeyBridge sits in front of Okta, Entra, Ping, OneLogin, or a homegrown stack as an assertion source and verification gate. The hybrid signatures live inside the attestation payloads; 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 verification key is published, and attestation payloads are JCS-canonicalized per RFC 8785, so the PQ signature can be checked with any FIPS 204 implementation. The playground issues real signed responses from production if you want to inspect one before talking to anyone.
Guides for this
Talk to us
One reply gets you a 2-page architecture brief and a real latency probe against production. No demo booking required.