The authorization tax is a governance cost teams keep undercounting

At a glance

What this is: This is an analysis of the hidden cost of building and maintaining in-house authorization systems, with the key finding that the financial and operational burden often exceeds what teams budget for.

Why it matters: It matters because authorization is a control plane for both human and non-human access, and underestimating its lifecycle cost can slow IAM, NHI, and platform governance programmes in equal measure.

By the numbers:

• Annual maintenance costs often run 50 to 100% of the original build cost, trending upward over time.
• Security is a key reason why 90% of AI projects fail, according to recent research cited by AuthZed.

👉 Read AuthZed's analysis of the authorization tax in custom systems

Context

Authorization tax is the accumulated cost of designing, running, and changing access decisions over time. For IAM teams, the problem is not only the initial build, but the ongoing burden of keeping authorization logic aligned with application change, compliance demands, and new identity patterns across humans, workloads, and AI-enabled systems.

The hidden cost appears when authorization becomes embedded in applications instead of treated as a governed control layer. At that point, engineering becomes the bottleneck for security, compliance, and business change, and the programme starts to absorb costs that rarely appear as a clean budget line.

That is why the article belongs in the governance conversation, not just the architecture conversation. The relevant question is how much control, agility, and lifecycle discipline an organisation loses when it carries authorization as custom infrastructure for too long.

Key questions

Q: How should teams quantify the cost of in-house authorization?

A: Teams should count more than engineering hours. Include initial design and build, maintenance, release dependency, training loss when engineers leave, and the business cost of delayed changes. The clearest view comes from measuring authorization as lifecycle infrastructure rather than as a one-off application feature, because that is where the hidden spend accumulates.

Q: Why does custom authorization slow security and compliance work?

A: Because the people who need to adjust or audit permissions are forced to wait on application engineers. That coupling turns authorization into a bottleneck for governance, especially when policy changes are frequent or audit deadlines are fixed. The result is not just slower delivery, but lower control over who can change access and when.

Q: When does an authorization system need replatforming?

A: Replatforming becomes likely when the current system cannot support new scale, finer-grained policies, compliance demands, or emerging identity patterns without heavy custom work. If each change requires a growing amount of code and specialist knowledge, the platform is no longer serving the business shape it was meant to support.

Q: Should organisations keep building custom authorization systems?

A: Only if they have a very specific need, strong infrastructure expertise, and a clear willingness to own the long-term maintenance burden. For most teams, the decision should be based on whether custom ownership creates more control than it consumes. If governance is slowing because of engineering dependency, the build model is already expensive.

Technical breakdown

What drives the authorization tax in custom systems?

The authorization tax is the total cost of owning an authorization engine instead of consuming one as governed infrastructure. It starts with design, implementation, testing, and hardening, then expands as new application features, organisational changes, and compliance requirements force more code. Because authorization is infrastructure, not just application logic, every exception and every new policy shape adds long-term maintenance weight.

Practical implication: map authorization work as lifecycle cost, not project cost, before committing to another bespoke build.

Why authorization becomes a dependency bottleneck

When authorization rules are embedded inside applications, every meaningful change depends on engineering availability. That creates a control bottleneck for Security, HR, Compliance, and product teams that need to modify, review, or audit permissions. The deeper issue is governance coupling: the identity decision path is no longer separable from the application release path, so access change inherits software delivery constraints.

Practical implication: separate permission governance from application release flow wherever policy changes must move faster than code.

Why replatforming becomes inevitable

A custom authorization system is built for a specific stage of the business, not for every future scale, compliance, or identity model shift. Over time, new use cases such as finer-grained access control or agentic execution patterns can expose limits that patching cannot fix. At that point, the issue is not only cost but architecture drift, because the system no longer fits the operating model it is supposed to support.

