Build versus buy for roles and permissions in enterprise software

At a glance

What this is: This is a build-versus-buy analysis for roles and permissions in enterprise software, and its key finding is that access-control logic becomes far more complex than teams expect once real-world collaboration, compliance, and service coordination are in scope.

Why it matters: It matters because IAM teams, app architects, and platform owners need access-control patterns that scale across human users, service accounts, and automated workflows without turning permissions into recurring technical debt.

By the numbers:

• Stripe has a recent survey that says 42 percent of developer time is actually spent in tech debt and maintenance.

👉 Read Cerbos' talk on build versus buy decisions for roles and permissions

Context

Roles and permissions are the policy layer that decides who can see, change, or approve actions inside software. In B2B applications, that layer stops being simple as soon as multiple users, departments, and workflows intersect, which is why IAM decisions often spill into engineering, audit, and compliance work.

The governance problem is not just technical overhead. When access rules are coded ad hoc, teams inherit brittle permission logic, weak auditability, and inconsistent enforcement across services, which creates long-term risk for human IAM and for non-human identities that also depend on reliable policy decisions.

Key questions

Q: How should teams decide whether to build or buy authorization logic?

A: Teams should build only when authorization is tightly coupled to a unique business rule that cannot be separated from the product. If roles, permissions, auditability, and cross-service enforcement are recurring concerns, buy or adopt a dedicated authorization layer so the organisation does not keep recreating the same control in every application.

Q: Why do simple role models fail in enterprise applications?

A: Simple role models fail because real organisations do not operate with only a few stable access patterns. Geography, department, workflow, and customer context all change what a person or service should be allowed to do, so static roles quickly require exceptions that weaken governance and make reviews unreliable.

Q: How can security teams tell when permissions logic is creating technical debt?

A: Look for repeated custom rules, manual access exceptions, inconsistent enforcement across services, and difficulty explaining decisions during audit. Those signals show that permissions logic has become an ongoing maintenance burden rather than a governed control, and the organisation is paying for the same design problem more than once.

Q: What should architects do before permissions logic is spread across multiple microservices?

A: Define a single policy model, decision owner, and audit approach before the logic fragments across services. Once permissions are embedded in many stacks and languages, consistency becomes harder to maintain and changes become expensive, which is why the governance model has to exist before the implementation sprawl starts.

Technical breakdown

Why roles and permissions become a distributed systems problem

A permissions model is not just a table of users and roles. In a real enterprise application, the policy decision may need to consider service boundaries, microservice calls, data sensitivity, workflow state, and audit expectations at the same time. Once authorization logic has to travel across multiple services and languages, the implementation becomes a distributed control plane rather than a simple application feature. That is why teams often underestimate the engineering burden: the hard part is not checking access once, but keeping the decision consistent everywhere it is enforced.

Practical implication: treat authorization as a shared platform concern, not a one-off feature in each service.

Why oversimplified roles fail in large organisations

The common mistake is assuming a few static roles will map cleanly to how people actually work. In practice, access needs vary by country, department, function, customer tier, and workflow stage, so coarse roles quickly turn into exceptions and manual overrides. That creates permission creep, weak segregation of duties, and hard-to-review entitlements. The problem is not that roles are useless, but that they are often too blunt to express real business conditions without supplemental policy logic.

Practical implication: model access around business context, then use roles only where they truly fit.

Audit logs and compliance are part of the authorization design

Authorization is not complete if it only decides whether an action is allowed. Enterprise software also has to explain why the decision was made, how it was recorded, and whether it can be reviewed later for GDPR, CCPA, or internal controls. That means audit logs, policy versioning, and consistent enforcement are part of the authorization architecture. Teams that bolt these on after the fact usually discover that their access model cannot support reliable evidence, especially when permissions are distributed across microservices.

Practical implication: include auditability and policy traceability in the original authorization design.

Breaches seen in the wild

• Azure Key Vault privilege escalation exposure — Azure Key Vault Contributor role misconfiguration enabled privilege escalation.
• JetBrains GitHub plugin token exposure — CVE-2024-37051 in JetBrains IntelliJ GitHub plugin exposed GitHub access tokens.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Build-versus-buy is really a governance-versus-duplication decision. The central mistake in in-house authorization projects is treating roles and permissions as a narrow feature instead of shared identity infrastructure. Once multiple services, workflows, and audit requirements exist, teams duplicate policy logic across the stack and create inconsistent enforcement. The practitioner lesson is to separate application logic from policy administration early.

