You get strong transport authentication but weak entitlement control, so identity and authorisation drift apart. The result is either over-broad access or custom middleware that becomes a second, harder-to-govern policy layer.
When mTLS answers transport trust but not who may do what
mTLS gives you cryptographic peer authentication on the wire, which is useful, but it does not by itself express business or event-level entitlement. Topic ACLs narrow that gap, yet they still tend to be coarse-grained and easy to outgrow when producers, consumers, tenants, and environments do not share the same access model. That is where the break appears: transport identity and authorisation no longer describe the same decision.
In practice, that mismatch shows up as a system that can prove a caller is a valid service but cannot prove the caller is allowed to read, publish, or replay a specific event stream under the current context. Once teams notice the gap, they often add custom middleware, broker plugins, or sidecar logic to compensate. Those additions may work, but they turn entitlement into a separate policy plane with its own drift, review burden, and failure modes.
A better mental model is to treat mTLS as authentication of the channel and ACLs as one layer of authorisation, not the complete security design. Event security usually needs an explicit mapping between workload identity, token or certificate claims, topic ownership, and environment boundaries. Without that mapping, you may have strong proof of who connected and still weak control over what that entity can actually do.
Where the control gap becomes operationally painful
Protocol-level trust often fails when organisations assume certificate possession is equivalent to least privilege. It is not. A certificate can say a client is legitimate, but it does not automatically encode tenant scope, data classification, publish versus subscribe intent, or whether a consumer may access only a filtered subset of messages.
That is why many teams start with a small ACL matrix and then slowly accumulate exceptions. As exceptions grow, the ACL becomes less of a policy and more of an access log of historical compromises. When that happens, security review gets harder because the real decision has moved into code, broker configuration, or an external policy engine that only a few people understand.
For stronger segmentation, practitioners often anchor the event plane to workload identity material such as SPIFFE SVIDs, which lets the broker or enforcement layer reason about a stable identity rather than just a network position. The goal is not to replace ACLs, but to make authorisation decisions expressive enough that they remain governable as the estate grows, which is the core problem addressed by SPIFFE workload identity specification.
What a cleaner design usually looks like
When event security is designed well, mTLS authenticates the workload, ACLs handle a limited set of coarse permissions, and a higher-level policy decides topic access from claims that matter to the business. That higher-level policy may live in the broker, an API gateway, or an external authorisation service, but it should remain the system of record for entitlement rather than an improvised middleware patch.
Current guidance in modern workload authentication also points to certificate-bound or sender-constrained approaches when a token is involved, because they reduce the chance that a bearer secret can be replayed outside its intended context. That matters when the same service must publish to one topic, consume from another, and do so only from approved runtime identities. The relevant standard pattern is described in RFC 8705: OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens, which ties authentication more tightly to the credential actually used.
In a mature design, topic ACLs become one enforcement point, not the only policy expression. If your broker supports richer identity claims or if your platform uses a workload identity layer, use that to keep access decisions readable, auditable, and consistent across teams. That is also why NHI Authentication Guide is useful for separating authentication strength from entitlement design.
Risk and Threat Considerations
The main risk is over-trust: once a certificate is issued, the platform may treat the caller as inherently safe even when the caller’s actual permissions are too broad. That creates exposure through mis-scoped topics, lateral movement across event streams, and policy bypass when developers add custom enforcement logic to close the gap.
Failure mechanism: A valid mTLS session authenticates the peer, but the authorisation model cannot distinguish intended from unintended event access, so privilege expands through broad ACLs, exceptions, or middleware shadow policies.
Impact: Sensitive messages can be read, published, or replayed by services that should not have that reach, and teams may lose confidence in the broker’s access controls because real decisions are no longer centralised.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5, NIST Zero Trust (SP 800-207), CSA Cloud Controls Matrix and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | mTLS-only event security can leave entitlement weak despite strong peer authentication. |
| NHI-05 — Overprivileged NHI | Broad topic ACLs and exception sprawl create excess non-human access across event streams. | |
| Recommendation — Bind event access to explicit workload identity and authorization, not certificate presence alone. Continuously trim topic permissions to the minimum publish and subscribe scope required. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Identification and Authentication (Non-Organizational Users) | Workloads and services authenticating over mTLS fit service-to-service identity control needs. |
| AC-6 — Least Privilege | The core issue is excessive event access when ACLs are too coarse or duplicated in code. | |
| Recommendation — Require strong service authentication before any broker access is granted. Enforce least privilege for topic publish, subscribe, and replay permissions. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | Zero trust requires explicit verification and least privilege beyond transport trust. |
| Recommendation — Separate authentication from authorization and verify access per topic and context. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | Event authorization depends on tying workload identity to governed access decisions. |
| Recommendation — Map broker permissions to governed identity controls and review them continuously. | ||
| OWASP ASVS | V8 — Authorization | The problem is missing or weak authorization, even when authentication is strong. |
| Recommendation — Define explicit authorization rules for each event action and resource. | ||
Practitioner Guidance
What to verify: Check whether the certificate or workload identity used at connection time can be mapped to a specific tenant, environment, and publish or consume right. If it cannot, the control plane is probably relying on trust signals that are too weak to support durable entitlement decisions.
Common mistake: Treating ACLs as complete authorisation when they only approximate it. If you need custom middleware to express the true policy, document that layer as security-critical and govern it like any other access control system.
Decision rule: If a service can authenticate but its permitted event actions cannot be explained in one policy model, redesign the access path before scaling the topic surface. The observable sign of a good design is that identity, authorisation, and audit all answer the same question about who may do what.
Practitioner takeaway: Use mTLS to prove the caller, but make sure a separate, governable entitlement model proves the caller’s event rights; otherwise you have strong transport trust and weak access control.