Quantum Readiness Assessment

What a quantum-readiness assessment means

A quantum-readiness assessment evaluates whether an organization can identify, understand, prioritize, and migrate cryptographic dependencies in response to the prospective impact of cryptographically relevant quantum computers. The assessment covers current cryptographic exposure, the value and lifetime of protected data, technical and organizational dependencies, migration capability, and governance. It should connect evidence to decisions: which systems require attention, what blocks change, what evidence is missing, and which actions reduce risk first. Post-quantum cryptography refers to asymmetric algorithms intended to resist attacks from both classical and quantum computers; it is not a guarantee that an algorithm will never be compromised.12

The assessment is not a quantum-threat forecast. The emergence date of a cryptographically relevant quantum computer is difficult to predict and remains uncertain. Nor is it a compliance certification: standards, approvals, module validation, accreditation, and organizational readiness are related questions but are not interchangeable. For example, an implementation can be designed to follow a standard while still requiring application-specific testing, and adherence to requirements for an approved key-encapsulation mechanism does not by itself guarantee that a particular implementation is secure.34

Inputs and scope

Begin by defining the business and technical boundary. Record the organizational units, environments, products, networks, data stores, devices, cloud and hosted services, suppliers, and trust relationships included or excluded. State the assessment date, evidence owners, assumptions, and known blind spots. A useful scope follows cryptographic functions rather than only application names: key establishment, digital signatures, certificates, authentication, key management, and cryptographic modules. NIST standards address encryption algorithms, digital signatures, hash functions, key establishment, random number generation, key management, protocols such as TLS, and cryptographic modules, so these are useful categories for organizing discovery.2

• A business and system register: services, applications, platforms, environments, data flows, owners, criticality, and dependencies.
• A cryptographic inventory: algorithms, key types and sizes, protocols, certificates, trust anchors, libraries, modules, HSMs, firmware, and hardcoded configurations where known.
• Data-lifecycle information: confidentiality or integrity requirements, retention periods, archival duration, exposure paths, and whether information must remain protected for years.
• Architecture and operational evidence: network paths, protocol versions, performance limits, packet or message constraints, device capabilities, update mechanisms, and recovery procedures.
• Supplier and product evidence: supported algorithms, implementation status, roadmaps, testing results, validation or accreditation statements, end-of-support dates, and contractual commitments.
• Governance evidence: policies, exception records, risk acceptance, change controls, ownership, procurement criteria, incident processes, and approval requirements.

The inventory should be treated as an evidence set with coverage and confidence, not as an assumption that every cryptographic use has been found. Modern software stacks can contain cryptography in many places. Discovery should therefore include searches for hardcoded algorithms in applications and reviews of exposed cryptographic configuration by administrators, policy officers, and compliance teams. Record the discovery method, population searched, date, responsible party, and unresolved areas.3

Discovery coverage and inventory quality

Discovery should proceed from externally visible and business-critical paths toward underlying implementation details. Map where public-key cryptography is used for key establishment and signatures, then trace certificates, certification authorities, certificate-management protocols, HSMs, trust anchors, libraries, operating systems, firmware, and devices. A certificate binds a public key to an owner through a certification authority, while a digital signature supports origin authenticity, data integrity, and signatory nonrepudiation. Those relationships make certificate and trust infrastructure part of the assessment rather than an optional administrative detail.53

For each inventory record, distinguish observed facts from inferred facts and unknowns. Useful quality fields include source, timestamp, owner, validation method, affected asset, algorithm or primitive, use, dependency, data lifetime, migration option, and confidence. Reconcile automated discovery with interviews, configuration review, code review, supplier responses, and controlled testing. Do not convert missing evidence into a low-risk finding: an unknown cryptographic dependency is itself a gap that can affect prioritization.3

Risk criteria and scoring dimensions

Use explicit dimensions instead of a universal maturity score. The dimensions below are assessment lenses; an organization may weight them differently by mission, data, and system context. Preserve the underlying evidence and explain the rationale for every rating.2

1. Cryptographic exposure: identify public-key algorithms and uses that could be affected if large-scale quantum computers are realized, including key establishment and digital signatures based on integer factorization or discrete logarithms.
2. Data longevity and sensitivity: prioritize information whose confidentiality, authenticity, or integrity must remain valuable for many years. The harvest-now-decrypt-later model makes long-lived sensitive data relevant before a quantum computer exists.
3. Business and system criticality: consider the effect of compromise, interruption, failed authentication, unavailable updates, or an invalid trust chain on essential operations.
4. Dependency concentration: identify shared libraries, certificate authorities, trust anchors, HSMs, platforms, suppliers, and protocols whose change affects many systems.
5. Migration capability: assess whether algorithms can be changed through configuration or APIs, whether software and firmware can be updated, whether certificates and keys can be replaced, and whether testing and rollback are possible.
6. Constraint severity: document bandwidth, packet size, latency, compute, memory, storage, interoperability, fragmentation, accreditation, regulatory, and validation constraints.
7. Evidence confidence: rate whether the finding is directly observed, corroborated, supplier-supported, inferred, or unknown.
8. Governance readiness: assess ownership, funding, procurement requirements, exception handling, change control, risk acceptance, and the mechanism for tracking remediation.

