Legacy application authorization: what externalized control changes

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

View Full Forum →  |  NHI Foundation Course →