Notifications
Clear all
Topic starter
11/06/2026 11:58 pm
TL;DR: Engineering teams that define ownership, tenant boundaries, and role meaning in separate services create authorization drift, longer policy changes, and hidden breach risk, according to Cerbos. Centralized shared definitions turn authorization into a governed vocabulary, so security and platform teams can update core access logic once and propagate it consistently.
NHIMG editorial — based on content published by Cerbos: shared authorization definitions and policy reuse
By the numbers:
- 30.9% of organisations store long-term credentials directly in code.
- Only 5.7% of organisations have full visibility into their service accounts.
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
Questions worth separating out
Q: How should teams govern shared authorization definitions across multiple services?
A: Treat the shared definition layer as a governed asset owned by the platform or security team, and limit it to concepts that recur across services and encode real security boundaries.
Q: Why do inconsistent authorization definitions create security risk?
A: Inconsistent definitions create drift, which means the same business concept can grant different access in different services.
Q: What should security teams get wrong about centralized authorization vocabularies?
A: The main mistake is centralizing everything.
Practitioner guidance
- Define a canonical access vocabulary Identify the small set of access concepts that recur across services, such as owner, tenant boundary, and team membership, then make one team accountable for each definition.
- Version shared definitions before changing semantics Introduce new definitions alongside deprecated ones, migrate consuming services gradually, and remove old logic only after adoption is complete.
- Test definitions against real principal and resource cases Run CI tests that cover representative users, resources, and actions so changes to shared logic fail fast before production rollout.
What's in the full article
Cerbos's full blog post covers the operational detail this post intentionally leaves for the source:
- Concrete examples of shared authorization variables for ownership, team membership, and tenant boundaries.
- Implementation patterns for hierarchical, domain-based, and compliance-driven authorization vocabularies.
- Testing approaches for validating shared definitions across consuming services in CI.
- Versioning approaches for changing authorization meaning without breaking existing policies.
👉 Read Cerbos's full post on shared authorization definitions and policy reuse →
Shared authorization vocabularies: what IAM teams need to know?
Explore further
12/06/2026 8:54 am
Shared authorization vocabularies are a governance control, not a convenience layer. When each team defines ownership, membership, or tenant boundaries differently, the organisation loses the ability to reason consistently about access. The result is not just developer friction, but policy ambiguity that weakens auditability and change control. Practitioners should treat the vocabulary itself as a governed asset.
A few things that frame the scale:
- 30.9% of organisations store long-term credentials directly in code, according to Ultimate Guide to NHIs.
- 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
A question worth separating out:
Q: How do teams know if shared authorization definitions are working?
A: Look for high reuse of the shared concepts, shorter turnaround for policy changes, and fewer authorization-related incidents. If teams keep building custom logic, the vocabulary is either too abstract or too specific. If the platform team can update one definition and propagate the change safely, the model is doing its job.
👉 Read our full editorial: Shared authorization definitions are becoming an IAM control plane
