Preparing your infrastructure for post-quantum cryptography

Your security team is asking about post-quantum cryptography (PQC). Your auditors are asking about PQC. Your customers are asking about PQC. And when you go looking for FIPS-validated post-quantum cryptography on Enterprise Linux, you find out it doesn't exist yet.

Federal contractors are getting Request for Proposal (RFP) language about quantum-resistant encryption. Healthcare organizations are fielding questions from compliance officers. Financial services firms are building out cryptographic inventories and discovering they have no compliant migration path. The pressure is real, but the infrastructure isn't ready.

NIST finalized three PQC standards in 2024: ML-KEM for key encapsulation, ML-DSA for digital signatures, and SLH-DSA for stateless hash-based signatures. Most major cryptographic libraries now include these algorithms. But "the algorithm exists" is not an answer you can give to an auditor asking for Federal Information Processing Standards (FIPS) 140-3 validation. For regulated environments, the gap between "technically possible" and "actually deployable" is the whole problem.

That's the gap CIQ is closing. We've done the engineering work to make the Network Security Services (NSS) package's ML-KEM and ML-DSA implementations FIPS 140-3 compliant. We pushed NSS through CAVP algorithm certification, achieved lab approval, and are now awaiting NIST’s stamp of approval. No Enterprise Linux vendor has FIPS-validated PQC today, but we're further along than anyone else in getting there.

This is where things stand, what the timeline looks like, and how to plan around it.

Why PQC matters now

The pressure comes from two directions, and neither is going away.

First, the regulatory calendar. Federal agencies and their contractors will move to PQC because they have no choice. Healthcare, financial services, and defense will follow because their auditors will make them. Budget cycles run 18 months. Procurement takes another year. Infrastructure refresh schedules are set three years out. The decisions made in 2026 determine what's actually deployable in 2028. That’s why treating 2035 as far away is the wrong way to think.

Second, the data itself. Any encrypted traffic captured today can be stored indefinitely; storage is cheap. When quantum computing reaches practical capability, that archived data becomes readable. Security researchers call this "harvest now, decrypt later," and it's not theoretical. Adversaries are actively collecting encrypted data today, waiting for the quantum computers that will eventually decrypt it.

If your data needs to stay confidential for ten years, the harvest-now-decrypt-later threat applies to you today.

The NSA built the Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) around this reality. The formal timelines apply to National Security Systems, but the underlying logic doesn't care about classification levels. Healthcare records, financial transactions, strategic business communications, defense contractor data: anything with long-term confidentiality requirements is already exposed to harvest-now-decrypt-later risk.

The gap between algorithms and validation

Most vendor materials skip over the fact that having PQC algorithms in your cryptographic libraries is not the same as having FIPS-validated PQC. For anyone who's sat through a FedRAMP audit, that distinction needs no explanation. For everyone else, it's the difference between passing a test and passing an audit.

When Rocky Linux shipped NSS version 3.112 in September 2025, it included ML-KEM and ML-DSA support. The algorithms worked correctly, passed test vectors, did everything they were supposed to do. That doesn’t mean they are FIPS 140-3 validated. Upstream open source projects prioritize functionality over compliance paperwork. Making those implementations meet federal standards requires additional engineering that most projects don't have the resources or interest to pursue: specific self-tests that run at module startup, proper entropy source handling, secure key zeroization on deallocation, and operational environment controls that add complexity without adding features. That’s before considering the time and cost of going through lab certification.

For organizations operating under FedRAMP, FISMA, HIPAA, or defense requirements, "the algorithm exists upstream" doesn’t satisfy compliance requirements. Compliance frameworks require CMVP-validated modules, full stop.

Three levels of "FIPS" exist, and conflating them causes expensive planning errors:

Algorithm availability means the PQC algorithms exist in your crypto library. This is table stakes for 2025, and most vendors can check this box, though not all modules can.

CAVP certification means NIST has tested and certified that the algorithm implementation is mathematically correct through the Cryptographic Algorithm Validation Program. Necessary, but not what auditors ask for.

CMVP validation means the complete cryptographic module, including all operational security controls, has been validated through the Cryptographic Module Validation Program. This is what compliance frameworks actually require, and this is where the bottleneck sits.

The path from CAVP to CMVP runs through NIST's validation queue, which takes 12+ months from submission on a good day. Anyone who's been through this process knows that timeline is optimistic. That's the system everyone operates under, not a constraint specific to any vendor.

What CIQ built

FIPS 140-3 requirements aren't static. NIST and the certifying labs continuously raise the bar, and novel algorithms like ML-KEM and ML-DSA face additional scrutiny. No validation precedent exists, so every implementation detail gets questioned. CIQ worked directly with atsec to close the gaps in NSS's PQC implementation.

Jeremy Allison, Distinguished Engineer at CIQ and co-creator of Samba, led the effort to make NSS's PQC implementation FIPS 140-3 compliant. This wasn't a simple configuration flag or a packaging change. FIPS 140-3 compliance requires self-test routines that verify cryptographic operations on every module load, entropy source validation that meets specific statistical requirements, key material zeroization that survives compiler optimization, and operational controls that most developers have never thought about. The kind of work that takes months, produces no visible features, and matters enormously to the people who need it.

All of this is publicly available on GitHub. It benefits the Rocky Linux community, other distributions, security researchers, and anyone else building FIPS-compliant PQC solutions.

Where things stand today

