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, a token claim, metered usage, or boolean feature access. Teams can otherwise end up maintaining repeated configurations or custom extensions for caller-specific behavior.
Regulated organizations also need deployment options that use cryptography aligned with current government validation requirements.
Kong API Gateway 3.16 addresses these operational, policy, monetization, and compliance needs. Platform teams gain targeted runtime debugging, caller-aware configuration, entitlement controls, and a separate FIPS 140-3 package.
Here's what's new:
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 exactly what's happening: a bad upstream response, a plugin misconfiguring a header, or an auth check failing for one consumer. However, defaulting to verbose logs is expensive at scale and will make sifting through the noise more time-consuming.
With Kong API Gateway 3.16, administrators can change log verbosity at runtime on any Hybrid Data Plane, with no restart required. Set a Time to Live (TTL) and the log level reverts automatically, so nobody has to remember to turn it back off after the incident is resolved. The override is temporary, runtime-only, and does not persist to kong.conf.
Enterprises often need to apply policies based on the caller: a per-consumer rate limit, a route that is off-limits depending on how a consumer authenticated, or a backend that needs an outbound JWT encoded with that consumer's specific attributes as claims. For supported fields, Kong Gateway 3.16 can calculate a value from caller context at request time.
Kong API Gateway 3.16 introduces expressible plugin fields. Select fields can now be driven by a Common Expression Language (CEL) expression evaluated per request against principal, consumer, and token-claim data.
CEL support is currently limited to documented fields in ACL, Rate Limiting, and Rate Limiting Advanced.
In 3.16, CEL support covers ACL allow_when and deny_when. Rate Limiting supports custom_key, second, minute, hour, day, month, and year.
Rate Limiting Advanced supports limit and custom_key.
Expressible fields fall back to their configured static value when an expression is unset, invalid, or fails. Direct CEL fields in ACL do not have that separate fallback.
Teams upgrading conditional expressions should also review the Kong Gateway 3.16 breaking changes. The release moves CEL evaluation to cel-cpp, which changes some missing-key and quoted-string behavior.
Bill shock cuts both ways. A customer can blow past a plan's limits without warning and rack up an unexpectedly high invoice, resulting in the service provider having to deal with angry tickets, disputed charges, and refund requests. It's the kind of surprise that drives churn not because the product failed, but because a lack of enforcement resulted in a bad customer experience.
Metering records usage. Entitlement enforcement uses plan and feature state to decide whether the next request should reach the upstream service.
Kong API Gateway 3.16 introduces an Enterprise-only Entitlement Enforcement plugin for Konnect deployments. It works with Kong Konnect Metering & Billing to enforce one configured feature per plugin instance.
The plugin blocks a request when the customer reaches a metered-feature usage limit or lacks access to a boolean feature.
Enforcement uses background-refreshed cache state rather than an entitlement API call in the request path. Decisions are therefore cached and eventually consistent, not live balance checks on every request.
Kong Konnect Metering & Billing's entitlement model supports usage allowances and feature access.
Kong Gateway 3.16 does not enforce prepaid credit balances.
As of September 17, 2026, Kong plans to deprecate FIPS 140-2 support in a future release.
Kong provides separately named FIPS 140-3 packages and images with the -fips-140-3 suffix for supported Kong Gateway 3.16 platforms. FIPS mode must be enabled for the package to operate as described.
Kong states that Kong Gateway has not been submitted to a NIST testing lab for validation.
NIST's security policy identifies OpenSSL FIPS Provider 3.1.2 as the validated cryptographic module used for approved cryptographic operations.
FIPS artifacts are platform-specific, and FIPS images are available only for AMD64. Check the Kong Gateway version support policy before selecting an operating system or architecture.
Moving from a FIPS 140-2 installation to the FIPS 140-3 package is not an in-place upgrade. Plan a fresh installation and migration, including compatibility checks for TLS peers, ciphers, keys, algorithms, and credentials.
Ready to get started? Review the Kong Gateway 3.16 changelog, plan your upgrade, or [request a demo](https://konghq.com/contact-sales)request a demo to see these capabilities in action.
**What is new in Kong API Gateway 3.16?**
Kong API Gateway 3.16 adds temporary log-level controls for Hybrid-mode Data Planes, CEL-driven plugin fields, Entitlement Enforcement, and separate FIPS 140-3 artifacts.
**Can I change Kong Gateway log levels without restarting?**
Yes, for Hybrid-mode Data Planes in Kong Gateway 3.16. The Control Plane can send a temporary runtime override with an optional TTL for automatic reversion.
**Which plugins support CEL-driven configuration in Kong Gateway 3.16?**
Supported fields are available in ACL, Rate Limiting, and Rate Limiting Advanced. CEL computes specific field values per request rather than making every plugin field dynamic.
**How does Entitlement Enforcement differ from API rate limiting?**
Rate limiting controls request volume over time. Entitlement Enforcement checks cached plan state to enforce metered usage limits or boolean feature access before the upstream.
**Does Entitlement Enforcement block requests when credits run out?**
No. Credit-balance enforcement is not implemented in Kong Gateway 3.16. The plugin currently enforces metered-feature usage limits and boolean-feature access.
**Does Kong Gateway 3.16 support FIPS 140-3?**
Kong offers separate FIPS 140-3 artifacts for supported 3.16 platforms. These packages use OpenSSL FIPS Provider 3.1.2 when FIPS mode is enabled.
**Can I upgrade a FIPS 140-2 installation to FIPS 140-3 in place?**
No. Kong documents the transition as a fresh-install migration to a separate package. Platform teams should assess cryptographic compatibility before the cutover.
**Is Kong Gateway itself NIST-validated?**
No. Kong states that the product has not been submitted to a NIST testing lab.The validated cryptographic module is OpenSSL FIPS Provider 3.1.2.
Traditional APIs are, in a word, predictable. You know what you're getting: Compute costs that don't surprise you Traffic patterns that behave themselves Clean, well-defined request and response cycles AI APIs, especially anything that runs on LLMs
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
Kong Gateway Enterprise 3.5 is packed with security features to support the use cases demanded by our enterprise customers through major improvements in Secrets Management integrations and our Open-ID Connect (OIDC) plugin. Additionally, we’ve a
We’re excited to announce the general availability of Kong Gateway 3.5 for Open Source (OSS). This release enables Javascript developers to extend the Gateway via the WebAssembly layer which is currently in Beta, delivers some enormous observability
