# Kong Gateway Enterprise 3.4.x.x EOL
# Kong Gateway Now Supports FIPS 140-3
Anthony Gatti
Product Manager, Kong
Regulated industries don't get to choose their cryptography standards; governments and auditors choose for them. If you sell software to a U.S. federal agency, a bank, a healthcare payer, or almost any organization operating under FedRAMP, HIPAA, or PCI DSS oversight, the cryptographic modules in your stack have to carry a FIPS validation.
Previously, that meant FIPS 140-2. Today, it increasingly means FIPS 140-3 - the current, more rigorous revision of the standard, and the one NIST is actively pushing the ecosystem toward as 140-2 validations age out.
We're announcing that Kong Gateway now supports FIPS 140-3, published side by side with our existing FIPS 140-2 artifacts. If you run Kong in a regulated environment, you can adopt the newer standard on your own timeline, without disrupting what's already in production.
## About FIPS 140-3
FIPS 140-3 is the U.S. and Canadian government standard for validating cryptographic modules - the code that does encryption, key generation, and digital signatures. It's issued by NIST and CCCS and enforced through CMVP, the Cryptographic Module Validation Program. A module doesn't get to self-certify; it goes through independent lab testing against the standard before it can be called "FIPS validated."
140-3 supersedes 140-2. It aligns with the international ISO/IEC 19790 standard, tightens requirements around self-tests, non-invasive attack mitigation, and lifecycle assurance, and - critically for anyone with a validation to maintain - it's the version CMVP is now issuing new certificates against. Increasingly, customers are asking for 140-3 by name.
## What FIPS 140-3 means for Kong
If you're running Kong Gateway as the front door for traffic into a regulated environment, the cryptographic module terminating TLS and handling keys has to be one your auditors will accept. Practically, FIPS 140-3 support means:
- - **You can meet the newer bar without switching gateways.** Federal agencies, financial institutions, and healthcare organizations that require FIPS 140-3 validated cryptography can run Kong Gateway natively, instead of routing around it with an external TLS terminator.
- - **Nothing breaks for existing FIPS 140-2 deployments.** Kong builds and publishes both certification levels as distinct artifacts, with distinct package and image names. If you're already running the 140-2 build, it keeps working exactly as it does today; you opt into 140-3 when you're ready, not because you're forced to.
- - **The upgrade path is a build choice, not a rewrite.** The same Kong Gateway codebase runs under either provider. Moving to FIPS 140-3 is a matter of pulling the
`-fips-140-3`artifact instead of`-fips`, not re-architecting how you deploy Kong.
## What we changed
Getting here took more than swapping a version number. A few of the key engineering pieces include:
**A newer, validated OpenSSL FIPS provider.** Kong upgraded its embedded OpenSSL FIPS provider from 3.0.9 to 3.1.2 — the provider version that carries the FIPS 140-3 validation. Both provider versions ship today, so Kong can build and release FIPS 140-2 and FIPS 140-3 artifacts side by side from the same source tree, selected at build time.
**TLS 1.3 in FIPS mode.** The FIPS 140-3 build adds TLS 1.3 alongside TLS 1.2, with AES-GCM and AES-CCM ciphersuites configured directly in the FIPS OpenSSL configuration. Previously, FIPS-mode Kong deployments were limited to TLS 1.2.
**A tightened, audited TLS 1.2 cipher suite.** Rather than carry forward the broad OpenSSL FIPS cipher alias, the FIPS 140-3 build serves an explicit, narrower list of four modern ECDHE + AES-GCM suites. It's a stricter default that reflects current guidance, decided before the first release rather than tightened after customers were already depending on the wider list.
**A centralized FIPS runtime model.** Kong added a single source of truth for FIPS state - resolved from the build-time package marker, consistent across reloads, and enforced across startup paths including package installs, systemd, traditional containers, and distroless images. FIPS-mode builds now default to FIPS enabled, with cryptographic policy (like a minimum RSA-2048 key floor) enforced centrally rather than scattered across call sites.
**Consistent cryptographic policy across every signing path.** Kong unified FIPS-mode signing and verification policy across JOSE, OpenID Connect, JWT, JWT Signer, and Datakit, so a single algorithm policy governs token and assertion handling everywhere it happens, rather than each plugin enforcing its own rules. Alongside this, Kong closed off weak-key paths that FIPS mode is specifically meant to prevent - rejecting weak SAML signing keys, weak audit-log signing keys, undersized ACME account and EAB JWS keys, and disallowing default EdDSA JWKS generation (not yet part of the FIPS-approved algorithm set) in favor of RSA-PSS or NIST-curve ECDSA.
**Honest boundaries around post-quantum cryptography.** Kong also shipped post-quantum TLS support (hybrid ML-KEM key exchange, ML-DSA certificates) as a separate, non-FIPS capability. No FIPS-validated OpenSSL provider yet implements ML-KEM at any certification level, so rather than let a FIPS deployment silently fail to negotiate PQC, Kong detects FIPS mode, drops any post-quantum configuration, logs a clear warning, and continues running in FIPS mode. You get an explicit answer instead of a confusing handshake failure.
## The bottom line
FIPS 140-3 support means Kong Gateway keeps pace with where cryptographic compliance is headed, without asking existing FIPS customers to move first. You get a validated, hardened cryptographic module built into the gateway you already run - chosen at build time, consistent at runtime, and backed by the same OpenSSL FIPS provider lineage CMVP is actively certifying today.
If you operate Kong Gateway under a FIPS 140-2 requirement today, no action is needed. If your compliance program is moving to FIPS 140-3, the `-fips-140-3` artifact is ready for you now.
Anthony Gatti
Product Manager, Kong
Recommended posts
# Kong Gateway 3.14: More Control, Less Toil With Simplified Security and Policies
Managing gateway configurations at scale is harder than it looks. When a plugin needs to apply to most routes, but not all, teams could either duplicate configuration across routes and violate DRY (“Don’t Repeat Yourself”) principles, or write custo
# Create an Internal API and Service Inventory with Konnect Service Catalog
When speaking with our customers, and particularly with platform teams, we repeatedly hear about how difficult it is to discover and govern all the services and APIs that actively run on their infrastructure. In ever-expanding and changing environm
# Kong Gateway 3.9: Extended AI Support and Enhanced Security
Today we're excited to announce Kong Gateway 3.9! Since unveiling Kong Gateway 3.8 at API Summit 2024 just a few months ago, we’ve been busy making important updates and improvements to Kong Gateway. This release introduces new functionality arou
# Faster Config Updates in Hybrid Mode with Incremental Config Sync
In Kong Gateway 2.0, we released Hybrid Mode , also known as Control Plane/Data Plane separation. With it, our customers could efficiently and securely deploy clusters of Kong Gateway Dataplanes on their on-prem, private, and public clouds in any c