If you verify eligibility outcomes, you already trust a signature. Today that is often ECDSA on a P-256 curve: small, fast, everywhere. The problem is not tomorrow's outage. It is tomorrow's attacker with a cryptographically relevant quantum computer, and the NCSC migration clock that already runs.
Picture a housing association that stores five years of right-to-rent attestations. Each record carries a compact ECDSA signature that verifiers check in milliseconds. That design is sound for 2026. The question is whether those signatures still mean anything in 2036 if the private key material was ever exposed to a harvest-now-decrypt-later adversary. Attestations are long-lived. Algorithms should be chosen with that horizon in mind.
ECDSA vs ML-DSA-65 at a glance
| Property | ECDSA (P-256) | ML-DSA-65 (FIPS 204) |
|---|---|---|
| Quantum resistance | No | Designed for post-quantum security |
| Typical signature size | ~64 bytes | ~3.3 KB |
| Public key size | ~33 bytes compressed | ~1.9 KB |
| Verifier ecosystem | Universal | Growing, must be pinned |
| NCSC migration priority | Deprioritise for new attestations | Preferred for new high-value proofs |
What changes for verifiers
When attestations move to ML-DSA-65, verifiers gain three new jobs. First, algorithm negotiation: reject ambiguous signatures and pin ML-DSA-65 for new proofs while you sunset ECDSA on a published timeline. Second, payload budgeting: larger signatures affect JWTs, webhooks, and offline QR codes, so measure your worst case now. Third, key rotation: publish and pin ML-DSA public keys the same way you pin TLS certificates.
Post-quantum migration is not a library upgrade you schedule for next quarter. It is a contract with future auditors about whether today's yes still proves anything tomorrow.
Operational note: log which algorithm validated each decision. Mixed fleets are normal for years. Ambiguous logs are not.
Coexistence strategy
Most teams will run dual verify for a period: accept ECDSA on legacy attestations with short TTL, issue ML-DSA-65 on all new proofs. Document the cutover date in your security policy and in customer-facing API docs.
AffixIO signs eligibility outcomes with ML-DSA-65 today, so the attestation path is not waiting on a future migration project. Read the NCSC alignment page at NCSC, benchmark your estate with PQC Gauge, and review verify responsibilities on Security.
Where size actually hurts
Three integration points feel the signature growth first. HTTP headers and webhook bodies that assumed 64-byte signatures may hit proxy limits. QR codes that embed signed outcomes need larger modules or shorter TTL with online verify. Offline queues on edge devices need storage headroom for provisional payloads. None of these are blockers if you measure early.
On the host
The prove step
Where AffixIO fits in your attestation path
Post-quantum work is an estate programme. Eligibility attestations are a sharp place to start because the records last. AffixIO signs those outcomes with ML-DSA-65 now.
- StaysDecision host
- Runs hereSign ML-DSA-65
- LeavesKeyed outcome
It sits at the moment your system says eligible or not eligible. Verifiers pin public keys, check signatures, and log the algorithm. ECDSA elsewhere can follow a published cutover. This path does not wait on 2031.
What stays on the host
What the verifier receives
- An explicit algorithm. Not a buried bureau score.
- A public key to pin. Dual-run logs can name which algorithm validated each decision.
- No extra migration debt. New proofs on this path are already ML-DSA-65.
- A size you can measure. Run proofs on a real integration before you freeze message formats.