Buying a PQC readiness assessment: what must a cryptographic inventory prove?

Before commissioning a post-quantum cryptography (PQC) readiness assessment, agree on what evidence will make the inventory useful for migration decisions. Require traceable connections between business services, applications, cryptographic operations, keys, certificates, suppliers, and accountable owners.

PQC refers to cryptographic methods designed to resist attacks by classical and quantum computers. NIST’s National Cybersecurity Center of Excellence (NCCoE) connects cryptographic discovery with risk management and migration prioritization. Its project provides a basis for asking where cryptography operates and what depends on it. NIST NCCoE migration project

NIST’s FAQ describes an inventory spanning systems, applications, services, devices, and data flows. It lists June 30, 2026, as its update date; that timestamp alone does not establish that its inventory guidance was newly issued then. NIST PQC migration FAQ

The acceptance checklist and contract requirements below are the author’s procurement recommendations, informed by these sources. They are not a NIST certification scheme or a prescribed NIST inventory schema. Ask prospective assessors to demonstrate them with sample records before signing the contract.

Agree on acceptance criteria.

In this article, TLS means Transport Layer Security, a protocol used to protect network connections.

Connect discovery to real services.

Require stable record identifiers, evidence references, collection dates, environments, responsible people, and an explicit scope status. Record uncertainty and the basis for confidence. Give each unresolved item an owner and a follow-up date.

Reconcile the service register against the configuration management database (CMDB), asset and deployment records, cloud accounts, Domain Name System (DNS) data, and certificate-management records. Report matched services, unmatched assets, exclusions, retired systems, and items awaiting confirmation. State the denominator behind every coverage percentage.

Agree on coverage beyond public websites. Consider internal service connections; application programming interfaces (APIs) and integrations; virtual private networks (VPNs), remote access, and administration; email and file transfers; database and backup connections; code signing and software updates; and employee, service, application, and device identities. Include public key infrastructure (PKI), hardware security modules (HSMs), key management systems (KMSs), secrets-management platforms, and supplier-operated services where relevant. Record exclusions and their consequences.

For each use, distinguish confidentiality, authentication, integrity, signing, and key establishment. Ask which component performs each operation and which application or service relies on it.

Record exact mechanisms and evidence status.

Require protocol versions and the exact deployed product and cryptographic-library versions, including relevant builds or modules. For each algorithm, record its operation and relevant parameters: key length, named curve or group, signature scheme and hash, encryption mode, or PQC parameter set. Where a hybrid mechanism is used, record its components and the specification implemented.

Keep four evidence categories distinct:

• Supported: the exact product version can implement the mechanism, according to identified documentation or capability testing.
• Configured: a dated configuration enables or selects the mechanism in a named environment.
• Observed: a dated connection or operation actually used it, with the client, endpoint, path, and test conditions recorded.
• Supplier-attested: a supplier states a capability or deployment fact; retain the statement, date, applicable version, and verification status.

A supplier statement may concern either support or configuration, so retain both what it claims and how it was established. Do not turn “supported” into “observed” without evidence. Limit each observation to its tested conditions.

Record a certificate’s subject public-key algorithm and parameters separately from the issuer’s signature algorithm and parameters. Identify connection authentication and key establishment through their own evidence. A certificate alone does not establish which key-establishment mechanism a connection used. NIST distinguishes authentication from key establishment in network protocols. NIST IR 8547, §3.1.3

For certificates, also require the chain, intended use, validity, installation location, renewal process, environment, and responsible person. For keys, require references, purpose, management location, lifecycle state, dependent services, the person responsible for creation and rotation, and replacement or recovery constraints.

Example: a hypothetical service-to-evidence record.

The following record is invented to illustrate the requested distinctions. Product names, versions, identifiers, and findings are fictional; this is not a recommended configuration.

Require equivalent traceability for other paths and environments. The public connection’s observed behavior does not close the unresolved archive dependency.

Protect the inventory itself.

