When should organisations replace broker-level ACLs with identity-based policy?

When broker-level ACLs stop being the right abstraction

Broker-level ACLs work best when access is stable, centrally managed, and naturally tied to the broker itself. Once topic access is driven by business context that already exists in an identity provider, such as team, environment, or application, the broker becomes an extra policy layer that can lag behind reality. At that point, identity-based policy usually gives you a clearer source of truth and simpler change management.

The practical signal is not that ACLs are “bad,” but that they are becoming a coordination point for decisions that are better owned where identity and context already live. When the same approval logic has to be rebuilt in multiple places, or when every change requires broker-specific maintenance, the model is telling you that authorization belongs closer to identity governance than to the messaging layer.

A useful Zero Trust Identity Guide reference for this shift is the idea that policy should follow the authenticated subject and its context, not remain trapped in one control plane. That is especially important when the broker only enforces what the identity platform already knows.

What identity-based policy changes operationally

Identity-based policy changes the unit of control from static broker entries to attributes and entitlements that can be evaluated continuously. Instead of asking “which principal has which topic ACL,” you ask whether the requesting identity, workload, or application should be allowed based on its current role, environment, and ownership. That makes the policy easier to align with joiner-mover-leaver processes, recertification, and environment separation.

This also improves maintainability when access patterns evolve quickly. If a team is reorganised, a service is moved between environments, or an application is split into multiple tiers, the policy update happens in the identity layer rather than through a set of broker edits. The more often your authorisation changes, the more identity-based policy tends to reduce operational friction.

For teams managing non-human access, the issue is usually broader than one broker. The NHI Lifecycle Management Guide is relevant because policy changes are much easier to govern when identities, ownership, and lifecycle events are already modelled cleanly. The broker then enforces a decision, instead of becoming the system where those decisions are invented.

Where the policy is already expressed in an identity provider, the broker should typically consume that decision rather than reimplement it. That is the main architectural inflection point: if broker ACLs are duplicating identity logic, the control is usually in the wrong place.

How to decide the migration point

The decision is usually justified when three conditions are true: access depends on identity context, that context is already authoritative in the identity system, and broker-level administration is becoming slower than the rate of change in the business. When those conditions line up, continuing with ACLs often preserves technical familiarity while increasing governance overhead.

A second useful trigger is auditability. Identity-based policy makes it easier to explain why access exists, who owns the entitlement, and how it should be removed. If an ACL entry on the broker cannot be tied cleanly to an identity, a role, or an ownership model, the access path is harder to review and harder to defend during recertification.

There is also a scaling consideration. As the number of topics, teams, and workloads grows, ACLs tend to fragment into many small exceptions. Identity-based policy can reduce that sprawl by allowing the same business rule to apply across multiple resources. The Identity Security Programme Guide helps frame this as an operating-model decision, not just a messaging configuration choice.

Risk and Threat Considerations

Broker-level ACLs create risk when they become the primary place where access logic is duplicated, delayed, or inconsistently applied. The bigger the gap between identity truth and broker policy, the more likely you are to see stale permissions, overbroad access, and accidental persistence after team or application changes.

Failure mechanism: Access control drift emerges when changes in ownership, environment, or application structure are updated in identity systems but not propagated cleanly to broker ACLs, leaving entitlements that no longer match the intended trust model.

Impact: The result is excessive access, slower revocation, and a larger blast radius if a credential, workload, or service account is misused.

Practitioner Guidance

What to verify: Confirm that the attributes you want to rely on, such as team, environment, application, or ownership, are authoritative, current, and stable enough to drive policy without constant manual exceptions.

Decision rule: If a broker ACL is encoding identity decisions that already exist elsewhere, move the decision up into identity-based policy and keep the broker focused on enforcement.

What practitioners underestimate: The hardest part is usually not the migration mechanics, but aligning ownership and exception handling so that policy changes do not simply recreate ACL sprawl in another layer.

Practitioner takeaway: Replace broker-level ACLs when the broker is no longer the right system of record for access intent; the cleaner model is the one that lets identity drive authorization once, rather than reinterpreting it at every broker.

Related resources from NHI Mgmt Group

• When should organisations replace a vault-first model with identity-based access?
• How should organisations implement policy-based access control in identity-centric security programmes?
• How should organisations replace document-based identity checks with biometric verification in high-risk digital journeys?
• How should organisations use policy-based access controls to improve governance across mixed identity environments?