Access control fundamentals are shifting toward policy-based authorization

At a glance

What this is: This is an access control guide arguing that policy-based authorization is often a better fit than rigid role models for complex applications.

Why it matters: It matters because IAM, IGA, PAM, and application teams need authorization controls that can scale with changing permissions, audit requirements, and least-privilege pressure.

By the numbers:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.

👉 Read Cerbos's guide to choosing the right access control approach

Context

Access control is the part of an application that decides who can do what once identity has been established. In practice, that means authentication, authorization, and audit need to work together, especially when permissions span microservices, cloud environments, and changing business roles.

The governance problem is not that access control is missing. It is that simple role structures often break down as applications accumulate exceptions, context-based conditions, and review obligations. For IAM and IGA teams, the question becomes whether access decisions remain explainable, testable, and maintainable at scale.

Key questions

Q: How should security teams choose between RBAC and ABAC for application access control?

A: Use RBAC when access follows stable job functions and the permission model is easy to explain. Use ABAC when context changes the decision, such as device, location, or resource sensitivity. Most mature programmes end up hybrid, with roles providing the baseline and attributes handling exceptions. The right choice is the one your team can govern, test, and audit consistently.

Q: When does externalized authorization become the better access control pattern?

A: It becomes a strong choice when access rules change often, when business logic and security logic need separation, or when audit evidence must be stronger than code review alone. Externalized authorization is especially useful in distributed applications because policy can be managed centrally while enforcement stays consistent across services.

Q: What do teams get wrong about least privilege in application access control?

A: They often treat least privilege as a one-time design choice instead of an ongoing governance task. In practice, permissions drift as roles change, exceptions accumulate, and application teams add shortcuts. Least privilege only holds when entitlements are reviewed against real usage and removed when the need disappears.

Q: How can organisations tell whether their access control model is actually working?

A: A working model produces decisions that are consistent, explainable, and reviewable. If teams cannot show why access was granted, cannot trace policy changes, or keep adding new roles to solve edge cases, the model is already weakening. Good access control reduces exceptions, supports audits, and survives organisational change without constant redesign.

Technical breakdown

Authentication, authorization, and audit in modern access control

Modern access control is usually built as three separate functions. Authentication proves identity through credentials, tokens, or multi-factor authentication. Authorization decides what the authenticated subject can do against a resource. Audit records what happened so the decision path can be reviewed later. When these layers are separated cleanly, teams can inspect policy logic without coupling it to application code. That separation becomes more important in distributed systems, where the same identity may request access from different services and contexts. Access control fails fastest when authorization rules are hidden inside business logic or cannot be traced after the fact.

Practical implication: centralise decision logic and logging so authorization can be reviewed independently of application features.

RBAC versus ABAC in policy-based authorization

Role-based access control assigns permissions by job function, which works well when access patterns are stable and hierarchical. Attribute-based access control evaluates context such as device type, time, location, or resource sensitivity, which gives finer control when the same user needs different access in different situations. The trade-off is operational complexity. RBAC is easier to manage but less expressive. ABAC is more flexible but needs stronger policy design, testing, and governance. Many real systems end up hybrid, using roles for baseline entitlement and attributes for exception handling. That approach is often the most practical way to avoid role explosion.

Practical implication: use RBAC for baseline access and reserve ABAC for context-sensitive decisions that would otherwise create role sprawl.

Externalized authorization and why it changes application architecture

Externalized authorization moves policy evaluation out of the application and into a separate decision layer. That lets developers keep business logic focused on product behaviour while security teams manage access rules centrally. It also improves testability because policy changes can be validated without rewriting application code. In complex environments, this approach supports separation of concerns, better auditability, and more consistent enforcement across services. It is not automatically superior to native IAM controls, but it is often a better fit when permissions change often, when context matters, or when audit evidence must be stronger than code review alone.

Practical implication: consider externalized authorization when access rules change frequently or need to be governed outside the application release cycle.

Threat narrative

Attacker objective: The objective is to turn excessive or poorly governed application permissions into unauthorized access, data exposure, or control over sensitive functions.

1. Entry occurs when an application accepts an overly broad identity or role mapping, allowing a user or service to reach sensitive functions without enough contextual filtering.
2. Escalation happens when static roles accumulate exceptions and permission sprawl, letting the subject perform actions that were never intended for its original access profile.
3. Impact follows when weak authorization boundaries expose sensitive data, create compliance gaps, or allow unauthorized operational changes across the application estate.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Codefinger AWS S3 ransomware attack — Codefinger used compromised AWS credentials to encrypt S3 buckets via SSE-C.

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

