PQC on Linux: What federal contractors need before CNSA 2.0 deadlines hit

Starting January 1, 2027, any new acquisition of equipment for a national security system must ship compliant with the Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) by default. That deadline is ten months away. For defense contractors in the middle of a hardware refresh or a software contract renewal, it is an active procurement requirement today.

The NSA published CNSA 2.0 in September 2022, establishing a set of post-quantum cryptographic algorithms for national security systems. NIST finalized the underlying algorithm standards in August 2024. FIPS-validated library implementations of those algorithms are a separate problem, and most security roadmaps have not caught up to it.

The 2027 acquisition deadline is already inside your procurement cycle

CNSA 2.0 sets differentiated mandates by system type. Web browsers and cloud services had a preferred adoption date of 2025. Traditional networking equipment (VPNs and routers) must support CNSA 2.0 by 2026 and phase out non-compliant hardware by 2030. Operating systems occupy a separate tier: organizations operating national security systems must support and prefer CNSA 2.0 by 2027 and use it exclusively by 2033.

A defense contractor buying servers, refreshing their Linux environment, or writing a software contract this year needs CNSA 2.0 readiness built into the procurement specification before the ink dries.

For most organizations, a hardware or OS procurement cycle runs 12 months or longer. The January 2027 deadline is already inside that window.

Security teams treating the operating system mandate as a 2033 problem, pointing to the exclusive-use date, are misreading it. The 2027 date applies to new acquisitions, not to systems already deployed. The 2033 date is the backstop for legacy systems that cannot be updated sooner.

Three NIST algorithms are finalized, and CNSA 2.0 mandates two by name

On August 13–14, 2024, NIST published its first three finalized post-quantum cryptographic standards:

• FIPS 203 (ML-KEM): module-lattice key encapsulation, replacing RSA and elliptic-curve key exchange
• FIPS 204 (ML-DSA): module-lattice digital signatures, replacing ECDSA
• FIPS 205 (SLH-DSA): stateless hash-based signatures, included as a backup if ML-DSA's mathematical foundations are ever weakened

CNSA 2.0 specifically mandates ML-KEM-1024 and ML-DSA-87 as the quantum-resistant algorithms for key establishment and digital signatures in national security systems. For firmware and software signing, CNSA 2.0 uses LMS and XMSS, the stateful hash-based signature schemes defined in NIST SP 800-208, rather than SLH-DSA. SLH-DSA is a valid NIST-standardized algorithm, but it is not in the current CNSA 2.0 mandate; architects building to CNSA 2.0 should prioritize ML-KEM and ML-DSA first.

The open question is which cryptographic libraries implement those standards, and which of those implementations carry the FIPS 140-3 validation that federal systems require. That is the compliance exposure. RLC Pro Hardened closes it.

A FIPS-validated library takes more than algorithm availability

OpenSSL 3.5, released in April 2025, added support for ML-KEM, ML-DSA, and SLH-DSA. That is algorithm availability. It is not FIPS 140-3 certification.

FIPS 140-3 validation, required for cryptographic modules used in federal and national security systems, is a distinct process. It requires testing by an accredited laboratory, submission to NIST's Cryptographic Module Validation Program (CMVP), and a review period that often runs two or more years from submission to certificate. OpenSSL 3.5.4 was submitted to CMVP for FIPS 140-3 validation in October 2025. As of early 2026, no certificate has been issued.

Organizations planning around an OpenSSL-based FIPS-validated PQC implementation should not expect that certificate in 2026.

Network Security Services (NSS) is Mozilla's cryptographic library that provides TLS and FIPS-mode cryptography for Java applications and system services on Linux. NSS is on a more advanced track. The CMVP offers a Module in Process (MIP) designation, which confirms a module is actively in the validation queue. Some federal procurement processes accept MIP status as evidence of meaningful progress while full certificate issuance is pending.

No Enterprise Linux distribution currently ships a FIPS 140-3 validated implementation of ML-KEM or ML-DSA. Organizations running in FIPS mode today cannot simultaneously enable post-quantum algorithms on any major commercial Linux distribution. FIPS mode is a standard configuration in federal contractor environments. This exposure is industry-wide, not a configuration issue a contractor can resolve unilaterally.

Rocky Linux customers get CAVP-certified ML-KEM and ML-DSA today

The Cryptographic Algorithm Validation Program (CAVP) validates algorithm implementations at the algorithm level. It is the prerequisite step for full FIPS 140-3 module validation, confirming that an algorithm is correctly implemented before the broader module review begins.

CIQ's NSS module for Rocky Linux is the first Enterprise Linux distribution module to achieve CAVP certification for both ML-KEM and ML-DSA, according to CIQ's press release. The module is currently in MIP status in the CMVP queue and is available now for Rocky Linux customers. For RLC Pro Hardened, the NSS module with CAVP-certified PQC algorithms ships as part of the commercial distribution. Security teams receive it without building, patching, or integrating the library independently.

The OpenSSL path is further behind. Organizations that depend on OpenSSL for FIPS-mode operations should track the CMVP submission for OpenSSL 3.5.4 and plan compliance timelines around the validation schedule, not the software release date.

Four facts that define your planning horizon

Security architects preparing to brief program managers, contracting officers, or CISOs should frame the conversation around these points:

What is true today	Why it matters for planning
NIST finalized ML-KEM, ML-DSA, and SLH-DSA in August 2024	Algorithm instability is no longer a reason to defer. The standards are set.
CNSA 2.0 requires new national security system OS acquisitions to default to CNSA 2.0, starting January 1, 2027	Any OS procurement in 2026 needs CNSA 2.0 capability in the spec, not as a future option.
FIPS 140-3 validation for PQC-enabled libraries often takes two or more years from submission	OpenSSL 3.5.4 is in the CMVP queue with no certificate as of early 2026. Do not plan around the software release date.
CAVP certification and MIP status provide interim compliance evidence	Starting with CIQ's NSS module gives you a documented posture today while full CMVP validation completes.

Organizations that begin qualification work now, in early 2026, can still build a defensible posture before January 2027. Those waiting for a fully FIPS-validated OpenSSL before acting are waiting for a milestone that will likely arrive after the deadline.

Begin qualification against CIQ's NSS module now. CAVP certification is complete, and the path to full module validation stays clear as CMVP review progresses.