Policy-based access control is back for modern authorization

At a glance

What this is: This is a Cerbos analysis arguing that policy-based access control is back because scattered code-level authorisation checks no longer scale for modern applications.

Why it matters: It matters because IAM, IGA, and application security teams need a clearer way to govern fine-grained access across human and non-human identities without embedding brittle rules in every service.

By the numbers:

• 94% of applications tested in 2021 had some form of broken access control, according to OWASP data cited by Cerbos.

Context

Broken access control is the failure mode this article is really addressing. When authorisation rules live as scattered if statements and role checks inside application code, every new exception or feature can create a gap that no one can see end to end. The primary identity security question is how to govern access decisions consistently across applications, services, and machine identities.

Policy-based access control, or PBAC, moves those decisions into a central policy engine instead of leaving them buried in code. That changes the operating model for IAM because access can be evaluated with context such as resource sensitivity, session conditions, and user or service attributes. The article frames PBAC as a response to authorisation debt, not just a newer implementation pattern.

Cerbos presents PBAC as a practical answer to modern application complexity, especially where microservices, multi-tenant systems, and mixed identity types make static role models brittle. That is the right lens for IAM teams: the problem is not simply more rules, but rules that can be governed, tested, and audited without being duplicated across every codebase.

Key questions

Q: What breaks when authorisation is hardcoded into application logic?

A: Hardcoded access rules become brittle as systems grow, because each code path must be updated and retested whenever permissions change. That creates audit gaps, slows remediation, and makes it difficult to apply consistent policy across clusters, services, and AI-driven workflows.

Q: Why does PBAC reduce broken access control in modern applications?

A: PBAC reduces risk by moving access logic into one governed policy layer instead of duplicating it across services. That makes decisions more consistent, easier to test, and easier to audit. It also lets teams express conditions that roles alone cannot capture, such as resource sensitivity or session context.

Q: How do you know if your authorisation model is too dependent on RBAC?

A: If access exceptions keep accumulating, if teams cannot explain decisions without reading code, or if the same rule is implemented differently across services, RBAC is too coarse for the environment. Those are signs that the authorisation model needs attribute and context-aware policy evaluation.

Q: Should IAM teams treat policy-based access control as part of identity governance?

A: Yes. Authorisation is part of identity governance because it determines how access is granted, reviewed, and explained across systems. PBAC gives IAM and IGA teams a shared decision model that can support least privilege, auditability, and change control without pushing every rule into each application.

Technical breakdown

Why scattered authorisation checks fail at scale

Traditional application authorisation often begins with simple role checks, then accumulates exceptions as products, tenants, and workflows expand. That produces authorisation logic spread across services, which makes it hard to reason about who can do what and under which conditions. In practice, the control breaks not because teams ignore security, but because the authorisation model is embedded in business code, where it becomes fragile, inconsistent, and expensive to change.

Practical implication: move away from per-service permission logic when the same access rule is being reimplemented in multiple places.

How PBAC externalises the decision point

PBAC separates the policy decision from the application request. The application asks whether an action is allowed, and a policy decision point evaluates rules based on subject, resource, action, and context. That model matters because it turns authorisation into a governed artefact rather than a hidden implementation detail. It also supports policy-as-code, which means access logic can be versioned, tested, and reviewed like other critical code.

Practical implication: treat authorisation policies as managed code assets with review, testing, and controlled deployment.

Why context-aware authorisation fits modern identity estates

Modern environments no longer run on static roles alone. Human users, services, APIs, and other non-human identities may all need different decisions depending on time, device, sensitivity, or relationship to the data. PBAC is useful here because it can express conditions that RBAC cannot and can absorb attribute-style logic without forcing every exception into hardcoded branches. For identity teams, the value is not just finer granularity, but a decision layer that can govern mixed identity estates consistently.

Practical implication: use PBAC where role-only access rules cannot represent the real decision context for the resource.

Threat narrative

Attacker objective: The attacker’s objective is to reach data or functions that the application should have denied, using weaknesses in authorisation logic rather than authentication.

1. Entry occurs through a developer-written authorisation path that allows a request to reach the wrong code branch or omits a required permission check.
2. Credential or identity misuse follows when the application trusts a coarse role or hardcoded condition that no longer matches the actual access context.
3. Escalation happens as additional exceptions, service-specific checks, and ad hoc rules widen the access path beyond its intended scope.
4. Impact is unauthorised data exposure or function use, which is the classic broken access control outcome the article highlights.

