Notifications
Clear all
Topic starter
23/06/2026 9:12 pm
TL;DR: As products add roles, services, and back-office workflows, authorization complexity rises faster than many teams expect, according to Cerbos's conference talk recap. The underlying lesson is that access control becomes a scaling and compliance problem long before teams notice the maintenance burden.
NHIMG editorial — based on content published by Cerbos: a conference talk recap on building smarter, not harder in authorization
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- 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.
- Assign lifecycle ownership for authorization policy Define who owns access policy design, review, change control, and exception handling across engineering and security.
What's in the full article
Cerbos' full post covers the operational detail this post intentionally leaves for the source:
- Why the author frames authorization as a build-versus-buy decision for engineering leaders.
- How the user-role growth pattern creates a practical 'train crash' in real product teams.
- What the talk says about the maintenance burden of custom authorization over time.
- Why compliance pressure makes ad hoc access logic harder to sustain.
👉 Read Cerbos's analysis of authorization scaling and build-versus-buy tradeoffs →
Authorization complexity and build-vs-buy choices for growing teams?
Explore further
25/06/2026 2:23 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Authorization complexity is the hidden train crash in software teams
