up:: In the Protocols MOC

BouncyCastle PQC Provider

Bouncy Castle is an open-source cryptography library, maintained by the Legion of the Bouncy Castle Inc., that ships in parallel Java and C#/.NET editions and, in Java, registers as a JCE/JCA security provider so existing code can reach new algorithms through the standard cryptographic API. Its general-purpose builds carry the three NIST post-quantum standards, ML-KEM, ML-DSA, and SLH-DSA, alongside a broad catalog of earlier NIST-competition candidates, which makes it one of the most common on-ramps to post-quantum cryptography for JVM and .NET applications. The load-bearing nuance is that its FIPS-validated module, BC-FJA, does not yet include those three standards, so “Bouncy Castle supports ML-KEM” and “our FIPS-bound system can use Bouncy Castle’s ML-KEM” are two different facts on two different clocks.

Source: Bouncy Castle, “Latest NIST PQC Standards and more, Bouncy Castle Java 1.79” (2024-10-31); Bouncy Castle Java FIPS, “roadmap” (BC-FJA 3.0.0 adds ML-KEM, ML-DSA, SLH-DSA, early access, under test).

The short version:

• Bouncy Castle is a widely deployed open-source crypto library with parallel Java and C#/.NET editions; the Java edition ships a JCE/JCA provider, so existing Java code picks up new algorithms with a provider registration rather than a rewrite.
• The general-purpose Java build added ML-KEM, ML-DSA, and SLH-DSA in release 1.79 (October 31, 2024); the C# edition added the same three in 2.5.0 (December 4, 2024).
• It also carries a wide set of earlier NIST-competition candidates for experimentation and hybrids, including HQC, BIKE, Classic McEliece, FrodoKEM, NTRU, NTRU Prime, and SABER (KEMs), plus Falcon, Picnic, Rainbow, and GeMSS (signatures), and the standardized stateful hash-based signatures LMS and XMSS.
• The FIPS-validated distinction is the catch. The certified BC-FJA module (version 2.1.1, CMVP certificate #4943, FIPS 140-3 Level 1) lists only LMS among post-quantum algorithms; ML-KEM, ML-DSA, and SLH-DSA arrive in BC-FJA 3.0.0, which sits in early access and under test rather than certified.
• Recent releases wired PQC into protocols: the Java JSSE negotiates ML-KEM-only and hybrid ML-KEM TLS cipher suites, CMS SignedData signs with ML-DSA and SLH-DSA, and Java 1.82 adds draft ML-DSA TLS client authentication.

Think of Bouncy Castle as the well-stocked hardware store that most JVM and .NET buildings quietly source their locks from. When the new quantum-resistant locks were standardized, the store put them on its open shelves fast, so any project could buy and fit them the same week. The government-inspected, tamper-sealed aisle, the FIPS-validated module, restocks on a slower audited schedule, so the new locks sit on the open shelf months before they clear the sealed aisle. That gap between “available in the library” and “available in the validated module” is the whole story of Bouncy Castle’s post-quantum posture.

What is the Bouncy Castle PQC provider?

Bouncy Castle is a general-purpose cryptography toolkit that exists as two sibling codebases, one for Java and one for C#/.NET, both maintained by the Legion of the Bouncy Castle Inc. In Java it exposes two faces: a lightweight low-level API, and a Provider implementation (BouncyCastleProvider, commonly registered as BC) that plugs into the Java Cryptography Architecture, so an application that already calls KeyPairGenerator, Signature, or KEM through the JCA can select a Bouncy Castle algorithm by name without changing its calling code.

Source: Bouncy Castle, main site and Specification and Interoperability.

The distinction that governs everything post-quantum about Bouncy Castle is that it ships in two forms with different release cadences:

1. The general-purpose library (the bcprov jars for Java, and the C#/.NET package). This is where new algorithms land first, on a fast open-source cadence. It is the right tool for building, prototyping, and any deployment that does not have a FIPS-validation requirement.
2. The FIPS-certified module, BC-FJA (Bouncy Castle FIPS Java API, the bc-fips jar). This is a separately built, separately validated cryptographic module whose boundary is a specific signed JAR, and it moves on the slow cadence of the FIPS 140-3 validation program. A federal or regulated deployment that must run a validated module uses this one.

So a precise answer to “does Bouncy Castle support algorithm X” always names which of the two builds is meant. The general-purpose library and the FIPS module are the same project, and on post-quantum algorithms they are, as of this writing, at different points in their timelines.

Which post-quantum algorithms does Bouncy Castle support?

The general-purpose library carries the full set of NIST post-quantum standards plus a deep bench of competition-era candidates, in both the Java and C# editions. The three finalized standards landed together: Bouncy Castle Java 1.79 (October 31, 2024) added support for ML-KEM, ML-DSA, and SLH-DSA, the algorithms NIST finalized in August 2024, and the C# .NET edition added the same three in release 2.5.0 (December 4, 2024).

Source: Bouncy Castle, “Latest NIST PQC Standards and more, Bouncy Castle Java 1.79” (2024-10-31); Bouncy Castle, “NIST PQC Support and more, Bouncy Castle C# .NET 2.5.0” (2024-12-04).

Beyond the standards, the library keeps a large catalog of NIST Round 3 and Round 4 candidates. The project’s own documentation flags these as non-standardized and unsuitable for long-term use, provided for experimenting and for hybrid cryptography rather than production defense.

Source: Bouncy Castle, Specification and Interoperability (lists ML-KEM, ML-DSA, SLH-DSA, LMS, XMSS as standardized, and BIKE, HQC, Classic McEliece, SABER, FrodoKEM, NTRU, NTRU Prime, Falcon, Picnic, Rainbow, GeMSS as non-standardized).

Algorithm or family	Type	General-purpose library (Java and C#)	FIPS-validated BC-FJA module
ML-KEM	Lattice KEM	Java 1.79+, C# 2.5.0+	Absent today; arrives in BC-FJA 3.0.0 (early access, under test)
ML-DSA	Lattice signature	Java 1.79+, C# 2.5.0+	Absent today; arrives in BC-FJA 3.0.0
SLH-DSA	Hash-based signature	Java 1.79+, C# 2.5.0+	Absent today; arrives in BC-FJA 3.0.0
LMS and XMSS	Stateful hash-based signature	Yes (NIST SP 800-208)	LMS is an approved algorithm in BC-FJA 2.1.1 (CMVP #4943)
HQC, BIKE, Classic McEliece, FrodoKEM, NTRU, NTRU Prime, SABER	Round 3 and 4 KEM candidates	Yes, flagged non-standardized and experimental	No
Falcon (draft FN-DSA), Picnic, Rainbow, GeMSS	Round 3 signature candidates	Yes, flagged non-standardized and experimental	No

Source: Bouncy Castle, Specification and Interoperability; Bouncy Castle Java FIPS, roadmap; NIST CMVP, certificate #4943 (BC-FJA 2.1.1).

Two coverage notes are worth holding. Falcon is present in the general-purpose library as a competition candidate, and its standardized form, FN-DSA under FIPS 206, is still in draft at NIST, so the library carries the research algorithm ahead of the finished standard. And the stateful hash-based signatures LMS and XMSS are already standardized (NIST SP 800-208), which is why LMS, and not the newer lattice standards, is the post-quantum algorithm that made it into the certified FIPS module first.

Is Bouncy Castle’s post-quantum support FIPS-validated?

Only partially, and this is the fact a regulated deployment turns on. Bouncy Castle’s FIPS story lives in a separate module, BC-FJA (the Bouncy Castle FIPS Java API), which attained FIPS 140-3 certification announced July 31, 2024, after roughly thirty months of work, as module version 2.0.0 under CMVP certificate #4743. A later build, BC-FJA 2.1.1, holds CMVP certificate #4943 at FIPS 140-3 overall Level 1, validated January 17, 2025, with a sunset date of January 16, 2027.

Source: Bouncy Castle, “Bouncy Castle Crypto API Attains FIPS 140-3 Certification” (2024-07-31); NIST CMVP, certificate #4943 (BC-FJA 2.1.1, FIPS 140-3 Level 1, validated 2025-01-17, sunset 2027-01-16).

The catch is what that validated module actually approves. The approved-algorithm list for BC-FJA 2.1.1 includes LMS among post-quantum schemes, and it does not include ML-KEM, ML-DSA, or SLH-DSA. Those three arrive in BC-FJA 3.0.0, which the Bouncy Castle Java FIPS roadmap describes as now available under early access and currently under test, building on the 2.2.0 stream, meaning it has not yet completed CMVP validation.

Source: NIST CMVP, certificate #4943; Bouncy Castle Java FIPS, roadmap (BC-FJA 3.0.0 adds ML-KEM, ML-DSA, SLH-DSA, early access, under test).

BC-FJA module	CMVP cert	FIPS 140-3	Status	ML-KEM / ML-DSA / SLH-DSA
2.1.1	#4943	Level 1	Validated 2025-01-17 (sunset 2027-01-16)	Absent; LMS is the post-quantum algorithm listed
3.0.0 (based on 2.2.0)	pending	Level 1 (target)	Early access, under test	Adds all three

The lesson generalizes past Bouncy Castle. An algorithm being present in an open-source library, even correct and interoperable, is a different event from that algorithm shipping inside a validated module, and a compliance gate turns on the module certificate. This is the same CAVP-versus-CMVP and library-versus-validated-module distinction that runs through the whole protocol layer, and Bouncy Castle is a clean worked example of the two dates being far apart: the general-purpose library had ML-KEM in October 2024, while the validated module carrying it is still under test.

How does Bouncy Castle put post-quantum algorithms into TLS and signatures?

Bouncy Castle moved its post-quantum primitives up into the protocol and message layers over its 1.80, 1.81, and 1.82 Java releases, so the algorithms do real work instead of sitting as standalone KEM and signature calls. The provider approach means much of this surfaces through the standard Java security APIs.

Source: Bouncy Castle, “Bouncy Castle Releases Java 1.81 and C# .NET 2.6.1”; Bouncy Castle, “New Releases, Bouncy Castle Java 1.82 and Bouncy Castle Java LTS 2.73.9” (2025-09-23).

The concrete pieces, in the order they matter for a rollout:

1. TLS key exchange. Bouncy Castle’s JSSE provider added TLS support for ML-KEM-only and classical cipher suites, aligned with the IETF drafts, so a Java service using the Bouncy Castle TLS stack can negotiate post-quantum key exchange.
2. Interoperable key formats. Both editions added the finalized PKCS#8 private-key encodings for the NIST PQC algorithms as defined by the IETF, which is what gives reliable interoperability with other stacks such as OpenSSL 3.5.
3. CMS and document signatures. CMS SignedData generation now uses ML-DSA and SLH-DSA, bringing the post-quantum signatures into signed-message and document-signing workflows.
4. TLS client authentication. Java 1.82 added support for the emerging draft-ietf-tls-mldsa specification, enabling experimentation with ML-DSA in client-side authentication.

Because the JCA/JSSE provider model is the delivery vehicle, an application that already speaks to the Bouncy Castle provider often gains a new post-quantum capability by upgrading the dependency and selecting the new algorithm or cipher suite, which is the crypto-agility pattern of rebuild-plus-configure rather than a code rewrite.

When does a developer reach for Bouncy Castle for post-quantum work?

Bouncy Castle tends to be the natural choice when the runtime is the JVM or .NET and the team wants standardized post-quantum algorithms through a familiar cryptographic API rather than a foreign-function binding to a C library. A few lines usually decide it:

1. You are on Java or C# and want the NIST PQC standards now. The general-purpose library has ML-KEM, ML-DSA, and SLH-DSA in both editions, reachable through the standard provider interface.
2. You want breadth for research or hybrids. The catalog of competition candidates (HQC, Classic McEliece, FrodoKEM, NTRU, Falcon, and others) is wider than most production libraries carry, which suits experimentation and hybrid constructions, with the project’s own caveat that these are non-standardized.
3. You need the algorithm inside standard Java protocol and message plumbing. The JSSE TLS hybrid groups and the CMS ML-DSA/SLH-DSA signing put PQC into TLS and signed messages without a separate integration.

The counter-case is a FIPS-bound deployment that needs a validated module today. There, the certified BC-FJA module does not yet carry the lattice standards, so a team either waits for BC-FJA 3.0.0 to complete validation or reaches for a different validated path such as AWS-LC, whose module already carries validated ML-KEM. For pure algorithm breadth in a non-Java setting, liboqs covers more candidates, with the same “not for production” caveat.

Common misconceptions

1. “Bouncy Castle supports ML-KEM, so my FIPS system can use it.” The general-purpose library supports ML-KEM; the FIPS-validated BC-FJA module does not yet. A FIPS-bound deployment needs the validated module, and as of this writing that module lists LMS, with ML-KEM, ML-DSA, and SLH-DSA still in the under-test BC-FJA 3.0.0.
2. “The FIPS jar and the regular jar are the same download.” They are separate artifacts built and released on different cadences. The bcprov general-purpose jars and the bc-fips validated module are distinct, and an algorithm in one does not imply it is present or approved in the other.
3. “All the post-quantum algorithms in Bouncy Castle are production-ready.” The three NIST standards are finalized, and the many competition candidates (HQC, BIKE, Classic McEliece, FrodoKEM, NTRU, Falcon, Picnic, Rainbow, GeMSS) are flagged by the project as non-standardized and unsuitable for long-term use, present for experimentation and hybrids.
4. “Bouncy Castle is Java only.” It ships parallel Java and C#/.NET editions, and both added ML-KEM, ML-DSA, and SLH-DSA, the C# edition in release 2.5.0.
5. “Falcon in Bouncy Castle means FIPS 206 is done.” Falcon is present as a competition candidate; its standardized form, FN-DSA under FIPS 206, is still in draft at NIST, so the library carries the research algorithm ahead of the finished standard.
6. “Adding the provider makes my traffic post-quantum.” Registering the provider makes the algorithms available; a connection goes post-quantum only when the TLS layer negotiates a post-quantum group or cipher suite. The capability is opt-in at the protocol configuration, and a classical-only handshake keeps producing harvest-now-decrypt-later exposure.

Questions people ask

Is Bouncy Castle’s ML-KEM FIPS 140-3 validated? Not in a currently certified module. The validated BC-FJA 2.1.1 module (CMVP #4943) lists LMS among post-quantum algorithms and does not include ML-KEM. ML-KEM, ML-DSA, and SLH-DSA are slated for BC-FJA 3.0.0, which the roadmap lists as early access and under test, so a FIPS-bound system should confirm the current CMVP listing before relying on it.

Which post-quantum algorithms are in the general-purpose library? The three NIST standards, ML-KEM (FIPS 203), ML-DSA (FIPS 204), and SLH-DSA (FIPS 205), plus the stateful hash-based signatures LMS and XMSS, plus competition candidates BIKE, HQC, Classic McEliece, FrodoKEM, NTRU, NTRU Prime, SABER, Falcon, Picnic, Rainbow, and GeMSS.

Does the C# edition have the same post-quantum support as Java? For the NIST standards, yes. Bouncy Castle C# .NET 2.5.0 (December 4, 2024) added ML-KEM, ML-DSA, and SLH-DSA, matching the Java 1.79 additions, and later C# releases added HQC updates and the finalized PKCS#8 key formats.

What is the difference between BC-FJA and the regular Bouncy Castle jar? BC-FJA is the FIPS-validated cryptographic module, a separately built and separately certified artifact whose boundary is a specific signed JAR. The regular bcprov library is the general-purpose build that gets new algorithms first but carries no FIPS validation. Compliance turns on the BC-FJA certificate.

Can I do post-quantum TLS with Bouncy Castle in Java? Yes, in the general-purpose build. The Bouncy Castle JSSE provider supports ML-KEM-only and hybrid ML-KEM TLS cipher suites aligned with the IETF drafts, and it uses the finalized PKCS#8 key formats for interoperability with stacks like OpenSSL 3.5.

Should I use the competition candidates like Classic McEliece in production? No, the project itself flags them as non-standardized and unsuitable for long-term use, and provides them for experimentation and hybrid cryptography. Production defense should rely on the standardized ML-KEM, ML-DSA, and SLH-DSA.

How do I get post-quantum support into an existing Java application? Upgrade to a Bouncy Castle release that carries the algorithms (Java 1.79 or later for the general-purpose provider), register the provider, and select the post-quantum algorithm or TLS cipher suite in configuration. That is a dependency-and-configuration change rather than an application rewrite, which is the crypto-agility pattern.

When will the FIPS module carry ML-KEM? When BC-FJA 3.0.0 completes CMVP validation. The roadmap currently lists it as early access and under test, so the certified date is not yet fixed; the current CMVP listing is the authoritative place to check its state before a regulated deployment.

---

Everything here is the map, given freely. When your team needs its Bouncy Castle versions, its bc-fips module state, and its provider configuration assessed across the estate for a real post-quantum rollout, that is the work I do, and there is an alignment briefing for it.

Last verified 2026-07-09 · Maintained by Addie LaMarr, LaMarr Labs.