What Should a Post-Quantum Cryptographic Inventory Include?

A useful post-quantum inventory connects each cryptographic function to its deployed implementation, protected information or operation, dependent systems, accountable owner and available change path. It records the evidence for those connections and what remains unknown. A list of certificates or algorithms is a starting point; it cannot, by itself, tell you which migration should happen first or whether a proposed replacement will work.

I would build the inventory around decisions: what must remain confidential, which signatures must remain trustworthy, what can be upgraded, and which dependency can prevent the change. The research question here is how to make discovery evidence sufficient for those decisions. I develop a method using standards, migration guidance and an original worked example. The example is hypothetical, and the acceptance tests are proposed. No deployment, benchmark or client outcome is presented as observed research.

Separate cryptographic functions before counting them

“Uses encryption” is too broad to support migration. A service may establish session keys, encrypt traffic with a symmetric cipher, authenticate a peer using a certificate, verify software updates and wrap stored data keys. Those functions have different keys, algorithms, owners and replacement dependencies. A single green label on the service conceals whether only one of them has changed.

FIPS 203 defines ML-KEM, a key-encapsulation mechanism that can establish a shared secret for subsequent symmetric cryptographic use. FIPS 204 defines ML-DSA for generating and verifying digital signatures. FIPS 205 defines SLH-DSA, a stateless hash-based signature algorithm (National Institute of Standards and Technology [NIST], 2024a, 2024b, 2024c). ML-KEM is not a bulk file-encryption replacement; ML-DSA is not a key-establishment mechanism. The two signature standards also represent different algorithm families, so “PQC signature supported” is insufficiently specific for compatibility planning.

I would make the unit of inventory a cryptographic use within a deployment: for example, the key-establishment function of one application connection, or the firmware-verification function of a device family. Several instances may inherit evidence from a common managed configuration, but that inheritance needs a defined scope. An algorithm reference found in source code and a negotiated algorithm observed on a running service are different records with a relationship between them.

This prevents misleading counts. Ten thousand certificates can depend on one issuance policy and one verifier implementation, making the shared dependency the consequential change. One appliance can contain several unrelated cryptographic functions, requiring several migration decisions. Inventory cardinality should follow the architecture rather than whichever tool happens to generate the most rows. The goal is to identify changes and their consequences, not maximize the quantity of discovered cryptography.

Record relationships and evidence, not secret material

I would retain a stable identifier for the service and environment, the cryptographic function, algorithm and parameter set, implementation version, relevant policy, and source of evidence. Then connect the use to the information protected, its required protection period, the key-management boundary, its counterparties and its change owner. The record needs enough detail to reproduce the decision without containing private keys, plaintext secrets or sensitive data samples.

CISA's 2024 discovery strategy identifies algorithm, service provided and key length as relevant inventory information, while distinguishing automated collection from context requiring other sources. Its discussion is framed around federal reporting and describes the capabilities available when it was written (Cybersecurity and Infrastructure Security Agency [CISA], 2024). I would adapt that separation between technical observations and organizational context without treating the document's reporting fields as a universal enterprise schema or its historical tooling limits as permanent facts.

The following is my proposed minimum decision record. It is a practical synthesis, not a new standard or a claim that a particular discovery product supplies every field.

Record area	Information needed	Decision it supports
Identity and scope	Service, environment, deployment/version, function, owner	Which actual use is being assessed?
Cryptographic mechanism	Algorithm, parameter set, protocol/profile, provider or library	What must change, and at which interface?
Protection requirement	Data confidentiality horizon or verification/trust lifetime; consequence of failure	How much delay can the service tolerate?
Dependency relationships	Peers, trust stores, issuer, key service, verifier, supplier and release mechanism	Which prerequisite can block migration?
Evidence state	Observation/assertion, collection method, scope, timestamp, confidence and gaps	What does the inventory establish?
Change and acceptance	Supported target, responsible party, tests, rollback constraints, closure evidence	What would demonstrate a successful transition?

