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.
Consider a bank using an AI agent to investigate potentially fraudulent transactions. A transaction is processed and the bank’s fraud detection system identifies suspicious activity. That event is published to Kafka: fraud.suspected The bank’s Fraud
If you've run Kong at scale, you know the moment: a spike in 5xxs from one specific data plane node, a customer opening a ticket about intermittent failures, or a partner integration that fails calls no one else does. Debug-level logs would tell you
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
