TL;DR: The “Authorization Tax” includes six to eighteen months of initial engineering work, ongoing maintenance that can run 50 to 100% of original build cost each year, and productivity losses when authorization logic becomes shared infrastructure, according to Authzed. The governance issue is broader than engineering spend: authorization decisions shape compliance, agility, and the ability to support new identity patterns without replatforming.
At a glance
What this is: This is an analysis of the hidden cost of in-house authorization, arguing that the spend shows up in engineering, maintenance, productivity, and lost agility rather than in a single budget line.
Why it matters: IAM and IGA teams need to treat authorization as shared governance infrastructure, because its real cost affects delivery speed, compliance change handling, and how quickly identity programmes can adapt.
Context
Authorization is the policy layer that decides who or what can do what in an application or platform. When teams build that layer themselves, the cost extends beyond software development into operations, audits, dependency management, and delayed change delivery.
Authzed frames this as an “Authorization Tax”, a cumulative burden that many organisations undercount because it is spread across engineering time, support work, and missed business opportunities. The article is really about governance maturity: when authorization becomes bespoke infrastructure, every new identity pattern raises the cost of keeping access decisions current.
That makes the topic relevant to human IAM, NHI governance, and emerging agentic AI environments alike. The common problem is not simply access control design, but the lifecycle cost of sustaining policy logic as business models, applications, and compliance requirements change.
Key questions
Q: What breaks when authorisation is hardcoded into application logic?
A: Hardcoded access rules become brittle as systems grow, because each code path must be updated and retested whenever permissions change. That creates audit gaps, slows remediation, and makes it difficult to apply consistent policy across clusters, services, and AI-driven workflows.
Q: Why do custom authorization systems become more expensive over time?
A: They accumulate policy debt. As products, compliance obligations, and organisational structures change, the authorization layer must be rewritten, retested, and re-integrated. That makes maintenance a recurring operating cost, not a one-off build expense, and it pushes teams toward higher support overhead every year.
Q: What are the signs that an authorization system is becoming a bottleneck?
A: Common signs include permissions logic being copied into multiple languages, recurring bugs across services, difficulty modeling relationships like groups within groups, and authorization checks consuming an outsized share of database CPU. Teams also feel pressure when the system cannot be federated or sharded cleanly and when new product features remain blocked by permission-model limits.
Q: When should organisations reconsider a home-grown authorization model?
A: They should reconsider it when the current model cannot support new granularity, scale, compliance needs, or identity patterns without major rewrites. At that point, the architecture is limiting strategy, and the cost of keeping it in place can exceed the cost of changing it.
Technical breakdown
Why custom authorization becomes infrastructure, not a feature
Authorization starts as application logic, but it quickly behaves like a shared control plane. Every service that needs permissions, entitlements, or policy decisions depends on it, which turns a local coding task into an enterprise platform obligation. That means availability, latency, schema evolution, and policy semantics all become governance issues, not just engineering concerns. The more embedded the authorization model becomes, the more expensive each product change becomes because the policy layer has to keep pace with application growth, organisational change, and audit demands. Practical implication: treat authorization as enterprise infrastructure with lifecycle ownership, not as code hidden inside each app.
Practical implication: separate authorization ownership from feature teams so policy changes do not create bottlenecks across the application portfolio.
Maintenance cost grows with every new use case
The article’s core point is that maintenance is not a small follow-on expense after the first build. New compliance requirements, new organisational structures, new data boundaries, and new product features all force the authorization system to evolve. That creates recurring code changes, testing overhead, operational tuning, and release coordination. In governance terms, the problem is policy drift: the access model that was correct at launch becomes incomplete or brittle as the business changes around it. Practical implication: budget authorization as a living system with ongoing change demand, not as a one-time development project.
Practical implication: track authorization maintenance as recurring platform work, and measure it separately from feature development to expose hidden operating cost.
Replatforming risk appears when authorization cannot support new identity patterns
A bespoke authorization stack can work until the business needs a new granularity, a new scale profile, or a new identity model. At that point, the system stops being a neutral control and starts constraining strategy. The article points to agentic systems as one example of where older authorization assumptions can break, because the policy model may not be able to express the needed delegation, scope, or decision boundaries cleanly. That is a governance problem as much as a technical one: the organisation becomes dependent on its old access model even when the business has moved on. Practical implication: assess whether your authorization architecture can absorb new identity patterns without a rebuild.
Practical implication: validate whether your current authorization model can support future identity patterns before it becomes a blocker to new products or operating models.
Breaches seen in the wild
- Zacks breach claim 2025: A hacker leaked 12 million Zacks accounts in 2025, claiming domain admin access in 2024; HIBP verified the data, Zacks has not confirmed.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Authorization is now a governance platform cost, not an application detail. When permission logic becomes shared infrastructure, the organisation inherits a permanent operating burden that extends far beyond the first implementation. Security, compliance, HR, and product teams all depend on the same control layer, so every change becomes a cross-functional governance event. The practitioner conclusion is simple: treat authorization as a strategic platform with lifecycle cost, not as incidental code.
The hidden cost is really policy debt. The article shows that the largest losses are not only engineering hours but the organisational friction created when access logic lags business change. That is a governance issue because the control layer no longer reflects the current operating model, which creates audit pressure and slows delivery. The practitioner conclusion is that policy ownership and change velocity are as important as initial build effort.
Authorization tax is the right named concept for this problem. It captures the full burden of building, maintaining, and adapting in-house authorization as business infrastructure. That burden increases whenever teams add new products, compliance demands, or identity patterns, because the access layer must evolve with the organisation. The practitioner conclusion is to measure authorization as an enterprise cost centre, not a line item hidden inside engineering.
Replatforming pressure is a signal that the access model has outlived its assumptions. When authorization no longer supports new scale, granularity, or delegation needs, the architecture itself becomes a constraint on growth. That forces organisations to choose between redesign, delay, or loss of opportunity. The practitioner conclusion is to test future fit early, before the current model becomes strategically blocking.
What this signals
Authorization tax creates an identity governance blind spot. Because the cost is distributed across delivery, support, and compliance work, teams often undercount it until it starts slowing change across the business. The practical lesson for IAM leaders is to manage authorization as a lifecycle capability, not a code asset.
Policy change speed is a programme health signal. If security or compliance teams still need engineering intervention for routine access updates, the organization is carrying unnecessary authorization debt. That is where governance starts to fail in practice, because the control layer cannot keep up with operational change.
For practitioners
- Quantify authorization as a programme cost Build a cost model that captures development time, maintenance effort, support overhead, and productivity loss across the teams that depend on access decisions.
- Separate policy ownership from feature delivery Assign clear ownership for authorization policy, review cadence, and change approval so application teams are not the only source of access control expertise.
- Measure maintenance as recurring platform work Track the time spent on policy updates, bug fixes, compliance changes, and operational care so hidden authorization effort becomes visible in planning.
- Test future fit against new identity patterns Review whether the current authorization model can handle finer-grained delegation, new application classes, and emerging agentic system requirements without redesign.
Key takeaways
- In-house authorization can look cheap on paper while creating substantial hidden cost across engineering, support, and governance functions.
- The article’s central warning is that maintenance and productivity loss often exceed the initial build effort over time.
- Teams should evaluate whether their authorization architecture can support future identity and compliance needs without forcing a rebuild.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Authorization sprawl often results in excess permissions and hard-to-audit access logic. |
| Recommendation — Review authorization scope against NHI-05 and remove embedded permission paths that outgrow their original purpose. | ||
| NIST CSF 2.0 | GV.PO-01 — Policy establishment and communication | The article is about turning authorization into a governed enterprise capability. |
| Recommendation — Define authorization policy ownership and change governance so access control remains managed across the programme. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | The cost discussion is rooted in maintaining precise, evolving access decisions. |
| Recommendation — Apply AC-6 to keep authorization decisions tightly scoped and prevent permission logic from drifting into excess access. | ||
| CIS Controls v8 | CIS-5 — Account Management | Authorization tax grows when access changes are slow, manual, or dependent on engineering. |
| Recommendation — Use CIS-5 to centralise account and permission governance so access changes do not depend on ad hoc developer effort. | ||
Key terms
- Authorization tax: The ongoing financial and operational burden created when an organisation builds, maintains, and evolves its own authorization system. It includes engineering time, maintenance, governance delays, and the hidden cost of future change when access control is tightly coupled to product delivery.
- Policy debt: The accumulation of stale exceptions, duplicated rules, and layered workarounds inside an authorization environment. It weakens governance because teams inherit access logic that no longer reflects business need, making review harder and increasing the likelihood of silent over-permissioning.
- Replatforming risk: The likelihood that a custom authorization design will no longer fit the organisation’s scale, compliance, or identity needs and will need to be replaced. It is a lifecycle issue, not only a technical one, because the cost of change grows as the system becomes more embedded.
- Shared Authorization Layer: A shared authorization layer is a central policy service that decides whether a subject can perform an action on a resource, while enforcement remains close to the application. It reduces duplicated rules, improves consistency, and makes access decisions easier to govern across services and identity types.
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 building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 10, 2026.
Updated on October 10, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org