NHI Mgmt Group analysis

Policy-based authorization is becoming the practical response to access control sprawl. Coarse roles work until applications accumulate too many exceptions, at which point permission management turns into exception management. That is the point where externalized policy logic becomes more governable than hard-coded access checks. For practitioners, the issue is not elegance, it is whether access decisions remain auditable and sustainable as complexity grows.

Least privilege breaks down when teams model access around static job titles instead of actual runtime context. RBAC can describe baseline entitlement, but it cannot always express time, device, resource sensitivity, or workflow state without exploding into brittle role variants. ABAC exists to close that gap, yet it only helps when policy design is disciplined. The practitioner takeaway is that access control failure often starts as a modelling problem, not a tooling problem.

Access control is now a lifecycle problem, not just an authorization problem. Joiner-mover-leaver drift, stale entitlements, and unreviewed permissions create the conditions for privilege creep even when the original policy was sound. That means governance has to include review cadence, change management, and audit evidence, not only runtime enforcement. Teams should treat authorization as something that must survive organisational change, not just application launch.

Externalized authorization changes where accountability sits. When policy is centralised, security teams can test and govern decisions without waiting for application redeployments, which is a material control advantage in fast-moving environments. That does not remove the need for application owners to understand access logic. It does mean the organisation can separate business change from security rule change more cleanly, which is the real governance win for complex systems.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• 43% of security professionals are concerned about AI systems learning and reproducing sensitive information patterns from codebases, according to GitGuardian & CyberArk.
• That concern makes Ultimate Guide to NHIs , Key Challenges and Risks the right next step for teams trying to reduce permission sprawl and secret exposure together.

What this signals

Access control programmes are moving toward policy centralisation because application teams can no longer keep pace with permission sprawl using manual reviews alone. With 6 distinct secrets manager instances on average, fragmentation is already a governance problem, not just an operational inconvenience, according to The State of Secrets in AppSec.

Permission sprawl debt: once access logic is spread across roles, code, and exceptions, the organisation loses a reliable way to explain, test, or recertify authorization. That is why externalized policy engines and cleaner policy ownership matter for IAM and IGA teams.

For teams extending access control into machine identities and service accounts, the same pattern shows up faster because non-human access rarely tolerates ambiguity. The most useful next reference is Ultimate Guide to NHIs, especially where lifecycle, audit, and least privilege overlap.

For practitioners

• Map access decisions to policy owners Assign clear owners to each authorization domain so every sensitive action has a named policy steward, a review cadence, and a change approval path.
• Reduce role explosion before moving to ABAC Use RBAC as the baseline model, then isolate the few decisions that genuinely need attributes such as device, time, or resource sensitivity.
• Separate policy logic from application code Externalize authorization rules where access conditions change often, and test those rules independently of product releases.
• Build audit evidence into every access path Log the identity, decision, resource, and policy result so reviewers can reconstruct why access was granted or denied without reading code.

Key takeaways

• Access control fails when static roles can no longer describe real-world application context.
• Auditability and separation of policy from code are now core requirements, not optional refinements.
• Teams that cannot govern role sprawl and exception logic will eventually trade simplicity for control loss.

Key terms

• Role-Based Access Control: A permission model that grants access according to the role a subject holds in the organisation or application. It is simple to administer and works well when access patterns are stable, but it can become rigid when teams need many exceptions or context-sensitive decisions.
• Attribute-Based Access Control: A policy model that decides access using attributes such as device, time, location, resource sensitivity, or user status. It is more flexible than role-based access control, but it demands stronger policy design and testing because decisions depend on more variables.
• Externalized Authorization: An architecture that moves policy evaluation out of the application and into a separate decision layer. This helps teams centralise control, improve auditability, and change access rules without rewriting product code, especially in distributed systems with many services.
• Permission Sprawl: The accumulation of roles, rules, exceptions, and one-off entitlements until access control becomes hard to understand or govern. It usually appears when applications grow faster than their review processes, and it is one of the clearest signs that authorization needs redesign.

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.

This post draws on content published by Cerbos: access control fundamentals and the best access control solution for modern applications. Read the original.