Risk should combine consequence, exposure, urgency, feasibility, and confidence rather than simply ranking algorithms. Long-lived sensitive data can require early action because an adversary may collect encrypted information now and attempt decryption after quantum technology matures. At the same time, migration duration includes preparation, integration, testing, auditing, and recertification, as well as vendor lead times and possible delays in regulation or accreditation.23

Vendor, protocol, and platform constraints

Vendor evidence should be specific enough to support a decision. Ask which product versions support which algorithms or hybrid constructions; where support is implemented; whether it applies to key establishment, signatures, certificates, or management; what configuration and interoperability limitations exist; what testing has been completed; and what validation or accreditation status applies. Mark statements as documented, tested, contractually committed, planned, or unsupported. A roadmap without a usable version, date, dependency, or acceptance evidence should not be treated as deployment readiness.34

Protocol and platform constraints can dominate the result. In IKEv2, for example, the size of the initial key exchange can create packet-fragmentation limitations, and proposed approaches may retain a traditional algorithm for the initial exchange before additional exchanges. Hybrid schemes can also increase bandwidth use, computation, message count, or round trips; performance varies by algorithm, platform, and implementation. Capture measured results for the actual deployment context rather than assuming that a standards-level option is operationally feasible.7

Accreditation and validation must be evaluated in context. ETSI’s 2024 technical report notes that FIPS 140-3 validation for cryptographic modules requires approved public-key algorithms and describes circumstances in which a post-quantum key-establishment or signature algorithm may be included with an approved traditional algorithm in a FIPS-compliant hybrid mode. This is evidence for a constraint or possible transition path, not a blanket conclusion that every hybrid deployment is approved or suitable.7

Target-state readiness and deliverables

Define a target state that is specific enough to test. It should state the approved or intended algorithms and parameters, protocol and certificate behavior, key and trust-anchor lifecycle, module and platform requirements, application interfaces, monitoring, rollback, supplier responsibilities, and treatment of legacy systems. The target state should also describe where hybrid approaches are being evaluated and what conditions would allow or require later movement to purely post-quantum algorithms. RFC 9794 defines a post-quantum algorithm as intended to withstand classical and quantum attacks, while also noting that attacks against any algorithm may be found; target-state language should therefore avoid absolute security claims.

Distinguish key-establishment work from signature and trust-infrastructure work. A post-quantum or hybrid key exchange may be relatively self-contained in a cryptographic library, whereas post-quantum signatures can require changes to certificates, certification authorities, certificate-management protocols, HSMs, and trust anchors. This distinction should appear in the dependency graph, effort estimate, test plan, and sequencing—not merely in a final recommendation.

• Assessment charter: scope, objectives, dates, evidence rules, assumptions, exclusions, and accountable owners.
• Coverage and inventory report: discovered assets, cryptographic uses, dependencies, evidence quality, unknowns, and discovery limitations.
• Risk register: affected data and systems, longevity, exposure, consequence, constraints, confidence, and rationale for priority.
• Vendor and platform matrix: product version, capability, evidence status, validation or accreditation considerations, dependencies, and open questions.
• Target-state and options paper: proposed cryptographic and protocol direction, compatibility considerations, performance results, lifecycle changes, and decision gates.
• Prioritized action backlog: action, owner, dependency, acceptance test, expected risk reduction, target timing, and review trigger.
• Executive decision record: material findings, residual uncertainty, funding or procurement decisions, exceptions, and governance cadence.

Turning findings into prioritized action

Prioritize actions that reduce uncertainty and unblock high-consequence systems. Typical early actions include completing inventory coverage, identifying long-lived sensitive data, engaging suppliers with evidence requests, testing cryptographic agility, establishing algorithm and certificate replacement procedures, and piloting changes on representative protocols and platforms. Early hybrid key-exchange deployments can provide operational experience, while prototyping post-quantum signature integration can expose ecosystem-wide effects; the appropriate choice remains dependent on the system, constraints, and applicable requirements.

Each finding should become an actionable record. State the affected asset or population, evidence and confidence, risk rationale, decision required, owner, dependencies, acceptance criteria, target date or trigger, and residual risk. Reassess when inventory coverage changes, a supplier releases support, a validation or accreditation condition changes, performance testing reveals a constraint, a standard or guidance document changes, or the business value and retention period of protected data changes. Migration timelines vary, and some systems require earlier transition because of long-term confidentiality needs or complex cryptographic infrastructure.

Conclusion

A quantum-readiness assessment is a structured way to turn uncertain future quantum risk into present engineering and governance decisions. It should identify cryptographic exposure, connect it to data longevity and business impact, test inventory quality, expose dependencies and constraints, verify vendor evidence, and define a target state that can be validated. Its most useful output is not a universal score but a prioritized, evidence-linked action plan with owners, dependencies, confidence, and review triggers. Starting with discovery and high-value or long-lived data enables organizations to build migration experience while the technical and accreditation landscape continues to evolve.