Why SAML MFA Fails When Other VPN Login Paths Remain

SAML MFA fails when other VPN login paths remain because an attacker only needs the weakest route to an account. A strong identity provider policy does nothing for a login that never reaches the identity provider. The exploited SonicWall flaw CVE-2026-19868 is the current example, with valid credentials for an alternate method getting past SAML controls. IT leaders should treat every extra login path as a risk with an owner, a reason and an expiry date, or remove it.

Why can SAML MFA be bypassed on a VPN?

SAML MFA depends on the VPN appliance sending each login to the identity provider and refusing anything that did not come back from it. If the appliance has another way to accept the same user, or fails to enforce the rule, the identity provider never gets involved.

That makes the appliance the real enforcement point. Conditional access policies, phishing-resistant factors and identity provider logging all sit behind a decision the appliance makes first. When you buy strong MFA and put it behind an edge device, your assurance can only be as strong as that device's enforcement.

The pattern keeps repeating

The CVE-2026-19868 SAML MFA bypass is a recent case of a familiar failure, and SonicWall's own history gives two earlier examples:

• CVE-2024-12802. Cybersecurity Dive, citing ReliaQuest, reported that this SSL-VPN MFA bypass was tied to how the appliance handled UPN and SAM account names with Active Directory. Exploitation began in February 2026. The 2025 firmware update did not remove the LDAP configuration behind the bypass, and ReliaQuest said Gen 6 devices needed six further manual steps.
• Migrated local passwords. SonicWall's 2025 SSLVPN notice described incidents, many of them involving Gen 6 to Gen 7 migrations, in which local user passwords carried over and were never reset.

The common thread is that a second route to the account outlived the decision to centralize authentication.

Why do extra login paths survive SSO projects?

Extra login paths survive because SSO rollouts are measured by how many users moved, and nobody is assigned to remove what the old method left behind. Local accounts and directory integrations keep working, so nothing breaks and no ticket gets raised.

There are usually sensible reasons at the start: a fallback for the identity provider, a vendor who needs temporary access, or a migration window. The trouble is that each one lacks an end date. Three years later, nobody remembers whether the LDAP integration still serves a purpose, and removing it feels riskier than leaving it alone.

What should the rule be for every login path?

Each path into a remote access system should either enforce the same MFA policy as SSO or have a documented exception with a named owner and a review date. Anything else should be removed. The rule is short enough to apply in a change review and clear enough to audit.

Applied in practice, that means:

• Default to one path. New VPN users authenticate through the identity provider and hold no other credential on the appliance.
• Separate administration from user access. Firewall management should not be reachable through the same exposed login as user VPN access.
• Treat a migration as a credential event. Reset or remove carried-over passwords as part of the cutover, and do not leave it for later.
• Require evidence. Run an audit of SSL VPN logins for non-SAML access after each upgrade and migration.

How do you keep a fallback without keeping the risk?

Keep one or two emergency accounts, restrict where they can be used from, and alert on every use. A break-glass path is a legitimate design choice, because identity providers do go down and a total lockout of remote access is a real operational risk.

Make the trade-off explicit. An emergency account should have a long unique secret stored offline, should not be used day to day, and should be tested on a schedule with the result written down. Restrict its source addresses if the appliance allows it. Avoid giving it VPN reach from the open internet if a management network or out-of-band path can do the job.

Keep in mind that CVE-2026-19868 was a product flaw. Good design would not have prevented the bug itself, and a patch is still required. Removing unneeded credentials does shrink the number of accounts an attacker could use against that bug, and it makes the log review far simpler, since any non-SAML login is immediately unusual.

Why patching alone does not close the gap

Firmware fixes the vendor's code, and it leaves your configuration alone. SonicWall's 8.2.3 release notes say upgraded firewalls keep their existing authentication configuration. The CVE-2024-12802 reporting shows the same risk in sharper form, with a firmware fix that left the underlying LDAP configuration in place.

Plan upgrade tickets accordingly. Add a configuration review to the change record, covering authentication sources, local accounts and the results of a login test on each remaining method. The extra step takes little time compared with incident response on a VPN account.

How to make the case internally

Three points tend to carry this argument with leadership and auditors:

1. Assurance. If you tell an insurer or auditor that all remote access requires MFA, every exception undermines that statement. Our guide to the MFA section of a cyber insurance application covers how to answer accurately.
2. Severity scores undersell it. SonicWall scored CVE-2024-12802 at 6.5 while CISA's ADP rated it 9.1, and ReliaQuest suggested the lower score may have led some organizations to deprioritize it. We explain why vendor and CVSS scores disagree in a separate article.
3. Cost. Removing unused login methods costs a change window and some testing. It is usually among the cheaper risk reductions available on an edge device.

For the underlying weakness class, read what CWE-308 single-factor authentication means. The practical goal is simple: when someone asks how a person can log in to your VPN, you should be able to answer with a short list you have tested.