Post-Quantum Cryptography Inventory: Plan Your Migration

A post-quantum cryptography inventory should connect each important use of cryptography to its business service, technical dependencies, owner, data lifetime and supporting evidence. Use that record to decide what needs investigation, a supplier answer or a migration pilot. An algorithm list alone leaves too many decisions unanswered.

For a security lead or IT manager, the first useful deliverable is a bounded dependency register. Another person should be able to open it, understand which service is under review, distinguish confirmed facts from assumptions, and see who owns the next action.

The workflow below offers original inventory fields, evidence states and a fictional example. It supports planning by teams authorized to review their own systems. A qualified cryptographic and platform review is still needed before selecting or deploying a migration design.

Start with the cryptographic function

Record what the cryptography does before discussing its replacement. The NIST standards announced in August 2024 include ML-KEM, specified in FIPS 203, for key establishment, and ML-DSA and SLH-DSA, specified in FIPS 204 and 205, for digital signatures. Those functions require different inventory questions. A key-encapsulation mechanism is not a replacement for the cipher that encrypts a large file.

Give a service separate records where it has separate cryptographic purposes. For example, the connection that transfers a document, the mechanism that protects a stored copy, and the signature used to approve an update should not disappear into one row labeled “encrypted.” Link the rows to a common service identifier so their relationship remains visible.

NIST’s October 2026 final IR 8547 distinguishes quantum-vulnerable public-key schemes from symmetric primitives and addresses dependencies across components. Avoid turning “PQC migration” into an instruction to replace every cryptographic algorithm in the same way. Record the function and ask the responsible specialist which transition applies.

If the terminology needs clarification, the symmetric and asymmetric encryption explainer provides background. Keep this inventory focused on the systems and decisions your team must manage.

Set a service boundary and accountable owners

Choose one service that the business can describe clearly: a design archive, a customer portal or a device-update service. Write its purpose, the environments included, the organizations operating it and the major interfaces it depends on. Identify exclusions explicitly, such as a separately managed customer device population.

Bring together the service owner, the data owner, the relevant application or infrastructure maintainers, and the person managing supplier relationships. A single coordinator can maintain the register, but cannot answer all of those questions alone. Give unresolved fields to the person who can obtain the evidence.

NIST’s CSWP 39-upd1, including June 2026 updates, places cryptographic inventories within broader governance, risk assessment and prioritized mitigation planning. Its asset-based approach includes code, libraries, hardware, protocols and enterprise services. Use that breadth to check your service boundary, without claiming that a register proves migration readiness.

A useful opening meeting ends with a named service, an agreed review boundary, accountable owners and an evidence collection plan. It need not end with every algorithm identified. Make the remaining uncertainty visible enough to guide the next meeting.

Build an inventory that supports a decision

Give each cryptographic use a stable identifier and link it to the existing asset or service record. The following fields are a proposed working format, not a mandatory NIST schema. Adapt them to your configuration records and change process.

Use references to controlled records rather than putting sensitive infrastructure detail in a widely shared spreadsheet. An inventory should point to the evidence needed for review; it should not become a new repository for private keys, credentials or confidential data samples.

Keep certificate references connected to the broader dependency record. Certificate expiry, issuance and renewal already have their own operating job. Use the TLS certificate inventory and renewal runbook for that work, then reference its relevant records here instead of maintaining conflicting copies.

Reconcile findings and preserve uncertainty

Start with records your team is authorized to inspect: architecture diagrams, application dependencies, configuration records and supplier documentation. Reconcile them with the responsible maintainers. Where an approved discovery exercise is needed, agree on its systems, methods, handling of results and operational constraints first.

The NCCoE migration project separates cryptographic discovery from interoperability work. Discovery asks where and how cryptography is used and how an inventory can support prioritization. Interoperability is a different question. Keep your register clear about which question each piece of evidence answers.

NCCoE’s December 2023 SP 1800-38B preliminary draft discusses differing discovery outputs and normalization. It remains a preliminary draft, rather than a final required inventory format or a tool endorsement. The practical implication is to preserve source references when combining findings, so a normalized row can still be traced to its original evidence.

Use separate fields for evidence and work state. “Supplier documentation reviewed” describes evidence. “Pilot planned” describes work. Neither establishes that the intended cryptographic function is active in the production environment.

For this workflow, label evidence as observed configuration, supplier-confirmed information, a documented plan or unknown. Add a date and scope to each label. If two records disagree, preserve both, assign a reconciliation task and keep the disputed field unresolved. A neat-looking register is less useful than an honest one.

Prioritize data lifetime and migration dependencies

NIST IR 8547 distinguishes harvest-now-decrypt-later confidentiality risk from signature and authentication migration concerns. Long-lived sensitive information and the time needed to change its protection deserve attention without predicting when a relevant quantum computer will arrive.

Ask the data owner how long disclosure would cause harm. A file’s deletion date or legal retention period does not automatically answer that business question. Record the reasoning and owner, especially where designs, research or other sensitive material have a long useful life.

For signature and authentication uses, ask a different set of questions: what relies on this trust relationship, who verifies it, how long the system must operate, and what constrains an update? Keep the answers specific to the use under review rather than copying a confidentiality priority into every row.

For an initial review, sort investigation work using three questions:

• Consequence: what sensitive information, business function or trust decision depends on this use?
• Lead time: does a supplier release, hardware replacement, partner change or lengthy validation process control the schedule?
• Uncertainty: which unanswered question could materially change the migration decision?