Key identifiers and metadata may still reveal sensitive architecture. I would restrict inventory access, record who changes it and avoid placing it in public issue trackers. The inventory should point to controlled evidence stores rather than copy their contents indiscriminately. A system designed to reduce cryptographic exposure should not create an unnecessary new collection of secrets or a detailed map available to everyone.

Use several discovery methods because they observe different things

Network observation can reveal a protocol exchange on a path the sensor sees. Active inspection can ask a reachable endpoint about supported behavior. Code and binary analysis can locate cryptographic implementations. Runtime instrumentation and configuration review can help determine which implementation a process uses. Supplier documentation contributes information about managed services and opaque devices. None of these is a complete substitute for the others.

The NCCoE's preliminary SP 1800-38B describes a multifaceted discovery approach, including network and application analysis and normalization of tool outputs. It is explicitly a preliminary draft describing a demonstration approach, not proof that a named tool finds every use of cryptography (Newhouse et al., 2023). I would borrow its architectural separation of collection and analysis, then evaluate coverage against the organization's actual deployment types.

For example, a source-code scan can find an unused library while missing a managed database's internal key wrapping. A network sensor may see a common application path but never observe disaster recovery, monthly file transfers or offline firmware verification. An endpoint query may identify a library installed on disk without establishing that the running process loaded it. These are proposed failure cases to test, not measurements of a particular scanner's miss rate.

A discrepancy between methods is useful evidence. If a supplier says a service uses a new mechanism but observation shows a classical path, investigate the product version, configuration, client cohort and measurement point. If the observations cover different paths, both may be correct. I would keep the competing assertions with their scopes until they can be reconciled, rather than silently allowing the most reassuring source to overwrite the others.

TLS shows why a cipher-suite list is insufficient

TLS 1.3 separates its cipher-suite selection from authentication and key exchange. The cipher suite identifies record protection and a hash, while other handshake elements handle key exchange and signatures. RFC 8446 also specifies that handshake messages after ServerHello are encrypted (Rescorla, 2018). Consequently, a passive observer without the necessary visibility cannot assume it has recovered the entire authentication chain simply because it recognized a TLS connection.

For a TLS-dependent service, I would distinguish offered capability from the selected mechanism, and both from the policy requiring it. Record the endpoint roles, supported groups, observed key-establishment choice, certificate and handshake-signature dependencies, client population and termination points. A modern cipher-suite name does not independently establish that the public-key portions of the connection resist quantum attacks. Nor does the TLS 1.3 version label itself establish adoption of a particular post-quantum extension.

Termination points matter. Suppose an external connection negotiates the intended protection at a gateway but the gateway opens a separate classical connection to the application. The first observation remains valid for its leg. It does not describe the internal leg or establish end-to-end protection across the complete data flow. I would inventory the two connections separately and assess what information is exposed to which observers on each path.

The same discipline applies to session resumption and exceptional clients. A successful demonstration using a new client may not represent older clients, partner integrations or recovery tooling. The inventory should identify the populations that still select a different path and the policy governing them. Those are deployment questions to verify through an approved test plan; this article has not inspected any live TLS service.

Preserve the difference between confidentiality and authenticity

The “harvest now, decrypt later” problem concerns encrypted information collected before an adversary can break the relevant protection. NIST's final transition report identifies this as a reason to begin migration before the future cryptanalytic capability exists (Moody et al., 2026). Changing protection for future traffic cannot withdraw ciphertext already collected by an adversary. That makes the required confidentiality period a decision input, not merely a retention label.

Signature migration has a different operational shape. A device may accept updates throughout a long service life, or an archive may need to verify old signed records. I would inventory the verifier and its trust-update mechanism, not just the system that produces signatures. If an installed device cannot accept a new verification algorithm or trust anchor, upgrading the signing server alone cannot complete that migration. The required continuity of trust becomes a dependency requiring its own engineering decision.

