Authorization complexity is the hidden train crash in software teams

At a glance

What this is: This is a Cerbos recap of a conference talk arguing that authorization becomes a hidden scaling problem as products, roles, and technology stacks grow.

Why it matters: It matters because IAM, NHI, and platform teams all face the same trap: treating access control as a later-stage implementation detail until complexity, compliance, and operational debt collide.

👉 Read Cerbos's analysis of authorization scaling and build-versus-buy tradeoffs

Context

Authorization is the decision layer that determines who or what can do what inside an application or platform. In growing systems, that layer stops being a simple role check and becomes a governance problem across users, services, and internal teams. The core issue in this post is not feature design, but the cost of building and maintaining authorization as the environment expands.

For IAM practitioners, the article maps a familiar pattern: the same governance pressure that appears in human access management also shows up in service accounts, back-office workflows, and platform permissions. The practical question is whether teams keep treating authorization as custom engineering work or align it with lifecycle, compliance, and least-privilege governance from the start.

Key questions

Q: How should security teams govern authorization as applications and roles grow?

A: Security teams should treat authorization as a governed control surface, not a local coding pattern. That means defining policy ownership, separating decision logic from product features, and reviewing how access rules behave as roles, services, and workflows expand. The goal is consistent enforcement that can be audited, changed, and scaled without rewriting application code.

Q: What breaks when authorization is built differently in each service?

A: When each service encodes its own access logic, the enterprise gets policy drift, duplicated rules, and inconsistent enforcement. Auditors may also find no single source of truth for who can do what. Over time, that creates higher maintenance effort and makes compliance harder because the same permission can mean different things in different parts of the stack.

Q: Should teams build custom authorization or adopt existing controls?

A: Teams should build only when they have a clear reason to own the long-term maintenance burden. For most growing systems, existing authorization controls reduce reinvention, improve consistency, and shorten the path to auditability. The key question is not whether engineers can build it, but whether the organisation wants to keep governing it for years.

Q: How can organisations tell whether their authorization model is scaling well?

A: A scaling authorization model stays understandable, consistent, and reviewable as new roles and services are added. If teams need frequent exceptions, duplicate checks, or manual fixes to keep access working, the model is already straining. Good scaling shows up as fewer custom patches, clearer ownership, and predictable enforcement across the application estate.

Technical breakdown

Why authorization becomes harder as roles multiply

Authorization starts simple when a product has one user type and a small set of permissions. The problem appears when customer-facing, support, finance, and engineering users all need different access paths inside the same application. At that point, hard-coded role checks and one-off exceptions become brittle because the system must express both entitlements and workflow boundaries. Authorization is not just about blocking access, it is about preserving business separation as operational complexity rises.

Practical implication: model role growth early and avoid embedding access logic directly into application code.

How stack sprawl turns access control into infrastructure debt

As software shifts from a single application stack to microservices, APIs, data platforms, and specialised internal tools, authorization decisions must work consistently across many execution points. Each new service adds another place where permissions can drift, duplicate, or fail open. That is why authorization becomes infrastructure rather than a feature. The real burden is not only policy design, but the maintenance cost of keeping decisions consistent across the stack.

Practical implication: centralise policy logic so service expansion does not create separate permission models.

Build versus buy in authorization engineering

The build-versus-buy question is not whether engineers can implement authorization, but whether custom code is worth the long-term maintenance and compliance burden. Rebuilding access control from scratch often shifts effort away from product work and toward sustaining logic that already exists elsewhere. Mature authorization also has to be fast, reliable, extensible, and secure because it sits in the request path of every protected action. That makes it a governance layer, not a throwaway utility.

Practical implication: treat authorization as a lifecycle-managed control surface, not a one-time development task.

Breaches seen in the wild

• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.
• Schneider Electric credentials breach — exposed credentials gave attackers access to Schneider Electric Jira, exfiltrating 40GB.

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

NHI Mgmt Group analysis

