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, a credit balance — and today's platforms force a choice between dozens of near-duplicate configurations or a custom plugin to bridge the gap. Add to that the regulated customers who can no longer deploy software unless its cryptography meets the government's current validation standard, not the one being phased out.

Kong API Gateway 3.16 addresses all three. Platform teams can now see and change what the gateway is doing right now, for the right consumer, without downtime, custom code, or a compliance gap.

Here's what's new:

• - **Dynamic log level**: Change log verbosity at runtime on Hybrid Data Planes(both Konnect and on prem)
• - **Dynamic plugin configuration**: Drive plugin fields per-principal by consumer metadata or a validated token claim 
• - **Entitlement enforcement, powered by OpenMeter**: Block requests in the gateway hot path a customer's credits, usage limit, or plan-based entitlement runs out
• - **FIPS 140-3 compliance**: Kong Gateway Enterprise moves from FIPS 140-2 to the current NIST validation standard

Read on for more details. See more about what's new in [_the changelog_](https://developer.konghq.com/gateway/)_the changelog_, or [_request a demo_](https://konghq.com/contact-sales)_request a demo_ to see these capabilities in action.

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.

Enterprises often need to apply policies based on the caller: per-consumer rate limit, a route that is off-limits depending on how a consumer authenticated, or a backend might need an outbound JWT encoded with that consumer's specific attributes as claims. Varying plugin behavior by consumer has meant one of two things: a separate plugin configuration per consumer, which doesn't scale and requires Control Plane-scoped consumers, OR a hand-built custom plugin that now has to be maintained.

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. One plugin configuration replaces dozens of near-identical ones. The mechanism is generic and schema-declared, and it's currently available to ACL, Rate Limiting, and Rate Limiting Advanced.

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.

Kong API Gateway 3.16 ships a new Entitlement Enforcement plugin, powered by OpenMeter, that blocks requests in the gateway as soon as a customer's prepaid credits, usage limit, or plan-based entitlement runs out. It's the connective step from metering (recording what happened) to governance (deciding what's allowed to happen next), enforced at the same layer that's already handling the request.

NIST's Cryptographic Module Validation Program is moving the industry to FIPS 140-3 and winding down acceptance of 140-2 validations over time. Regulated industries, like banking and public sector, are the most exposed to that transition.

Kong Gateway now offers a dedicated [_FIPS 140-3 compliant package_](https://developer.konghq.com/gateway/fips-support/)_FIPS 140-3 compliant package_, distributed separately with a -fips-140-3 suffix, currently available starting with Kong Gateway 3.14 LTS and 3.16. Customers who need an actively validated cryptographic module can adopt it now without changing anything else about how they deploy Kong.

Ready to get started? Upgrade to Kong API Gateway 3.16 and see what's new in [_the changelog_](https://developer.konghq.com/gateway/)_the changelog_, or [_request a demo_](https://konghq.com/contact-sales)_request a demo_ to see these capabilities in action.