The widespread adoption of Kafka and event streaming platforms is evident across several enterprises, where they serve as the backbone of critical operations, ranging from financial transactions to AI inference pipelines.

However, in the domains of security and identity, most teams continue to face several pressing challenges, including:

• Coarse-grained access control limited to the topic level
• Fragmented identity models spanning disparate systems
• Complex and inconsistent mutual TLS (mTLS) configurations
• Limited integration with modern OAuth-based security architectures

In the traditional synchronous world, API security has largely standardized on OAuth 2.0 and OpenID Connect (OIDC). However, Kafka’s native security model operates differently, relying heavily on mutual TLS (mTLS) for authentication and Access Control Lists (ACLs) for authorization. Consequently, while APIs have matured into identity-aware and policy-driven interfaces, event systems often maintain an infrastructure-centric security posture.

This yields a massive disconnect when teams try to expose Kafka topics to external partners, edge devices, or cross-domain internal teams. Developers are usually forced to choose between bad options, such as:

• Compromise on security by granting overly broad access to data streams.
• Slow down development by building and maintaining clunky, custom middleware to translate web identities into Kafka identities.
• Isolate the data, keeping valuable real-time events locked away from the teams that need them most.

Kong Event Gateway v1.1 bridges this gap, allowing you to secure your event streams using the modern identity standards you already use for your APIs, without breaking Kafka’s native security posture.

Kong Event Gateway 1.1 focuses on bridging this gap by bringing identity and security to the forefront of event streaming.

OAuth Token Claim Mapping for Policies

Modern systems rely heavily on OAuth and JWT tokens to represent identity and context. Until now, that context was largely lost when interacting with event systems.

With OAuth token claim mapping, Kong Event Gateway can do the following.

• Validate incoming tokens
• Extract standard and custom claims, such as roles, scopes, or tenant identifiers
• Map those claims directly into policy enforcement decisions

This enables fine-grained, identity-aware authorization at the event layer. Instead of asking “can this client access this topic?”, you can now ask the following questions.

• Can this user role publish to this stream?
• Can this tenant consume only their own events?
• Can this AI agent access only scoped data?

This is a fundamental shift from infrastructure-level control to context-aware security.

How it works in practice

Imagine you have a multi-tenant application where external consumers need to read order events. A consumer authenticates and presents an OAuth token containing the claim "tenant_id": "eu-region-4".

Instead of writing custom code to validate this, Kong Event Gateway intercepts the connection, reads the token, extracts the claim, and dynamically restricts that user's read access to the orders-eu-region-4 Kafka topic. If they attempt to subscribe to a different topic, the gateway drops the connection before it ever reaches the Kafka broker.

mTLS authentication aligned with Kafka practices

Security shouldn’t come at the cost of friction. Kafka relies on mTLS for Zero Trust security between clients and brokers. Previously, bridging external consumers to this internal standard required complex certificate management or breaking the mTLS chain at the edge, neither of which aligned with Kafka's architectural assumptions.

That is why Kong Event Gateway 1.1 introduces mTLS authentication that fully aligns with common Kafka practices. Rather than forcing teams into a new model, this approach:

• Works with existing Kafka security patterns: Leverages familiar certificate-based mutual authentication
• Simplifies certificate management: The list of trusted certificate bundles is maintained centrally in Kong Konnect. You can easily manage your trust stores as first-class resources, whether you prefer to click through the UI or deploy via declarative configuration.
• Integrates cleanly into the current platform setups: Creates a secure-by-default communication layer that feels native to Kafka teams.

The result is a secure-by-default communication layer that feels familiar to Kafka teams while still benefiting from Kong’s policy enforcement capabilities.

How it works in practice

The gateway seamlessly handles the mTLS handshake with the consuming client and verifies the certificate against your configured trust store.

Crucially, the gateway doesn't just authenticate the connection; it can also dynamically extract the principal from the client's certificate. You can then use this extracted identity to drive advanced gateway logic, such as applying custom encryption based on the specific client, enforcing strict access policies, or logging the exact identity for downstream auditing.

By handling all of this at the edge, the gateway ensures end-to-end encryption and strict identity verification before a single byte is forwarded, drastically reducing the attack surface of your Kafka clusters while maintaining the architectural purity your infrastructure teams expect.

These two features are powerful individually, but together they unlock something even more significant and powerful.

• OAuth claim mapping defines who you are and what you can do
• mTLS authentication ensures secure and trusted communication

Together, they form the foundation for a zero-trust model in event streaming. This is where event infrastructure starts to look and behave like modern API platforms.

With Kong Event Gateway 1.1, organizations can:

• Build secure multi-tenant event platforms
• Enforce fine-grained access control across event streams
• Support AI and agent-based architectures with scoped data access
• Reduce operational complexity by aligning with existing Kafka practices
• Move toward a unified connectivity layer across APIs and events

This is not only about adding features. It’s about redefining how event systems participate in modern architectures.

Kong Event Gateway 1.1 enables organizations to scale event-driven architectures securely, so you no longer have to choose between modern identity standards and native Kafka security.

You can get started by:

• Exploring the updated documentation
• Deploying in your existing Kubernetes or hybrid environments
• Testing OAuth-based policies and mTLS configurations in your current Kafka setup

Event streaming is becoming the crucial nervous system of modern applications. As that happens, security and identity can no longer be an afterthought. Kong Event Gateway is evolving to meet this reality, bringing policy-driven, identity-aware connectivity to the world of events.

Kong Event Gateway v1.1 is a step forward in that direction. And this is only the beginning.