Build versus buy for roles and permissions in enterprise software

At a glance

What this is: This is a build-versus-buy analysis of roles and permissions in enterprise software, with the central finding that access logic becomes much harder to manage as real-world requirements expand beyond a small set of roles.

Why it matters: It matters because IAM, IGA, and product engineering teams often inherit roles and permissions as a hidden platform burden, and weak design choices here create audit, compliance, and operational drag across human and machine access patterns.

Context

Roles and permissions are the rules that decide who can do what inside an application. In B2B software, that problem stops being simple as soon as multiple users, departments, regions, and workflows have to share the same system without creating overbroad access.

The core governance gap is that teams often treat access control as a small library problem when it is really an application-wide design issue. Once audit logs, microservices, and compliance requirements enter the picture, the decision becomes part of product architecture, not just a coding task.

Cerbos uses that pattern to argue that many teams are rebuilding the same non-core capability repeatedly. The article is about enterprise application access control, but the implications reach directly into IAM, IGA, and software platform strategy.

Key questions

Q: When should teams build roles and permissions in-house versus buy them?

A: Teams should build in-house only when access logic is genuinely core to the product and they can sustain the governance, testing, and audit burden over time. If the capability mainly supports enterprise workflow, compliance evidence, and multi-service consistency, buying or adopting a specialised control layer usually reduces long-term maintenance debt.

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: What breaks when API permissions are managed separately for every service?

A: When permissions are managed separately for every service, identity, authorisation, and revocation evidence fragment across tools and teams. That makes it difficult to answer basic audit questions and easy for access to drift over time. The control breaks at the governance layer because no single model can explain the full set of permissions in use.

Q: How should security teams evaluate whether a permission system is worth maintaining?

A: Evaluate whether the system can survive growth, compliance demands, and repeated product changes without creating hidden engineering debt. If it needs constant rewrites, duplicate rules, or manual reconciliation across services, the maintenance burden is already overtaking the original feature value.

Technical breakdown

Why roles and permissions expand beyond simple user tiers

Role design usually begins with a small set of assumptions: admin, editor, viewer, and maybe a few exceptions. That works until business workflows depend on geography, department, reporting line, product line, or customer segment. At that point, the permission model is no longer a lookup table. It becomes an authorization system that must express context, support change over time, and remain understandable to developers and auditors. In B2B environments, the difficult part is not granting access once. It is preserving coherent decisions as the organisation grows and the application’s data model becomes more granular.

Practical implication: design authorization as a governed product capability, not a one-off code helper.

Why microservices make in-house permission logic fragile

When multiple services each enforce access decisions separately, the risk is not only duplication. The real failure is policy drift, where the same business rule is implemented differently across services, languages, and deployment cycles. Even a simple library does not solve synchronisation, auditability, or consistent change control. In practice, permission logic needs a shared source of truth or a well-governed policy layer, otherwise every new service reintroduces inconsistency. That is why access control work scales poorly when it remains embedded inside each application boundary.

Practical implication: centralise policy decisions enough to prevent per-service authorization drift.

Why audit logs and compliance turn permissions into lifecycle governance

Access control is not complete when a user can perform the right action. It also has to support evidence, traceability, and review. Audit logs, approval history, and revocation handling are what turn authorization from a runtime decision into a governable control. Once GDPR, CCPA, or sector-specific obligations are in scope, teams need to show not just that access existed, but why it existed and how it changed. That shifts roles and permissions from feature logic into lifecycle governance, which is why underbuilding them creates hidden operational debt.

Practical implication: include auditability and access lifecycle evidence in the initial permission architecture.

NHI Mgmt Group analysis

Roles and permissions are now an application governance layer, not a feature. The article shows that once enterprise software has multiple user groups, services, and compliance obligations, access control stops being a narrow engineering task. It becomes part of the product’s governance model, with direct consequences for auditability, change management, and enterprise trust. Practitioners should treat authorization as a platform decision with lifecycle impact, not as a helper function bolted onto the codebase.

Build-versus-buy mistakes in authorization usually come from underestimating scale, not misunderstanding concepts. Teams rarely fail because they do not know what a role is. They fail because real-world access models need exceptions, delegation, service boundaries, and logging that the original design did not anticipate. The practical lesson is that the first version of a permissions system is usually the cheapest part of its total cost.

Identity blast radius is the right lens for enterprise permissions work. When permissions logic is duplicated across services, the damage from a single modelling mistake spreads across applications, audits, and customer-facing workflows. That is why the issue is not just development speed, but how far a flawed entitlement model can travel once it is embedded in production. Practitioners should measure authorization design by the size of the blast radius it creates when it changes.

Open-source infrastructure can reduce repeated reinvention, but it does not remove governance responsibility. The article’s build-versus-buy argument is strongest where teams are rebuilding the same non-core control repeatedly. Even then, buyers still need to govern policy ownership, evidence quality, and service-wide consistency. The decision is less about whether to own code and more about whether the organisation is prepared to own the resulting control surface.

Permission models must be designed for change, not just correctness at launch. A system that works for ten users and three roles can fail when it meets departments, countries, and partial exceptions. That is the real warning here: access control architecture that ignores growth will create future refactoring pressure in exactly the place enterprise software can least afford it. Practitioners should optimise for evolvability as much as for initial correctness.

What this signals

Authorization becomes a governance problem once software serves real enterprises. The deeper lesson is that permission logic must survive organisational complexity, not just pass a demo. Teams that postpone this decision usually discover that access rules, audit evidence, and service coordination all become intertwined after launch.

Build-versus-buy decisions should be measured by control surface growth. If a permissions model will spread across microservices, audit workflows, and regulated use cases, the hidden cost is not the first implementation but every future change to that model. That is where platform thinking matters more than short-term coding speed.

For practitioners

• Define authorization as a shared product control Treat roles and permissions as a cross-service capability with clear ownership, not a local implementation detail inside each application.
• Model for real organisational complexity Test the access model against departments, regions, exceptions, and approval chains before assuming a small role set will hold.
• Build auditability into the permission layer Require traceable decisions, change history, and revocation evidence wherever access rules affect regulated or customer-sensitive workflows.
• Compare build cost against ongoing governance cost Assess whether internal development will keep absorbing engineering time that could be directed at the core product and customer value.

Key takeaways

• Roles and permissions in B2B software become hard to manage once the application has to reflect how real organisations work.
• The main risk is not only engineering effort, but the governance debt created when access logic is copied across services and workflows.
• Teams should judge build-versus-buy choices by how much ongoing audit, maintenance, and policy drift the control will create.

Key terms

• Authorization: Authorization is the decision about what an authenticated identity is allowed to do. In NHI and IAM practice, it covers scope, duration, and allowable actions, and it is the layer that most directly controls blast radius when access is active.
• Role Explosion: Role explosion happens when a shared authorization model accumulates too many narrowly tailored roles, often because every customer or team request becomes a permanent global role. The result is a harder-to-understand access catalogue, broader blast radius, and weaker governance over who can do what.
• Policy Drift Detection: Policy drift detection is the process of identifying when an access policy no longer matches the intended rule or the current business context. It helps teams catch unauthorized changes, stale permissions, and exceptions that have quietly become the new normal, so governance stays aligned with actual identity and app usage.
• Auditability: Auditability is the ability to reconstruct who or what acted, what permissions were used, and what data or tools were touched. For AI and NHI governance, it is the minimum evidence needed to investigate incidents, validate controls, and prove that autonomous actions stayed within approved scope.

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.