Permission models fail when they are too coarse to represent business reality. The article’s examples show the same pattern that appears in human IAM and NHI governance: a small number of roles cannot express how access actually varies across functions, environments, and responsibilities. That leads to exceptions, manual fixes, and eventual policy drift. The implication is that authorization needs to be designed for variability, not idealized simplicity.

Auditability is not an add-on to authorization, it is part of the control. If access decisions cannot be reconstructed after the fact, the organisation does not really have governed authorization, only runtime gating. That matters for compliance and for operational trust, because policy enforcement without evidence is difficult to defend. Practitioners should treat decision logging and policy traceability as core requirements, not after-the-fact reporting.

Named concept: permission debt. This article illustrates how teams accumulate recurring rework when they rebuild access-control logic from scratch in every product or service. Permission debt grows when the organisation accepts local shortcuts, then pays later through maintenance, inconsistency, and delayed delivery. The practitioner conclusion is that repeated custom authorization builds are a hidden governance cost, not just an engineering preference.

From our research:

• 79% of organisations have experienced secrets leaks, with 77% of these incidents resulting in tangible damage, according to the Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which shows how quickly identity governance breaks down when ownership is fragmented.
• For the broader control picture, read NIST Cybersecurity Framework 2.0 alongside the Ultimate Guide to NHIs to align governance, protection, and recovery expectations.

What this signals

Permission debt: repeated in-house authorization builds create a hidden governance liability because the organisation keeps paying to rediscover the same access model in different products. That pattern slows delivery and makes policy review harder, especially when audit evidence and service boundaries are inconsistent.

With 97% of NHIs carrying excessive privileges, according to the Ultimate Guide to NHIs, the broader lesson is that permission design mistakes do not stay isolated in human IAM. They spill into service accounts, automation, and platform access unless the control model is centralised and reviewed end to end.

For practitioners

• Map authorization to shared platform services Centralize policy decisions so application teams do not rebuild roles, conditions, and enforcement logic in every service. Keep the policy model separate from product code and define who owns changes, reviews, and exceptions.
• Test role models against real business variation Validate whether a small role set can represent geography, department, customer tier, and workflow state without excessive manual overrides. If not, add policy conditions before the model hardens into technical debt.
• Make auditability a design requirement Require every access decision to produce reviewable evidence, including policy version, decision context, and enforcement point. This is essential when compliance teams need to explain why access was granted or denied.
• Quantify build cost against opportunity cost Compare internal engineering time, maintenance load, and delay to product delivery against the cost of adopting a dedicated authorization layer. Use a concrete estimate for team months, not a vague preference for control.

Key takeaways

• Authorization is a shared governance problem, not just a code exercise, once an application spans multiple services and real business variation.
• The scale of identity risk is amplified by poor visibility and excessive privilege, which makes permission mistakes expensive to correct later.
• Teams should decide early whether they need a platform authorization layer, because repeated custom builds create permission debt that slows delivery and weakens auditability.

Key terms

• Authorization policy: An authorization policy is the set of rules that determines whether a subject can perform an action on a resource under specific conditions. In enterprise systems, it becomes a control layer that must stay consistent across services, workflows, and audit requirements, not just a single application check.
• Permission debt: Permission debt is the accumulated cost of repeatedly rebuilding access rules, roles, and exceptions in different systems. It shows up as duplicated logic, manual overrides, weak auditability, and slower delivery because the organisation keeps paying to solve the same authorization problem again.
• Auditability: Auditability is the ability to reconstruct and explain access decisions after they happen. For identity governance, it means policy versioning, decision logging, and evidence capture are built into the control so compliance and security teams can verify why access was allowed or denied.

Deepen your knowledge

Authorization design, role modelling, and identity governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is trying to separate product logic from access control in the same way, it is worth exploring.

This post draws on content published by Cerbos: a talk on build-versus-buy decisions for roles and permissions in enterprise software. Read the original.