Shared authorization vocabularies: what IAM teams need to know

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

View Full Forum →  |  NHI Foundation Course →