Notifications
Clear all
Topic starter
10/06/2026 11:17 pm
TL;DR: Externalized authorization can cover legacy applications without code changes by placing a gateway in front of them, centralising policy in Cerbos Synapse, and combining OAuth2/OIDC authentication with route-level and context-aware decisions, according to Cerbos. The hard problem is not policy design but extending governance to systems that cannot be rewritten, where audit gaps and inconsistent controls still dominate.
NHIMG editorial — based on content published by Cerbos: Externalized authorization for legacy applications
Questions worth separating out
Q: How should teams extend centralized authorization to legacy applications they cannot change?
A: Teams should place the legacy application behind a gateway that authenticates the user, calls a policy decision point, and enforces allow or deny before the request reaches the app.
Q: Why do legacy applications create a bigger governance problem than modern services?
A: Legacy applications often sit outside modern identity controls because they cannot easily integrate an SDK or fine-grained policy engine.
Q: What breaks when teams try to rely on application-local authorization in old systems?
A: Application-local authorization fails when the original logic is outdated, incomplete, or impossible to modify.
Practitioner guidance
- Place legacy apps behind a gateway policy decision point Front unmodifiable applications with a reverse proxy that authenticates users, calls a policy engine on every request, and blocks unauthorized traffic before the app is reached.
- Start with route-level authorization rules Map legacy URLs and HTTP methods to the smallest practical set of roles, then separate dashboard, employee, payroll, and admin paths into distinct policy conditions.
- Attach external trust signals to policy decisions Pull device posture, risk score, HR status, and approved access context into the decision flow so static roles are no longer the only input.
What's in the full article
Cerbos's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step gateway deployment patterns for legacy applications that cannot accept an SDK
- Concrete policy examples for route-based allow and deny logic across payroll, admin, and employee paths
- Context extension examples showing how device posture, HR state, and risk signals feed authorization decisions
- A phased rollout model from observe mode to enforce mode for mixed application estates
👉 Read Cerbos's analysis of externalized authorization for legacy applications →
Legacy application authorization: what externalized control changes?
Explore further
12/06/2026 5:11 am
Externalized authorization only works as a governance strategy when it reaches the systems that cannot be rewritten. Modern services can call a policy engine directly, but legacy estates still carry the largest concentration of inconsistent access control and audit gaps. The field problem is not policy sophistication, it is coverage across the full application mix. Practitioners should treat legacy enforcement as a core authorization boundary, not a side project.
A few things that frame the scale:
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
- Another Ultimate Guide to NHIs , Key Challenges and Risks finding shows that 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
A question worth separating out:
Q: How do contextual signals improve authorization for legacy environments?
A: Contextual signals let policy consider more than identity roles. Device health, managed status, geolocation, HR state, and approved tickets can all become inputs to the decision, so an authenticated user still needs to meet current trust conditions before access is allowed. That is especially useful for sensitive legacy systems that need stronger control without application rewrites.
👉 Read our full editorial: Externalized authorization for legacy apps needs gateway enforcement
