Scope
This guide outlines post-quantum cryptography (PQC) implementation requirements for federal agencies and defense contractors using systems subject to NIST SP 800-53, NIST SP 800-171, FedRAMP authorization, or CMMC assessment. It focuses on cryptographic inventory, risk assessment, and transition planning for systems handling Controlled Unclassified Information or operating within federal enclaves.
You'll find requirement mappings, implementation steps, and a reference table to use during system security plan updates and authorization package reviews.
Key Concepts and Definitions
Cryptographically Relevant Quantum Computer (CRQC): A quantum computer capable of breaking current public-key cryptography mechanisms like RSA, ECDSA, and ECDH. While no CRQC exists today, development timelines are shortening.
Harvest Now, Decrypt Later: The tactic of intercepting and storing encrypted data now for decryption once a CRQC is available. This threat model applies immediately to data needing long-term confidentiality.
Quantum-Safe Cryptography: Algorithms designed to resist attacks from both classical and quantum computers. NIST has standardized three: CRYSTALS-Kyber (key encapsulation), CRYSTALS-Dilithium (digital signatures), and SPHINCS+ (digital signatures).
Cryptographic Agility: The ability to quickly update or replace cryptographic algorithms without major system redesign. SC-12(2) in NIST SP 800-53 Rev 5 addresses this capability.
Requirements Breakdown
NIST SP 800-53 Rev 5 Controls
SC-12: Cryptographic Key Establishment and Management
Document cryptographic mechanisms in your system security plan. Include PQC transition status during continuous monitoring updates.
SC-12(2): Symmetric Keys
Enhancement (2) requires symmetric cryptographic keys of adequate strength. AES-256 remains quantum-resistant, but key exchange mechanisms likely aren't.
SC-13: Cryptographic Protection
Implement FIPS 140-2 validated cryptography. As NIST releases quantum-safe algorithms, update implementations accordingly.
SC-17: Public Key Infrastructure Certificates
Your X.509 Certificate infrastructure is vulnerable to quantum attacks. Plan certificate authority migration paths now.
NIST SP 800-171 Rev 3 Requirements
3.13.11: Employ FIPS-validated cryptography
While PQC isn't explicitly mandated yet, your self-assessment or CMMC assessment will eventually need to address quantum readiness as FIPS modules incorporate quantum-safe algorithms.
3.13.16: Protect the confidentiality of CUI at rest
For CUI needing protection beyond five years, harvest-now-decrypt-later threats apply today. Document this risk in your system security plan and plan of action and milestones.
FedRAMP Implications
FedRAMP authorization packages require cryptographic inventories in the System Security Plan attachment. When FedRAMP updates its baseline controls to address PQC, you'll need to demonstrate transition planning during annual assessments.
Your independent assessor will test for cryptographic agility during security control assessments. Systems without documented migration paths will face findings.
CMMC Considerations
While CMMC 2.0 doesn't explicitly require PQC readiness, the underlying NIST SP 800-171 Rev 2 requirements for cryptographic protection apply. As DoD updates DFARS 252.204-7012 requirements, expect PQC readiness to flow down through prime-to-subcontractor relationships.
Implementation Guidance
Phase 1: Cryptographic Inventory (0-3 months)
Document every cryptographic mechanism in your environment:
- Public Key Infrastructure components
- VPN and remote access solutions using public-key authentication
- Code signing and software integrity verification
- Encrypted data at rest (focus on key exchange, not AES encryption itself)
- Authentication mechanisms including SAML, OAuth, and API tokens
Map each mechanism to the systems and data flows that depend on it. Your Risk Management Framework authorization boundary diagram should reflect these dependencies.
Phase 2: Risk Assessment (3-6 months)
Evaluate each cryptographic mechanism against the harvest-now-decrypt-later threat model:
Immediate risk: Data requiring confidentiality beyond 10 years (personnel records, acquisition-sensitive information, long-term research data, treaty-related communications).
Medium-term risk: Authentication systems and Public Key Infrastructure that would allow adversaries to impersonate trusted entities or forge data.
Lower risk: Ephemeral session keys and data with short confidentiality requirements.
Document these findings in your risk register. If you're operating under continuous authorization, brief your authorizing official on quantum-related risks during your next status update.
Phase 3: Transition Planning (6-12 months)
Build a cryptographic modernization roadmap:
Identify hybrid-capable systems: Modern TLS implementations can support both classical and quantum-safe algorithms. Prioritize these for early adoption.
Assess vendor roadmaps: Your cloud service providers, VPN vendors, and PKI vendors should have published PQC transition plans. If they haven't, escalate this supply chain risk.
Plan certificate authority migration: Design a phased approach where new certificate authorities support quantum-safe signatures while maintaining backward compatibility.
Budget for cryptographic module updates: FIPS 140-2 validated modules will need recertification as they incorporate quantum-safe algorithms. Factor this into your authority to operate renewal cycles.
Phase 4: Pilot Implementation (12-24 months)
Stand up a test environment using quantum-safe algorithms:
- Deploy a pilot certificate authority using CRYSTALS-Dilithium signatures
- Test VPN connections using CRYSTALS-Kyber key encapsulation
- Measure performance impacts on authentication flows
- Validate that your Security Technical Implementation Guide compliance scanning tools recognize the new algorithms
Document lessons learned for your broader implementation.
Common Pitfalls
Waiting for perfect standards: NIST has published standardized algorithms. Start your inventory and planning now.
Assuming symmetric encryption is the problem: AES-256 resists quantum attacks. Vulnerabilities lie in key exchange and digital signatures.
Ignoring procurement implications: The G7 advisory warns that failing to adopt PQC may lead to exclusion from public procurement. Expect quantum readiness questions from agency customers if you're pursuing FedRAMP authorization.
Treating this as an IT-only initiative: Your legal, acquisition, and mission teams need to understand which data requires long-term confidentiality protection. This isn't a decision your ISSO can make alone.
Overlooking supply chain dependencies: Your subcontractors and common control providers need to transition too. If you're a prime contractor, add PQC readiness questions to your supplier risk assessments.
Quick Reference Table
| System Component | Quantum Vulnerability | Priority | Recommended Action |
|---|---|---|---|
| TLS/SSL connections | Key exchange (ECDH) | High | Test hybrid TLS 1.3 with Kyber |
| VPN authentication | Public-key auth | High | Evaluate vendor PQC roadmaps |
| Code signing | Digital signatures | Medium | Plan Dilithium migration for CI/CD |
| SSH keys | Public-key auth | Medium | Monitor OpenSSH PQC support |
| Certificate authorities | RSA/ECDSA signatures | High | Design dual-root CA architecture |
| Email encryption (S/MIME) | Public-key encryption | Medium | Assess S/MIME alternatives |
| Document signing | Digital signatures | Low | Inventory signing tools and usage |
| Encrypted backups | Key exchange | High if long-term | Re-encrypt with PQC key exchange |
| API authentication tokens | Signatures (JWT) | Medium | Plan for quantum-safe JWT signing |
| HSM/TPM modules | Algorithm support | High | Verify vendor PQC roadmaps |
Your next step: Schedule a cryptographic inventory workshop with your system owners, network architects, and authorizing official representatives. Bring your system security plans and network diagrams. Address the present risk to data confidentiality that adversaries are already exploiting through collection and storage.