Authorization debt is a governance problem, not just an engineering inconvenience. The article shows how teams can spend years building access logic that does not advance the core business. That pattern creates hidden policy drift, inconsistent enforcement, and growing compliance exposure as roles multiply. The practitioner lesson is to govern authorization as a control domain with lifecycle ownership, not as incidental code.

Stack expansion exposes the limits of application-local access decisions. Once one system becomes many microservices, the access decision has to survive across boundaries, teams, and release cycles. Localised permission logic cannot keep pace with that spread without creating duplicate rules and inconsistent outcomes. The practical implication is that identity governance must extend beyond user login into application-level entitlement control.

Authorization policy sprawl: when every team encodes access logic differently, the enterprise inherits multiple versions of the same control and no single audit point. That is the hidden failure mode this talk points to, and it becomes more visible as organisations scale from MVP to platform. The implication is not simply to add tooling, but to stop treating authorization as a project-owned artifact. Practitioners should recognise this as a lifecycle and governance issue.

Build-versus-buy decisions in authorization are ultimately control-design decisions. The article's core warning is that custom security logic creates long-tail maintenance and assurance costs that business teams often underestimate. That cost grows when compliance expectations such as GDPR and CCPA require explainable and durable enforcement. The practitioner implication is to align authorization ownership with security architecture, auditability, and operational resilience from day one.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• That same research finds that only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared with nearly 1 in 4 for securing human identities.
• For the broader lifecycle context, the Ultimate Guide to NHIs and lifecycle processes for managing NHIs helps teams connect access design to provisioning, review, and offboarding.

What this signals

Authorization complexity is now a lifecycle issue, not just an application design issue. As products add roles, services, and internal operators, the same permission logic has to survive more change events than most teams budget for. That is why control ownership needs to sit alongside identity governance and not inside a single engineering squad.

The practical signal for readers is that access control debt often appears first as exception handling, duplicated logic, and delayed reviews. Teams that see those symptoms should treat them as an early warning that authorization is being managed by code churn rather than by policy.

For teams aligning to broader governance frameworks, the strongest fit is a control model that treats protected actions as governed decisions across the stack. That posture becomes more important as internal services, support workflows, and machine identities start sharing the same application surface.

For practitioners

• Map authorization decision points across the stack Inventory every place where access is checked in application code, APIs, and internal tooling, then identify which decisions are duplicated or inconsistent. Use that map to find where policy drift is already likely.
• Separate business logic from access logic Move role and permission rules out of feature code where possible so product changes do not silently change access behaviour. Keep the decision model explicit and reviewable by security and platform owners.
• Assign lifecycle ownership for authorization policy Define who owns access policy design, review, change control, and exception handling across engineering and security. Treat policy maintenance as an ongoing governance function rather than a development side task.
• Test authorization for scale and failure modes Validate how the control behaves when new roles, services, and teams are added, and confirm the default state does not weaken security under load or partial failure. Include auditability and recovery in those tests.

Key takeaways

• Authorization becomes a scaling problem once roles, services, and workflows multiply faster than policy governance.
• Custom access logic can create long-term maintenance, audit, and compliance debt even when it solves an immediate product need.
• Teams should govern authorization as a lifecycle control, not as code that each service invents for itself.

Key terms

• Authorization: Authorization is the decision process that determines whether an identity can perform a specific action on a specific resource. In practice, it is a policy and enforcement function that must stay consistent as applications, roles, and services grow across an organisation.
• Policy Sprawl: Policy sprawl happens when access rules are duplicated across teams, services, or products without a single governance model. The result is inconsistent enforcement, harder audits, and more exceptions, because no one can easily tell which rule is authoritative.
• Access Decision Point: An access decision point is the place where an application evaluates whether an action should be allowed. For large systems, it becomes a control surface that must be reliable, auditable, and consistent across many workflows rather than embedded ad hoc in each service.

Deepen your knowledge

Authorization and policy governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is facing the same growth pattern described here, it is worth exploring.

This post draws on content published by Cerbos: a conference talk recap on building smarter, not harder in authorization. Read the original.