Breaches seen in the wild

• ASP.NET machine key attacks 2025: Developers copied ASP.NET machine keys from public sources; attackers used one to run Godzilla via ViewState. Microsoft found 3,000+ such keys.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

PBAC is a response to authorisation debt, not just an access-control pattern. When permission logic is scattered through application code, every feature change adds another place where policy can drift from intent. That is why broken access control persists even in otherwise mature engineering teams. The practitioner lesson is that authorisation must be governed as a lifecycle asset, not treated as incidental application logic.

Authorization as code becomes the control plane when identity is distributed. Microservices, multi-tenant systems, and mixed human and machine identities make a single static role model too blunt for real-world governance. PBAC restores decision consistency because the policy, not the service, becomes the source of truth for access. That shift is especially relevant where IAM and application teams need the same answer across many execution paths.

Fine-grained decisioning matters because RBAC alone cannot express modern access context. The article’s strongest point is not that PBAC replaces roles, but that it can incorporate attributes and environmental conditions alongside them. That makes it a practical fit for identity programmes that need least privilege to operate at runtime, not just on paper. The implication is that access governance must move closer to the request path.

Centralised authorisation will increasingly sit beside authentication as a first-class identity control. The article reflects a broader market correction: organisations now recognise that who authenticated is not enough to answer what they may do. PBAC gives IAM, IGA, and security architects a common policy layer for human users and non-human actors alike. The practitioner takeaway is to design for governed decisioning, not scattered exceptions.

What this signals

PBAC is becoming the practical control plane for authorisation sprawl. When human users, services, and other non-human identities all depend on the same applications, scattering access rules across code becomes ungovernable. A central policy layer gives security and IAM teams one place to reason about decision logic, test changes, and prove intent at audit time.

Policy-based access control also closes a lifecycle gap. Access reviews are only useful when the organisation can describe the rule that granted access in the first place. With PBAC, policy intent is explicit and versioned, which means joiner-mover-leaver changes, entitlement reviews, and emergency access adjustments can be aligned to the same governed decision model.

Authorisation is moving closer to identity architecture than application plumbing. That shift matters because the question is no longer only whether a user authenticated, but whether the request satisfies the current policy context. Teams that keep access logic buried in services will continue to accumulate authorisation debt even if their authentication stack is strong.

For practitioners

• Separate policy from application code Identify where authorisation checks are embedded directly in services and replace repeated logic with a central decision layer for shared rules.
• Model access around subject resource action and context Define policies using attributes such as user role, resource sensitivity, action type, and environmental conditions instead of relying on roles alone.
• Version and test policies like code Store policies in source control, review changes, and run tests that prove allowed and denied decisions before promoting updates.
• Start with the highest-risk services Begin PBAC adoption where broken access control would have the most severe impact, then expand policy coverage to adjacent services.

Key takeaways

• Broken access control remains common because access logic is still too often embedded in application code and repeated inconsistently across services.
• PBAC addresses that problem by centralising policy decisions, which improves consistency, auditability, and the ability to apply context-aware rules.
• For IAM teams, the practical decision is whether authorisation should remain a code concern or become a governed policy layer shared across the stack.

Key terms

• Policy-Based Access Control: Policy-based access control grants or denies access using rules that evaluate context, signals, and identity state at decision time. It is more adaptive than static role assignment, but only if the policy engine receives accurate runtime inputs and can enforce them across systems.
• Authorization debt: Authorization debt is the accumulation of local rules, duplicated policy logic, and exception handling that builds up when access decisions are implemented ad hoc. It is an identity governance problem because the organisation eventually cannot explain, verify, or maintain its own permission model reliably.
• Policy decision point: A policy decision point evaluates contextual rules and returns an access decision that enforcement points can act on. It separates authorization logic from application code, which helps teams manage tenant rules, resource ownership, and risk signals consistently.
• Broken Access Control: Broken access control occurs when a system fails to restrict what an authenticated user, service, or workload can do. The issue often appears as missing checks, inconsistent enforcement, or excessive permissions. It is a structural weakness because attacks exploit the gap between verified identity and permitted action.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.