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.
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.
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:
`-fips-140-3` artifact instead of `-fips`, not re-architecting how you deploy Kong.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.
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.
Two kinds of problems only show up once an API is already live. Something breaks, and a team needs visibility into one specific node right now — not after a redeploy. Or the right behavior for a request depends on who's calling it: a consumer's plan
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
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
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
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
