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.
NHIMG editorial — based on content published by AuthZed: the authorization tax in custom systems
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.
Questions worth separating out
Q: How should teams quantify the cost of in-house authorization?
A: Teams should count more than engineering hours.
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.
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.
Practitioner guidance
- 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.
What's in the full article
AuthZed's full article covers the operational detail this post intentionally leaves for the source:
- Detailed cost inputs for calculating the authorization tax across build, maintenance, productivity, and replatforming.
- Examples of how customers benchmark authorization waste against business metrics such as deployment frequency.
- The open-source and managed-service paths the article contrasts for reducing custom authorization overhead.
- Implementation context for managed infrastructure, including operational responsibilities that remain with the customer.
👉 Read AuthZed's analysis of the authorization tax in custom systems →
Authorization tax and IAM teams: where are the hidden costs?
Explore further
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: The authorization tax is a governance cost teams keep undercounting