Notifications
Clear all
Topic starter
10/06/2026 11:14 pm
TL;DR: Customers have seen seven-figure lifetime costs, at least £200,000 in developer time, and 3 to 6 months of saved build time when they avoid building authorization in-house, according to Cerbos. The core issue is not initial access logic but the long tail of policy drift, audit burden, and maintenance overhead that compounds as systems grow, while IDC research puts developer security work at roughly 19% of time.
NHIMG editorial — based on content published by Cerbos: the build-versus-buy case for application authorization
By the numbers:
- IDC research found that half of developers surveyed spend roughly 19% of their time on security-related tasks.
Questions worth separating out
Q: How should security teams decide whether to build authorization in-house or buy it?
A: Teams should compare total lifecycle cost, not just first-release effort.
Q: Why does in-house authorization become more expensive over time?
A: Authorization cost compounds because each new service, tenant type, and exception creates more policy paths to maintain.
Q: What breaks when authorization logic is scattered across application code?
A: Scattered logic breaks consistency, traceability, and change control.
Practitioner guidance
- Map all authorization decision points Inventory every place where permission checks are enforced in application code, middleware, and service edges.
- Quantify the full lifecycle cost of internal auth Include developer time, maintenance, audit prep, regression testing, and release delays in the business case.
- Separate policy logic from product logic Move authorization rules out of feature code where possible so engineers can change access policy without rewriting business logic.
What's in the full article
Cerbos's full guide covers the operational detail this post intentionally leaves for the source:
- Customer-by-customer cost breakdowns showing how lifetime authorization spend was estimated
- Implementation detail on Cerbos PDP, Hub, PEP SDKs, and Synapse for teams comparing architectures
- Practical examples of how policy authoring, testing, and distribution work in distributed environments
- The source article's discussion of when building in-house can still make sense for niche requirements
👉 Read Cerbos's guide to build-versus-buy decisions for authorization →
Authorization build vs buy: what does it mean for IAM teams?
Explore further
12/06/2026 5:06 am
Authorization sprawl is a governance failure before it is a software problem. Once permission logic is copied into multiple services, teams stop governing a single policy model and start managing exceptions scattered across code. That fragmentation makes access decisions harder to audit, harder to test, and easier to break during product change. Practitioners should treat scattered authorization as a sign that the control has already lost coherence.
A few things that frame the scale:
- One company audited their in-house authorization costs and found a seven-figure total over the company's lifespan, according to The State of Secrets in AppSec.
- Organisations maintain an average of 6 distinct secrets manager instances, creating fragmentation that undermines centralised control.
A question worth separating out:
Q: How can teams tell if authorization governance is working?
A: Look for central policy versioning, consistent decision logs, and the ability to prove which rule set applied to each access request. If engineers still need to search across services to answer basic audit questions, the authorization model is not yet governed as a reliable control plane.
👉 Read our full editorial: Building authorization in-house gets expensive fast for IAM teams
