How should security teams enforce phishing-resistant access on legacy web apps without changing source code?

Put a reverse proxy or access gateway in front of the application and make it the enforcement point for authentication and authorization. Use WebAuthn or passkeys for the login ceremony, then pass only an authenticated session to the app. This approach is useful when the app cannot be modified, or when teams need to add stronger access controls quickly across multiple deployments.

Why Phishing-Resistant Enforcement Belongs Outside the Legacy App

When a legacy web app cannot be changed, the practical answer is to move the trust decision in front of it. A proxy or access gateway can enforce modern authentication, including phishing-resistant factors, without waiting for a code rewrite. That matters because the app itself usually still trusts a session cookie, basic form login, or other weak ceremony that attackers can target directly. Security teams should treat the gateway as the policy boundary and the app as a downstream consumer of an already-verified session. Modern phishing-resistant methods are designed to bind the login ceremony to the legitimate origin, which is why they are much harder to replay through credential theft or adversary-in-the-middle attacks than password-only flows. The OWASP Non-Human Identity Top 10 is not the right framework for this question, but the same architectural lesson applies: move enforcement to the layer you can actually control. In practice, many teams discover that the app was never the real control point only after an exposed login path has already been abused.

How It Works in Practice

The gateway pattern works by separating authentication from application compatibility. The user authenticates to the proxy with WebAuthn or passkeys, the proxy validates that ceremony, and the proxy then creates the session that the legacy app consumes. The app does not need to understand passkeys; it only needs to receive a trusted identity assertion, headers, or a session token from a component it trusts. This is why the design is effective for older systems that cannot support modern identity protocols natively.

Implementation quality depends on making the proxy the only accepted entry path. If the app remains reachable directly, attackers will bypass the phishing-resistant layer and target the old login route. Teams should therefore pair the gateway with network restrictions, origin checks, and session controls that prevent backdoor access. The most important verification is that the gateway, not the browser or the app, is the source of truth for authentication state. NHI practitioners often apply the same discipline when fronting brittle services with a control layer, because the control point matters more than the application’s internal logic. The Ultimate Guide to NHIs is useful here because it shows how much exposure comes from weak lifecycle and trust boundaries, even when the downstream system looks stable.

Operationally, teams should define what the proxy is allowed to pass through and what it must strip. Identity headers, group claims, and session context should be minimal, signed where possible, and protected from tampering. If the app still performs its own password prompt, the result is usually a confusing hybrid state that weakens the migration rather than strengthening it. The strongest deployments also time-bound the downstream session so the phishing-resistant check is not treated as a one-time event forever.

Place the gateway in front of every reachable path to the app, not only the primary URL.
Disable or tightly restrict direct access to the legacy login endpoint.
Pass only the minimum authenticated identity context the app needs.
Log gateway decisions, session issuance, and failed assertions for audit and incident response.

These controls tend to break down when a legacy app has multiple hidden entry points, because one unprotected path is enough to undo the phishing-resistant boundary.

Common Variations and Edge Cases

Tighter enforcement often increases operational complexity, so teams have to balance user experience, application brittleness, and rollback risk. Some legacy apps cannot accept modern headers cleanly, while others break if the upstream identity format changes. In those cases, best practice is evolving toward the least invasive trust translation that still preserves the strong login ceremony, rather than forcing a perfect end-state on day one.

Another common edge case is shared or service-style access. Human phishing resistance does not solve machine access, so teams should not confuse passkeys for users with safe handling of automated accounts, API keys, or admin backdoors. Where an app depends on those paths, the gateway should cover human access first while a separate control plan addresses non-human credentials and administrative exceptions. The same caution applies to step-up authentication: if a highly sensitive function can be reached through a weak legacy path, the gateway must still enforce the stronger ceremony at that boundary. Current guidance suggests that the cleanest deployments are the ones where the legacy app never learns the difference between password-era and phishing-resistant users; it only sees an authenticated request from a trusted enforcement point.

Risk and Threat Considerations

The main risk is false confidence. If the legacy app still exposes a direct login route, or if the gateway can be bypassed, attackers can continue to target passwords, session theft, or replay attacks and ignore the stronger ceremony entirely. This is especially important in mixed environments where one weak path undermines a stronger front door.

Failure mechanism: The control fails when the proxy is treated as advisory rather than mandatory. Common mechanisms include directly reachable origin servers, stale alternate domains, weak session handoff, or forged trust headers that let a request impersonate an already-authenticated user.

Impact: Users believe phishing-resistant access is in place while the application still accepts weaker authentication. The result is exposure to account takeover, lateral movement through trusted sessions, and control gaps that are hard to detect because the visible login experience looks secure.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK address the attack and risk surface, while CIS Controls v8, NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST SP 800-63 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	6 — Access Control Management	Enforce strong access paths and remove bypassable legacy login routes.
Recommendation — Restrict direct app access and funnel users through the enforced access gateway.
NIST CSF 2.0	PR.AA — Identity Management, Authentication, and Access Control	Central identity and phishing-resistant authentication control at the gateway boundary.
Recommendation — Implement phishing-resistant authentication at the trusted access boundary.
NIST Zero Trust (SP 800-207)	5 — Policy Engine, Policy Administrator, and Policy Enforcement Point	The gateway acts as the enforcement point for legacy application access.
Recommendation — Place policy enforcement in front of the app and allow only verified sessions through.
NIST SP 800-63	3 — Digital Identity Guidelines	WebAuthn/passkeys are the phishing-resistant authenticator family this question relies on.
Recommendation — Use phishing-resistant authenticators and bind authentication to the intended origin.
MITRE ATT&CK	T1556 — Modify Authentication Process	Attackers often target weak or bypassable login paths around legacy apps.
Recommendation — Hunt for alternate authentication paths and harden them against tampering.

Practitioner Guidance

What to prioritise: Make the proxy the only enforced authentication path before you refine UX or claim full rollout. If any direct application route remains open, treat the deployment as partial protection, not phishing-resistant access.

What to verify: Confirm that the legacy app cannot be reached by a path that bypasses the gateway, and verify that downstream trust is established only through signed, minimally scoped session context. Also verify that emergency accounts and admin paths are not exempted without compensating controls.

Decision rule: If the app cannot be modified, prefer a hard enforcement boundary with a short-lived downstream session over a soft integration that still leaves password login available. If the app can only tolerate a partial rollout, constrain access by network and audience first, then expand gradually.

Practitioner takeaway: The real objective is not to modernise the app immediately, but to ensure that every meaningful user session is born through a phishing-resistant control point that attackers cannot sidestep.