Authorization is still failing because teams defer it too long

At a glance

What this is: This podcast episode argues that authorization is still routinely under-designed, with teams defaulting to simplistic roles and custom logic until scale and compliance force the issue.

Why it matters: It matters because authorization failures ripple across human IAM, workload access, and NHI governance when organisations cannot prove or constrain what identities are actually allowed to do.

By the numbers:

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

👉 Read Cerbos' podcast transcript on authorization, ZSP, and scaling access controls

Context

Authorization is the decision layer that determines what an authenticated identity can actually do, and that distinction matters more as systems become distributed. The article’s core problem is familiar to IAM teams: access logic is often treated as a later implementation detail, then hard-coded, simplified, or widened as business pressure grows.

For practitioners, this is not just a software design issue. The same habit that produces over-broad application roles also shows up in NHI and workload governance, where teams assume identity proof is enough and delay fine-grained entitlement design until the blast radius is already too large. That is why mature programmes treat authorization as an architectural control, not a convenience feature.

Key questions

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. Over time, access becomes a patchwork of business shortcuts rather than a governed model, which increases blast radius and makes recertification less meaningful.

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. That makes it harder to prove least privilege, easier for attackers to abuse a stolen credential, and more difficult for IAM teams to certify access accurately.

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. If access is still being granted indefinitely for convenience, JIT has become a label rather than an operational control.

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.

Technical breakdown

Why authorization collapses into coarse roles

Authorization fails when teams compress business logic into a few generic roles because the system becomes easier to ship, not safer to operate. In practice, that means developers blur the line between who can sign in and what that identity can do after sign-in. As applications grow, those broad roles accumulate exceptions, hidden branching, and ad hoc overrides that no longer map cleanly to the underlying business process. The result is predictable: authorization logic becomes opaque, fragile, and expensive to change without breaking production workflows.

Practical implication: model access decisions separately from application code before role sprawl becomes irreversible.

Zero standing privileges and just-in-time access in practice

Zero standing privileges means no identity should keep persistent access it does not need continuously. Just-in-time access narrows privilege to the task window, then removes it when the work is done, which reduces the amount of standing authority attackers can abuse. For workload and application environments, this is especially important because long-lived privileges often survive well beyond the original business reason for granting them. The article’s hotel analogy is useful because it captures the operational intent: access should be checked out, not permanently owned.

Practical implication: replace always-on access paths with task-scoped entitlements and enforce expiration by default.

Build versus buy for authorization control planes

The article makes a familiar but important point: custom authorization systems may work early on, then become technical debt once the organisation scales or the original builders move on. Off-the-shelf authorization platforms reduce reinvention, but the deeper lesson is governance, not product selection. Teams need a durable control plane that can express policy, support change, and survive personnel churn. In identity terms, the control must outlast the implementation team, or the organisation ends up with access rules that nobody fully understands and nobody can safely modify.

Practical implication: assess whether your current authorization layer can survive growth, staff turnover, and audit scrutiny without a rewrite.

NHI Mgmt Group analysis

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.

Zero standing privilege becomes more valuable when access logic is dynamic. Static permissions are increasingly misaligned with how modern systems operate, because business context, data sensitivity, and task scope change faster than fixed roles do. ZSP and just-in-time access do not solve every authorization problem, but they force organisations to prove why privilege exists at the moment it is used. That shifts the control question from 'who gets access' to 'why does this access need to persist'. Practitioners should use that distinction when reviewing both human and machine access paths.

Coarse roles create identity blast radius. When one role covers too many actions, a single credential compromise or policy mistake can expose far more than the original business need justified. That is true for employees, but it is equally true for workloads and service identities that are granted broad application privileges. The governance failure is not simply over-permissioning, but the inability to bound impact through a clean entitlement model. Practitioners should measure whether their role design actually limits blast radius or merely labels it.

The market is moving from bespoke authorization logic toward policy-based control planes. That shift reflects a broader identity trend: security teams want controls that are easier to audit, easier to delegate, and less dependent on fragile in-house code. The implication is not that every organisation must buy the same thing, but that teams should stop treating authorization as a one-off engineering problem. Practitioners should evaluate whether their access model can be governed centrally even when enforcement is distributed across apps and services.

For NHI and human IAM alike, access review is only useful when the underlying permissions model is intelligible. If entitlement structure is fragmented into ad hoc roles and application-specific logic, recertification becomes a paper exercise rather than a real control. That is why lifecycle governance and authorization design have to be aligned. Practitioners should ask whether their review process can actually validate privilege, or only confirm that a messy model still exists.

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.
• 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.
• For adjacent workload identity risk, review Ultimate Guide to NHIs , Key Challenges and Risks for the control patterns that authorization debt eventually collides with.

What this signals

Identity blast radius: when authorization is left coarse, the issue is not just over-permissioning but the inability to prove how far a compromised identity can move. Teams that still rely on broad roles should expect every new application and workload to make entitlement review harder, not easier.

The practical signal is that security programmes need to shift from entitlement volume to entitlement quality. If your access model cannot survive staff turnover, audit questions, or workload expansion, it is already too fragile for modern identity operations.

For teams building a broader control baseline, the NIST Cybersecurity Framework 2.0 remains a useful reference for aligning governance, protection, detection, and recovery, especially where authorization decisions are distributed across applications and identities.

For practitioners

• Define authorization separately from authentication Map who can log in and what that identity can do as two distinct control problems. Use explicit policy objects or decision services for entitlement logic instead of hiding permissions in application branches.
• Replace broad roles with task-scoped permissions Inventory roles that bundle unrelated actions, then split them into narrower policies that reflect real business tasks. Where possible, pair that model with just-in-time elevation so access expires when the task ends.
• Test your control plane for staff turnover resilience Check whether a new engineer can explain and safely modify your authorization logic without tribal knowledge. If the answer is no, your access model has become operationally fragile and needs simplification.
• Review NHI access with the same scrutiny as human access Apply the same entitlement clarity, expiry discipline, and review cadence to service accounts and workload identities. Broad machine roles are just as likely to create hidden blast radius as broad human roles.

Key takeaways

• Authorization is the control that turns identity proof into actual permission boundaries, and it is still too often bolted on late.
• Coarse roles and custom logic create hidden identity blast radius that becomes harder to govern as systems scale.
• Just-in-time access and policy-based control planes matter because they make privilege easier to explain, review, and expire.

Key terms

• Authorization: Authorization is the decision process that determines what an authenticated identity may do inside a system. It becomes a governance problem when those decisions are encoded loosely, scattered across application logic, or expanded beyond the original business need.
• Zero Standing Privilege: Zero Standing Privilege means identities do not retain persistent access unless a task requires it. For human, workload, and autonomous contexts, the point is the same: privilege should exist for a reason, for a limited time, and within a reviewable boundary.
• Identity Blast Radius: Identity blast radius is the amount of access, data, and systems exposed if one identity is misused or compromised. Broad roles and weak entitlement design enlarge that radius, making a single control failure much more damaging than the original permission request suggested.
• Task-scoped access: Task-scoped access is permission granted only for a specific action, workflow, or time-bound need. It reduces standing privilege and makes access easier to justify, review, and revoke across both human and machine identities.

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: Security Repo podcast discussion on authorization in modern software. Read the original.