Purpose of This Script
You're on a five-year timeline to move high-value assets from quantum-vulnerable cryptography to post-quantum cryptography (PQC). According to NIST's October 2026 guidance, federal agencies must mitigate "as much quantum risk as feasible" by the end of 2030, with complete deprecation of quantum-vulnerable digital signatures after 2030 and disallowance under NIST standards after 2035.
This script guides you in implementing hybrid cryptographic solutions during the transition. It's aimed at information security officers who need to defend against "harvest now, decrypt later" attacks while ensuring compatibility with systems that haven't yet migrated.
The hybrid approach combines classical and quantum-resistant algorithms, or multiple PQC options with different mathematical foundations, to keep your systems secure even if one algorithm becomes vulnerable. Think of it as a cryptographic safety net during the 10-to-20-year journey from standardization to full integration.
Prerequisites
Before you begin:
- Complete Cryptographic Inventory: Identify all instances where your organization uses public-key cryptography for key establishment, digital signatures, code signing, and TLS/VPN encryption.
- Risk Classification Completed: Determine which systems qualify as high-value assets or high-impact systems under your risk framework.
- NIST-Approved Algorithms Identified: Review Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) for key exchange and the four families of PQC digital signature algorithms recognized by NIST.
- Development and Operations Teams Briefed: Ensure your technical staff understands this is a phased migration requiring coordination across application, infrastructure, and security layers.
Transition Script
Phase 1: Prioritize by Exposure Window
Risk-Based Prioritization Script:
FOR EACH cryptographic use case:
IF use_case = "data transmission over TLS/VPN"
OR use_case = "code signing"
OR use_case = "document signing/encryption"
OR use_case = "asymmetric key user sign-in"
THEN
priority = HIGH
rationale = "Subject to harvest-now-decrypt-later attacks"
migration_target = "2027-2028"
ELSE IF use_case = "user-machine authentication"
THEN
priority = MEDIUM
rationale = "Not vulnerable to retrospective decryption"
migration_target = "2029-2030"
DOCUMENT:
- Current algorithm in use
- System dependencies
- Interoperability requirements
- Estimated migration effort
Phase 2: Configure Hybrid Key Establishment
For Systems Using Key Exchange (TLS, VPN, Secure Channels):
HYBRID_KEM_CONFIGURATION:
primary_algorithm: ML-KEM
fallback_algorithm: [current classical algorithm]
negotiation_logic:
1. Client proposes: ML-KEM + RSA-2048 (or current standard)
2. Server responds with supported combination
3. Both parties derive shared secret using BOTH algorithms
4. Final key = KDF(ML-KEM_output || classical_output)
validation_check:
- Verify both algorithms contributed to final key
- Log algorithm selection for audit trail
- Alert if fallback-only mode persists beyond expected timeline
This setup ensures your key exchange remains secure as long as one algorithm holds. If ML-KEM becomes vulnerable, the classical component still protects you. If quantum computers arrive sooner, ML-KEM protects you.
Phase 3: Implement Hybrid Digital Signatures
For Code Signing, Document Signing, and Authentication:
HYBRID_SIGNATURE_CONFIGURATION:
signature_generation:
1. Generate signature_PQC using NIST-approved PQC algorithm
2. Generate signature_classical using current algorithm (RSA, ECDSA)
3. Combine: hybrid_signature = (signature_PQC, signature_classical)
signature_verification:
1. Extract both signature components
2. Verify signature_PQC against PQC public key
3. Verify signature_classical against classical public key
4. Accept ONLY IF both verifications pass
certificate_structure:
- Include both public keys in certificate
- Mark PQC algorithm as primary
- Set transition_end_date for classical component removal
Phase 4: Document Your Transition Timeline
Internal Governance Template:
TRANSITION_GOVERNANCE_RECORD:
system_name: [specific system identifier]
current_state:
- Algorithms in use: [list]
- Risk classification: [high-value asset / high-impact / standard]
hybrid_implementation_date: [YYYY-MM-DD]
hybrid_configuration:
- PQC algorithm: [specific NIST-approved algorithm]
- Classical algorithm: [current algorithm]
- Combination method: [describe]
pure_PQC_target_date: [YYYY-MM-DD, must be before 2035]
dependencies_blocking_pure_PQC:
- [vendor systems requiring classical algorithms]
- [legacy clients not supporting PQC]
- [estimated resolution timeline]
review_frequency: quarterly
responsible_party: [name, role]
Customization Options
Adjust Priority Thresholds Based on Your Threat Model: If you're protecting intellectual property in a sector with nation-state adversaries harvesting encrypted data, shift everything to HIGH priority. If you're a mid-market company with standard risk exposure, you can follow NIST's suggested timeline more conservatively.
Choose Your Hybrid Combination Method: The script shows concatenation of algorithm outputs (KDF of both results), but you might implement:
- Cascaded encryption (encrypt with algorithm A, then encrypt that ciphertext with algorithm B)
- Parallel signing with independent verification
- Algorithm-agile frameworks that let you swap components without changing the overall architecture
Modify the Governance Template for Compliance Requirements: If you're subject to ISO/IEC 27001 Clause 8.24 (use of cryptography), add fields for how this transition maps to your cryptographic controls documentation. If you're maintaining SOC 2 Type II, include fields for demonstrating the operating effectiveness of your hybrid implementation over the audit period.
Scale the Certificate Structure for Your PKI: Large organizations with complex certificate hierarchies need to consider root CA migration, intermediate CA updates, and certificate chain validation when both classical and PQC keys are present.
Validation Steps
Test Interoperability Before Production Deployment: Set up a lab environment to verify:
- Clients supporting only classical algorithms can still connect (graceful degradation)
- Clients supporting hybrid mode correctly derive shared secrets
- Signature verification fails appropriately if either component is invalid
Monitor Algorithm Negotiation Patterns: Your logging should capture which algorithm combinations are used in production. Persistent fallback to classical-only mode indicates a deployment gap to investigate.
Audit the Transition Timeline Quarterly: Review your governance records to ensure you're on track. NIST's 2035 disallowance deadline is firm. If dependencies block your pure-PQC migration, document them now and escalate vendor conversations.
Validate That Complexity Isn't Creating New Vulnerabilities: Hybrid implementations add code paths, configuration options, and operational overhead. Run penetration tests targeting the hybrid logic: can an attacker force downgrade to classical-only? Can they exploit timing differences between algorithm paths?
The goal isn't to run hybrid solutions forever. You're buying time to migrate safely while protecting against both classical and quantum threats. Once your dependencies support pure PQC and you've validated the algorithms in production, remove the classical components and simplify your architecture. That second transition is just as important as the first.