Key lifetime and information lifetime must also remain distinct. NIST SP 800-57 Part 1 defines cryptoperiods and distinguishes periods for applying protection from periods for processing protected information (Barker, 2020). A key that stops encrypting new data can still be needed to decrypt existing records. Likewise, retiring a signing key does not automatically eliminate the need to validate signatures it previously produced. A migration plan that destroys old key material solely because the new algorithm is deployed can break authorized recovery or verification.

I would therefore ask separate questions for every use: when does new protection switch, how are existing protected objects handled, and what evidence must remain available afterward? The answer may involve retaining a bounded legacy verification capability, reprocessing data where appropriate, or replacing a constrained device. It must be derived from the threat model and retention obligations. There is no universally safe instruction to re-encrypt everything, delete every old key or keep every old mechanism indefinitely.

Use time horizons without pretending to predict a quantum deadline

Mosca's planning model distinguishes the security shelf life of information, the time required to migrate and the time until a relevant quantum capability. If the first two exceed the third, an organization can run out of protection time before the transition is complete (Mosca, 2016). I use that relationship as a planning test. I do not adopt the presentation's historical forecasts as current predictions.

Let L be the confidentiality period required for information created today, M the estimated migration duration, and Q an assumed time until the relevant cryptanalytic capability. For a service that continues producing information under vulnerable protection until migration ends, the latest such information could require confidentiality until approximately M + L from now. The expression Q − M − L is therefore a scenario margin under those assumptions, not a probability of compromise or a forecast of when quantum computers will arrive.

Consider invented planning values: L = 8 years and M = 3 years. If Q is assumed to be 10 years, the margin is −1 year; if Q is assumed to be 15 years, it is 4 years. Reducing migration to 2 years changes those margins to 0 and 5 years. The calculation shows how a dependency delay affects the protection requirement without claiming either Q value is likely. A zero margin has no allowance for estimation error and is not a safety guarantee.

The model's limits matter. It does not prove that an adversary can collect the relevant ciphertext, that all data has identical value, or that one algorithm change covers every protection path. For already captured information, future migration cannot undo the collection. For signatures and long-lived devices, a confidentiality shelf-life model may miss the main risk entirely. I would keep separate trust-lifetime and updateability assessments rather than forcing every cryptographic use into one equation.

Turn the inventory into a dependency graph

An inventory becomes actionable when it shows what must change before something else can change. Represent deployed functions and shared services as nodes, with directed relationships for prerequisites: a client must support the selected protocol, a device must understand a new signature, an issuer must produce an accepted credential, and a key service must support the implementation's lifecycle. Each relationship should identify the evidence and the responsible party.

The graph is more useful than simply ranking algorithms because migration duration often sits in a shared prerequisite. A library update might be easy while an appliance replacement, supplier release or partner certification determines the earliest completion date. NIST's crypto-agility guidance treats hardware, firmware, software, protocols and technology supply chains as connected parts of change (Barker et al., 2025). I would use the graph to locate the dependency that actually constrains the schedule.

A dependency can also form a cycle. A verifier may need a trusted update before it accepts a new signing scheme, while the proposed delivery mechanism assumes that new scheme is already accepted. The migration plan must identify a supported way to establish the new trust path. Labeling both components “PQC capable” does not resolve the cycle. If no supported path exists, replacement or a different deployment design may be necessary.

I would prioritize investigation by consequence, protection horizon, uncertainty and lead time, then schedule changes according to their prerequisites. This creates a partial order rather than an invented universal risk score. Two services may be equally urgent but require different immediate work: one can enter interoperability testing, while another needs a supplier commitment or replacement design. Unknown dependencies belong visibly on the critical path, not hidden inside a completion percentage.

Ask suppliers for a deployable claim

