Planning & Assessment

Purpose: Pre-migration planning, system inventory, and migration strategy selection

Version: 3.0.0

Overview

Successful migration to post-quantum cryptography requires thorough planning and assessment before importing the first key. This phase identifies:

• Current cryptographic inventory (algorithms, key sizes, usage patterns)
• Compatibility with PQC algorithms (migration paths)
• Risk assessment (data sensitivity, timeline constraints)
• Migration strategy selection (phased, parallel, big bang)
• Stakeholder communication (team roles, training needs)

Time Investment: 1-2 weeks for comprehensive assessment

Outcome: Migration roadmap with clear timeline, responsibilities, and success criteria

Migration Planning Checklist

Use this checklist to ensure all planning activities are completed before beginning migration:

Discovery Phase

• [ ] Inventory all cryptographic systems (applications, databases, file storage)
• [ ] Identify all cryptographic algorithms in use (RSA, ECDSA, AES, SHA-*, etc.)
• [ ] Document key sizes and algorithm parameters
• [ ] Map certificate expiration dates
• [ ] Identify key storage locations (PKCS#12 files, HSMs, key management systems)
• [ ] Document data encrypted with each key
• [ ] Identify signature verification dependencies

Risk Assessment

• [ ] Classify data by sensitivity (public, internal, confidential, secret)
• [ ] Determine regulatory requirements (FIPS, PCI-DSS, HIPAA, GDPR)
• [ ] Assess harvest-now-decrypt-later risk (long-lived data)
• [ ] Identify mission-critical systems (zero downtime required)
• [ ] Document rollback requirements

Technical Readiness

• [ ] Verify ANKASecure deployment (Core API, Admin API, Auth API)
• [ ] Confirm authentication configured (JWT scopes for migration endpoints)
• [ ] Test connectivity to legacy systems (PKCS#12 access)
• [ ] Validate trust anchor configuration (if using PKIX validation)
• [ ] Confirm license capacity (usage limits)

Stakeholder Alignment

• [ ] Identify migration team members (roles and responsibilities)
• [ ] Schedule stakeholder communication (kickoff, milestones, cutover)
• [ ] Define success criteria (technical and business metrics)
• [ ] Plan training sessions (migration process, rollback procedures)
• [ ] Establish escalation paths (issue resolution)

Timeline Planning

• [ ] Define migration phases (pilot, rollout, cutover)
• [ ] Schedule maintenance windows (if downtime required)
• [ ] Plan parallel operation period (dual-algorithm support)
• [ ] Set cutover date (legacy retirement)
• [ ] Define monitoring period (post-migration validation)

Legacy System Assessment

Key Discovery Tools

Identify where cryptographic keys exist across your infrastructure:

File System Scanning:

# Find PKCS#12 files
find / -name "*.p12" -o -name "*.pfx" 2>/dev/null

# Find PEM-encoded certificates
find / -name "*.pem" -o -name "*.crt" -o -name "*.cer" 2>/dev/null

# Find Java keystores
find / -name "*.jks" -o -name "*.keystore" 2>/dev/null

Application Configuration Review:

• Application configuration files (e.g., application.yml, .env, web.xml)
• TLS/SSL configuration (Nginx, Apache, load balancers)
• Database connection encryption settings
• API gateway configurations

Certificate Inventory:

Use tools like openssl to inspect certificates:

# Inspect PKCS#12 file
openssl pkcs12 -in certificate.p12 -info -noout

# View certificate details
openssl x509 -in certificate.pem -text -noout

# Check certificate expiration
openssl x509 -in certificate.pem -noout -enddate

Algorithm Identification

Create an inventory of cryptographic algorithms currently in use:

Output: Comprehensive algorithm inventory spreadsheet

Certificate Inventory

Document all X.509 certificates in your environment:

Certificate Details to Capture:

• Common Name (CN), Organization (O), Organizational Unit (OU)
• Subject Alternative Names (SANs)
• Issuer (CA details)
• Serial Number
• Validity period (notBefore, notAfter)
• Key usage extensions
• Extended key usage
• Certificate chain (intermediate CAs, root CA)

Tools:

• Manual inspection: openssl x509 -in cert.pem -text -noout
• Automated scanning: Certificate management platforms (Venafi, Sectigo, Let's Encrypt Certbot)
• Network scanning: SSL Labs, Qualys SSL Scan

Compatibility Analysis

Algorithm Mapping (Classical → PQC)

Map each legacy algorithm to its post-quantum equivalent:

Encryption Algorithms

graph LR
    subgraph Classical["Classical Algorithms"]
        RSA2048["RSA-2048 OAEP"]
        RSA4096["RSA-4096 OAEP"]
        ECC256["ECDH P-256"]
        ECC384["ECDH P-384"]
    end

    subgraph PQC["Post-Quantum Algorithms"]
        MLKEM512["ML-KEM-512"]
        MLKEM768["ML-KEM-768"]
        MLKEM1024["ML-KEM-1024"]
    end

    RSA2048 -->|Equivalent Security| MLKEM768
    RSA4096 -->|Equivalent Security| MLKEM1024
    ECC256 -->|Equivalent Security| MLKEM768
    ECC384 -->|Equivalent Security| MLKEM1024

    style RSA2048 fill:#ffcccc,stroke:#333,stroke-width:2px
    style RSA4096 fill:#ffcccc,stroke:#333,stroke-width:2px
    style ECC256 fill:#ffcccc,stroke:#333,stroke-width:2px
    style ECC384 fill:#ffcccc,stroke:#333,stroke-width:2px
    style MLKEM768 fill:#51cf66,stroke:#333,stroke-width:2px
    style MLKEM1024 fill:#51cf66,stroke:#333,stroke-width:2px

Mapping Table:

Signature Algorithms

graph LR
    subgraph Classical["Classical Algorithms"]
        RSA_SIG["RSA-SHA256/512"]
        ECDSA256["ECDSA P-256"]
        ECDSA384["ECDSA P-384"]
    end

    subgraph PQC["Post-Quantum Algorithms"]
        MLDSA44["ML-DSA-44"]
        MLDSA65["ML-DSA-65"]
        MLDSA87["ML-DSA-87"]
        FALCON512["FALCON-512"]
        FALCON1024["FALCON-1024"]
    end

    RSA_SIG -->|Standard| MLDSA65
    RSA_SIG -.->|Compact| FALCON512
    ECDSA256 -->|Standard| MLDSA65
    ECDSA256 -.->|Compact| FALCON512
    ECDSA384 -->|High Security| MLDSA87
    ECDSA384 -.->|Compact| FALCON1024

    style RSA_SIG fill:#ffcccc,stroke:#333,stroke-width:2px
    style ECDSA256 fill:#ffcccc,stroke:#333,stroke-width:2px
    style ECDSA384 fill:#ffcccc,stroke:#333,stroke-width:2px
    style MLDSA65 fill:#51cf66,stroke:#333,stroke-width:2px
    style MLDSA87 fill:#51cf66,stroke:#333,stroke-width:2px
    style FALCON512 fill:#4dabf7,stroke:#333,stroke-width:2px

Mapping Table:

Note: Choose ML-DSA for standard use cases, FALCON for constrained environments (smaller signatures).

Key Size Considerations

Understand the size implications of migrating to PQC:

Impact Analysis:

• Storage: PQC keys require ~3-10x more storage than classical equivalents
• Network bandwidth: Larger ciphertext/signatures increase payload sizes
• Database schema: May need to increase field sizes for key storage
• API payload limits: Verify max request/response sizes accommodate PQC

Mitigation:

• Use streaming APIs for large payloads
• Compress signatures/ciphertexts during transmission
• Update database columns to TEXT or BLOB types
• Increase API gateway payload limits if needed

Performance Impact

Estimate performance changes when migrating to PQC:

Encryption/Decryption Performance (approximate, hardware-dependent):

Signature Performance (approximate):

Verdict: PQC encryption (ML-KEM) is significantly faster than RSA. PQC signatures are comparable or faster for signing, slightly slower for verification.

Migration Strategy Selection

Choose the migration approach that best fits your organization's risk tolerance, timeline, and operational constraints.

Decision Matrix

Use this matrix to select the appropriate migration strategy:

graph TD
    Start{"How many applications<br/>use cryptography?"}

    Start -->|< 50 apps| Small["Small Scale"]
    Start -->|50-200 apps| Medium["Medium Scale"]
    Start -->|200+ apps| Large["Large Scale"]

    Small --> Timeline1{"Timeline constraint?"}
    Timeline1 -->|< 2 weeks| BigBang1["Big Bang Migration"]
    Timeline1 -->|Flexible| Parallel1["Parallel Operation"]

    Medium --> Risk{"Risk tolerance?"}
    Risk -->|Zero downtime required| Parallel2["Parallel Operation"]
    Risk -->|Acceptable downtime| Validate{"Validate in stages?"}

    Validate -->|Yes| Phased1["Phased Migration"]
    Validate -->|No| BigBang2["Big Bang Migration"]

    Large --> Phased2["Phased Migration<br/>Mandatory"]

    style BigBang1 fill:#ffd43b,stroke:#333,stroke-width:2px
    style BigBang2 fill:#ffd43b,stroke:#333,stroke-width:2px
    style Parallel1 fill:#4dabf7,stroke:#333,stroke-width:2px
    style Parallel2 fill:#4dabf7,stroke:#333,stroke-width:2px
    style Phased1 fill:#51cf66,stroke:#333,stroke-width:2px
    style Phased2 fill:#51cf66,stroke:#333,stroke-width:2px

Big Bang vs. Phased vs. Parallel

Rollback Planning

Regardless of strategy chosen, plan for rollback scenarios:

Rollback Triggers:

• Performance degradation > 20% from baseline
• Critical functionality broken
• Unacceptable error rates (> 1% failed operations)
• Security incident related to migration
• Regulatory compliance violation

Rollback Procedures:

1. Big Bang: Restore pre-migration database backup, redeploy legacy configurations
2. Parallel Operation: Shift traffic back to legacy algorithms (configuration change)
3. Phased Migration: Rollback specific phase, retain completed phases

Rollback Testing:

• Test rollback procedure in staging environment
• Document step-by-step rollback runbook
• Assign rollback decision authority (avoid decision paralysis)
• Define rollback time window (e.g., within 4 hours of issue detection)

Stakeholder Communication

Team Roles Matrix

Define clear roles and responsibilities for the migration effort:

Training Requirements

Ensure team members understand migration concepts before execution:

Migration Training Curriculum:

1. Introduction to Post-Quantum Cryptography (2 hours)

   • Quantum threat timeline
   • NIST PQC standards (ML-KEM, ML-DSA, SLH-DSA)
   • Regulatory landscape (Executive Order 14144, NSA CNSA 2.0)

2. ANKASecure Migration Capabilities (3 hours)

   • Import operations (PKCS#12, certificate validation)
   • Analyze operations (compatibility assessment)
   • Convert operations (re-encryption, re-signing)
   • Utility operations (bridge patterns)

3. Migration Strategy Deep Dive (2 hours)

   • Big bang vs. phased vs. parallel
   • Risk assessment and rollback planning
   • Timeline estimation and milestone planning

4. Hands-On Workshop (4 hours)

   • Import sample PKCS#12 files
   • Analyze certificate status
   • Perform test re-encryption
   • Monitor migration health

Total Training: 11 hours per team member

Go-Live Procedures

Define clear procedures for cutover events:

Pre-Cutover Checklist (T-1 week):

• [ ] All systems imported, analyzed, and converted in staging
• [ ] Performance benchmarks meet or exceed baseline
• [ ] Regression testing passed (100% functional coverage)
• [ ] Rollback procedure tested and documented
• [ ] Stakeholder communication sent (cutover schedule, expected downtime)
• [ ] Monitoring dashboards configured
• [ ] On-call rotation defined for cutover weekend

Cutover Day Procedures:

1. T-4 hours: Final backup of production databases and configurations
2. T-2 hours: Deploy ANKASecure PQC configurations to production
3. T-1 hour: Smoke tests (verify connectivity, authentication)
4. T-0: Begin migration (import → analyze → convert)
5. T+1 hour: Functional validation (critical user journeys)
6. T+4 hours: Performance monitoring (compare to baseline)
7. T+24 hours: Go/no-go decision (continue or rollback)

Post-Cutover Monitoring (T+1 week):

• Monitor error rates, latency, throughput
• Validate audit trail completeness
• Confirm compliance with regulatory requirements
• Gather stakeholder feedback
• Document lessons learned

Timeline & Milestones

Sample 3-Month Migration Timeline

gantt
    title Enterprise Migration Timeline (200 Applications)
    dateFormat YYYY-MM-DD
    axisFormat %b %d

    section Planning
    System Inventory & Assessment   :done, plan1, 2025-01-01, 7d
    Risk Assessment                 :done, plan2, 2025-01-08, 5d
    Strategy Selection              :done, plan3, 2025-01-13, 3d

    section Pilot (5 apps)
    Import Legacy Keys              :active, pilot1, 2025-01-16, 3d
    Analyze Compatibility           :pilot2, after pilot1, 2d
    Convert Data                    :pilot3, after pilot2, 5d
    Validate Results                :pilot4, after pilot3, 3d

    section Phased Rollout
    Cohort 1 (20 apps)              :rollout1, 2025-01-29, 7d
    Cohort 2 (20 apps)              :rollout2, after rollout1, 7d
    Cohort 3 (20 apps)              :rollout3, after rollout2, 7d
    Cohort 4 (20 apps)              :rollout4, after rollout3, 7d
    Cohort 5-10 (120 apps)          :rollout5, after rollout4, 30d

    section Cutover
    Final Applications              :cutover1, 2025-03-15, 5d
    Legacy Key Retirement           :cutover2, after cutover1, 3d
    Performance Validation          :cutover3, after cutover2, 7d

    section Post-Migration
    Monitoring & Optimization       :post1, 2025-03-30, 14d
    Documentation & Training        :post2, after post1, 7d

Key Milestones:

• Week 2: Planning complete, strategy selected
• Week 3: Pilot complete (5 applications validated)
• Week 8: 50% of applications migrated (100 apps)
• Week 11: All applications migrated (200 apps)
• Week 13: Post-migration validation complete

Related Documentation

• Overview & Strategy - Strategic foundation and pillar alignment
• Complete Enterprise Migration^* - Detailed 200-app migration workflow
• RSA to ML-KEM Migration^* - Encryption algorithm transition
• Monitoring & Validation - Success criteria and health checks

Version: 3.0.0

Last Updated: 2025-12-24

Status: Production Ready