How to Start a Post-Quantum Cryptography Migration: Inventory, Prioritize, Pilot

Post-quantum cryptography is no longer a “later” topic for architecture teams. NIST finalized its first three principal PQC standards in August 2024 — FIPS 203 for ML-KEM (key encapsulation), FIPS 204 for ML-DSA (digital signatures), and FIPS 205 for SLH-DSA (stateless hash-based signatures) — and has told organizations to begin migrating now. NIST’s transition timeline points toward deprecating quantum-vulnerable public-key algorithms by 2030 for most federal use and removing them entirely from NIST standards by 2035, with high-risk systems expected to move earlier.

That makes PQC a migration problem, not just a research topic. The NCCoE’s active Migration to Post-Quantum Cryptography project is focused on demonstrating practices that help organizations discover where quantum-vulnerable algorithms are used, prioritize risk, and test interoperability with standardized PQC approaches. The operational point keeps coming up in every NIST migration document: the first phase is about inventory, prioritization, and pilot readiness, not instant replacement everywhere.

This tutorial gives you a realistic first-phase migration program. By the end, you will have a working crypto inventory format, a risk-based prioritization model, a crypto-agility review checklist, a pilot definition, a vendor questionnaire, and a phased roadmap you can take into enterprise architecture or security planning. If you want the strategic context before diving into the hands-on work, read the companion article on building a post-quantum cryptography migration roadmap.

Step 1: Inventory Where Cryptography Lives

Your first job is not choosing algorithms. It is finding where public-key cryptography actually exists in your environment. NCCoE’s migration project has made cryptographic discovery one of its two core workstreams specifically because most organizations do not have a complete view of where quantum-vulnerable algorithms are embedded across hardware, software, services, and protocols.

Start with the obvious protocol and PKI surfaces

At minimum, inventory these categories:

• TLS termination and mutual TLS
• Internal and external certificates
• VPNs and remote access
• Code signing and artifact signing
• Email security and document signing
• Identity providers and federation
• SSH, S/MIME, and other trust infrastructure
• HSM-backed and PKI-backed workflows

Create one inventory file instead of spreading this across separate notes.

File: pqc-crypto-inventory.csv

system,owner,environment,category,public_key_usage,current_algorithms,certificate_or_key_source,external_facing,confidentiality_lifetime,notes
public-web-gateway,network-team,production,tls,key-establishment-and-server-auth,RSA-ECDHE,corp-pki,yes,medium,front-door internet traffic
idp-platform,identity-team,production,identity,tls-signing-and-federation,ECDSA-RSA,corp-pki,yes,high,sso and federation dependencies
site-to-site-vpn,infra-team,production,vpn,key-exchange-and-auth,ECDSA-ECDH,vendor-managed,yes,high,long-lived tunnel data
artifact-signing,platform-team,production,code-signing,digital-signatures,RSA,ci-key-store,no,high,software trust chain
internal-service-mesh,platform-team,production,mtls,key-establishment-and-auth,ECDSA,mesh-ca,no,medium,service-to-service identity

Include code, libraries, and embedded usage

Inventory is not just a certificate report. You also need to find cryptography inside:

• Application libraries
• SDKs and language runtimes
• Mobile apps and embedded firmware
• Load balancers and API gateways
• HSM integrations
• Smart cards, tokens, or secure elements
• Vendor appliances and managed SaaS products

A simple source search can help you build the first pass:

grep -rI \
  "RSA\|ECDSA\|ECDH\|X25519\|secp256r1\|Ed25519\|PKCS#11\|OpenSSL\|BoringSSL\|wolfSSL" \
  ./services ./infra ./scripts

Do not forget vendor products and black boxes

NCCoE’s migration material explicitly includes hardware, software, and services, not just code you wrote yourself. Many of the hardest PQC problems will be inside products you do not control directly.

Create a separate product worksheet:

File: vendor-product-crypto-tracker.yaml

products:
  - name: edge-load-balancer
    owner: network-team
    pqc_visibility: low
    crypto_usage:
      - tls-termination
      - certificate-management
    vendor_contact: account-team
    roadmap_status: unknown

  - name: remote-access-vpn
    owner: infra-team
    pqc_visibility: low
    crypto_usage:
      - tunnel-key-exchange
      - device-authentication
    vendor_contact: support-escalation
    roadmap_status: unknown

Tag systems by migration relevance, not just presence

A complete inventory should capture:

• What the system does
• Where public-key crypto is used
• Whether it is internet-facing
• How long the protected data matters
• Whether the system is easy or hard to update

