Skip to content
Notes

Executive briefing

Post-quantum identity: five decisions before procurement

A credible transition begins with the trust paths an institution must preserve—not with an algorithm name on a product sheet. Five decisions help turn post-quantum intent into an accountable programme.

For Security leaders · public institutions · boards 8 min read

Published
Reviewed
Revision
1.1
Owner
AstraSutra Editorial
In this note 6 sections

01

Begin with the trust path, not the primitive

Post-quantum procurement is often framed as a search for a new algorithm. That is necessary, but it is not the programme. Identity systems distribute trust across enrolment, credentials, federation, workload identities, sessions, signing services, recovery procedures and audit records. A new primitive at one boundary does not repair an old assumption everywhere else.

The useful unit of analysis is therefore a trust path: who or what is making an assertion, which service validates it, what policy governs the result, how long the result remains meaningful and which evidence would survive a later dispute. This view gives executives a portfolio to govern and architects a sequence to test.

02

Decision 01 — define the exposure horizon

Not every identity object carries the same time risk. A short session token, a decade-long document signature, a firmware release key and an employee credential have different consequences if their cryptographic assumptions age badly. The first decision is which information and decisions must remain confidential, authentic or non-repudiable—and for how long.

That horizon should include data that an adversary could collect now and exploit later, as well as signatures whose value depends on long-term verification. For a public institution, the horizon may be shaped by archival duties and sovereign records. For a company, it may be product life, contractual exposure or the lifetime of critical intellectual property.

03

Decision 02 — inventory dependencies, not just certificates

A cryptographic inventory becomes useful when it connects algorithms to owners, systems, data flows and change windows. Counting certificates alone misses libraries, protocols, hardware roots, code-signing processes, partner integrations and evidence stores that may embed the same vulnerable assumption.

Each entry should answer a practical question: who can change it, what will break if it changes, how quickly it can be rotated, which external party must cooperate and what fallback is permitted. Unknown ownership is itself a migration risk because an unowned dependency cannot be prioritised or retired with confidence.

  • Identity object and business or mission purpose
  • Algorithm, protocol, library and trust anchor
  • System owner, supplier dependency and renewal window
  • Data or assertion lifetime and failure consequence
  • Migration state, approved fallback and observable evidence

04

Decision 03 — assign algorithms to explicit roles

Key establishment and digital signatures solve different problems. FIPS 203 specifies ML-KEM for establishing shared secrets; FIPS 204 and FIPS 205 specify different digital-signature approaches. A procurement statement should say which role is supported, at which boundary, with which parameter set and under which policy. The phrase ‘post-quantum enabled’ is too broad to answer any of those questions.

Role clarity also prevents a product’s strongest implemented path from being generalised across the whole identity estate. If a service protects selected envelopes with one mechanism but leaves credential issuance or audit verification on another, the accurate description is mixed—not complete and not necessarily deficient. It is a transition state that must be governed.

05

Decision 04 — design coexistence and downgrade control

Institutions rarely migrate every relying system at once. Classical and post-quantum mechanisms may coexist across suppliers, jurisdictions and refresh cycles. The security question is not simply whether coexistence is possible; it is who may select the weaker path, how that selection is recorded and when the fallback expires.

A sound transition defines negotiation policy, exception ownership, rollback criteria and evidence for downgrade attempts. It also tests size, latency, interoperability and failure behaviour in the real operating environment. A hybrid design can reduce transition risk, but only when both success and failure states are observable and the legacy path has an exit plan.

06

Decision 05 — procure lifecycle evidence

An algorithm demonstration proves very little about an identity service. Decision-makers should ask for evidence across issuance, verification, rotation, revocation, replay resistance, recovery, policy change and audit continuity. They should also ask which claims come from executable tests, which depend on a specific environment and which remain design intent.

This makes procurement a staged assurance exercise rather than a binary feature check. Begin with a bounded trust path, agree the expected evidence, test adverse and recovery conditions, and expand only when the institution can explain both the protection and its operational limits.