Notifications
Clear all
Topic starter
09/06/2026 11:04 pm
TL;DR: Enterprise teams still spend months rebuilding roles, permissions, audit trails, and multi-service coordination in software that is not core to their business, while complex access patterns and compliance demands make simple in-house models break down, according to Cerbos. The practical issue is not whether access control is needed, but whether teams can afford to keep rediscovering the same governance and engineering debt.
NHIMG editorial — based on content published by Cerbos: a talk on build-versus-buy decisions for roles and permissions in enterprise software
By the numbers:
- Stripe has a recent survey that says 42 percent of developer time is actually spent in tech debt and maintenance.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- Map authorization to shared platform services Centralize policy decisions so application teams do not rebuild roles, conditions, and enforcement logic in every service.
- 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.
- Make auditability a design requirement Require every access decision to produce reviewable evidence, including policy version, decision context, and enforcement point.
What's in the full article
Cerbos' full talk covers the operational detail this post intentionally leaves for the source:
- The full build-versus-buy walkthrough for enterprise roles and permissions.
- The concrete examples behind the three implementation mistakes that teams repeatedly make.
- The open-source implementation context for teams that want to evaluate the approach in practice.
- The team-time estimate that Cerbos uses to illustrate the maintenance cost of building in-house.
👉 Read Cerbos' talk on build versus buy decisions for roles and permissions →
Roles and permissions in B2B apps: what teams should build vs buy?
Explore further
10/06/2026 1:16 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Build versus buy for roles and permissions in enterprise software
