Legacy application authorization governance without application rewrites

At a glance

What this is: This is an analysis of how externalized authorization can bring legacy applications under centralized governance without changing application code.

Why it matters: It matters because legacy systems often sit outside modern IAM and JML controls, which leaves high-value data exposed and audit evidence incomplete across NHI, autonomous, and human access programmes.

By the numbers:

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

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

Context

Legacy applications create an identity governance problem when authorization is trapped inside code that teams no longer control. In practice, that means access rules, audit trails, and lifecycle enforcement drift apart across payroll, vendor portals, and custom internal tools. The primary issue is not a lack of security intent, but a governance model that cannot reach the systems holding the most sensitive data.

For IAM teams, this is the same familiar failure mode seen in identity dark matter: local accounts, undocumented access paths, and fragmented authorization logic that central policy cannot touch. The post’s core claim is that governance has to move closer to the request path if the application itself cannot be changed.

When legacy estates are left outside centralized policy, recertification and offboarding become partial exercises. The result is a control environment where evidence is reconstructed after the fact instead of being generated as part of normal access decisions.

Key questions

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. This lets identity, device, and risk signals control access without refactoring old code. The key is to make the boundary the enforcement point so the legacy app no longer owns the decision.

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. The gap appears when the identity programme can change roles in the IdP but cannot reach the real access path. That is why governance looks complete on paper but fails in practice.

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. That creates privilege persistence, weak audit evidence, and manual cleanup after changes or terminations. The governance failure is not the lifecycle process itself, but its inability to reach the application boundary.

Q: How can teams tell whether legacy authorization visibility is enough?

A: Visibility is enough only if it is producing usable evidence about routes, accounts, and access patterns that can be turned into policy. If the team can see who is using admin endpoints but cannot enforce anything from that data, the programme has observability, not control. The practical test is whether the findings change access decisions within the same control plane.

Technical breakdown

Externalized authorization at the gateway

Externalized authorization moves the decision point out of application code and into a policy layer that sits in front of the application. The application still receives only allowed requests, but the policy engine can evaluate identity, context, and route-level conditions before access is granted. This pattern is especially useful where legacy code cannot be refactored, because governance becomes a runtime service rather than a code change project. It also creates a common control surface across heterogeneous applications, so one policy model can cover systems with very different internal logic.

Practical implication: put the authorization decision where legacy code cannot block it, at the request boundary.

Observe mode and authorization visibility

Observe mode is the transitional phase where requests are evaluated and logged but not denied. That turns every access attempt into an authorization event, which exposes who accessed what, from where, and under which conditions. For legacy systems, this matters because teams usually lack reliable knowledge of routes, sensitive endpoints, and abnormal access patterns. Visibility is not the same as control, but it is often the first usable governance artifact when the application cannot emit meaningful audit data itself.

Practical implication: map real usage before enforcing denials so policy is grounded in observed access patterns.

Context-aware policy beyond role checks

Role-based checks are too coarse for many legacy environments because they ignore device posture, risk signals, and timing conditions. A context-aware policy layer can combine identity information from the IdP with device, HR, or geolocation data to make a runtime decision on each request. That lets organisations distinguish between ordinary access and high-risk access without changing the legacy application. The architecture extends Zero Trust principles to systems that were previously outside continuous verification.

Practical implication: use contextual signals to narrow access without forcing legacy applications to understand every risk input.

Threat narrative

Attacker objective: The attacker or insider objective is to reach sensitive legacy data and privileged routes in a system that central IAM cannot fully govern.

1. Entry begins with an application that already exists in the estate, often a payroll, vendor, or internal business-critical system whose authorization logic is inconsistent or minimal.
2. Credential access and abuse persist because local accounts, undocumented routes, and built-in permissions are hard to govern from the identity layer, leaving standing access in place.
3. Impact accumulates through weak auditability and incomplete lifecycle enforcement, so terminated or changed users may retain access until someone manually intervenes.

Breaches seen in the wild

• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Legacy authorization failures are governance failures, not code-quality failures. The hardest systems to govern are often the ones that cannot be modified, which means the real problem is control reach, not technical understanding. Once authorization is embedded in old application code, security teams lose the ability to apply consistent policy, audit, and lifecycle enforcement. The practitioner conclusion is that governance must be re-anchored at the boundary, not left trapped in the application.

