Purpose of the Template
You need a structured plan to inventory, assess, and migrate your cryptographic infrastructure to quantum-resistant algorithms. This template forms the core of the PQC Migration Plan that federal agencies must submit by October 22, 2026, under Executive Order 14412. It's equally important for any organization protecting data with a shelf life beyond the next five years.
The template covers three stages: discovering your current cryptographic footprint, prioritizing assets based on quantum vulnerability, and scheduling the transition to NIST approved post-quantum algorithms. Federal High Value Assets must complete key establishment migration by the end of 2030 and digital signatures by the end of 2031. Your timeline may differ, but the methodology remains consistent.
Prerequisites
Before customizing this template, ensure you have:
Stakeholder alignment. Your CISO, Chief Privacy Officer, application owners, and infrastructure teams must agree on scope and authority. Cryptographic migration affects every system that encrypts, signs, or authenticates data.
Discovery tooling. Manual cryptographic inventory is ineffective at scale. You need automated scanning that identifies cipher suites, certificate chains, key exchange mechanisms, and signature algorithms across your entire estate. If you're subject to federal compliance requirements, consider FedRAMP Moderate authorized tools like Quantum-Safe Security (QSS) that provide audit-ready documentation.
Asset classification. Identify which systems handle restricted data, support critical operations, or face regulatory retention requirements. These assets face "Harvest Now, Decrypt Later" risk: adversaries archive your encrypted traffic today and decrypt it when quantum computers mature.
NIST algorithm familiarity. Your team should understand the approved post-quantum algorithms for key establishment and digital signatures. The migration isn't a simple swap; some algorithms require different key sizes, processing overhead, and integration patterns.
The Template
# Post-Quantum Cryptography Migration Plan
**Organization:** [Your organization name]
**Plan owner:** [Name, title]
**Submission date:** [Date]
**Review cycle:** Quarterly
---
## 1. CRYPTOGRAPHIC INVENTORY
### 1.1 Discovery methodology
- **Scanning tools used:** [Tool names, versions, authorization status]
- **Scope:** [Networks, applications, databases, cloud services covered]
- **Scan frequency:** [Initial scan date, ongoing schedule]
- **Inventory completeness:** [Percentage of estate scanned, known gaps]
### 1.2 Current cryptographic footprint
| Asset ID | Asset type | Current algorithm | Key size | Usage (encryption/signing/both) | Owner |
|----------|-----------|-------------------|----------|--------------------------------|-------|
| [ID] | [Application/service/database] | [Algorithm] | [Bits] | [Usage] | [Team] |
### 1.3 Cryptographic debt assessment
- **Legacy algorithms still in production:** [List with counts]
- **Hardcoded cryptographic implementations:** [Count, systems affected]
- **Undocumented key management processes:** [Description]
- **Third-party dependencies:** [Vendors, libraries, APIs using vulnerable crypto]
---
## 2. QUANTUM VULNERABILITY ASSESSMENT
### 2.1 Asset prioritization
| Priority tier | Criteria | Asset count | Example assets |
|--------------|----------|-------------|----------------|
| Critical | High Value Assets, restricted data, 10+ year retention | [Count] | [Examples] |
| High | Regulated data, 5-10 year retention | [Count] | [Examples] |
| Medium | Business-sensitive data, 2-5 year retention | [Count] | [Examples] |
| Low | Short-term operational data | [Count] | [Examples] |
### 2.2 Harvest Now, Decrypt Later exposure
- **Assets with long-term confidentiality requirements:** [List]
- **Data retention periods exceeding 5 years:** [Systems, data types]
- **Regulatory obligations preventing early deletion:** [Frameworks, retention rules]
---
## 3. MIGRATION ROADMAP
### 3.1 Target architecture
- **Key establishment algorithm:** [NIST-approved PQC algorithm]
- **[Digital signature](/glossary/digital-signature) algorithm:** [NIST-approved PQC algorithm]
- **Hybrid approach:** [Yes/No; if yes, describe classical + PQC pairing]
### 3.2 Migration phases
| Phase | Timeline | Scope | Success criteria | Dependencies |
|-------|----------|-------|------------------|--------------|
| Phase 1: Critical assets | [Start - End] | [Asset IDs] | [Measurable outcomes] | [Prerequisites] |
| Phase 2: High priority | [Start - End] | [Asset IDs] | [Measurable outcomes] | [Prerequisites] |
| Phase 3: Medium priority | [Start - End] | [Asset IDs] | [Measurable outcomes] | [Prerequisites] |
| Phase 4: Remaining estate | [Start - End] | [Asset IDs] | [Measurable outcomes] | [Prerequisites] |
### 3.3 Remediation approach
- **Algorithm replacement:** [In-place upgrade vs. system rebuild]
- **Key rotation strategy:** [Frequency, automation, rollback procedures]
- **Certificate reissuance:** [CA coordination, validity periods]
- **Testing requirements:** [Performance benchmarks, interoperability validation]
---
## 4. RISK MITIGATION
### 4.1 Continuity planning
- **Backward compatibility:** [Support for legacy clients, sunset timeline]
- **Rollback procedures:** [Triggers, process, responsible parties]
- **Performance impact:** [Latency tolerance, throughput requirements]
### 4.2 Third-party coordination
| Vendor/partner | Cryptographic dependency | PQC readiness | Migration coordination plan |
|----------------|-------------------------|---------------|----------------------------|
| [Name] | [Algorithm, usage] | [Status] | [Plan] |
---
## 5. GOVERNANCE
### 5.1 Accountability
- **Migration program lead:** [Name, title]
- **Technical lead:** [Name, title]
- **Compliance oversight:** [Name, title]
- **Executive sponsor:** [Name, title]
### 5.2 Reporting
- **Progress metrics:** [KPIs tracked]
- **Reporting frequency:** [Cadence, recipients]
- **Escalation triggers:** [Conditions requiring executive intervention]
### 5.3 Documentation requirements
- **Change records:** [System, format, retention]
- **Audit trail:** [What's logged, where, for how long]
- **Exception process:** [Approval authority for deviations]
---
## 6. VALIDATION AND COMPLIANCE
### 6.1 Testing protocol
- **Algorithm verification:** [Confirm NIST-approved implementations]
- **Interoperability testing:** [Cross-system, cross-vendor scenarios]
- **Performance regression testing:** [Baseline vs. post-migration]
### 6.2 Compliance checkpoints
- **Regulatory alignment:** [GDPR retention rules, CCPA, sector-specific mandates]
- **Internal policy compliance:** [Data classification, access controls]
- **Audit readiness:** [Evidence collection, documentation standards]
Customizing the Template
Section 1: Cryptographic Inventory. Use automated discovery across your entire estate. Manual inventories miss embedded cryptographic libraries, deprecated APIs still handling live traffic, and shadow IT deployments. If your scanning tool can't identify the cipher suite in a TLS handshake or the signature algorithm in a certificate chain, you need better tooling.
Section 2: Quantum Vulnerability Assessment. Prioritize based on data sensitivity and retention period, not system age or visibility. A legacy HR database holding employee records for seven years faces higher quantum risk than your public-facing marketing site. If you're subject to regulatory retention rules under GDPR, CCPA, or sector-specific frameworks, those assets move to the critical tier automatically.
Section 3: Migration Roadmap. Specify whether you're implementing pure post-quantum algorithms or a hybrid approach that pairs classical and PQC cryptography during the transition. Hybrid implementations provide backward compatibility but double your key management complexity. Document that trade-off explicitly.
Set realistic phase timelines. Consider a scenario where your team manages authentication for a suite of internal applications. Phase 1 might tackle the identity provider and certificate authority first, establishing the quantum-safe foundation before migrating downstream applications. Each phase should have measurable success criteria: "95% of critical assets using NIST-approved key establishment" beats "migrate critical systems."
Section 4: Risk Mitigation. Your third-party coordination table must include every vendor whose product or service performs cryptographic operations in your environment. SaaS providers, API gateways, payment processors, and cloud infrastructure all introduce dependencies. If a vendor can't articulate their PQC roadmap, you're carrying their risk.
Section 5: Governance. Assign a single program lead with budget authority and executive access. Cryptographic migration isn't an IT project; it's a cross-functional program requiring coordination across application teams, infrastructure, security, compliance, and procurement. Your escalation triggers should include technical blockers ("vendor X cannot support PQC before our deadline") and compliance gaps ("asset Y still using vulnerable algorithms 90 days before deadline").
Section 6: Validation and Compliance. Testing must confirm you're using authentic NIST-approved implementations, not experimental or pre-standardization versions. Performance regression testing matters: if your post-quantum key exchange adds 200ms latency to every authentication, you'll discover that in production when users revolt, not in your test environment.
Validation Steps
Completeness check. Every asset in your cryptographic inventory must appear in your migration roadmap. If you've identified 847 systems using vulnerable algorithms but your roadmap only addresses 600, you have a 247-asset gap. Close it before you submit.
Timeline feasibility. Walk through your migration phases with the teams who'll execute them. If Phase 2 requires upgrading 200 applications in three months and your release cycle is monthly with a 20-application capacity, your timeline is fiction. Adjust now.
Dependency mapping. Trace every cryptographic operation to its upstream dependencies. If your application relies on a cloud provider's key management service, your migration timeline depends on their PQC support. Document those dependencies and confirm vendor timelines in writing.
Regulatory alignment. Cross-reference your asset prioritization against your data retention obligations. If you're retaining customer data for ten years under a preservation order or Legal Obligation, that data faces quantum vulnerability today. Those assets belong in your critical tier, regardless of system age or technical debt.
Audit trail. Your plan should generate evidence that satisfies both internal compliance and external audit. If your supervisory authority or auditor asks "How did you prioritize these assets?" or "What testing validated this algorithm implementation?", your documentation should answer directly. Vague assertions fail audits. Specific evidence, timestamps, and responsible parties pass them.
