Post-quantum cryptography readiness is a planning and inventory problem before it becomes a replacement project. This checklist helps IT teams identify vulnerable cryptographic dependencies, prioritize long-lived data and exposed systems, assess vendors, and build a migration plan that can adapt as approved algorithms, libraries, and infrastructure support change.
Overview
Post-quantum cryptography (PQC) refers to cryptographic methods designed to remain secure against attacks from both conventional and sufficiently capable quantum computers. The practical concern for most organizations is not that every encrypted system must be replaced immediately. It is that cryptography is embedded throughout infrastructure, applications, devices, certificates, identity systems, backups, and supplier connections. Teams may not know exactly where it is used, which algorithms protect each asset, or how difficult an upgrade will be.
A sensible post-quantum readiness program therefore starts with visibility and flexibility. First, create a cryptographic inventory. Next, identify systems that protect information requiring long-term confidentiality or that support high-value authentication. Then assess dependencies, test upgrade paths, and assign owners. The result should be a prioritized migration backlog rather than a vague statement that the organization is “quantum safe.”
Use the following checklist as a working document. Record evidence where possible, mark unknowns explicitly, and avoid treating an unverified vendor response as a completed control.
- Scope: Include production, development, disaster recovery, employee devices, operational technology, embedded systems, and third-party connections where relevant.
- Ownership: Assign a technical owner, business owner, and risk or compliance contact for each important system.
- Evidence: Capture configuration files, certificate records, protocol settings, software versions, contracts, and test results.
- Status: Use clear states such as unknown, discovered, assessed, planned, testing, migrated, and retired.
For context on the wider security-planning process, see the quantum computing readiness checklist for enterprise security teams.
Checklist by scenario
1. Build a cryptographic inventory
Begin with a repeatable discovery exercise rather than relying on one scanning tool. Ask each infrastructure and application team to document where cryptography is used and what it protects.
- List algorithms, key sizes, certificate types, signature schemes, key-exchange methods, and protocol versions.
- Record where keys are generated, stored, rotated, backed up, revoked, and destroyed.
- Inventory TLS endpoints, VPNs, email security, identity services, API gateways, service meshes, databases, storage, and backup systems.
- Include code libraries, container images, operating-system packages, hardware security modules, firmware, and device-management platforms.
- Document cryptography used by applications, including hard-coded algorithms, custom implementations, and legacy integrations.
- Capture the business owner, technical owner, supplier, environment, data classification, and upgrade path for every record.
A useful inventory entry might contain: system name, business function, data protected, cryptographic purpose, algorithm, library or provider, key-management location, external dependencies, replacement options, operational impact, owner, and review date.
2. Prioritize long-lived information
Not all systems require the same migration order. Prioritize information whose confidentiality must last for many years, such as sensitive research, personal records, strategic plans, credentials, regulated records, or proprietary designs. Consider the period during which the data must remain confidential, not only its current value.
- Identify data that is transmitted today but retained for a long time.
- Review archived files, backups, logs, message stores, and exported datasets.
- Ask whether encrypted data can be collected now and decrypted later if cryptographic protections become vulnerable.
- Map each high-retention dataset to its encryption, key-management, transport, and access-control dependencies.
- Define whether the appropriate response is migration, shorter retention, stronger access controls, re-encryption, or a combination.
3. Review certificates, protocols, and identity
Certificate and protocol changes can affect availability as well as confidentiality. Create an inventory of public-key certificates and the systems that validate them. Include internal certificate authorities, mutual TLS, VPN authentication, device identity, code signing, document signing, and software-update mechanisms.
- Record certificate issuance, renewal, revocation, and deployment workflows.
- Find applications that validate algorithms or certificate fields too narrowly.
- Check whether devices can receive certificate, firmware, or trust-store updates after deployment.
- Identify dependencies on external identity providers, payment networks, partners, and managed services.
- Test failure behavior so an unsupported cryptographic option does not cause an uncontrolled outage.
4. Assess vendors and suppliers
Ask vendors specific, testable questions rather than accepting broad claims of quantum readiness. Request the supported algorithms, product versions, deployment limitations, licensing assumptions, hardware requirements, and documented migration procedure. Ask whether support applies to the product itself, its management plane, its customer-facing protocols, or only a roadmap.
For each critical supplier, record the answer, date, product version, contractual commitment if any, and the person responsible for follow-up. Include cloud providers, security products, network equipment, enterprise applications, outsourced platforms, and embedded technology.
5. Plan for algorithm agility
Algorithm agility means an organization can change cryptographic algorithms and parameters without redesigning every application. Review whether cryptographic choices are centralized, configurable, and separated from business logic. Prefer managed libraries and approved interfaces over scattered custom code, while preserving compatibility with required systems.
- Remove hard-coded algorithm names and key sizes where configuration is appropriate.
- Document supported alternatives and the conditions under which each may be used.
- Separate certificate, key, protocol, and application release cycles where practical.
- Automate inventory collection and certificate expiration monitoring.
- Define rollback procedures and emergency disablement procedures before production migration.
Use the organization’s approved security standards and current supplier documentation when selecting algorithms. A technical comparison of current post-quantum options is available in Post-Quantum Cryptography Algorithms Compared.
What to double-check
| Area | Question to verify | Evidence to retain |
|---|---|---|
| Data retention | How long must the protected information remain confidential? | Retention schedule and data classification |
| Discovery | Have both automated and application-level uses of cryptography been reviewed? | Scan results, code review, and team attestations |
| Certificates | Can certificates and trust stores be replaced without an outage? | Renewal records and test results |
| Vendors | Is support available in the specific product and version in use? | Versioned documentation or written supplier response |
| Interoperability | Can internal and external systems negotiate compatible options? | Integration and compatibility test results |
| Operations | Can monitoring, backup, recovery, and incident response handle the change? | Runbooks, recovery tests, and alert rules |
| Governance | Who approves exceptions and tracks remediation? | Risk acceptance and remediation records |
Pay particular attention to systems that are difficult to update: industrial equipment, medical or laboratory devices, satellites, long-lived appliances, offline environments, and software embedded in products. Their migration schedule may be driven by procurement or replacement cycles rather than ordinary application releases.
Common mistakes
- Starting with a product purchase: A new security tool cannot compensate for an incomplete inventory or unclear ownership.
- Counting only encryption: Signatures, key exchange, certificates, code signing, identity, and firmware updates also need review.
- Ignoring stored data: Long-term confidentiality requirements can make archives and backups a higher priority than frequently replaced short-lived data.
- Trusting a roadmap as current support: Distinguish generally available functionality from planned, experimental, or limited deployment options.
- Testing only the happy path: Verify renewal, revocation, recovery, interoperability, monitoring, and rollback—not just successful connection setup.
- Creating a static spreadsheet: An inventory becomes stale when ownership, review dates, discovery methods, and change-management links are missing.
- Making unsupported promises: Describe risk, assumptions, and validation status precisely. “Under assessment” is more useful than an unverified claim of compliance.
When to revisit
Review this checklist at least during annual security planning and before major infrastructure or procurement cycles. Revisit it sooner when workflows, software libraries, cloud services, certificate authorities, network protocols, or data-retention policies change.
Use these triggers to reopen the assessment:
- A critical vendor releases a new product version or changes its cryptographic support.
- A new application, acquisition, cloud migration, or supplier connection enters the environment.
- A certificate authority, key-management service, identity provider, or hardware platform is replaced.
- Retention rules change or a new class of long-lived sensitive data is created.
- Security standards, approved algorithms, implementation guidance, or library support changes.
- A migration test exposes interoperability, performance, storage, or operational problems.
For the next planning cycle, choose a manageable starting point: inventory one high-value service, confirm its cryptographic dependencies, contact its vendors, and test one reversible change in a non-production environment. Record the result, update the risk ranking, and use the lessons to improve the organization-wide process. Post-quantum readiness is best treated as recurring lifecycle work—measured, owned, and revised as systems and cryptographic guidance evolve.
