What is SAML single sign-on, and how can MFA be bypassed? A guide for admins

In short

SAML is an XML-based standard that lets one system, the identity provider (IdP), vouch for a user to another system, the service provider (SP), so people sign in once and the SP never sees their password. Multi-factor authentication (MFA) usually happens at the IdP, and the SP trusts a signed message saying it did. That design is only as strong as the SP's checks: if the SP also accepts some other login route, or skips a validation step, the IdP's MFA can be bypassed. That is the class of problem behind the SonicWall SonicOS SSL-VPN flaw CVE-2026-19868, which CISA added to its exploited-vulnerabilities list on 6 November 2026.

Why SAML exists

Before single sign-on, every application kept its own user database and password. Employees juggled dozens of logins and administrators had to remove access one system at a time. SAML (Security Assertion Markup Language) is an OASIS standard that moves authentication to one place. The OASIS technical overview says it solves the multi-domain web single sign-on problem "by providing a standard vendor-independent grammar and protocol." Applications across organisational boundaries can then trust portable statements about a user.

The cast: IdP, SP and assertions

The OASIS overview defines the roles:

• Identity provider (IdP): authenticates the user and issues assertions about them. Microsoft Entra ID is an example.
• Service provider (SP): relies on the IdP's assertions to grant access and creates its own local session. The application, or a VPN appliance, is the SP.
• Assertion: a statement issued by the IdP. It has a subject (usually identified by a name identifier), conditions such as a validity period and the intended audience, and one or more statements: authentication statements (how and when the user signed in), attribute statements (such as name or group) and authorisation decision statements.

The two sides must know about each other first. In Microsoft's documentation for Entra ID, an app developer registers federation details including a redirect URI and a metadata URI, and the identity platform uses the metadata to retrieve the app's signing key and logout address. That up-front trust relationship is the foundation: OASIS calls a pre-existing trust relationship between the parties the primary defence, typically built on a public-key infrastructure.

How a SAML sign-in works, step by step

The most common flow is "SP-initiated" browser SSO, described in the OASIS overview:

1. The user asks for a protected resource at the SP and has no session. The SP remembers the target address.
2. The SP redirects the browser to the IdP's SSO service with an authentication request (AuthnRequest) and a RelayState token.
3. The IdP checks whether the user already has a session that meets its authentication policy. If not, it challenges the user for credentials. This is where a password prompt and an MFA prompt happen.
4. The user authenticates and the IdP establishes its own session.
5. The IdP builds a signed assertion inside a Response and sends it back through the browser, as an auto-submitting HTML form posted to the SP's Assertion Consumer Service.
6. The SP validates the signature, creates a local session and sends the user to the original resource.
7. The SP checks authorisation and returns the resource.

Notice what the SP never does: it never sees the password or the second factor. It sees only the signed result. SAML defines other bindings (HTTP Redirect, HTTP Artifact, SOAP) and other flows, but this is the one most people meet.

Where MFA lives, and what the SP is told

Because the IdP runs the sign-in, the IdP is where MFA is normally enforced. SAML can also describe how strongly the user authenticated. An authentication statement can include an AuthnContext, and the OASIS overview says an SP can ask for specific requirements, such as multi-factor authentication, in its AuthnRequest. The example assertion in the document uses the PasswordProtectedTransport class.

That matters for defenders. MFA is not magic that travels with the user; it is a property of how the IdP chose to authenticate this sign-in, reported to the SP in a signed message. An SP that wants MFA has to either rely on the IdP's policy or check the context it receives.

What the SP must check

Receiving a SAML response is not the same as trusting it. The OWASP SAML Security Cheat Sheet lists what a service provider must validate:

• Signature: verify the response or assertion signature against the IdP's trusted certificate, ignoring any key information inside the document. Require RSA-SHA-256 or stronger and reject SHA-1.
• Issuer and audience: confirm the signer is an authorised IdP and that the audience matches the SP's entity ID.
• Destination: it must exactly match the SP's Assertion Consumer Service URL.
• InResponseTo: it must match the original request's ID.
• Time conditions: NotBefore and NotOnOrAfter must be valid.
• Replay: detect replayed responses, especially for IdP-initiated SSO, and prefer short lifetimes.
• XML signature wrapping: make sure the signature covers the exact assertion used for authentication, and reject assertions outside signed content.

