Post-quantum cryptography checklist

A post-quantum cryptography implementation checklist should tell you what to inspect, who must act and what evidence closes each task. Post-quantum cryptography, or PQC, uses algorithms designed to resist attacks by both conventional computers and future quantum computers.

This checklist is for the IT manager turning a migration strategy into work packages. It separates discovery from deployment. You can complete a useful assessment before your suppliers support every required change.

1. Define the service and the protection it needs

Choose one important service for the first assessment. Record its business purpose, owner, users, external partners and recovery requirements. Map where information enters, travels, is stored and leaves.

Distinguish three functions:

• Encryption protects the confidentiality of information.
• Key establishment lets parties agree the secret material used to protect a connection.
• Digital signatures help verify the origin and integrity of software, messages or documents.

A change to one does not prove the others have changed. For example, hybrid TLS key establishment can coexist with a conventional certificate signature. Record both rather than describing the entire service as quantum safe.

The migration strategy guide explains how to prioritise services. This checklist covers the evidence needed to implement those priorities.

2. Inventory algorithms and dependencies

For each connection and stored-data mechanism, record the protocol, negotiated algorithm, product version, library and configuration owner. Capture evidence from approved configuration exports, vendor documentation or a scoped test. Do not copy private keys or production secrets into the inventory.

A protocol label such as TLS 1.3 does not, by itself, tell you the key establishment group used by a particular connection. Likewise, a certificate's expiry date is an operational renewal date, not a universal quantum migration deadline.

Record missing evidence as a task with an owner. A supplier marketing page is not a substitute for support confirmation for your installed version.

3. Apply the right cryptographic assessment

NIST's first final PQC standards distinguish ML-KEM for key establishment from ML-DSA and SLH-DSA for signatures. Select supported implementations appropriate to the protocol and your assurance requirements. Do not invent your own combination.

Avoid generic rules such as "all asymmetric keys must be at least 384 bits". Key sizes cannot be compared that way across RSA, elliptic-curve and post-quantum algorithms. Increasing the size of a quantum-vulnerable public-key algorithm does not make it a PQC algorithm.

Do not mark AES-128 as unsafe simply because it has a shorter key than AES-256. NIST's PQC FAQ permits continued use of AES at 128, 192 and 256 bits in current applications. Assess your actual implementation and applicable requirements. Pay attention to the public-key mechanisms that exchange or wrap its keys.

4. Prioritise by information lifetime and replacement difficulty

Ask the information owner how long disclosure would cause harm. Then consider how long a migration could take, including procurement, partner testing and replacement of unsupported hardware.

Here is a hypothetical assessment record:

The ten-year period is an example assumption, not a required retention period. A short-lived session and a long-lived signing device may need different priorities even if both use public-key cryptography.

5. Get a version-specific supplier response

Ask each supplier to identify the supported release, algorithm and deployment mode. Separate production support from experiments or previews. Confirm whether the proposal changes key establishment, signatures or both.

Check the dependencies beyond the product itself. A VPN upgrade might require client updates. A signing change might require a new trust anchor. A managed service might protect the public connection while leaving another connection inside your integration unchanged.

Require a test plan, support route and rollback procedure. Record any additional licence, hardware or professional-service cost before committing. Add the response to your supplier risk assessment.

6. Test a supported configuration in isolation

Use a non-production environment and synthetic information. Reproduce representative client versions, proxies, load balancers and inspection devices. Do not run an exploratory cryptographic change directly against a critical production service.

Your test record should include:

• Exact software versions and configuration before and after the change.
• Evidence of the negotiated mechanism, including fallback cases.
• Successful and failed connections from each supported client group.
• Handshake time, application latency, resource consumption and error rates.
• Certificate validation, renewal and relevant signature verification checks.
• Backup, restore and operational support checks affected by the change.
• The rollback trigger, owner and result of testing rollback.

Hybrid key establishment aims to retain security when one component remains secure, but that depends on the construction and implementation. NIST describes the need for application-specific analysis. Compatibility fallback is a separate issue: it may restore connectivity without the intended PQC protection.

Keep experimental Kyber configurations distinct from standardised ML-KEM configurations. Google's Chrome migration account explains why the earlier Kyber hybrid and final ML-KEM hybrid are incompatible. Exact identifiers belong in the test evidence.

7. Make the release decision explicit

Agree acceptance criteria before looking at the results. For a customer service, those criteria might cover supported-client success, maximum added latency and a tested recovery route. For a signed update service, successful verification on the oldest supported device may matter more.

Do not hide a failed test inside an overall pass. Record which combinations remain unsupported and whether they can be excluded, upgraded or given a temporary exception. The business owner should understand the consequence of an exception.

The release plan should identify who can stop the change, how monitoring will detect problems and which conditions trigger rollback. Have the service desk's instructions ready before deployment. A configuration that works technically can still fail operationally if nobody knows how to diagnose it.

8. Retain a completion record and review it

Close the work package only when the deployed version and observed behaviour match the accepted configuration. Retain the inventory update, supplier statement, test results, approval and rollback reference together.

Track remaining conventional dependencies separately. "Key establishment upgraded; certificate signatures unchanged" is more useful than an unqualified "quantum safe" label.

Review the record when a supplier changes support, an algorithm recommendation changes, a client group changes or the service handles different information. An implementation can be correct today and need further work after those changes.

A checklist for the release meeting

• We know which service and information this change protects.
• We have recorded key establishment, encryption and signature dependencies separately.
• The supplier supports the exact configuration we intend to deploy.
• Representative clients and network devices passed the agreed tests.
• We understand fallback behaviour and any resulting loss of protection.
• Recovery and rollback work within the service's requirements.
• The service owner has accepted documented exceptions.
• Operations has the configuration, monitoring and support instructions.

If you cannot tick an item, give it an owner and an evidence requirement. Do not treat an incomplete checklist as a reason to stop all preparation; use it to identify the next dependency to resolve.

Need an independent implementation review?

My technical consulting and security consulting services can help turn a cryptographic inventory into a scoped pilot and release decision. Book a consultation with the services you are concerned about, the suppliers involved and the information that needs long-term protection. Those details are enough to start identifying the work and its dependencies.