Skip to main content
INS // Insights

Post-Quantum Cryptography for Federal Systems

Updated May 2026 · 6 min read

The era of cryptographic uncertainty is over. NIST finalized its post-quantum cryptographic standards in 2024, and NSA's Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) has established migration timelines that federal agencies and National Security System (NSS) operators must meet. For government contractors and defense programs, the question is no longer whether to migrate cryptographic systems — it's how quickly and in what order.

Why Post-Quantum Cryptography Is Urgent

Current public-key cryptographic algorithms — RSA, ECDH, ECDSA — derive their security from the computational difficulty of factoring large integers or computing discrete logarithms on elliptic curves. Sufficiently powerful quantum computers running Shor's algorithm would solve these problems efficiently, rendering current public-key cryptography broken.

Two threat vectors make this urgent even before powerful quantum computers exist:

Harvest now, decrypt later (HNDL): Adversaries are already recording encrypted government communications with the intent to decrypt them once quantum computing matures. Data with long-term sensitivity (10–25 year classification periods) encrypted today with RSA-2048 or ECDSA may be decryptable within the adversary's timeline. Any sensitive government data transmitted or stored today that will retain sensitivity into the 2030s is potentially at risk.

System replacement lead times: Replacing cryptographic libraries in critical defense systems — weapon systems, satellite communications, command and control infrastructure — takes years. Programs that don't begin migration planning now will miss compliance deadlines and create security gaps as quantum computing advances.

NIST PQC Standards: What Was Standardized

NIST standardized three primary post-quantum algorithms in FIPS publications:

ML-KEM (FIPS 203) — Key Encapsulation Mechanism: Based on the CRYSTALS-Kyber algorithm. Used for key exchange — the post-quantum replacement for ECDH in TLS, SSH, VPNs, and similar protocols. This is the most immediately deployable standard since key exchange is where HNDL attacks strike.

ML-DSA (FIPS 204) — Digital Signature Algorithm: Based on CRYSTALS-Dilithium. Post-quantum replacement for ECDSA and RSA signatures used in code signing, certificates, and authentication protocols.

SLH-DSA (FIPS 205) — Stateless Hash-Based Digital Signature: Based on SPHINCS+. A hash-based signature scheme as a conservative alternative to lattice-based approaches, valuable for high-assurance applications where algorithm diversity is preferred.

NSA's CNSA 2.0 specifically mandates ML-KEM (Kyber) and ML-DSA (Dilithium) as the required algorithms for National Security Systems.

CNSA 2.0 Migration Timeline

NSA's published CNSA 2.0 migration guidance establishes specific timelines by system type:

Software and firmware: All new software developed for NSS should use CNSA 2.0 algorithms now. Legacy software must be migrated by 2030 for most categories.

Network security devices: VPN gateways, TLS terminators, and network appliances must support CNSA 2.0 algorithms by 2026 and fully transition by 2030.

Operational technology and embedded systems: Longer lead times recognized — 2033 timeline for legacy OT systems. New OT systems must use CNSA 2.0 algorithms from now.

Satellite communications: NSA has specific satellite comm migration guidance; affected programs should obtain direct NSA/CISA guidance for their specific systems.

These timelines apply specifically to National Security Systems. For systems that do not carry NSS designations but fall under FedRAMP or FISMA authority, NIST guidance and OMB direction will govern timelines. OMB has directed agencies to inventory cryptographic assets and begin migration planning.

Practical Migration Steps for Defense Contractors

Cryptographic inventory: The first step is knowing where cryptography lives in your systems. This means identifying every location where RSA, ECDSA, ECDH, AES (for symmetric, AES-256 is quantum-resistant), and SHA (SHA-384 and SHA-512 are quantum-resistant; SHA-256 is borderline) are used — in TLS connections, certificates, code signing, authentication systems, and in data at rest.

Prioritize by sensitivity timeline: Not all cryptographic migration needs to happen simultaneously. Data encrypted with transport security (TLS) that is not archived can be re-encrypted when the transport is upgraded. Data at rest that will remain sensitive in 2040 is higher priority. Key exchange (VPNs, TLS) is the highest priority for HNDL protection.

Hybrid classical/PQC approaches: The transition period justifies hybrid key exchange — using both classical and post-quantum algorithms simultaneously so that security depends on neither being broken. IETF has standardized hybrid key exchange methods for TLS 1.3 (RFC 8734, draft specifications). Deploying hybrid key exchange in VPNs and TLS now provides HNDL protection with minimal operational risk.

Vendor assessment: For commercial-off-the-shelf (COTS) security products — VPN appliances, certificate authorities, HSMs, TLS libraries — assess vendor PQC roadmaps. Products that do not support ML-KEM or ML-DSA will need replacement. Open-source libraries (OpenSSL 3.x, AWS-LC, BoringSSL) have integrated post-quantum support.

Classified systems — consult NSA/CNSS: For systems processing classified national security information, PQC migration should be coordinated with NSA's National Manager function and relevant CNSS policies. Do not implement ad-hoc PQC on classified systems without appropriate coordination.

The Window Is Now

Every month of inaction on cryptographic migration is a month of HNDL exposure accumulating in adversary hands. The timeline pressure from CNSA 2.0 is real for NSS operators. For FedRAMP systems, the migration requirement is coming through OMB guidance and will become a compliance item. Programs that build PQC migration into their roadmap now will be positioned for compliance; programs that wait will face compressed, expensive migrations under deadline pressure.

Rutagon supports government and defense programs with cryptographic risk assessments and PQC migration planning. Contact us to discuss your program's cryptographic posture.

Frequently Asked Questions

What is the difference between CNSA 2.0 and NIST PQC standards?

NIST developed the post-quantum cryptographic algorithms through an open international competition and published them as FIPS standards (FIPS 203, 204, 205). CNSA 2.0 is NSA's policy guidance specifically for National Security Systems, designating which NIST PQC algorithms are approved for NSS use and establishing migration timelines. NIST standards apply broadly to federal civilian systems under FISMA; CNSA 2.0 applies specifically to NSS operators.

Is AES-256 quantum-resistant?

Yes. Symmetric encryption algorithms like AES-256 and hash functions like SHA-384 and SHA-512 are considered quantum-resistant. Grover's algorithm provides a quadratic speedup for searching symmetric key spaces, effectively halving the security parameter — meaning AES-256 provides approximately 128-bit security against quantum attacks. CNSA 2.0 approves AES-256 for data-at-rest encryption and retains it in the approved algorithm suite.

How quickly can a defense contractor begin using post-quantum algorithms?

Very quickly for software systems. OpenSSL 3.x (with the OQS-Provider), AWS-LC (Amazon's cryptography library), and BoringSSL all support ML-KEM and ML-DSA. TLS 1.3 implementations that use these libraries can be configured to support hybrid key exchange today. The challenge is not algorithm availability — it's identifying all the places cryptography is used and prioritizing migration. Start with the cryptographic inventory.

Does my FedRAMP system need to migrate to post-quantum cryptography?

OMB has directed all federal agencies to develop cryptographic inventories and migration plans. FedRAMP's authorized services are tracking PQC integration at the cloud provider level — AWS, Azure, and GCP are all implementing PQC in their cryptographic services. FedRAMP system boundaries will need to address PQC through future NIST 800-53 revision guidance or specific FedRAMP PMO direction. Programs should begin inventory and planning now rather than waiting for specific compliance mandates.