OASIS adds that assertions delivered through the browser POST binding must be digitally signed with XML Signature, and that defences target man-in-the-middle and replay attacks. The OWASP page says nothing specific about SP-side checks for authentication context or MFA; it covers only IdP-side items.

How MFA gets bypassed in SAML setups

No single bug explains every case, so here are the general mechanisms, labelled by how well documented they are.

An alternate login route. A service that offers SAML but also accepts another method, for example a local account or an older directory login, is only as strong as its weakest route. CISA's entry for CVE-2026-19868 describes a flaw that "may allow a user with valid credentials for an alternate authentication method to bypass SAML authentication controls", which may include bypassing SAML-enforced MFA. SonicWall has not published a technical write-up that we could open, so we cannot say precisely how this particular bug works; the pattern above is the general lesson, not a description of the bug. CISA classifies the weakness as CWE-308, Use of Single-factor Authentication.

Skipped or weak validation. If an SP does not check the signature, audience, destination or timestamps as listed in the OWASP cheat sheet, an attacker may forge or replay assertions. XML signature wrapping is a documented example: the signature is valid, but it covers a different element than the one the application reads.

Stolen credentials plus a gap. Attackers with leaked or stolen passwords can only use them where the second factor is not enforced. This is why bypasses are valuable: they turn a pile of credentials into access.

Terms you will see in SAML settings

• Entity ID: the name by which an IdP or SP identifies itself. The assertion's audience must match the SP's entity ID, per OWASP.
• Metadata: a document each side publishes with its signing keys and endpoints. Microsoft's documentation says Entra ID retrieves an app's signing key and logout address from the metadata address registered for the app, and Entra ID publishes its own federation metadata at tenant-specific and common endpoints.
• Assertion Consumer Service (ACS): the SP address that receives the IdP's response. The Destination in the response must match it exactly.
• RelayState: a token that carries the user's target page through the sign-in. OASIS warns it can leak details of a user's activity at the SP to the IdP, so protect user privacy.
• Bindings: how messages travel. HTTP Redirect puts messages in URL query strings, HTTP POST sends base64-encoded messages in HTML form fields, and HTTP Artifact passes a short reference the receiver resolves over a back channel.
• Single logout: a companion profile for ending sessions. Logout requests are also signed, per OASIS.

A checklist for administrators

These are practical steps drawn from the sources above, not vendor requirements:

1. Inventory the login routes. For each SAML-enabled service, list every other way to sign in (local accounts, API keys, legacy directory logins). Disable what you do not need.
2. Enforce MFA at the IdP and ask for it in the request. The OASIS overview says an SP can request specific authentication requirements in the AuthnRequest.
3. Check SP validation. Confirm the product validates signature, audience, destination and time conditions per the OWASP list, and keep the product updated. For edge devices, that means applying vendor fixes promptly.
4. Compare logs. Match the service's sign-in records against the IdP's. A VPN or app session with no matching IdP sign-in event deserves investigation. This is our suggestion, not a vendor-documented method.
5. Watch the KEV list. CISA's Known Exploited Vulnerabilities catalog is the quickest signal that a flaw is being used in attacks. For how to rank patches, see our guide to EPSS, CISA KEV and SSVC.

Common questions

Does SAML replace MFA? No. SAML moves the sign-in to the IdP. MFA is a policy the IdP applies during that sign-in.

If my IdP enforces MFA, am I safe? Only for the routes that go through the IdP. If a service accepts another login route, the IdP's MFA does not cover it.

Is SAML the same as OAuth or OpenID Connect? They solve related problems with different formats. SAML uses XML assertions; this guide covers SAML only.

Why is the SP's signature check so important? The signed assertion is the only evidence the SP has that the IdP authenticated the user.

Sources

• OASIS: Security Assertion Markup Language (SAML) V2.0 Technical Overview
• OWASP: SAML Security Cheat Sheet
• Microsoft Learn: How the Microsoft identity platform uses the SAML protocol
• CISA: Known Exploited Vulnerabilities catalog (CVE-2026-19868)
• Our article on CVE-2026-19868