Rocky Linux from CIQ has been through the FIPS validation process enough times to know what it takes.

The RLC 9.6 NSS module with ML-KEM and ML-DSA has been approved by our lab partner, atsec, and is now in the Modules in Process (MIP) list pending NIST validation. Based on historical velocity, it will sit for at least 12 months alongside everyone else's submissions before achieving validation. The RLC 8 and 9.2 NSS modules (without PQC) are expected to achieve certification by Q2 2026.

To be direct about the current state: the engineering work is done and the compliance code exists, but no Enterprise Linux distribution has FIPS 140-3 validated PQC today. Not CIQ, not Red Hat, not Oracle, not anyone. CIQ is moving PQC through the validation process and we will announce when we have a certificate number to point to.

Status as of 2/3/2026:

RLC Version	Package	Status	MIP Date	CMVP Date
8	kernel	CMVP (Validated/Certified)	December 2024	11/24/2025
8	OpenSSL	MIP	January 2025
8 & 9.2	GnuTLS	MIP	January 2025
8 & 9.2	nss	MIP	December 2024
8 & 9.2 & 9.6	libgcrypt	CMVP (Validated/Certified)	December 2024	1/6/2026
9.2	kernel	CMVP (Validated/Certified)	February 2025	12/18/2025
9.2, 9.6	OpenSSL	CMVP (Validated/Certified)	February 2025	1/6/2026
9.6	GnuTLS	MIP	October 2025
9.6	kernel	MIP	October 2025
9.6	nss	MIP	January 2026

Planning your transition

The practical path forward depends on what your auditors will accept, though they often accept more than you might think.

If you require FIPS-validated cryptography, you cannot deploy PQC in production until CMVP validation completes. Plan for a hybrid transition where development environments and non-regulated workloads can experiment with PQC algorithms while production systems wait. Keep an eye on NIST's MIP list for timeline visibility. Budget for the integration work now so you're ready when certificates land.

If your compliance framework accepts MIP status, you may have more flexibility than you realize. Many organizations treat Modules in Process as sufficient for compliance purposes while waiting for full CMVP validation. Check with your auditors. The answer might surprise you.

If you have flexibility on validation, you can experiment with PQC algorithms today. Test the performance impact before it surprises you in production, because PQC key sizes and computational overhead differ meaningfully from classical cryptography. Building familiarity now means fewer surprises when mandates arrive.

Regardless of your compliance posture, inventory your cryptographic dependencies. Know which systems actually require FIPS-validated cryptography and which inherited the requirement from a checkbox someone checked years ago. The transition won't happen overnight, and understanding your real exposure surface now prevents expensive scrambling later.

The organizations doing this planning work in 2026 are the ones who won't be panicking in 2030 when the timelines start compressing.

What comes next

CIQ is tracking PQC implementation across all five FIPS cryptographic modules:

NSS: ML-KEM and ML-DSA in MIP as of January 2026 with validation anticipated by Q2 2027 at current velocity.

OpenSSL: PQC support added in OpenSSL 3.5. FIPS validation is planned for RLC 10.2 beginning Q3 2026 and RLC 9.10 in mid-2027.

Kernel: Monitoring upstream PQC development. The kernel crypto API will need PQC eventually, but stable implementations aren't there yet.

GnuTLS: PQC stabilization ongoing upstream. CIQ is monitoring and will prioritize compatibility with Enterprise Linux.

LibGCrypt: Awaiting stable upstream release and ingestion into the Enterprise Linux ecosystem.

As upstream projects mature their PQC implementations, CIQ will continue doing the FIPS compliance engineering and pursuing validation. The goal is comprehensive quantum-resistant infrastructure across the entire cryptographic stack, delivered on a timeline that lets you actually plan around it.

Start the conversation

If your compliance team is asking about PQC and you're trying to figure out what to tell them, that's exactly where we can help. CIQ has been through the FIPS validation process repeatedly. We know what's realistic, what the actual timelines look like, and how to sequence your preparation so you're not scrambling when certificates land.

For organizations that need FIPS-compliant infrastructure today while preparing for PQC, Rocky Linux from CIQ - Hardened (RLC-H) delivers pre-validated FIPS 140-3 cryptographic modules alongside the security hardening that regulated environments require. When PQC validation completes, RLC-H customers will have a tested upgrade path. Everyone else will be starting from scratch.

We can help you build a roadmap that accounts for both regulatory pressure and validation reality. Reach out at info@ciq.com or visit ciq.com to learn more.

---

References

NSA, "Commercial National Security Algorithm Suite 2.0" (September 2022).
https://media.defense.gov/2025/May/30/2003728741/-1/-1/0/CSA\_CNSA\_2.0\_ALGORITHMS.PDF

NIST, "Post-Quantum Cryptography FIPS Approved" (August 2024). FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), FIPS 205 (SLH-DSA). https://csrc.nist.gov/news/2024/postquantum-cryptography-fips-approved

Federal Reserve, "'Harvest Now Decrypt Later': Examining Post-Quantum Cryptography and the Data Privacy Risks for Distributed Ledger Networks" (2025). https://www.federalreserve.gov/econres/feds/harvest-now-decrypt-later-examining-post-quantum-cryptography-and-the-data-privacy-risks-for-distributed-ledger-networks.html

NSA, "CNSA 2.0 FAQ" (December 2024). https://media.defense.gov/2022/Sep/07/2003071836/-1/-1/1/CSI_CNSA_2.0_FAQ\_.PDF