This is an editorial triage aid, not a validated numerical risk model. A critical service with an unknown supplier dependency may warrant an early investigation even when no replacement has been selected. Record the reason for its priority and the next fact needed.

The UK NCSC migration guidance sets targets of discovery and initial planning by 2028, highest-priority migration activities by 2031, and completion by 2035. It primarily addresses large organizations, critical national infrastructure and bespoke IT. Treat those dates within their UK guidance context; establish applicable obligations separately. Its discovery approach also considers service dependencies, data lifetime and managed providers.

Ask suppliers about the deployed path

Turn each unanswered dependency into a specific supplier question. A roadmap can help plan a conversation, but your register needs to distinguish what is promised, what is available for the relevant version and what has been checked in your environment.

Use these questions as a starting point for the supplier owner:

• Which cryptographic function and component does the answer cover?
• Which product version, deployment model and configuration are included?
• What protocol, library, module or hardware dependencies must also change?
• Which communicating parties, certificate systems or external integrations need coordination?
• Is the proposed capability planned, documented as available, or supported by scoped deployment evidence?
• What can the customer configure and verify, and what remains the provider’s responsibility?
• What compatibility, support and recovery information is available for a pilot?
• Who owns the answer, which document supports it, and when should it be revisited?

Attach the answer to the exact inventory records it addresses. Avoid marking an entire supplier “ready” because one product team answered a narrower question. Where the response is incomplete, retain the open dependency and a follow-up date.

The third-party cyber risk checklist supports the surrounding supplier review. This inventory adds the cryptographic function, implementation path and migration evidence needed for this particular service.

Use a fictional archive to test the planning logic

Consider a fictional engineering firm whose design archive must keep drawings confidential for many years. The archive uses a managed transfer service and a separate storage platform. The same firm also operates a device-update service that depends on signature verification.

The team creates distinct records for the archive’s transfer protection, its storage protection and the update service’s signature dependency. It does not infer the algorithm used by any of them from the product name or an “encryption enabled” setting.

The archive’s data owner explains the expected sensitivity period. Its technical maintainer supplies a dated configuration reference. The supplier’s general roadmap, however, does not identify the relevant transfer-service version. That row remains “supplier answer pending,” with the service owner responsible for obtaining a scoped response.

The update-service owner records a different uncertainty: which deployed device versions can accept the proposed verification change? The next action is to establish the supported device population and update constraints with the responsible vendor and engineering team.

Both uses may deserve early investigation, for different documented reasons. The archive’s confidentiality lifetime influences one decision; the update dependency and replacement lead time influence another. Neither row becomes “migrated” merely because an algorithm standard exists.

This example contains no measured configuration, vendor response or test result. Its purpose is to show how a useful register assigns different questions and owners to different cryptographic uses.

Turn one dependency into a controlled pilot

Choose a bounded pilot only after the service owner and relevant specialists agree on the candidate design and its dependencies. Document the intended cryptographic function, supported components, participating counterparts and environment. Identify the evidence that would demonstrate the intended behavior.

Write acceptance criteria before the exercise. They should cover the expected function, compatibility with required systems, relevant operational effects and the authorized recovery procedure. Have the responsible team define how to observe actual cryptographic use for that platform and version.

Keep the change controlled. Specify who approves it, what systems it may affect, when to stop and who can restore the approved prior state. Resolve a failed compatibility or assurance requirement through that process; do not weaken authentication, certificate validation or other protections simply to obtain a successful connection.

Afterward, attach the actual observations to the pilot record. Record the environment, versions, configuration, method, time and limitations. A successful exercise in that scope does not close every production dependency. If a required case was not performed, retain it as untested with an owner.

Catch the mistakes that make an inventory misleading

Counting products instead of uses. One application can have several cryptographic dependencies. Ask whether the row hides separate functions, environments or counterparties that need different evidence.

Confusing a library version with active behavior. A package record establishes what was recorded about that package. Ask the platform owner what additional configuration or observation is needed to establish the function in use.

Closing unknowns through formatting. Blank fields, merged rows and a general “ready” status can conceal unanswered questions. Preserve the evidence gap and name the person responsible for resolving it.

Letting migration planning replace routine maintenance. Keep current patching, certificate renewal and other approved security work moving through their existing processes. Link relevant change records so the PQC investigation can use their evidence.

Carrying forward stale answers. A supplier release, architecture change, service replacement or new counterpart can change the dependency under review. Revisit the affected rows instead of treating the previous assessment as permanent.

Keep the migration plan connected to evidence

End the first review with a register another maintainer can use: a defined service boundary, distinct cryptographic uses, traceable evidence, accountable owners and dated next actions. Keep unresolved questions in the migration plan where they can influence priorities and resources.

Start with one important service. Resolve its most consequential unknown, use the answer to choose the next investigation or pilot, and update the record after each meaningful change. That creates a practical basis for migration decisions without overstating what the team has established.

Research and testing disclosure: six adopted official sources were reviewed as of October 30, 2026, including NIST IR 8547 final, CSWP 39-upd1 with June 2026 updates, and the explicitly preliminary December 2023 discovery draft. The register, triage questions, evidence states and fictional example are original editorial aids. EncryptCentral performed no deployment, cryptographic scan, supplier interview or product testing for this guide. Qualified technical review and implementation-specific validation remain necessary.