Post-quantum migration begins with a deceptively simple question: which business functions depend on cryptography that the organization may need to replace? A list of certificate expiry dates cannot answer it. The dependencies also include protocols, signatures, libraries, hardware, suppliers, and data whose confidentiality must survive for years.
NIST finalized IR 8547, Transition to Post-Quantum Cryptography Standards, on October 27, 2026. The report describes a transition from quantum-vulnerable public-key algorithms to post-quantum signatures and key-establishment schemes. It is a planning reference; it does not make an arbitrary product quantum-resistant because its marketing mentions the report.
Give the cryptographic inventory a business owner
Choose a manageable starting scope, such as one externally exposed application and its dependencies. Name the service owner who understands the business impact and the technical owner who can verify the implementation. Capture uncertainty explicitly instead of filling missing fields with assumptions.
For each dependency, record its purpose, algorithm or protocol where known, implementation, key or certificate location, provider, replacement constraints, and evidence source. Distinguish what a scanner observed from what a supplier declared and what the team tested.
Include signing and verification as well as encrypted transport. Software updates, long-lived document signatures, device identity, remote-access services, and embedded products can have different migration constraints even when they use the same cryptographic library.
Prioritize consequences and replacement time
Ask how long the protected information must remain confidential and how long the system will remain in service. A short-lived public transaction and a sensitive archive retained for decades do not present the same planning problem.
Also ask how quickly the organization can change each dependency. A component with a long certification, procurement, or hardware replacement cycle may need attention before a technically simpler service. Record dependencies that the team cannot modify without vendor support.
This is an ordering exercise, not a prediction of the date when a cryptographically relevant quantum computer will arrive. Teams can act on data lifetime and migration lead time without claiming to know that date.
Separate algorithms from working deployments
NIST’s PQC project identifies ML-KEM for key establishment and ML-DSA and SLH-DSA for digital signatures among its principal standards. Their roles differ. Selecting a standard does not by itself establish protocol support, interoperability, validation status, or a safe rollout for a particular application.
Ask vendors which released products implement the proposed migration, which clients and peers interoperate, and which configurations have been tested. Require a support and rollback story. A roadmap slide is useful planning evidence, but it should not be recorded as an installed control.
Design a pilot with measurable failure conditions
Choose a representative service and retain a comparison baseline. Exercise authentication, certificate handling, handshake behavior, payload sizes, latency, monitoring, and recovery. Include old clients and constrained devices that the deployment still supports.
Decide in advance what would stop the rollout and how the team would restore service safely. Keep changes to algorithms, libraries, configuration, and deployment images traceable. Otherwise a successful pilot may be impossible to reproduce in production.
Our threshold-cryptography guide addresses concentration of key risk. That is a related architectural discussion, but distributing a key operation and changing a quantum-vulnerable algorithm solve different problems.
Make this week’s output concrete
- One scoped service and named owners.
- An inventory with evidence and unresolved questions.
- Priorities based on confidentiality lifetime and change lead time.
- Specific vendor questions and a pilot candidate.
- A dated review of gaps and dependencies.
Post-quantum migration becomes manageable when it is expressed as owned changes to known systems. The first deliverable is a reliable map that turns a broad strategic concern into decisions the organization can test.
