Network Security Services, almost always shortened to NSS, is the cryptographic library inside Mozilla Firefox, Thunderbird, Red Hat Enterprise Linux, several IBM products, and a long list of identity systems that hardly anyone notices. NSS turns 30 years old in 2026. It started life inside Netscape, was open-sourced when Mozilla was spun out, and has been the workhorse for any application that needs FIPS-validated TLS without adopting OpenSSL.
When the world started shipping post-quantum TLS in 2023 and 2024, Firefox was visibly later than Chrome. That gap had a specific cause and a specific fix. This article walks through what NSS supports today, what is coming next, and how Firefox compares to other browsers in terms of post-quantum readiness.
What NSS Is and Where It Runs
NSS is a C library distributed by Mozilla. Its primary consumer is Firefox, but it also ships in:
- Thunderbird (Mozilla email client)
- Red Hat Enterprise Linux (in /usr/lib64/libnss3.so and friends)
- Pkcs11-tools and many smartcard middleware stacks
- Older versions of Curl on certain distributions
- Several Java keystores via the Sun-PKCS11 bridge
This breadth is why NSS's design has historically prioritized FIPS validation, hardware token integration, and deterministic builds across platforms over raw speed. The trade-off is that NSS tends to adopt new algorithms slower than BoringSSL, which has only one master and one priority.
For wider context on which libraries support post-quantum algorithms, see openssl PQC status 2026.
Where NSS Stands on Post-Quantum
NSS's post-quantum support is centered on ML-KEM. As of mid-2026 the picture looks like this.
| Algorithm | Status in NSS |
|---|---|
| X25519MLKEM768 hybrid TLS group | Available, Firefox enabling rollout |
| ML-KEM-512 / 768 / 1024 standalone | API-level support |
| ML-DSA | Engineering in progress |
| SLH-DSA | Not present |
| FN-DSA | Not present |
| HQC | Not present |
| Hybrid certificate signatures | Not present |
The pacing follows two principles. The first is to ship what NIST has finalized: ML-KEM via FIPS 203. The second is to align with the IETF draft for hybrid TLS groups so that Firefox interoperates with servers that adopted the same draft.
The Firefox Rollout Story
Firefox 132, which shipped in late 2024, included the X25519MLKEM768 hybrid key exchange behind a preference. Users could enable it manually via about:config by toggling the security.tls.enable_kyber preference (the name retained the historical Kyber spelling for backwards continuity). Firefox 135 and later moved the hybrid group toward enabled-by-default behavior on most platforms.
The pace is conservative for several deliberate reasons. NSS supports older Linux distributions, and Firefox ESR builds carry post-quantum changes downstream to enterprise users on a slower schedule. Firefox also negotiates TLS with a long tail of legacy servers that can break when ClientHello messages cross MTU boundaries. The Chromium team made the same observation but accepted slightly higher breakage in pursuit of broader rollout. Mozilla pushed for fixes on the server side first.
This split is sometimes summarized as Chrome shipping faster, Firefox shipping more carefully. Both end states are the same.
For more on TLS handshake size impact, see hybrid encryption.
How NSS Implements ML-KEM
The implementation lives in lib/freebl in the NSS source tree. NSS has its own internal cryptography backend called Freebl, which provides primitives like AES, SHA-2, and now ML-KEM. The ML-KEM code derives from a clean-room implementation reviewed against the FIPS 203 reference vectors.
Important integration details:
- ML-KEM key types are exposed via PK11SlotInfo and PK11PubKey objects, the same API surface used for RSA and EC keys
- A new mechanism, CKM_NSS_ML_KEM_KEM_PAIR_GEN, was added to the PKCS#11 layer for ML-KEM keypair generation; the standardized OASIS PKCS#11 mechanism numbers will replace this once finalized
- The hybrid TLS exchange uses internal helpers that combine X25519 and ML-KEM secrets via SHA3-256 per the IETF draft
This PKCS#11 routing matters because NSS is the standard-bearer for hardware-token compatibility. When someone says "FIPS module support," they often mean NSS. ML-KEM in software is straightforward; ML-KEM behind a smartcard or HSM is harder and requires the PKCS#11 layer to ship.
NSS Versus BoringSSL: Different Goals, Different Choices
Comparing NSS to BoringSSL PQ status clarifies why the rollout pace differs.
BoringSSL has one consumer that matters (Chrome) and ships when Chrome ships. NSS has dozens of downstream packagers. Red Hat's RHEL 9.4 backports NSS post-quantum support behind enterprise stability gates. Firefox ESR users only get changes that have been baked for months on the rapid release channel.
BoringSSL strips features it does not need; NSS keeps things working for legacy SSL clients in heavily regulated environments. ML-KEM in NSS therefore had to coexist with FIPS 140-3 boundaries, smartcard middleware that pre-dates the algorithm, and Java JCE bridges that route through PKCS#11.
The consequence is that NSS adopts post-quantum algorithms about a year behind BoringSSL but is the right place to look for FIPS-validated, hardware-token-compatible deployments.
Post-Quantum Signatures in NSS
ML-DSA support is in active development inside NSS. The work is split across:
- A pure software implementation in Freebl
- PKCS#11 wiring so smartcard vendors can add ML-DSA when they support it
- Certificate parsing changes so X.509 certificates with ML-DSA SubjectPublicKeyInfo entries are recognized
X.509 certificate processing is where the engineering gets thorny. Firefox needs to verify TLS server certificate chains. The chain might mix RSA, ECDSA, and ML-DSA signatures across the leaf, intermediate, and root. NSS's certificate path validator must handle all combinations, including hybrid certificates that carry two signatures (a classical and a post-quantum one) for parallel verification. The IETF X.509 PQC drafts under discussion in the LAMPS working group are active inputs to this work.
For a dedicated comparison of post-quantum signature algorithms, see ML-DSA vs SLH-DSA.
What Mozilla Has Said Publicly
Mozilla's security and crypto teams have published roadmap items via:
- Mozilla Wiki entries under wiki.mozilla.org/Security
- Bugzilla bugs tagged with the [pqc] tracking flag
- Hacks blog posts at hacks.mozilla.org
- Talks at IETF and Real World Crypto
The consistent message is that Firefox aims to track NIST-final algorithms through NSS, prioritize correctness and interoperability over rollout speed, and provide explicit user-facing controls so that enterprise administrators can disable hybrid groups if they break legacy middleboxes.
This conservatism extends to algorithms that did not become NIST standards. NSS does not ship HQC, BIKE, or FrodoKEM, and does not plan to. The library carries one KEM family (ML-KEM) and is preparing one signature family (ML-DSA), with hash-based signatures (SLH-DSA) under evaluation but not yet implemented.
Production Use Today
If you are running Firefox and visit a site behind Cloudflare, Google, or any of the major edge providers that opted in, you may already be using post-quantum TLS. The negotiated cipher details are visible by clicking the padlock icon and viewing connection details, which list the negotiated key exchange group. X25519MLKEM768 in that field means the ML-KEM software inside NSS handled the handshake.
For server administrators, Firefox interoperates with any server that follows the IETF X25519MLKEM768 draft. OpenSSL 3.5 with native or oqs-provider support, Cloudflare BoringSSL-based edges, and AWS-LC servers all qualify.
For deeper deployment specifics, see AWS KMS quantum migration and Azure Key Vault post-quantum.
What's Not in NSS Yet
To set expectations clearly:
- No hybrid certificate verification (chains carrying both classical and PQ signatures)
- No SLH-DSA, HQC, or other secondary algorithms
- No PQ for Smime in Thunderbird yet
- No PQ for client certificates in TLS yet
These items are tracked in Bugzilla and on the Mozilla wiki. The current focus remains on bedding down ML-KEM in TLS and bringing ML-DSA to certificate validation.
NSS in Red Hat and Enterprise Linux
Red Hat Enterprise Linux is one of the largest commercial consumers of NSS outside Mozilla itself. RHEL 9.x and the upcoming RHEL 10 ship NSS as part of the standard cryptographic stack. Red Hat backports security and feature updates from Mozilla's NSS releases into the RHEL package set, with their own QA and support contracts wrapping around it.
For PQC, this means the NSS in RHEL gains ML-KEM and (eventually) ML-DSA on a slightly delayed schedule compared to upstream NSS. Enterprises running RHEL with FIPS-validated configurations get a predictable rollout path: Red Hat backports the changes once they have been bedded down in Mozilla's release channel.
The same pattern holds for Fedora (which tracks upstream NSS more aggressively), CentOS Stream (which feeds RHEL), and downstream rebuilds like Rocky Linux and AlmaLinux.
How Firefox Decides Whether to Negotiate Hybrid TLS
Firefox makes the decision client-side based on:
- Whether the user's profile has enabled or disabled the security.tls.enable_kyber preference (legacy name retained for the X25519MLKEM768 group)
- The version of NSS bundled with the running Firefox (older Firefox lacks the supporting code)
- The operating system's network configuration (some captive portals or middleboxes break large ClientHello messages)
In normal browsing, the decision is automatic. Server compatibility is determined by the supported_groups extension exchange, just like with classical TLS groups. Server administrators do not need to do anything special on the Firefox side; if the server supports X25519MLKEM768, Firefox will negotiate it.
For deeper TLS background, see openssh PQC migration.
Comparing NSS to BoringSSL Architecturally
A high-level comparison highlights why pacing differs:
| Dimension | NSS | BoringSSL |
|---|---|---|
| Number of consumers | Many (Firefox, RHEL, Thunderbird, etc.) | Effectively one (Chrome and friends) |
| Release model | Versioned releases on a fixed cadence | Git head, no releases |
| FIPS validation strategy | First-class, multiple validations | Frozen subset (BoringCrypto) |
| Hardware token integration | Strong via PKCS#11 | Limited |
| API stability promise | Strong | None promised |
| Algorithm breadth | Conservative, NIST-final | Conservative, Chrome-driven |
These structural differences are why NSS post-quantum rollout is slightly slower but reaches a broader ecosystem when it does roll out.
Frequently Asked Questions
Why did Firefox ship post-quantum TLS later than Chrome?
NSS supports many downstream consumers, including FIPS-validated builds and hardware-token middleware. That ecosystem requires more conservative pacing than a single-vendor library like BoringSSL. The end result is similar deployment but with a few months of lag.
Is NSS FIPS validated for ML-KEM?
NSS has historically been the most FIPS-aligned library in widespread open-source use. ML-KEM is a NIST FIPS 203 algorithm, and NSS's implementation matches the spec, but FIPS module-level validation goes through CAVP/CMVP and is a separate certification process. Updated NSS modules with ML-KEM in scope are progressing through CMVP through 2026.
Can I enable hybrid post-quantum TLS in older Firefox versions?
Older Firefox releases shipped the feature behind preferences in about:config. Look for security.tls.enable_kyber. Modern Firefox versions enable it by default on supported platforms, so the preference toggle is no longer needed for most users.
Does NSS support OpenSSL's oqs-provider algorithms?
No. oqs-provider is an OpenSSL 3 plugin and does not integrate with NSS. NSS provides its own native ML-KEM via Freebl. They share no code paths.
Where can I find the source?
NSS source is mirrored at hg.mozilla.org and github.com/nss-dev/nss. The post-quantum modules live in lib/freebl and the TLS integration in lib/ssl.
How do Thunderbird users benefit from NSS PQC support?
Thunderbird uses NSS for both its TLS connections to mail servers and for S/MIME message encryption and signing. As NSS adds PQC, Thunderbird's TLS connections to IMAP, POP, and SMTP servers can use hybrid PQ groups. S/MIME message-level PQC requires additional ecosystem support (mail clients on the receiving end and CA infrastructure that issues PQ certificates). Mozilla is participating in those broader discussions.
Does Firefox Sync use post-quantum cryptography?
Firefox Sync's encryption is layered on top of TLS plus client-side keys. The TLS leg uses NSS, so it picks up PQC as NSS does. Client-side encryption keys are still classical; the migration of those is a separate Mozilla project tied to overall service architecture.
Sources
- Mozilla NSS source repository, hg.mozilla.org/projects/nss
- NIST FIPS 203 (Module-Lattice-Based Key-Encapsulation Mechanism), August 2024
- Mozilla Security Engineering Blog, posts on PQ deployment
- Bugzilla NSS PQ tracker bugs (search bug status with [pqc] tag)
- IETF draft-kwiatkowski-tls-ecdhe-mlkem
- Mozilla Wiki, Security Engineering pages
Related Articles
- What is post-quantum cryptography
- ML-KEM explained
- ML-DSA vs SLH-DSA
- OpenSSL PQC status 2026
- Hybrid encryption
Protect Your Data Before Q-Day Arrives
QNSQY's NIST-standardized post-quantum encryption protects files against both current and quantum-era threats.