Separate authentication from authorization and document both layers. The gateway can establish the trusted identity for policy decisions while the application keeps its own login for local access, if required. That split is common in older systems, and governance should treat it as an interim control model rather than a clean SSO design.
How to handle a legacy app that still needs its own login
When a legacy application cannot be fully modernised, security teams should treat the app’s login as a local access control layer, not as the source of truth for enterprise identity. The stronger design is to let the gateway or front door establish who the user is, then let the application enforce its own local permissions only where it still must.
Why the split matters in older applications
Legacy systems often mix authentication and authorization because they were built before central identity platforms were common. That creates two separate questions: who the user is, and what the app will allow them to do. If those layers are blurred, teams lose clarity around trust, auditability, and where a control failure actually lives. A clean separation also makes it easier to govern access decisions without pretending the app has been redesigned.
In practice, the gateway can validate the trusted identity, apply coarse policy, and forward claims or assertions that the app can consume. The legacy app then keeps only the local login it still needs, ideally for tightly scoped use cases such as administrative access, fallback access, or session continuity. That approach is still a compromise, but it is more transparent than letting each layer invent its own version of identity.
What security teams should standardize around the split
The most important work is to define which layer owns which decision. Authentication should happen once in the front door when possible, while the application should only authorize local functions it truly owns. Teams should document where the trusted identity is established, what the app still checks locally, and how users are reauthenticated or stepped up when the legacy flow cannot be removed. For broader control design, the boundary should align with NIST Cybersecurity Framework 2.0 governance and access control expectations.
That documentation matters because legacy login paths are often temporary for years, not weeks. If the app continues to accept its own credentials, security teams should treat those credentials as an exception with an owner, expiry review, and explicit blast-radius understanding. Where the application still speaks directly to APIs or backend services, the authorization boundary should remain visible rather than hidden inside the login page. Related API control patterns are well captured in the OWASP API Security Top 10.
Risk and Threat Considerations
The main risk is false confidence. When a legacy app keeps its own login, teams may assume enterprise authentication automatically covers the whole session, while the app continues to make separate access decisions with stale, weak, or overbroad local accounts. That creates room for privilege creep, orphaned credentials, and inconsistent enforcement between the gateway and the application.
Failure mechanism: the front door proves identity, but the legacy app still trusts a second login path or stale local account model, so access can survive longer than the centralized control intended.
Impact: attackers or insiders may exploit the weaker layer to reach functions that the gateway policy would not have allowed, and defenders may struggle to prove which control failed when access is abused.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OC-01 — Organizational Context | Legacy login exceptions need clear ownership and context. |
| PR.AA-05 — Identity Management, Authentication, and Access Control | The question is about separating authentication from authorization. | |
| Recommendation — Define the legacy app's identity boundary and assign explicit ownership for the exception. Separate gateway authentication from application authorization and document the trust boundary. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Centralized user authentication is a core part of the split-login model. |
| Recommendation — Use a trusted front door to authenticate users before the legacy app applies local access rules. | ||
| OWASP ASVS | V6 — Authentication | Legacy apps with their own login still need explicit authentication control design. |
| Recommendation — Verify the remaining login flow is tightly scoped and does not duplicate enterprise authentication. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Mixed login layers can create inconsistent or bypassable authentication paths. |
| Recommendation — Check that no alternate login path weakens the authenticated session established at the gateway. | ||
Practitioner Guidance
What to verify: confirm that the gateway and the application do not each believe they are the primary authenticator. If both layers can independently let a user in, document which one is authoritative for policy and which one is only maintaining legacy local access.
Common mistake: treating the legacy login as harmless because it sits behind SSO. If the app still issues its own session, local passwords, or admin bypass paths, that mechanism needs the same inventory and review discipline as any other privileged access path. Where possible, align the exception handling with NIST AI Risk Management Framework style thinking about accountability, even though this is not an AI problem, because the governance pattern is the same: know where decisions are made and who owns them.
Practitioner takeaway: the goal is not to force a fake SSO story onto a legacy app, but to make the split control model explicit, bounded, and reviewable until the application can be redesigned or retired.
Related resources from NHI Mgmt Group
- How should security teams decide whether legacy PAM still fits cloud-native access needs?
- How should security teams handle legacy app access when older applications still need to connect to modern cloud identities?
- How should security teams prioritise NHI remediation in cloud environments?
- How should security teams govern non-human identities at scale?