TL;DR: Fine-grained authorization is increasingly a scaling problem for application teams, as roles and permissions are becoming too costly to build and maintain in-house, according to Cerbos. The IAM implication is that authorization governance is moving from an application concern to a broader identity control plane issue, where policy, lifecycle, and privilege boundaries need clearer ownership.
NHIMG editorial — based on content published by Cerbos: From the Ground Up podcast summary with Emre Baran on application authorization
Questions worth separating out
Q: How should security teams govern fine-grained authorization across applications?
A: Security teams should treat authorization as a governed policy layer, not an application-by-application coding choice.
Q: Why does homegrown authorization create governance risk?
A: Homegrown authorization creates governance risk because access logic gets duplicated, patched, and forgotten across teams and codebases.
Q: When does externalized authorization make sense for IAM programmes?
A: Externalized authorization makes sense when multiple applications need consistent access rules, when policy changes outpace release cycles, or when privilege decisions must be audited centrally.
Practitioner guidance
- Map authorization ownership across applications Document which teams define, approve, and enforce access rules in each application.
- Inventory homegrown permission logic Identify applications with duplicated roles, hardcoded checks, or manual access exceptions.
- Bring authorization into access review Include application permission design in recertification and offboarding workflows so that dormant roles, unused exceptions, and stale delegation paths are removed instead of inherited.
What's in the full article
Cerbos' full article covers the operational detail this post intentionally leaves for the source:
- How the product models roles and permissions for application teams that need fine-grained control
- Why the founding team framed authorization as a market gap in application development
- What the conversation suggests about scaling access control without maintaining large in-house policy code
- How the startup journey shaped the product's positioning around developer productivity and control
👉 Read Cerbos' podcast summary on simplifying application authorization →
Authorization controls for applications: what IAM teams need to know?
Explore further
Application authorization is becoming an identity governance problem, not just a developer problem. When roles and permissions are implemented separately in every app, the organisation loses a single governable view of who can do what. That fragmentation weakens recertification, exception handling, and least-privilege enforcement across the stack. The practitioner conclusion is simple: authorization design now belongs in the identity architecture conversation.
A few things that frame the scale:
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to The State of Secrets in AppSec.
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities.
A question worth separating out:
Q: What should teams look for before replacing in-app permission checks?
A: Teams should look for duplicated rules, unclear policy ownership, weak testing, and exceptions that have become permanent. If the application already has fragmented access logic, replacing it with a governed control layer can reduce drift and improve certification. If ownership stays vague, the same problems will simply move to a new place.
👉 Read our full editorial: Authorization controls are becoming a core IAM growth area