Legacy app authorization gaps: what IAM teams can do now

TL;DR: Legacy systems often retain weak or inconsistent authorization because teams cannot safely modify them, leaving audit gaps, local accounts, and unchecked access paths in place, according to Cerbos. The practical shift is moving governance to a gateway layer so identity, policy, and audit coverage can extend to applications that cannot be rewritten.

NHIMG editorial — based on content published by Cerbos: externalized authorization for legacy applications without code changes

By the numbers:

• The Verizon 2025 DBIR found credential abuse accounted for 22% of all confirmed breaches.

Questions worth separating out

Q: How should security teams add authorization to legacy applications without changing code?

A: Security teams should place authorization at the request boundary, usually through a gateway or reverse proxy that evaluates policy before the application sees traffic.

Q: Why do legacy applications create a governance gap for IAM teams?

A: Legacy applications often keep authorization logic, local accounts, and audit trails inside the application itself, which means central IAM cannot consistently enforce policy or prove access removal.

Q: What breaks when JML does not reach legacy application access?

A: When JML stops at the directory or IdP, users can keep local accounts and embedded permissions inside the application long after they should lose access.

Practitioner guidance

• Map legacy authorization boundaries first Inventory which applications still make internal authorization decisions, which rely on local accounts, and which routes have no central policy coverage.
• Run legacy apps in observe mode before denying traffic Use a gateway policy layer to log requests, roles, routes, and device context without blocking traffic until you understand real usage.
• Extend JML to the application boundary Connect role changes, terminations, and access reviews to the proxy or policy layer so access changes take effect on the next request even when the application cannot be modified.

What's in the full article

Cerbos' full blog post covers the operational detail this post intentionally leaves for the source:

• Gateway deployment patterns for wrapping legacy payroll and business-critical applications without modifying code
• Step-by-step examples of policy decisions that combine identity, device posture, and context at request time
• Implementation details for observe mode, including how to turn request logs into enforceable policy
• The practical mechanics of using a reverse proxy with an identity provider and authorization engine

👉 Read Cerbos' analysis of gateway-level authorization for legacy applications →

Legacy app authorization gaps: what IAM teams can do now?

Explore further

View Full Forum →  |  NHI Foundation Course →