Notifications
Clear all
Topic starter
09/06/2026 11:28 pm
TL;DR: Authorization sprawl, not just app complexity, becomes the real governance problem once roles multiply and product changes accelerate, according to Cerbos. NTWRK says Cerbos helped replace scattered permission logic with centralized policies, cutting authorization checks to microseconds and supporting a rollout from admins and partners toward all users.
NHIMG editorial — based on content published by Cerbos: a case study on centralized access control at NTWRK
By the numbers:
- The engineering team consists of 32 people right now.
Questions worth separating out
Q: How should teams centralize authorization without slowing application delivery?
A: Teams should separate decision logic from application code, place it in one governed policy layer, and validate latency under production load.
Q: What breaks when authorization logic is scattered across multiple services?
A: Scattered authorization logic creates policy drift, missed edge cases, and inconsistent enforcement between teams.
Q: How do you know if policy-based authorization is actually working?
A: Look for a single source of truth for permission rules, clear audit logs for allow and deny decisions, and low latency under realistic traffic.
Practitioner guidance
- Map all authorization decision points Inventory where access checks are currently embedded in code, middleware, and service boundaries.
- Move policy logic into a single source of truth Centralize roles, attributes, and decision rules in one governed policy layer so changes are made once and evaluated consistently across the application.
- Test policy changes in isolation before rollout Use an isolated policy test workflow to validate allow and deny outcomes against real application scenarios before the rules reach production.
What's in the full article
Cerbos' full case study covers the operational detail this post intentionally leaves for the source:
- Step-by-step implementation notes for the sidecar authorization pattern in a live application stack
- Developer workflow details for testing policies in the Cerbos playground before production changes
- Operational examples of how NTWRK maps roles and attributes into policy decisions
- The practical trade-offs NTWRK evaluated when comparing centralised authorization with federated alternatives
👉 Read Cerbos' case study on centralized authorization at NTWRK →
Centralized authorization and policy sprawl: what IAM teams need to know?
Explore further
10/06/2026 1:47 am
Centralized authorization is a policy governance problem, not just an engineering convenience. NTWRK’s case shows what happens when permission decisions live in multiple places and each product change risks missing one of them. That is not a tooling issue alone. It is an access governance failure that turns business agility into policy drift, and practitioners should treat it as a control-plane design issue.
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.
- 43% of security professionals are concerned about AI systems learning and reproducing sensitive information patterns from codebases.
A question worth separating out:
Q: Who should own authorization policy decisions in a modern application stack?
A: Ownership should sit with a clearly defined governance function, but implementation must be shared with application teams so the rules reflect real business processes. The key is that no team should be able to change access behaviour invisibly or in isolation.
👉 Read our full editorial: Centralized authorization for NTWRK shows why policy sprawl breaks
