Notifications
Clear all
Topic starter
09/06/2026 11:04 pm
TL;DR: Modern authorization is increasingly being externalised from application code into policy layers, with Cerbos arguing that this improves speed, consistency, and compliance while reducing permission logic buried in services, according to Cerbos. The governance question is no longer whether teams can enforce access checks, but whether they can manage policy lifecycle, visibility, and drift across environments.
NHIMG editorial — based on content published by Cerbos: the ShipTalk discussion on modern authorization and policy governance
By the numbers:
- Only 44% of organisations are currently using a dedicated secrets management system.
Questions worth separating out
Q: How should security teams centralise authorization without losing control?
A: Security teams should centralise authorization by separating policy from code, defining ownership for rule changes, and keeping exceptions visible in one approval path.
Q: Why do embedded authorization checks create governance problems?
A: Embedded checks create governance problems because each application can implement access rules differently, even when the business intent is the same.
Q: When should organisations move to externalized authorization?
A: Organisations should move to externalized authorization when permissions are being rebuilt repeatedly, when microservices multiply access logic, or when compliance review becomes difficult because policy is scattered.
Practitioner guidance
- Separate policy from application logic Move access decision logic into a centrally governed policy layer so the same rules can be reviewed, versioned, and reused across services without code duplication.
- Define clear policy ownership Assign authorship, approval, and exception handling for authorization policy before centralising it, so the shared control does not become a queue with no accountable owner.
- Map roles and attributes to real decisions Use roles for stable access patterns and attributes for contextual decisions such as ownership or environment, then validate that each rule is understandable to auditors and developers.
What's in the full article
Cerbos' full podcast discussion covers the operational detail this post intentionally leaves for the source:
- How the authorisation model is structured in application-layer deployments and where it sits relative to authentication
- Why Cerbos and OPA are positioned for different implementation patterns, including the practical trade-off between flexibility and simplicity
- How teams can prototype policy changes with the Cerbos Playground before applying them in production workflows
- What the AuthZEN standardisation effort means for central policy management across distributed systems
👉 Read Cerbos' ShipTalk discussion on modern authorization and policy governance →
Authorization in DevOps: what changes when policies move out of code?
Explore further
10/06/2026 1:17 am
Authorization is becoming a governance layer, not just an application feature. The central shift in this discussion is that access decisions are moving out of scattered code paths and into a managed policy surface. That matters because authorization logic is where identity intent becomes enforceable action, and unmanaged duplication across services creates drift that IAM teams cannot see cleanly. Practitioners should treat authorization policy as part of identity governance, not just software architecture.
A few things that frame the scale:
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
- A second finding from the same research shows that 1 in 4 organisations are already investing in dedicated NHI security capabilities, with an additional 60% planning to do so within the next twelve months.
A question worth separating out:
Q: What is the difference between authentication and authorization in practice?
A: Authentication proves who or what a subject is, while authorization determines what that subject can do after identity is established. In practice, teams often over-focus on authentication controls and leave authorization buried in code. That gap matters because access risk usually appears at the decision point, not the login screen.
👉 Read our full editorial: Modern authorization is shifting from code logic to policy governance