You should now have a first-pass inventory that covers protocols, PKI, code, hardware, and vendor products where public-key cryptography appears.

Step 2: Prioritize by Risk

NIST’s guidance is clear that not every system should move on the same timeline. Its project pages and related migration material emphasize prioritization based on risk, especially for systems that protect long-lived sensitive data and broadly deployed trust infrastructure.

Prioritize long-lived sensitive data first

The most urgent PQC migration candidates are often the systems protecting information that must remain confidential for many years. NCCoE’s migration documents explicitly call out “harvest now, decrypt later” risk as a major reason to start now. TLS and other widely deployed protocols are particularly relevant because encrypted traffic captured today could become readable later if it relied on quantum-vulnerable public-key cryptography.

A practical risk model should elevate:

• Sensitive legal or regulated records
• Intellectual property
• Government or defense-related information
• Long-lived customer or employee data
• Secrets and credentials protected in transit

Prioritize broad trust infrastructure

NIST’s 2025 PQC transition timeline highlights long-lived and widely deployed infrastructure such as PKI, code signing, TLS, and VPN as early priorities. These systems often affect many downstream systems at once.

Prioritize hard-to-upgrade systems

Some systems are risky because they are brittle, not because they are the most exposed. Examples include:

• Hardware appliances
• Embedded products
• Industrial or operational systems
• Remote sites with long replacement cycles
• Partner integrations that are protocol-sensitive

Build a risk scoring worksheet

File: pqc-prioritization.yaml

systems:
  - name: public-web-gateway
    data_lifetime: medium
    external_exposure: high
    upgrade_difficulty: medium
    trust_infrastructure: high
    pqc_priority: high

  - name: artifact-signing
    data_lifetime: high
    external_exposure: medium
    upgrade_difficulty: medium
    trust_infrastructure: critical
    pqc_priority: critical

  - name: site-to-site-vpn
    data_lifetime: high
    external_exposure: high
    upgrade_difficulty: high
    trust_infrastructure: high
    pqc_priority: critical

  - name: internal-service-mesh
    data_lifetime: medium
    external_exposure: low
    upgrade_difficulty: medium
    trust_infrastructure: medium
    pqc_priority: medium

You should now have a ranked list of systems that tells you where to focus first instead of trying to migrate everything at once.

Step 3: Assess Crypto Agility

NIST’s guidance frames the PQC transition as larger than previous cryptographic transitions because all public-key algorithms need replacement, not just one family. Crypto agility is defined as the capability to replace algorithms across protocols, applications, software, hardware, firmware, and infrastructure while preserving operations.

Ask whether the system can swap algorithms without redesign

For each system, answer:

• Is the cryptographic algorithm hardcoded?
• Is it chosen through config or policy?
• Can certificate chains and trust stores change cleanly?
• Can keys, signatures, and certificate sizes grow without breaking integrations?
• Does the protocol allow multiple or hybrid algorithms?

Ask whether hybrid mode is possible

For many early pilots, the practical question is not “can this system be PQC-only now?” It is “can this system interoperate in a hybrid or dual-stack posture while the ecosystem catches up?” NIST’s migration and interoperability workstreams are explicitly focused on helping vendors and standards bodies update commonly used protocols to include standardized PQC mechanisms and work through compatibility issues in controlled environments.

Ask what breaks when crypto changes

Use a crypto-agility checklist:

File: crypto-agility-checklist.md

# Crypto Agility Checklist

- [ ] Are algorithm identifiers configurable?
- [ ] Are key sizes and signature sizes assumed in code?
- [ ] Are certificates parsed with rigid size or field expectations?
- [ ] Can trust stores hold both current and PQC-related artifacts during transition?
- [ ] Can APIs, protocols, or appliances tolerate hybrid negotiation?
- [ ] Can HSMs, smart cards, or firmware be updated?
- [ ] Are there performance or packet-size assumptions tied to current crypto?

Track vendor roadmap certainty

NCCoE’s project audience explicitly includes product developers, integrators, and standards bodies because migration is not only a local implementation problem. Vendor readiness is a material factor.

File: vendor-agility-matrix.csv

product,owner,pqc_roadmap_known,hybrid_support,field_upgradeable,blocking_risk,notes
edge-load-balancer,network-team,no,unknown,yes,high,needs vendor escalation
remote-access-vpn,infra-team,partial,unknown,partial,high,awaiting protocol guidance
artifact-signing-service,platform-team,yes,no,yes,medium,can pilot sooner

