Building authorization in-house gets expensive fast for IAM teams

At a glance

What this is: This is a build-versus-buy analysis for application authorization, with the key finding that in-house authorization often becomes a long-term engineering and governance cost rather than a one-time feature build.

Why it matters: It matters because authorization design influences NHI, autonomous, and human access decisions across applications, so hidden complexity quickly turns into policy inconsistency, audit friction, and developer time loss.

By the numbers:

• IDC research found that half of developers surveyed spend roughly 19% of their time on security-related tasks.

👉 Read Cerbos's guide to build-versus-buy decisions for authorization

Context

Authorization starts as a simple decision layer, but it becomes a governance problem once products add tenants, service boundaries, audit requirements, and role exceptions. For IAM teams, the issue is not whether access checks exist, but whether those checks stay consistent as the application and operating model expand.

The article’s central claim is that building authorization in-house often hides its true cost until the maintenance burden is already embedded in engineering roadmaps. That matters for NHI, autonomous, and human identity programmes because authorization policy usually sits at the point where identity, context, and privilege finally become an enforceable decision.

For teams trying to reduce scattered permission logic, the real question is whether authorization remains a product feature or becomes a permanent control plane. That distinction is familiar to practitioners working through workload identity, app-level access models, and lifecycle governance.

Key questions

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. Include developer time, policy maintenance, audit evidence, regression testing, and the cost of changing rules as products add services or tenants. If authorization is not a core differentiator, the in-house model usually becomes an ongoing engineering tax rather than a one-time build.

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. When checks are embedded in code, every change risks drift, inconsistent enforcement, and extra testing. The result is a recurring burden on engineering and security teams, not a fixed implementation cost.

Q: What breaks when authorization logic is scattered across application code?

A: Scattered logic breaks consistency, traceability, and change control. Different services can implement slightly different rules, so teams lose a single source of truth for access decisions. That makes audits harder, increases the chance of missed updates, and creates hidden privilege mistakes during product changes.

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.

Technical breakdown

Why scattered authorization logic becomes a control problem

When authorization checks live inside application code, every service can evolve its own permission logic, edge cases, and policy exceptions. That creates drift between the intended model and the actual runtime decision. Fine-grained access control needs one policy source, otherwise developers patch locally and auditors inherit inconsistency. This is especially brittle in multi-tenant systems, where resource boundaries and customer isolation rules change often. Practical implication: centralise policy evaluation so authorization is governed as a control plane, not as dispersed code fragments.

Practical implication: centralise policy evaluation so authorization is governed as a control plane, not as dispersed code fragments.

How compliance and audit logging change the build-versus-buy equation

Authorization is not just about making an allow or deny decision. In regulated environments, teams also need evidence of why the decision was made, which policy version applied, and whether the logic was consistent across services. If logs are scattered, audit preparation becomes manual reconstruction rather than straightforward validation. That burden grows quickly as services multiply and compliance regimes tighten. Practical implication: if an authorization model cannot produce consistent decision records, it will expand audit cost even when runtime access looks correct.

Practical implication: if an authorization model cannot produce consistent decision records, it will expand audit cost even when runtime access looks correct.

Authorization maintenance and developer time are the hidden cost centres

The headline build cost is only the start. The larger expense is recurring developer time spent updating policies, testing permission changes, and chasing regressions as products add services, tenants, and exceptions. IDC’s finding that developers spend around 19% of their time on security work shows how quickly this overhead can crowd out feature delivery. In practice, authorization becomes a tax on every release cycle if ownership is not clearly separated. Practical implication: treat authorization maintenance as an operating cost, not a one-time engineering task.

Practical implication: treat authorization maintenance as an operating cost, not a one-time engineering task.

Breaches seen in the wild

• Azure Key Vault privilege escalation exposure — Azure Key Vault Contributor role misconfiguration enabled privilege escalation.
• 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 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.

Build-versus-buy decisions in authorization should be measured in lifecycle cost, not feature parity. The meaningful question is how much engineering capacity disappears into policy updates, evidence collection, and exception handling over the life of the platform. The article shows that the cost gap widens as tenancy, compliance, and product complexity increase. Practitioners should compare the full operating burden, not just the first implementation sprint.

