Identity beyond classical public-key assumptions

Much of today’s identity infrastructure uses RSA or elliptic-curve cryptography to authenticate credentials, establish protected sessions and sign evidence. On classical computers, their security rests on the difficulty of integer factorisation and discrete logarithms. Shor’s algorithm shows that a sufficiently capable quantum computer would alter that premise.

The responsible response is not to predict an arrival date. It is to identify which trust decisions would be exposed, how long their value persists and how the organisation can migrate before urgency removes its choices.

NIST’s first three final post-quantum standards define important building blocks. FIPS 203 specifies ML-KEM for key establishment. FIPS 204 specifies ML-DSA digital signatures, and FIPS 205 specifies the stateless hash-based SLH-DSA signature scheme.

These standards let organisations use publicly reviewed mechanisms rather than inventing cryptography. They do not decide where a relying party should trust an assertion, how a session should be revoked, which partner can interoperate during transition or what evidence makes a later audit credible. Those remain system responsibilities.

A person or workload may be enrolled in a directory, receive a credential, exchange it through a federation service, obtain a session and leave signed evidence behind. Each object has its own issuer, verifier, lifetime and recovery path. A post-quantum option at the transport layer does not automatically change the credential or the evidence.

Migration should therefore map the chain and its ownership. Where can algorithms change independently? Which formats carry fixed-size assumptions? Which verifiers are outside institutional control? Which audit records must remain meaningful after the issuing key rotates? These questions reveal the real programme surface.

Crypto-agility is sometimes described as an abstraction layer. In operation it is a governed ability to introduce, select, rotate, deprecate and remove algorithms without losing policy or evidence. The technical interface matters, but so do ownership, compatibility, safe defaults, downgrade control and observability.

A system is not agile merely because it supports multiple algorithms. It is agile when the organisation can explain which one is active for a particular trust path, why it was selected, how exceptions expire and what proves that a retirement actually occurred.

Start with a cryptographic inventory linked to identity objects and data lifetimes. Prioritise long-lived confidentiality and verification, externally dependent trust paths and components with slow replacement cycles. Test coexistence in bounded environments before expanding scope.

Most importantly, preserve the distinction between standards alignment and system assurance. Using a standardised primitive is valuable; proving that the whole identity decision is secure, recoverable and operable requires architecture, implementation evidence and continuing governance.