You should now know which systems are configurable, which can support hybrid migration patterns, and which are likely to become blockers.

Step 4: Build a Pilot Scope

The best first PQC pilot is narrow, meaningful, and measurable. NCCoE’s own project structure reinforces this: discovery and interoperability testing are separate workstreams because organizations need both visibility and a controlled place to test compatibility before broad rollout.

Choose one manageable system

Pick something that is:

• Important enough to matter
• Controlled enough to test safely
• Narrow enough to complete
• Representative enough to teach you something

Good first pilots often include:

• An internal TLS-protected service
• A limited code-signing workflow
• A lab VPN connection
• A small PKI-dependent application path

Define interoperability requirements

Your pilot should answer concrete questions such as:

• Does the endpoint negotiate successfully with the chosen implementation?
• Do client libraries still work?
• Do certificates, signatures, or key material create tooling issues?
• What is the performance impact?
• What monitoring changes are needed?

Define rollback criteria

Do not run a pilot with no exit rules.

File: pqc-pilot-plan.yaml

pilot_name: internal-artifact-signing-lab
scope:
  system: artifact-signing-service
  environment: staging
  protocols:
    - signing
    - verification
goals:
  - validate interoperability with selected pqc-capable components
  - measure signing and verification performance
  - identify tooling or certificate-chain breakage
rollback_criteria:
  - verification failures exceed 1 percent
  - downstream tooling cannot validate artifacts
  - operational latency exceeds agreed threshold
success_metrics:
  - 100 percent successful signing in pilot path
  - 100 percent successful verification in pilot path
  - no undocumented integration failures

Keep the pilot bounded

Do not make your first pilot all of these at once:

• New algorithms
• New PKI
• New hardware
• New vendor contracts
• New application stack
• New network path

Change the fewest variables possible.

You should now have a pilot definition with scope, interoperability goals, rollback rules, and measurable success criteria.

Step 5: Engage Vendors and Internal Owners

PQC migration is not a security-only program. NIST’s migration documents explicitly target federal agencies, technology providers, standards organizations, and labs because the transition depends on coordinated product and protocol change, not just local configuration.

Ask vendors direct migration questions

Send a structured questionnaire instead of vague “what’s your PQC plan?” emails.

File: vendor-pqc-questionnaire.md

# Vendor PQC Questionnaire

1. Which NIST-standardized PQC algorithms do you support or plan to support first?
2. What is your expected timeline for production support?
3. Do you support hybrid deployment modes?
4. Which protocols or product features will gain PQC support first?
5. What interoperability testing have you completed?
6. What hardware, firmware, or software versions are required?
7. What logging and monitoring changes should we expect?
8. What are the rollback or downgrade considerations?
9. Are there licensing, hardware refresh, or contract impacts?
10. What is the documented roadmap and who owns it on your side?

Clarify internal ownership

At minimum, assign owners for:

• PKI and certificate lifecycle
• Network and TLS endpoints
• Remote access and VPN
• Application libraries and runtime upgrades
• HSM or hardware-backed trust
• Procurement and vendor management
• Enterprise architecture governance

Include procurement early

If a strategic product has no credible PQC roadmap, that is a procurement problem as much as an engineering problem. Put roadmap commitments into renewals and new purchases where appropriate.

You should now have named internal owners and a structured way to pressure vendors for real migration information.

Step 6: Create a Phased Roadmap

NIST’s current guidance supports a phased transition, not a single cutover. Its project pages emphasize discovery, prioritization, interoperability, and guidance development, while its transition timeline indicates different urgency levels for different systems.

Use a four-phase roadmap

File: pqc-roadmap.yaml

phase_1_discovery:
  target: now
  objectives:
    - complete cryptographic inventory
    - identify critical quantum-vulnerable systems
    - map owners and vendor dependencies

phase_2_pilot:
  target: within_6_months
  objectives:
    - complete one bounded interoperability pilot
    - document operational and compatibility findings
    - refine success and rollback criteria

phase_3_hybrid_transition:
  target: 6_to_18_months
  objectives:
    - deploy selected systems in dual-stack or hybrid-compatible patterns
    - update monitoring and operational runbooks
    - validate broader ecosystem interoperability

phase_4_broader_migration:
  target: 18_months_and_beyond
  objectives:
    - expand to prioritized production systems
    - retire or reduce dependence on quantum-vulnerable public-key algorithms
    - fold pqc planning into normal architecture and procurement cycles

Sequence by business and technical reality

A practical order is usually:

