How to start a post-quantum cryptography inventory
A practical inventory for engineering teams preparing for post-quantum migration, based on NIST’s transition guidance.
Start by finding where your systems depend on public-key cryptography. A quantum-ready migration is partly a dependency discovery exercise: a certificate, VPN appliance or firmware update chain can be shared by products whose owners work in different teams.
Record the dependencies you need to change
| Surface | Record |
|---|---|
| TLS and service identity | Termination point, library/provider, certificate owner, client compatibility |
| Signing | Artifact format, verification lifetime, trusted roots and rollover procedure |
| Stored data and key wrapping | Retention, key owner, envelope or KMS provider and recovery process |
| Suppliers | Product version, supported algorithms, planned updates and contractual ownership |
Track confidentiality lifetime separately from the lifetime of a signing key. Data that must stay confidential for years deserves attention even when today’s session keys are short-lived. For software signing, ask how long previously shipped devices must still recognise valid updates.
Choose a pilot with rollback
Pick a noncritical service with known clients. Inventory the TLS termination layer, test the vendor’s supported post-quantum or hybrid configuration where available, and measure handshake size, failures, and compatibility. Keep a rollback path, record which clients were exercised, and include the operating team that will own the change.
NIST IR 8547 provides a transition roadmap. Apply the relevant requirements for your own sector and systems, and consult your platform’s supported configurations before changing a production protocol. A successful pilot is evidence about that environment.