Notifications
Clear all
Topic starter
12/06/2026 9:16 pm
TL;DR: Authorization is still treated as an afterthought in software design, even though it becomes harder to retrofit once systems scale, according to Cerbos’ Security Repo podcast episode with Emre Baran. The central lesson is that access decisions need to be designed as part of the architecture, not patched in after authentication is already solved.
NHIMG editorial — based on content published by Cerbos: Security Repo podcast discussion on authorization in modern software
Questions worth separating out
Q: What breaks when teams treat authorization as an afterthought?
A: They usually end up with coarse roles, scattered exceptions, and brittle policy logic that is hard to audit or change.
Q: Why do broad roles create more risk than they appear to save?
A: Broad roles reduce implementation effort, but they also bundle unrelated privileges into a single identity boundary.
Q: How can teams tell whether just-in-time access is working?
A: They should look for shorter privilege duration, fewer persistent entitlements, and fewer exceptions that bypass expiration.
Practitioner guidance
- Define authorization separately from authentication Map who can log in and what that identity can do as two distinct control problems.
- Replace broad roles with task-scoped permissions Inventory roles that bundle unrelated actions, then split them into narrower policies that reflect real business tasks.
- Test your control plane for staff turnover resilience Check whether a new engineer can explain and safely modify your authorization logic without tribal knowledge.
What's in the full article
Cerbos' full podcast transcript covers the operational detail this post intentionally leaves for the source:
- The transcript’s full discussion of why developers default to one-role-per-system patterns and how that decision compounds technical debt.
- The extended airport-security analogy used to separate authentication from authorization in practical terms.
- The longer explanation of when building custom authorization becomes unsustainable and why scale changes the governance model.
- The closing discussion on who should own authorization decisions across product, platform, and security teams.
👉 Read Cerbos' podcast transcript on authorization, ZSP, and scaling access controls →
Authorization and zero standing privileges: what IAM teams miss?
Explore further
12/06/2026 11:13 pm
Authorization debt is an identity governance problem, not just an application design flaw. Once teams defer authorization, they create a control surface that is harder to review, harder to certify, and easier to over-expand than authentication. The pattern is the same across human IAM, service accounts, and application roles: if access intent is not modelled early, the programme inherits exceptions instead of policy. Practitioners should treat authorization debt as a governance backlog item, not a code cleanup task.
A few things that frame the scale:
- 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.
- 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.
A question worth separating out:
Q: Who should own authorization governance in a scaling product organisation?
A: Ownership usually sits across application, security, and platform teams, but the control itself must be governed centrally. If no team can explain the policy model, change it safely, and prove it during review, ownership is effectively missing even if the code exists.
👉 Read our full editorial: Authorization is still failing because teams defer it too long
