PQC Migration Plan Template for Enterprise Teams

A post-quantum migration plan should connect every cryptographic dependency to an owner, target capability, test, rollback path, and evidence source. A list of algorithms is not a plan. It does not show which application depends on a certificate authority, whether an HSM supports the target key type, or who decides that a pilot can proceed.

Download the PQC migration plan CSV. The file is intentionally open and editable. No form is required.

Use it alongside the Post-Quantum Migration Checklist and Cryptographic Inventory Guide. Federal agencies preparing the plan required by OMB can also use the M-26-15 federal PQC migration guide to map these fields to the memo’s minimum submission requirements. The inventory discovers cryptography. This template turns the inventory into accountable migration work.

Template fields

Field	What to record	Why it matters
System ID	Stable inventory identifier	Connects evidence across tools and reports
System owner	Technical person or team accountable	Prevents ownerless dependencies
Business owner	Person accepting service and data risk	Separates technical work from risk acceptance
Application and environment	Service plus production, test or development	Prevents test support being mistaken for production support
Cryptographic function	Key establishment, signature, certificate, code signing, authentication, encryption wrapping	PQC support is capability-specific
Data classification and lifetime	Sensitivity and required confidentiality period	Supports harvest-now prioritization
Current algorithm and parameters	Exact deployed primitive and size	Names the migration source state
Key location	Software, KMS, HSM, device, file, EKM	Determines available replacement paths
Dependency	Client, protocol, library, CA, HSM, vendor or firmware dependency	Reveals blockers outside the application team
Provider capability	Exact supported workflow and status	Avoids provider-wide “PQC ready” labels
Standards status	Final standard, RFC, draft, vendor construction or research	Prevents drafts being treated as requirements
Target replacement	Exact algorithm or hybrid construction	Makes the plan testable
Hybrid required	Yes, no, or undecided with rationale	Captures transition design
Migration status	Discovery, assessed, blocked, pilot, validated, rollout, complete	Supports portfolio reporting
Test plan	Interoperability, performance, failure and security tests	Defines evidence before rollout
Rollback plan	Previous policy, key, certificate or release bundle	Limits operational risk
Target date	Organization-specific milestone	Must be tied to policy or risk, not speculation
Evidence link	Primary documentation, test result or approval	Makes status auditable
Last verified	Date the capability was rechecked	Vendor status changes

Start with cryptographic function, not product name

One cloud provider may support hybrid post-quantum TLS on an endpoint, ML-DSA signatures in a key service, and no PQ key type in another managed service. Recording only “Google Cloud,” “AWS,” or “Azure” creates a false status.

Split rows when one application uses multiple functions. A public API might need separate rows for TLS key establishment, certificate authentication, JWT signing, code signing, backup key wrapping, and administrative SSH. Each has different dependencies and migration maturity.

Use the cloud capability comparison and vendor support matrix to identify candidates, then verify the exact service documentation before updating the plan.

Assign ownership correctly

The system owner understands the implementation. The business owner accepts residual operational and data risk. A cryptography or security architecture team maintains policy and approved constructions. Procurement manages vendor evidence. These roles can belong to the same person in a small company, but the responsibilities should still be explicit.

A central migration lead should not become the owner of every application. The lead maintains the portfolio, resolves shared blockers, defines evidence requirements, and reports progress. Application teams remain responsible for implementation and testing.

Prioritize with data lifetime and exposure

Do not assign a universal date to every row. Prioritize systems that protect data with a long confidentiality lifetime and traffic that an adversary can capture today. Also prioritize long-lived signatures and firmware where future verification matters.

Availability and integrity requirements can change the order. A code-signing migration may depend on bootloaders, devices, update servers, recovery images, HSMs, and offline roots. A TLS key-establishment pilot may be technically easier, but it does not complete signature migration.

Government deadlines apply to defined systems and capabilities. They are useful planning references, not automatic legal deadlines for every private organization. Record the policy source and applicability in evidence or notes.

Define target capability precisely

Use exact names such as X25519MLKEM768, ML-KEM-768, ML-DSA-65, or a documented composite construction. State whether the target is hybrid. Do not enter “quantum safe” as the replacement algorithm.

Separate standards status from product status. FIPS 203, FIPS 204 and FIPS 205 are final NIST standards. A protocol that uses those algorithms may still be an IETF draft. A cloud implementation may be Preview even when the underlying algorithm standard is final.

The NIST standards guide and Hybrid Cryptography Explained provide the necessary distinctions.

Testing and acceptance evidence

A useful test plan includes:

exact client, server, library and firmware versions;
negotiation or key-operation evidence;
interoperability with unsupported clients;
message, certificate or handshake size impact;
latency, CPU, memory and HSM throughput;
error handling and fallback behavior;
audit logs and monitoring;
key rotation, backup, restore and revocation;
rollback under production-like load.

Use the PQC implementation testing guide for technical checks. Store results at the evidence link rather than writing “tested” in notes.

Rollback is part of migration design

Hybrid and staged deployment reduce compatibility risk only when teams can return to a known-good configuration. Record the previous TLS policy, library release, certificate chain, key version or firmware image. Define who can trigger rollback and how long it takes.

Rollback does not mean silently disabling a required protection after an error. A failed control should alert the owner and return the system to an explicitly approved state. Security and availability tradeoffs require documented risk acceptance.

Reporting without false completeness

Track status by capability and system. “80 percent migrated” is meaningless if the remaining 20 percent contains all root signing keys or long-lived exposed data. Report inventory coverage, assessed rows, blocked dependencies, validated pilots and production rollouts separately.

Migration is complete only for the defined scope and evidence standard. A hybrid TLS deployment does not make storage encryption, authentication, PKI or software signing post-quantum secure.

Frequently asked questions

Is this template a compliance document?

No. It is a planning and evidence structure. It does not establish SOC 2, HIPAA, regulatory or contractual compliance.

Should every cryptographic function have a separate row?

Yes when the function, key location, dependency, target or status differs. This preserves capability-level accuracy.

What if a vendor only publishes a roadmap?

Record the capability as blocked or roadmap-only, link the dated source, and define an alternative or reassessment date. Do not mark it supported.

Should target dates copy government deadlines?

Only when the requirement applies to the system. Otherwise derive dates from data lifetime, exposure, dependencies, lifecycle and organizational risk.

How often should the plan be reviewed?

Review it when inventory changes, vendors release capabilities, standards change, tests fail, or system ownership changes. High-priority rows deserve scheduled verification.