Identity dark matter in legacy estates creates a blind spot that normal IAM programme metrics miss. Local accounts, undocumented routes, and partial SSO integration mean the identity plane can look healthy while critical applications remain effectively unmanaged. That is why recertification and JML checks often fail to cover the highest-risk access. The practitioner conclusion is that visibility over access paths is a prerequisite to any credible governance claim.

Runtime authorization is the missing control plane for systems that cannot be rewritten. Externalized policy changes the operational model from code changes to request-time decisions, which is a better fit for old applications with long support tails. This is especially relevant when access must reflect device posture, risk status, or job changes in real time. The practitioner conclusion is that legacy modernization should be framed as control relocation, not application replacement.

Legacy JML breaks when deprovisioning stops at the IdP and never reaches the application boundary. The identity lifecycle was designed for systems that can actually consume central role changes, but many old applications still maintain their own local accounts and entitlements. That assumption fails when governance cannot trigger access removal inside the application itself. The implication is that teams must rethink where lifecycle authority actually terminates.

Authorization visibility and authorization control are not the same control outcome. Observability can surface route-level access patterns before enforcement begins, but it does not by itself reduce exposure. The field needs to treat visibility as evidence generation for governance, not as a substitute for policy enforcement. The practitioner conclusion is to convert observed legacy access into explicit policy decisions quickly, before the visibility project becomes a permanent reporting layer.

From our research:

• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, according to The 2024 ESG Report: Managing Non-Human Identities.
• A quarter of organisations in that report encountered multiple successful attacks from compromised non-human identities, which shows how repeated exposure compounds when governance is partial.
• For a broader control perspective, see NHI Lifecycle Management Guide for how provisioning, rotation, and offboarding close the access paths that linger in legacy estates.

What this signals

Legacy authorization modernisation is becoming a control-plane issue, not an application-modernisation issue. The organisations that keep treating these systems as rewrite candidates will continue to leave sensitive routes outside policy, which is exactly where audit findings and access drift accumulate. The practical signal is that teams should measure control reach across the estate, not just identity platform coverage.

Authorization visibility should be treated as a prerequisite for lifecycle governance in old systems. If teams cannot see which routes are actually used, they cannot credibly certify access or prove offboarding. The right programme response is to use observed access data to narrow the highest-risk paths first, then formalise those policies in the boundary layer.

The governance model that works for modern services can be extended to legacy apps if the policy layer becomes the control point. That is where the access decision, audit record, and context all converge. For teams aligning to broader identity governance, the useful reference point is the NIST Cybersecurity Framework 2.0, especially when mapping control ownership across identity, detect, and recover functions.

For practitioners

• 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. Treat the boundary where the IdP stops as the first remediation target, because that is where governance usually breaks down.
• 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. Build the first deny rules from observed admin routes, unmanaged devices, and endpoints that do not match known business processes.
• 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. This is the practical way to reduce local-account drift in long-lived systems.
• Add context to legacy authorization decisions Use device posture, risk score, and time-based conditions for high-value routes such as payroll or financial reporting. Keep the application unchanged and let the policy engine consume the context needed to narrow access.

Key takeaways

• Legacy applications become security liabilities when authorization remains trapped in code that no one can safely change.
• The control problem is visible in incomplete audit trails, local accounts, and lifecycle gaps that central IAM cannot reach.
• Gateway-level externalized authorization gives teams a practical way to extend policy, context, and evidence to systems that cannot be rewritten.

Key terms

• Externalized Authorization: A model where access decisions are made outside the application, usually in a dedicated policy layer or gateway. This lets teams govern old and new systems consistently without rewriting business logic, while keeping the application focused on serving requests rather than deciding who should be allowed in.
• Observe Mode: A deployment state in which authorization decisions are evaluated and logged but not enforced. It is useful for legacy systems because it reveals actual access patterns, routes, and risk signals before teams commit to deny rules. The value is in evidence generation, not in reducing exposure by itself.
• Identity Dark Matter: Hidden or poorly governed identity activity that sits outside central visibility, such as local accounts, undocumented access paths, or embedded permissions in legacy systems. It matters because IAM may appear complete while the most sensitive systems still operate with unmanaged access and weak auditability.
• Gateway-Level Enforcement: Policy enforcement that happens at the network or request boundary rather than inside the application. For legacy estates, this is often the only practical way to add context-aware authorization, because the application cannot safely be changed but still must be governed.

Deepen your knowledge

Legacy authorization governance and lifecycle enforcement are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are dealing with systems that cannot be rewritten but still need policy control, it is worth exploring.

This post draws on content published by Cerbos: externalized authorization for legacy applications without code changes. Read the original.