Should organisations centralise authorization logic or keep it distributed?

Use a governed hybrid approach. Centralise shared patterns that need consistency, but keep application-specific policy local enough for clear ownership and faster change control. The decision should be driven by reuse value and reviewability, not by a preference for one extreme architecture.

Why authorization architecture should avoid extremes

Authorization is not just a policy engine choice, it is an operating model choice. Centralising every decision can improve consistency, auditability, and reuse, but it can also create a bottleneck that slows delivery and pushes application teams to bypass the control. Fully distributed authorization can move fast, but it often fragments policy, creates drift, and makes reviews harder.

The practical question is whether the same decision logic must hold across multiple systems or whether the rule is tightly coupled to one business process. If the policy is shared, stable, and high value to standardise, centralisation helps. If it depends on local data, local workflow, or frequent product change, some distribution is usually healthier.

A guided comparison of authorization models is useful here because the centralised versus distributed debate is often really a debate about where policy decisions, entitlements, and enforcement logic should live.

What a governed hybrid model actually separates

A governed hybrid approach separates the reusable core from the application-specific edge. Common building blocks such as role design, shared attributes, policy language, and decision APIs can be centralised so teams do not reinvent the same rules. The application still keeps ownership of the business context, the enforcement point, and any exception handling that only local teams can judge.

This separation works best when the central layer defines standards and guardrails, while the application layer applies them to concrete actions. In practice, that means central teams own policy patterns, schema, review criteria, and consistency checks, while product teams own the context needed to decide whether access is appropriate for that workflow.

That division aligns well with the IAM and IGA basics model, where access governance and entitlement control sit alongside application ownership rather than replacing it.

How to tell when centralisation or distribution is the better fit

Centralise when the same decision is repeated often, the rule must be reviewed consistently, and policy changes should propagate across multiple applications without drift. Distributed control fits better when the policy is embedded in a unique workflow, needs rapid local iteration, or depends on data that only the application can interpret cleanly. The best design is often not one policy architecture, but one shared policy language with multiple enforcement points.

For engineering teams, the main design test is whether a local exception would be rare and documentable, or whether local context is so important that the central rule would become a constant source of exceptions. If exceptions are frequent, the “central” rule is probably too abstract. If every team invents its own logic, the control plane is probably too fragmented.

The AI Agent Authorisation Guide is a good example of why this matters in practice: per-action decisions and delegated authority need consistency, but the actual action context often has to stay close to the application or agent runtime.

Risk and Threat Considerations

Authorization architecture creates real exposure when it is either too centralised or too fragmented. A single central policy layer can become a high-impact failure point if it is misconfigured, unavailable, or trusted too broadly. A distributed model can create inconsistent enforcement, privilege creep, and blind spots that attackers can exploit by moving to the weakest application or policy path.

Failure mechanism: Security breaks when policy intent, enforcement, and ownership drift apart, or when one control plane is asked to serve too many different business contexts without enough local validation. Attackers and insiders benefit when the weakest application becomes the easiest place to bypass intended access rules.

Impact: The result can be over-authorization, data exposure, unauthorized actions, and slow incident response because reviewers cannot quickly tell which rule applied, who owned it, or whether it was enforced consistently. At scale, that becomes a governance problem as much as a technical one.

Role design discipline matters because poorly designed central roles are a common path to role explosion and privilege creep, while poorly governed local roles create hidden access paths.

Practitioner Guidance

What to prioritise: Standardise the parts of authorization that benefit from reuse, such as policy vocabulary, review criteria, and decision patterns, then leave workflow-specific judgment with the team that owns the application. That keeps the model reviewable without forcing every decision through one bottleneck.

What to verify: Check whether every application can explain who owns the policy, where the decision is enforced, and how exceptions are reviewed. If the answer is unclear, the architecture is already too hard to govern.

Common mistake: Teams often centralise because it sounds safer, then discover they have created a slow policy monolith that product teams work around. The better test is whether the control is easier to review after centralisation, not merely easier to describe.

Practitioner takeaway: The strongest authorization architecture is the one that preserves consistent control where it matters, while keeping enough local context to avoid brittle, overgeneralised decisions.

Related resources from NHI Mgmt Group

• How can organisations keep authorization decisions reviewable in distributed teams?
• Should teams centralise authorization logic in one engine or keep it close to the application?
• How do organisations operationalise NHI ownership at scale?
• When should organisations treat an NHI as a high-priority risk?