Practical implication: treat replatforming risk as a planned governance checkpoint, especially when new identity types will stress current policy design.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Zacks Investment Research breach — Zacks breach exposed 12M customer records including credentials.

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 is identity infrastructure, not an application feature. When teams treat it as a sidecar to product engineering, they inherit hidden operating costs, release bottlenecks, and audit friction that compound over time. The field-level mistake is to understate authorization as a code concern when it is really a control plane concern. Practitioners should judge it as shared identity infrastructure with lifecycle implications.

Customization debt is the real authorization tax. Each new business rule, compliance exception, or organisational change pushes bespoke logic deeper into the stack, which increases long-term dependency on the original engineers. That is why maintenance costs climb after the first build and why teams struggle to transfer knowledge cleanly. Practitioners should assume that custom authorization will grow less flexible, not more, unless it is deliberately governed.

Access governance breaks when authorization is too close to delivery. Security and compliance teams cannot sustainably depend on software release cadence for permission changes. That coupling turns governance into queue management, which is a structural failure in fast-moving environments. Practitioners should re-evaluate where authorization lives in the architecture before policy velocity becomes a business constraint.

Authorization economics now shape AI readiness as much as traditional app security. The article’s own warning about AI project failure shows that access trust is becoming a gating factor for new workloads, not just an efficiency concern. As organizations add agents, services, and delegated workflows, authorization design determines whether those systems can be governed at all. Practitioners should plan for access models that can absorb new identity forms without starting over.

Replatforming cost is a governance signal, not just a finance signal. When an authorization stack can no longer support granularity, scale, or new operating patterns, the organisation is already paying for a mismatch between policy intent and technical reality. The named concept here is authorization tax: the hidden premium paid for owning policy infrastructure too long. Practitioners should use that signal to challenge whether custom ownership still makes sense.

From our research:

• Organisations maintain an average of 6 distinct secrets manager instances, creating fragmentation that undermines centralised control, according to the State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, showing that control quality is often limited by day-to-day developer behaviour.
• The operational lesson extends beyond secrets to broader identity infrastructure, including the State of Secrets in AppSec and NIST SP 800-63 Digital Identity Guidelines.

What this signals

Authorization tax becomes visible when identity governance slows the business. If access changes require engineering release cycles, the programme is already paying a control premium that will only rise as systems grow. Teams should watch for policy work that keeps expanding into product backlog work, because that is usually the first sign that governance has become operational debt.

The next pressure point is non-human identity growth, where policy logic will be asked to govern services, workloads, and agent-like execution paths alongside human access. Organisations that cannot separate policy intent from application code will struggle to absorb those identities without creating new delays and exceptions. That makes authorization architecture a forward-looking IAM decision, not just a backend engineering choice.

For practitioners

• Quantify authorization as a lifecycle cost Track initial build effort, annual maintenance, release dependency, and replatforming risk together so the business sees the full authorization tax rather than only project spend.
• Measure governance delay caused by engineering dependency Record how long security, compliance, and operations wait for permission changes when authorization is embedded in code, then use that delay as an operating metric.
• Separate policy change from application release Move toward an architecture where access rules can change without requiring every authorization update to ride a software deployment cycle.
• Review replatforming triggers before the next expansion Test current authorization design against new compliance requirements, new business units, and non-human identity use cases before the current model becomes structurally hard to extend.

Key takeaways

• In-house authorization creates a hidden tax that includes build cost, maintenance, training loss, and slower business change.
• The scale of the burden grows when permission governance depends on application engineers for every meaningful change.
• Teams should reassess custom authorization before new compliance demands and non-human identity use cases make the current model too expensive to extend.

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 coupling: The condition where access rules cannot be changed without changing application code or waiting for a software release. This creates governance friction because security and compliance work inherit engineering dependencies that slow decisions and reduce control over permissions.
• 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.

Deepen your knowledge

Authorization lifecycle cost, policy governance, and platform trade-offs are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is carrying custom authorization into new service and agent use cases, it is worth exploring.

This post draws on content published by AuthZed: the authorization tax in custom systems. Read the original.