Centralised policy evaluation changes the governance model for applications, APIs, workloads, and AI agents. Once authorization is externalised from code, the organisation can apply one decision layer across multiple actor types and execution contexts. That matters because access governance increasingly spans human users, machine identities, and agentic workflows. Practitioners should align authorization architecture with the identity mix they actually operate.

Auditability is the named control gap that in-house authorization often fails to cover. The article makes clear that one of the biggest hidden costs is evidence gathering after the fact, especially when decision logic is distributed. That failure mode is not lack of access control, but lack of authoritative traceability. Practitioners should view audit visibility as part of the authorization architecture, not an afterthought.

Policy drift is the named concept that best captures the long tail of internal authorization builds. Each new service, tenant type, and compliance requirement increases the chance that local logic diverges from intended rules. Over time, the organisation ends up with multiple truths about access. Practitioners should treat policy drift as a structural governance risk, not a tooling inconvenience.

From our research:

• 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.
• That fragmentation pattern is echoed in the NHI Lifecycle Management Guide, which frames lifecycle control as a governance problem rather than a point-in-time fix.

What this signals

Policy drift will keep widening the gap between application teams and governance teams unless authorization is treated as a shared control surface. The more services and tenants an environment accumulates, the more likely local rule changes will diverge from intended access policy. Practitioners should expect authorization to become a central programme dependency, not just a developer convenience, and align it with NIST Cybersecurity Framework 2.0 governance expectations.

Authorization architecture now sits alongside lifecycle governance for NHIs and workload identities. Once access decisions are embedded across applications, the organisation has to manage them with the same discipline it applies to entitlement review and offboarding. That is why the NHI Lifecycle Management Guide matters here: policy control without lifecycle control still leaves teams with accumulated privilege and hard-to-explain access paths.

Centralised decisioning is the right mental model for teams that want fewer audit surprises and less developer drag. The point is not to eliminate application ownership, but to stop each codebase from becoming its own access policy island. Teams should watch for the same failure patterns in human IAM, NHI governance, and service-to-service access, then standardise the decision layer before the next compliance cycle.

For practitioners

• Map all authorization decision points Inventory every place where permission checks are enforced in application code, middleware, and service edges. Identify duplicate rules, one-off exceptions, and any logic that cannot be centrally tested or audited.
• Quantify the full lifecycle cost of internal auth Include developer time, maintenance, audit prep, regression testing, and release delays in the business case. Compare that against the cost of policy authoring, versioning, and decision visibility over the same horizon.
• 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. Keep the policy source versioned and traceable, with clear ownership between application teams and governance teams.
• Review audit evidence requirements before the next compliance cycle Check whether your current authorization model can show who was allowed to do what, under which policy version, and in which service. If it cannot, the audit workload will continue to rise with every new system.

Key takeaways

• In-house authorization often turns into a long-term governance burden once services, tenants, and compliance requirements start to multiply.
• The scale of hidden cost is material, with one audited build landing in seven figures over its lifespan and other teams reporting months of engineering time saved by not rebuilding the control.
• Teams should treat authorization as a centrally governed control plane, because scattered permission logic increases drift, audit effort, and developer overhead.

Key terms

• Authorization sprawl: Authorization sprawl is the condition where access rules are duplicated across multiple services, code paths, or teams. The result is inconsistent enforcement, harder audits, and more expensive change management because no single policy source governs all decisions.
• Policy drift: Policy drift occurs when the intended access model and the actual runtime rules slowly diverge. It usually appears after repeated local fixes, exceptions, and service-specific logic, leaving teams with multiple versions of the truth about who or what can access a resource.
• Externalised authorization: Externalised authorization is the practice of moving access decisions out of application code and into a dedicated policy layer. This separates business logic from access logic, improves consistency, and makes decision records easier to version, test, and audit.

Deepen your knowledge

Authorization governance and lifecycle control are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is deciding whether to centralise access decisions across applications and workloads, this is a useful place to start.

This post draws on content published by Cerbos: the build-versus-buy case for application authorization. Read the original.