Skip to main content

Wolfcore Cyber Security

Try our phishing simulations free for 14 days. Start free trial →
Get Started

How SAML authentication bypass works, and why MFA can be skipped

Written by Ruben Selby, founder and penetration tester at Wolfcore. Last reviewed 13 November 2026.

In one sentence: SAML is the system that lets you sign in once to many services, and a SAML authentication bypass is any flaw that lets someone get in without the identity checks, including multi-factor authentication, that the system was meant to enforce.

What it is

SAML (Security Assertion Markup Language) is an open standard for exchanging authentication and authorisation information. Many firms use it for single sign-on. There are two parties. The identity provider, such as Microsoft Entra ID or Okta, checks who you are. The service provider, such as a VPN gateway or a business app, trusts the identity provider’s answer.

The identity provider’s answer is an “assertion”: a signed statement that says who you are and that you passed the checks. If MFA is enforced at the identity provider, the assertion is the proof. That is why a weakness in how the service provider handles the assertion can undo MFA, even though MFA itself is working.

How it works

Bypass flaws fall into a few families. The mechanism, not a recipe:

  1. A second way in that skips SAML. The service accepts SAML for most users but also leaves another login method enabled. If the second path does not enforce the same checks, someone with a valid login for that path never meets the MFA prompt.
  2. Assertion not fully checked. The service provider must check the signature, the intended audience, the time window, and that the response answers a request it actually made. OWASP lists these checks and says that missing any of them is a common gap.
  3. Signature wrapping. XML is flexible. If the code that checks the signature and the code that reads the user’s identity look at different parts of the document, a signed element can be paired with an unsigned one. OWASP describes this family and says never to select security elements without validating first.
  4. Replay. A captured assertion is used again because it had a long life or was never marked one-time-use.
  5. A stolen signing key. OWASP says that if an attacker can use the identity provider’s signing key, they can create assertions that say anything. Signing keys are a top target.

What the attacker is after: a trusted session on your network or in your apps, without triggering the checks that would stop a stolen password.

Real examples

On 6 November 2026 CISA added SonicWall’s CVE-2026-19868 to its Known Exploited Vulnerabilities catalogue. The Hacker News reports SonicWall’s description: a user with valid credentials for an alternate authentication method may be able to bypass SAML authentication controls in the SSL-VPN service, and may also bypass SAML-enforced MFA. It is rated 7.1 or 7.5 on CVSS depending on the scoring. SonicWall said it had investigated a report of potential exploitation and did not share specifics. Federal agencies were told to patch by 20 November 2026. Fixed versions are in SonicWall’s advisory SNWLID-2026-0014, which we have not opened, so check it for your model.

Note what the example shows. The attacker still needed valid credentials. The bypass removed the second factor. That is the practical lesson: MFA only protects you if every route to the login enforces it.

Who it affects and how badly

Any organisation using SAML single sign-on in front of remote access or business apps, which includes most firms of 10 staff upwards using Microsoft 365, Google Workspace or a VPN. MSPs are exposed twice, through their own tools and their customers’.

Realistic worst cases: a small business with stolen staff passwords loses email and files because the extra check did not apply. A mid-sized business sees an intruder on the internal network through the VPN. A regulated business faces a personal data breach and supervisor questions about why its MFA did not hold.

The UK angle

Cyber Essentials requirements v3.3 (NCSC, April 2026) say authentication to cloud services must always use MFA, and that security updates fixing vulnerabilities with a CVSS v3 score of 7 or above must be applied within 14 days. A SAML bypass in a VPN is both a patching question and an MFA question, and an assessor will ask about both. The same document says firewall administration interfaces must not be open to the internet without MFA or an IP allow list.

What we check on a test

Method only, no findings claimed:

  • Which login methods each remote access service and app accepts, and whether any of them skip the identity provider.
  • Whether accounts that should use SAML can also sign in locally or by another method.
  • Whether single sign-on is IdP-initiated, which OWASP says lacks login CSRF protection.
  • What the service does with expired, repeated or mismatched assertions, checked in a safe test setup, not by attacking a live identity provider.
  • Whether sign-in logs on the service match events at the identity provider.
User Identity providerpassword + MFA Second login pathno MFA check VPN or apptrusts both The weak path decides how strong your MFA really is

How to detect it

  1. Compare VPN or app sign-in logs with your identity provider’s sign-in logs. A session with no matching identity provider event is a red flag.
  2. In your identity provider’s sign-in logs, look for sign-ins to the VPN or app that show only one factor was used.
  3. Alert on logins from unfamiliar countries or at odd hours for accounts that normally use MFA.
  4. Watch for new sessions on accounts that never use the VPN.
  5. Subscribe to your vendors’ security advisories and the CISA catalogue so you hear about exploited flaws quickly.

How to fix or prevent it

  1. Apply the vendor’s security update as soon as it is released, within 14 days at most for flaws scored 7 or above.
  2. Disable every login method you do not need, so SAML is the only way in.
  3. Make the service require signed assertions, check audience, recipient, time window and the request ID, and reject SHA-1 signatures, as the OWASP cheat sheet lists.
  4. Prefer service-provider-initiated sign-in and turn off IdP-initiated sign-in where you can.
  5. Protect and rotate identity provider signing keys, ideally in a hardware security module.
  6. Limit what a VPN account can reach, so one bypass does not open the whole network.

Frequently asked questions

Does this mean MFA does not work? No. The SonicWall example is about a path that did not enforce it.

Did the attacker need a password? In the SonicWall case, valid credentials for an alternate method were needed.

Is there a workaround for the SonicWall flaw? The reports we opened give the update advice only. Check the vendor advisory.

Related terms

Category hub: Hacking techniques explained. Related entries: multi-factor-authentication, cisa-kev, cve, cvss, how-session-hijacking-works, patch-management.

How Wolfcore helps

A Wolfcore penetration test finds this the way an attacker would, by hand, not with a scanner. See manual penetration testing and start with the free web vulnerability scan.