Only when there is a clearly documented operational need and the exception is tightly bounded. If the feature exists mainly for convenience, it should be disabled because every bypass path expands the number of ways an attacker can satisfy the gateway’s trust logic without proving identity normally.
Why VPN Override Features Should Be the Exception, Not the Default
Authentication override features are not inherently unsafe, but they change the trust model of the gateway. Once an override exists, the device can accept access through a non-standard path, so the question is whether that bypass is genuinely necessary and tightly controlled, or whether it simply weakens the assurance that a normal sign-in is meant to provide.
When organisations leave override paths enabled for convenience, they usually create a broader and less visible entry point than the primary authentication flow. That matters because remote access devices are already high-value targets, and bypass logic often survives longer than the business case that justified it.
In practice, this is where remote access hardening and identity assurance meet. A sensible baseline is the one described in Remote Access Identity Guide: keep every entry point aligned to the same identity standard unless there is a documented exception with a clear owner and expiry.
What Changes When the Gateway Accepts a Bypass Path?
An override feature does more than add a second login method. It creates an alternate control path that may be easier to reach, less monitored, or exempt from the same checks as the standard flow. If the override can be used to satisfy the gateway’s trust logic without proving identity normally, then it effectively becomes part of the authentication surface.
That surface can expand in several ways: help desk workflows may begin to depend on it, administrators may use it as a shortcut during incidents, and exceptions may quietly become normal operating practice. The more often the override is used, the harder it becomes to argue that it is exceptional.
There is a strong practical reason to align the gateway to phishing-resistant sign-in and tightly bounded exception handling. NIST’s identity guidance in NIST SP 800-63 Digital Identity Guidelines is relevant because the core issue is authentication assurance, not just convenience.
When Disabled Is the Safer Default
If the override exists mainly to make administration easier, to avoid fixing an upstream identity problem, or to preserve legacy access patterns, it should usually be turned off. Those are all signs that the feature is compensating for process weakness rather than satisfying a real operational requirement.
By contrast, a temporary, documented override can make sense for break-glass recovery, narrowly scoped maintenance, or a regulated continuity requirement. Even then, it should be time-limited, owner-approved, and observable, because the control weakness is not the existence of the exception itself, but the tendency for exceptions to outlive their original justification.
That principle is reinforced by the broader trust model in NIST SP 800-207 Zero Trust Architecture: access should be verified, bounded, and explicit, not assumed because a device sits at the edge of the network.
Risk and Threat Considerations
Override features on VPN gateways create a clear exposure point because attackers often target the path that is easiest to abuse, not the one the organisation considers primary. If an override weakens authentication, bypasses MFA, or permits emergency access without strong review, it can become the shortest route to remote access and lateral movement.
Failure mechanism: A bypass path can let an attacker satisfy the gateway’s trust decision through an exception, stolen approval, or legacy rule instead of normal identity proofing.
Impact: That can reduce detection, increase the blast radius of a compromised account, and make a remote access appliance a pivot point for broader intrusion.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, 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 |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | VPN override bypasses affect how users prove identity to access a gateway. |
| IA-5 — Authenticator Management | Override features can sidestep normal authenticator lifecycle and assurance controls. | |
| AC-6 — Least Privilege | An always-enabled override grants broader access than the standard trust path needs. | |
| Recommendation — Require normal user authentication and limit any bypass to tightly approved break-glass use. Manage authenticators so exceptions do not weaken issuance, rotation, or revocation discipline. Restrict override use to the smallest necessary scope and duration. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | The question is about whether a gateway should trust a bypass path instead of verified access. |
| Recommendation — Verify every access path explicitly and remove standing exceptions that weaken trust boundaries. | ||
| NIST SP 800-63 | Digital Identity Guidelines | The issue is authentication assurance and exception handling for remote access sign-in. |
| Recommendation — Use phishing-resistant authentication and treat any bypass as a temporary exception with strong review. | ||
Practitioner Guidance
What to verify: Confirm that every override has a named business justification, a technical owner, an expiry date, and logging that distinguishes override use from standard authentication. If any of those elements are missing, treat the feature as an open control gap rather than a convenience feature.
Decision rule: If the gateway can operate securely without the override, disable it. If it cannot, restrict it to a break-glass process with strong approval, narrow scope, and post-use review.
What practitioners underestimate: The main risk is not only misuse during an incident, but the quiet normalisation of bypasses over time. A feature that is “there just in case” often becomes the path teams rely on when the primary control is inconvenient.
Practitioner takeaway: Keep override features disabled unless they are needed for a specific, controlled failure mode, because any standing bypass weakens the assurance boundary that remote access is supposed to enforce.
Related resources from NHI Mgmt Group
- When should organisations keep the legacy MFA method enabled alongside push authentication?
- Why is it crucial to adopt new authentication methods in MCP usage?
- How do organisations keep governance strong when they run a hybrid authentication model?
- Should organisations keep dynamic client registration enabled for older MCP clients?