1. Discover what exists
2. Prioritize high-risk trust systems
3. Run one pilot
4. Prepare hybrid or dual-stack periods where needed
5. Migrate broader systems in waves
6. Clean up laggards and exceptions

Expect multiple waves, not one final state

NIST has finalized the first three PQC standards (FIPS 203, 204, 205) and selected HQC as an additional key encapsulation mechanism for future standardization. Ongoing standardization work continues for additional algorithms and use cases. That is another reason to emphasize crypto agility, not one-time substitution thinking.

Step 7: Document and Govern

A migration program fails quietly when inventory goes stale, exceptions pile up, and nobody connects the work to enterprise planning. The NCCoE project explicitly links discovery outputs to risk management, prioritization, and roadmap refinement.

Keep the crypto inventory alive

Turn the inventory into a managed artifact, not a one-time spreadsheet.

File: crypto-governance-checklist.md

# Crypto Governance Checklist

- [ ] Inventory owner assigned
- [ ] Quarterly review scheduled
- [ ] New systems must declare public-key crypto usage
- [ ] Vendor roadmap status reviewed at renewal
- [ ] Exceptions tracked with expiry dates
- [ ] Pilot findings fed back into architecture standards

Track exceptions deliberately

File: pqc-exceptions.csv

system,owner,reason,blocking_dependency,review_date,expiry_date
legacy-vpn-appliance,infra-team,vendor-roadmap-missing,hardware-refresh,2026-06-01,2026-12-01
partner-b2b-gateway,bizops-team,partner-protocol-constraint,external-counterparty,2026-05-15,2026-11-15

Tie the program to enterprise architecture

Make PQC part of:

• Architecture review
• Certificate and PKI planning
• Vendor review and procurement
• Security roadmap reviews
• Lifecycle and refresh planning
• Major protocol or trust-infrastructure changes

You should now have a governance pattern that keeps inventory current, tracks exceptions, and connects PQC work to broader enterprise decision-making.

Common Setup Problems

Inventory looks complete but misses embedded crypto

Certificate and PKI reports only cover infrastructure you manage centrally. Many applications embed crypto libraries directly (OpenSSL, BoringSSL, wolfSSL, Go’s crypto/tls). Run source-level searches and dependency scans across application repos, not just infrastructure docs.

Vendor says “we support PQC” but means something different

“Supports PQC” can mean anything from “we have a lab prototype” to “our next release ships ML-KEM in production.” Always ask for specific algorithm names, protocol versions, release dates, and interoperability test results. Use the vendor questionnaire from Step 5.

Pilot scope creeps into a full migration

A pilot that tries to cover new algorithms, new PKI, new hardware, and new vendor contracts simultaneously is not a pilot. It is a migration. Constrain your first pilot to one system, one environment, and the fewest variable changes possible.

Teams argue about priority because the risk model is subjective

Anchor prioritization to concrete factors: data confidentiality lifetime (years), external exposure (internet-facing or not), trust-infrastructure breadth (how many downstream systems depend on it), and upgrade difficulty (firmware versus config change). Subjective “importance” rankings invite political arguments.

Governance artifacts get created once and never updated

A crypto inventory that was accurate six months ago is not useful for migration planning today. Assign a named owner, schedule quarterly reviews, and require new system deployments to declare public-key crypto usage as part of architecture review. Treat the inventory like a living register, not a compliance checkbox.

Wrap-Up

A realistic first-phase PQC migration program should achieve four things: a credible inventory of where public-key cryptography lives, a risk-based prioritization model, a crypto-agility assessment for key systems, and at least one bounded pilot with rollback and success metrics. That aligns closely with NIST’s current direction: standardized algorithms are available now, the NCCoE migration project is actively demonstrating discovery and interoperability practices, and NIST is telling organizations to begin migrating rather than wait for a perfect future state.

What not to do yet: do not force a big-bang algorithm swap across every protocol, do not assume every product is crypto agile, and do not treat vendor roadmaps as someone else’s problem. What to start immediately: build the inventory, rank high-risk systems, open vendor conversations, define one pilot, and make crypto agility part of architecture and procurement review. The earlier you do that, the more freedom you keep for the harder interoperability and replacement decisions later.

For the strategic business case and architecture-level framing behind this work, see Post-Quantum Cryptography Migration Roadmap: A Practical Guide for Enterprise Security Teams. For related infrastructure hardening, the tutorials on hardening your CI/CD pipeline with Sigstore, SLSA, and SBOMs and rolling out enterprise passkeys cover complementary trust infrastructure topics.