Exclude private-key material and other secret key material from collection. Collect only metadata necessary for the assessment. Key references, system locations, ownership details, and dependency maps may themselves be sensitive. Require sensitivity classification and controls for access, transfer, retention, and deletion, including copies in assessor systems. Prefer evidence references or redacted extracts when they satisfy the agreed purpose.

Assess long-term confidentiality explicitly.

An attacker may collect encrypted traffic today and decrypt it later with a sufficiently capable quantum computer. A later service migration cannot protect copies already captured. This is the “harvest now, decrypt later” threat. NIST IR 8547, §3

For each relevant data class, require a documented confidentiality period and the person who approved it. Link the data to repositories, transfer paths, and protection mechanisms. Record where collection could occur, what evidence supports that exposure assessment, and the estimated time needed to implement and validate migration, including supplier dependencies. Use these inputs together; the target migration date is insufficient as a screening test.

Analyze an archive’s symmetric encryption separately from public-key mechanisms protecting or establishing its keys. NIST treats symmetric cryptography and public-key key establishment differently. NIST IR 8547, §§2.1.3 and 3.1.3

As a procurement requirement, ask the assessor to trace how archive keys are generated, protected, distributed, recovered, and replaced. Require separate findings for data encryption, key protection, and transfer connections. Do not accept an archive-encryption algorithm label as the complete analysis.

Make supplier dependencies actionable.

For each relevant supplier, request the product or service version, deployment model, cryptographic role, supported upgrade path, and dated evidence for PQC claims. Separate available capabilities from future commitments. Record constraints on cryptographic agility—the ability to change cryptographic mechanisms while maintaining service operation.

Assign a person responsible for working with the supplier and a follow-up date. Keep unanswered questions in the exception register, with their impact on the assessment. “Vendor dependent” should initiate an action rather than close a finding.

Validate before acceptance and maintain the result.

Select a sample spanning production and nonproduction, public and internal connections, cloud and on-premises systems, employee identities and identities of services, applications, and devices, and supplier-operated services. Trace each record from service ownership to dated evidence. Compare it independently with available configurations, deployment records, certificates, or connection observations. Record discrepancies and expand checks where they reveal a coverage problem.

Require coverage metrics for reconciled business services, assigned owners, sufficiently detailed cryptographic records, unresolved items and their age, supplier responses, and exclusions. Withhold acceptance when records cannot be traced, unknowns disappear, dependencies lack responsible people, or priorities lack a stated rationale.

Then assign corrective actions: repair inventory gaps, confirm unknown mechanisms, obtain supplier evidence, evaluate supported upgrades, and plan testing. Prioritize systems for migration using business impact, confidentiality needs, collection exposure, dependencies, and implementation lead time. Update the plan regularly and refresh affected records after significant application, infrastructure, certificate, or supplier changes.

State the limits of each method: which paths were observed, which configurations were examined, and where access or evidence was unavailable. Preserve assumptions and unresolved items. NIST IR 8547 remains labeled an initial public draft; use it as a proposed transition approach, not a final universal implementation mandate. NIST IR 8547 publication status

Is external TLS discovery a reasonable starting point?

Yes, for the public endpoints included in the exercise. Require the final assessment to account separately for internal services, other cryptographic uses, supplier dependencies, and data requiring long-term confidentiality.

Must the assessment scan every system?

Not necessarily. Agree on a documented scope based on risk and use complementary evidence sources. Sampling should validate selected records. Exclusions and areas for which evidence cannot be obtained must remain visible, with a responsible person, rationale, and follow-up plan.

What should the final deliverable contain?

Require an evidence-linked inventory, scope and methods, exact mechanisms and evidence status, reconciliation and coverage metrics, confidentiality-risk analysis, supplier dependencies and exceptions, prioritized actions, responsible people, deadlines, and a refresh process. A spreadsheet is acceptable if it preserves these relationships and supports review.

Further reading

• Penetration test preparation
• Reporting and risk