A supplier's statement should identify the product and version, cryptographic function, algorithm and parameter set, protocol or profile, required configuration and supported peers. It should distinguish planned support, released capability and verified behavior in the customer's deployment. I would also ask what changes in the key service, hardware security module, certificate handling, backup process and recovery tooling. These details determine whether an upgrade can be consumed safely.

“Hybrid” needs particular care. RFC 9794 defines terminology for schemes combining post-quantum and traditional asymmetric components, and distinguishes different constructions. It is an Informational RFC; it does not establish the security of every product described as hybrid. Protocol-specific security analysis remains necessary (Driscoll et al., 2025). I would record the exact construction and specification rather than accepting the word as evidence that all security properties survive failure of either component.

Validation claims require similar precision. NIST's agility guidance distinguishes cryptographic algorithm validation from cryptographic module validation and discusses the standards and validation dependencies affecting suppliers (Barker et al., 2025). Ask which implementation, version, operating environment and configuration the evidence covers. Even applicable validation evidence does not show that the organization's clients negotiate the desired mechanism or that its recovery process works.

The next procurement question is what happens after the first transition. Can the supplier replace a mechanism again without replacing the entire device? Who maintains its cryptographic provider? How are unsupported peers and disabled algorithms reported? The limits of an SBOM as assurance apply here: a component list can identify dependencies, but it does not prove runtime selection, protocol interoperability or successful future migration.

Measure size and operational cost at the right boundary

Parameter sets are not decorative inventory fields. FIPS 203 lists an ML-KEM-768 encapsulation key of 1,184 bytes and ciphertext of 1,088 bytes. FIPS 204 lists an ML-DSA-65 public key of 1,952 bytes and a signature of 3,309 bytes (NIST, 2024b, Table 3; NIST, 2024a, Table 2). These are algorithm object sizes, not complete certificate, application-message or network-handshake sizes.

For example, 1,184 + 1,088 = 2,272 bytes accounts for those two ML-KEM objects, but excludes protocol framing, any traditional hybrid component, authentication and other messages. It also does not establish the incremental difference from a particular existing protocol. I would use these values to identify where measurement is needed, not to predict a latency increase from an isolated byte count.

The proposed test should examine complete messages and actual operating constraints: serialization limits, certificate or signature storage, transfer fragmentation, processing time, memory use, concurrency and failures under degraded links. A firmware distribution system and an interactive application may have very different acceptable tradeoffs. The inventory should point to the relevant service-level requirement and test environment, so a benchmark from a powerful developer laptop cannot silently become evidence about a constrained device.

I would measure the entire workflow, including key generation, signing or encapsulation, verification or decapsulation, distribution, recovery and failure handling where applicable. Identify which operations occur on each side and how frequently. A fast verifier may matter more than a fast signer in one system; another may be constrained by message size or a hardware interface. This is a test-design proposal, not a claim that one standardized algorithm or parameter set universally performs best.

A worked migration slice exposes what the inventory is missing

Assume a hypothetical service receives confidential partner files, stores encrypted records and distributes signed application updates to remote devices. It has an external gateway, an internal processing connection, a managed key service and a device update verifier. These are invented architecture elements, not descriptions of a customer. The service has more than one migration objective, even if procurement calls the entire product “quantum ready.”

Function	What discovery might establish	What remains necessary for migration acceptance
Partner-to-gateway connection	Selected mechanism for tested partner versions	Coverage of all approved partners; authentication and fallback policy
Gateway-to-processor connection	Separate protocol/configuration and deployed provider	Intended protection on this leg; compatible failover and recovery paths
Stored-record protection	Data-encryption mechanism and dependency on wrapped keys	Protection and lifecycle of wrapping keys; recovery of retained records
Signed device updates	Signing implementation and installed verifier versions	Verifier upgrade path, trust continuity and rejection of invalid updates

The first discovery pass might show that the gateway supports a target mechanism. That is progress for one dependency. It does not close the internal connection, key-management or device-verification records. The team can stage the gateway change while separately investigating whether old devices can receive an authorized verifier update. Treating those activities as separate work avoids withholding every useful improvement until the hardest dependency is solved.

