Notifications
Clear all
Topic starter
10/06/2026 11:57 pm
TL;DR: Static roles and allow lists break down when access decisions happen in dynamic production systems, leaving teams unable to prove what was enforced or why, according to Cerbos. The real issue is not identity proofing but decision-time observability and policy evaluation at runtime.
NHIMG editorial — based on content published by Cerbos: Static authorization and why it fails at runtime
Questions worth separating out
Q: What breaks when authorization is treated as a static configuration?
A: Static authorization breaks when the conditions that justified access at setup time no longer match the situation at decision time.
Q: When should organisations re-evaluate access instead of relying on long-lived entitlements?
A: Organisations should re-evaluate access whenever the business context changes, not just on a fixed calendar.
Q: How do security teams know whether authorization is actually working?
A: They need evidence that shows what was evaluated, which inputs were used, and why the request was allowed or denied.
Practitioner guidance
- Map every access decision path Inventory where authorization is enforced across applications, gateways, data services, and exception workflows so you can see where policy is duplicated or silently overridden.
- Add runtime context to policy evaluation Require access decisions to consider current identity state, resource state, request context, and business conditions instead of relying on static roles alone.
- Instrument decision logs for audit replay Record the policy version, evaluated inputs, and final outcome for each sensitive request so security and compliance teams can reconstruct enforcement after an incident.
What's in the full article
Cerbos' full guide covers the operational detail this post intentionally leaves for the source:
- A structured approach to externalized authorization design for teams replacing scattered checks
- Practical guidance on decision logging, replayability, and audit evidence for sensitive access flows
- Implementation detail on where policy evaluation belongs in application and API architectures
- A structured approach to moving from static roles to runtime authorization without breaking existing services
👉 Read Cerbos' analysis of why static authorization fails at runtime →
Authorization at decision time: where static access models break?
Explore further
12/06/2026 6:24 am
Static authorization is a governance assumption, not a control strategy. The article exposes a central premise that access decisions can be safely precomputed and reused. That assumption was designed for stable systems with predictable conditions. It fails when production context changes continuously, because the decision at the moment of access is no longer the same decision that was made at provisioning time. Practitioners should treat this as a broken operating model, not a tuning problem.
A few things that frame the scale:
- Organisations maintain an average of 6 distinct secrets manager instances, creating fragmentation that undermines centralised control.
- 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: Who is accountable when access is allowed by code, gateway, or local exception?
A: Accountability should rest with the team that owns the authoritative policy and the evidence of enforcement, not with whichever system happened to make the final check. Fragmented authorization creates shared ambiguity, so governance needs one clear decision authority and one accountable owner for policy changes.
👉 Read our full editorial: Static authorization fails at runtime, not at design time
