TL;DR: Monolithic authz logic becomes harder to govern as systems grow, and modular schema design is now an operational requirement, not just a developer convenience, as composable schemas are now generally available in SpiceDB 1.51.1, giving teams a filesystem-aware way to split large authorization models into reusable files, improve compiler feedback, and make validation and navigation easier across complex schemas, according to Authzed.
NHIMG editorial — what this means for NHI practitioners
Questions worth separating out
Q: How should teams govern multi-file authorization schemas safely?
A: Teams should treat multi-file authorization as governed infrastructure.
Q: When does schema modularisation improve security rather than add complexity?
A: Schema modularisation improves security when it reduces duplication, clarifies ownership, and makes policy changes easier to review without weakening traceability.
Q: What do identity teams get wrong about reusable authorization patterns?
A: Teams often assume reuse automatically improves control.
Practitioner guidance
- Define schema ownership by file and fragment Assign named owners to each schema file, import, and partial so reviewers can trace responsibility before merge.
- Validate the full schema graph in CI Run multi-file validation on every change and block merges until imports resolve cleanly and referenced fragments compile.
- Standardise reusable authorization patterns Create a small library of approved schema fragments for common access patterns so teams reuse known structures instead of copying and modifying large policy blocks.
What's in the full announcement
Authzed's full blog post covers the operational detail this post intentionally leaves for the source:
- Exact CLI commands for validating and compiling multi-file SpiceDB schemas
- Editor workflow details for navigating definitions, caves, and partials across files
- The specific breaking changes introduced for import syntax and partial declarations
- Practical notes on why the SpiceDB playground does not yet support import syntax
👉 Read Authzed's post on composable schemas in SpiceDB 1.51.1 →
Composable schemas in SpiceDB 1.51.1: what it means for IAM teams?
Explore further
Composable authorization is a governance problem, not just an engineering refactor. Once access logic spans multiple files, the real issue becomes whether teams can still answer who changed what, why a rule exists, and how a dependency affects downstream access decisions. That is an identity governance question as much as a software design question. Practitioners should treat schema modularisation as a control boundary, not a coding preference.
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.
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
A question worth separating out:
Q: How do you know if a large authorization model is still manageable?
A: A manageable authorization model can be validated across files, understood by reviewers outside the original author group, and changed without breaking unrelated parts of the decision tree. If the team relies on tribal knowledge to explain imports, partials, or schema relationships, the model has outgrown safe operational control.
👉 Read our full editorial: Composable schemas in SpiceDB 1.51.1 change how authz scales