For this slice, I would require representative partner tests, a check of both communication legs, recovery of a controlled retained record, and device verification tests using approved valid and invalid artifacts. Each result should identify the exact versions and configurations. A failed old-device test should produce a specific remaining population and treatment plan, not invalidate unrelated successful tests or disappear inside an overall “mostly migrated” label.

Completion also requires a policy decision about residual classical paths. Some may be temporarily permitted for a defined population; others should be rejected. Both outcomes need observable enforcement. The team should be able to distinguish authorized compatibility from unexpected fallback and to identify when the remaining exception is no longer justified. Nothing in this example authorizes a production change or substitutes for the relevant product's implementation guidance.

Treat fallback and rollback as security decisions

Crypto agility means changing mechanisms while preserving security and operations, not merely offering many algorithms. NIST's guidance identifies integrity protection of negotiation as important to preventing an attacker from influencing algorithm selection toward vulnerable choices (Barker et al., 2025). More choices can create more states to reason about. An inventory that records only the preferred mechanism misses the paths chosen when something goes wrong.

I would test three distinct outcomes: successful use of the required target, explicitly permitted compatibility behavior, and rejection of a prohibited path. Record how operators tell them apart. A dashboard that counts attempted new handshakes while clients silently fall back does not establish adoption. Conversely, refusing every older client without understanding the business effect can cause an outage that drives an uncontrolled rollback.

Rollback deserves its own acceptance conditions. Returning to an earlier application version may restore operation while reintroducing a cryptographic exposure or removing support needed to process newly protected objects. Before a pilot, establish which data and keys each version can read, what trust state persists, and who may authorize a rollback. A recovery procedure should state the residual security consequence rather than implying that operational recovery restores every former assurance claim.

These questions extend the security architecture review of trust boundaries. The cryptographic mechanism must be examined where systems accept identities, updates and protected data from one another. A successful isolated algorithm test is useful evidence, but the release decision concerns that whole interaction.

Finish a bounded inventory without claiming the estate is complete

The strongest objection to inventory-first migration is that discovery can become an endless program that delays available improvements. I agree with the concern. I would use bounded slices with explicit acceptance criteria: every relevant cryptographic function in the selected service has an owner, evidence state, dependency path and treatment. Unknowns must be assigned and visible. A service can enter a pilot while broader discovery continues.

The opposite failure is declaring completion from the portion a tool can see. I would reconcile discovered uses against independent service and software inventories, procurement records, key-service records and recovery documentation. Ask specifically about dormant systems and paths absent from routine telemetry. Report verified coverage within a named scope and collection window, alongside unresolved populations. “Eighty percent migrated” is meaningless unless the denominator, weighting and acceptance test are defined.

Calendar guidance should shape planning without being misrepresented as a quantum forecast. The NCSC's published milestones call for discovery and initial planning by 2028, priority migration activity by 2031 and completion by 2035 (National Cyber Security Centre [NCSC], 2025). NIST's October 2026 final transition report describes its standards transition and federal policy context (Moody et al., 2026). Their scopes and obligations differ; an organization must identify the requirements actually applicable to it rather than copy one date into every record.

My method does not solve the uncertainty of future cryptanalysis, prove inventory completeness or validate a supplier's implementation. It also depends on people who understand data sensitivity and service dependencies. Its contribution is narrower: it makes the evidence needed for a migration decision explicit, separates claims that are often collapsed, and connects discovery to tests that can refute an unsupported completion claim.

If you need a defensible starting point, I can help assess one consequential service from cryptographic discovery through dependencies, prioritization and pilot acceptance. The deliverable should identify what the evidence establishes, what still blocks migration and which test would resolve each material uncertainty. Request a post-quantum migration assessment to turn an algorithm list into a change sequence your engineers, suppliers and leadership can evaluate.