SharePoint On-Premise MFA: Options for Internal and External Users

On July 14, 2026, SharePoint Server 2016 and SharePoint Server 2019 reached end of extended support. On the same day, Microsoft's Patch Tuesday disclosed CVE-2026-56164 — a missing-authentication flaw (CWE-306) in on-premises SharePoint Server that lets an unauthenticated attacker elevate privileges over the network with no credentials and no user interaction. CISA added it to the Known Exploited Vulnerabilities catalog the day it was published, alongside two other actively exploited SharePoint flaws being chained to steal IIS machine keys and establish persistence.

Those two facts landed together, and the combination changes the math. There is no Extended Security Update program for SharePoint 2016 or 2019 the way there is for Windows Server and SQL Server. The patches that shipped on July 14 were the last ones those farms will get. For every farm that hasn't finished migrating to Subscription Edition or SharePoint Online — and there are a lot of them — access control at the network edge has stopped being a compliance checkbox and become the primary compensating control.

Which brings most teams to the same question: how do you actually put MFA in front of on-premises SharePoint?

Why SharePoint on-premises resists MFA

The obstacle is protocol support, and it differs by version. This is the single most important table in this article, because it determines every option available to you:

Two conclusions follow.

First, Windows authentication has nowhere to put a second factor. NTLM and Kerberos are single-exchange protocols. The browser negotiates with IIS, a ticket or challenge-response completes, and the user is in. There is no interactive step where MFA can be inserted. You cannot bolt MFA onto NTLM, because NTLM has no place for it. Forms-based authentication has the same problem — it validates a password and issues a cookie, full stop.

Second, SharePoint 2019 and earlier cannot speak to a modern identity provider directly. Their only federation option is SAML 1.1 over WS-Federation. Microsoft Entra ID, Okta, Ping, Cisco Duo, and OneLogin all issue SAML 2.0 or OIDC. Some IdPs can be configured to emit SAML 1.1 over WS-Federation with additional work; most deployments end up putting ADFS in the middle as a protocol broker — ADFS federates upstream to Entra ID or your IdP of choice using modern protocols, then issues the SAML 1.1 token SharePoint will accept. That is why Microsoft's documented path for 2013, 2016, and 2019 involves ADFS: not because ADFS adds security value, but because it translates protocols.

Subscription Edition changed this. SE supports OIDC 1.0 with Entra ID, ADFS 2016 or higher, and third-party IdPs implementing OIDC 1.0. If you're on SE and your IdP speaks OIDC, you can federate directly and drop the ADFS dependency.

What a claims migration actually costs

Every native federation path — ADFS, Entra ID as trusted IdP, or SE with OIDC — requires registering a trusted identity token issuer (New-SPTrustedIdentityTokenIssuer) and converting the web application from Windows claims to federated claims. That conversion is the expensive part, and it applies on Subscription Edition too.

When you switch, the encoded identity string for every user changes. i:0#.w|CONTOSO\jsmith becomes something like i:0e.t|entraid|jsmith@contoso.com. SharePoint treats those as two unrelated principals.

Concretely:

• Every permission entry has to be re-mapped. Site collection permissions, library-level grants, item-level breaks, audience targeting, and workflow initiators all reference the old claim string. Farms with years of accumulated fine-grained permissions are the hardest hit. This is true on every version, SE included.
• People Picker stops resolving users. On 2013, 2016, and 2019, SAML 1.1 or OIDC means the People Picker can't search, resolve, or validate users and groups without a custom claims provider written in C# — in practice, EntraCP or LDAPCP. Subscription Edition genuinely improves this: SE's People Picker can resolve users and groups from the User Profile Application, which removes the custom-code requirement for many farms. Credit where it's due — but it doesn't undo the re-permissioning above.
• Search crawl breaks. The crawler authenticates with Windows credentials. Standard practice is to extend the web application into a second zone that keeps Windows authentication for the crawler, then manage Alternate Access Mappings for both zones.
• Office rich clients, WebDAV, and Explorer view get unpredictable. Non-browser clients handle passive federation redirects inconsistently, and mapped drives are usually the first casualty.
• Identifier claim choice is close to irreversible. Pick UPN and you hit the mangled-UPN problem with Entra guest accounts. Pick mail and you must guarantee it's populated and unique on every account. Changing your mind means re-permissioning again.

For a small farm with clean permissions, this is a project. For a ten-year-old farm serving three business units, it's a multi-quarter program — a hard sell when the driver is an unpatched, actively exploited vulnerability you need mitigated this month.

Your options, by version and IdP

The bottom three rows share the property that matters: authentication happens at the network edge, and SharePoint keeps authenticating exactly as it does today. No claims conversion means no re-permissioning, no custom claims provider, and no People Picker rework.

Entra Application Proxy is a reasonable fit if you're all-in on Entra, hold P1 or P2 licensing for Conditional Access, and are publishing a manageable number of applications — though it needs connector agents inside your network and the internal/external URL handling for SharePoint takes care to get right.

The Datawiza alternatives

Datawiza Access Proxy is an identity-aware proxy that deploys in front of SharePoint. It supports SharePoint Server 2013, 2016, 2019, and Subscription Edition, and offers two distinct modes.

Mode 1: OIDC or SAML 2.0 directly with any identity provider

The proxy intercepts before SharePoint's login page and runs the authentication flow itself:

1. A user requests a SharePoint URL. The request hits the proxy first.
2. The proxy redirects to your IdP over OIDC or SAML 2.0 — Microsoft Entra ID, Okta, Ping, Cisco Duo, OneLogin, or any other standards-compliant provider.
3. The IdP authenticates and enforces MFA plus whatever conditional access policy you run: device compliance, location, risk score, session controls. Existing MFA investments carry over unchanged.
4. On success, the proxy performs the SSO handoff into SharePoint. For Windows-authenticated farms this uses Kerberos Constrained Delegation with protocol transition to obtain a ticket for the authenticated user.
5. SharePoint serves content to what looks like a normal authenticated request.

The significance is the protocol translation. On SharePoint 2013, 2016, or 2019, this is how you use Okta, Ping, Duo, or OneLogin as your MFA authority without deploying ADFS as a broker — the proxy speaks the modern protocol your IdP already speaks, so nothing needs to be downgraded to SAML 1.1. On Subscription Edition, where native OIDC to Entra ID is a legitimate option, the differentiators shift: you skip the claims conversion and re-permissioning entirely, you aren't limited to OIDC-capable IdPs, and you get one enforcement layer that also covers your other legacy applications.

You install nothing on the SharePoint servers, write no code, deploy no ADFS, register no trusted identity token issuer, and touch no permission entries. The documented walkthrough is here and typically completes in under an hour.

Mode 2: Built-in MFA with no identity infrastructure at all

The second mode assumes nothing about your identity stack. There is no AD dependency, no ADFS, no IdP, no federation. The user signs in to SharePoint with whatever credentials SharePoint already accepts, and Datawiza presents an MFA challenge before granting access to the application.

This is the option for organizations that don't have a modern IdP, don't want to license one, or — as covered below — need to cover external users who will never exist in their corporate directory.

The vulnerability angle

Because the proxy authenticates every request before forwarding it, unauthenticated traffic never reaches the SharePoint web front end. For a missing-authentication flaw like CVE-2026-56164, that removes the exact network path the attack depends on. Two honest caveats: it only applies to traffic that must traverse the proxy, so a directly reachable web front end on the LAN or in a DMZ is unprotected, and it is a compensating control, not a patch. On an out-of-support farm where no future patch is coming, though, a compensating control is what you have.

SharePoint MFA for external users

This question splits cleanly in two, and the answer depends entirely on which SharePoint you mean. Most published guidance answers the wrong half.

If you're on SharePoint Online

External access is Entra B2B, and MFA is a Conditional Access policy. Create a policy scoped to All guest and external users, target all resources (excluding anything that genuinely shouldn't require a second factor), and set the grant control to Require multifactor authentication. Run it in report-only mode first.

Three things that trip teams up:

• Conditional Access needs Entra ID P1 or P2. One reason organizations use guest sharing is that external users don't consume an M365 license — but the policy that secures them does have a licensing footprint.
• Authentication strength policies don't cover every guest type. They don't apply to email one-time passcode, SAML/WS-Fed federated, or Google-federated users. For those, the plain "Require multifactor authentication" grant control is what you need. Configure only an authentication strength policy and a subset of your guests slips through it.
• Guests must redeem the invitation. Users who only click a file link without accepting the tenant invitation aren't fully onboarded, and MFA and compliance policies won't reliably apply.

Also worth configuring: cross-tenant access settings that trust MFA completed in the partner's home tenant, which removes the double-prompt friction behind most "external users have to MFA every single time" complaints.

If you're on SharePoint on-premises

There is no B2B guest model. On-prem SharePoint has no equivalent of an Entra invitation, so external users need an identity your farm can resolve — and every native MFA option inherits that constraint:

The usual architecture is to extend the web application into an Extranet zone with its own URL and AAM entry, then place that zone behind a reverse proxy in the DMZ. That buys network isolation but not authentication strength — the extranet zone still authenticates the same way, so a stolen partner password is still a valid partner login.

This is where Datawiza's built-in MFA is the strongest fit in the entire product. External users are precisely the population you don't want to provision into your corporate directory, don't want to license in your IdP, and can't realistically federate with one partner organization at a time. Built-in MFA sidesteps all of it: your external users keep signing in to SharePoint with the credentials they already have — extranet AD accounts, FBA accounts in SQL, whatever the farm accepts — and Datawiza challenges them for a second factor before granting access to the application. No AD dependency, no ADFS, no IdP, no per-partner federation, no credential store for you to build and defend.

If your external users do live in a modern IdP — B2B guests in your Entra tenant, or accounts in a partner-facing Okta, Ping, or Entra External ID directory — Mode 1 applies instead, and you get SSO along with MFA. The requirement to plan for there is that the delegation step needs an account SharePoint can resolve, so each external identity has to map to an extranet account, typically matched on email or UPN. Built-in MFA has no such requirement, which is exactly why it fits the external-user case better.

Either way, the enforcement point is a policy layer you control, so you can apply materially stricter policy to external traffic than internal: tighter session lifetimes, IP or geo restrictions, MFA on every session rather than remembered devices.

Compliance drivers

For regulated environments, on-prem SharePoint holding sensitive content is frequently in scope for MFA requirements that make no exception for legacy applications:

• CJIS Security Policy requires MFA for access to criminal justice information, including from legacy on-prem systems. CJIS MFA requirements.
• NYDFS Part 500 requires MFA for all individuals accessing internal networks from external networks — extranet SharePoint access is squarely in scope. NYDFS Part 500 MFA requirements.
• PCI DSS 4.0 requires MFA for all access into the cardholder data environment, not just administrative access.
• Cyber insurance underwriting increasingly asks whether MFA covers all remotely accessible applications. "All except SharePoint" is an answer that affects premiums and, in some cases, coverage.

Running an out-of-support platform is separately a problem for SOC 2, HIPAA, and ISO 27001 audits, which generally require production systems to be within active vendor support. MFA at the edge doesn't fix that — but it materially changes the risk conversation while migration is in flight.

Which option fits your situation

FAQ

Can you use MFA with SharePoint on-premises?

Yes, but not through Windows authentication, which has no second-factor step. You either convert the web application to federated claims and let an identity provider enforce MFA, or you enforce MFA at a reverse proxy in front of the farm.

Does SharePoint Server 2019 support MFA?

Not natively, and its federation options are limited: 2019 and earlier support only SAML 1.1 over WS-Federation, not SAML 2.0 or OIDC. Reaching a modern IdP therefore requires ADFS as a protocol broker, or a reverse proxy that handles the modern protocol on SharePoint's behalf.

Does SharePoint Subscription Edition support OIDC?

Yes. Subscription Edition is the only version that supports OIDC 1.0, working with Microsoft Entra ID, ADFS 2016 or higher, and third-party OIDC 1.0 providers. It still requires a trusted identity token issuer and the claims conversion that comes with it.

Do I need ADFS to enable MFA on SharePoint on-premises?

On 2013, 2016, or 2019, Microsoft's documented path effectively requires ADFS as a protocol broker, because those versions can't consume SAML 2.0 or OIDC. On Subscription Edition you can federate directly over OIDC. A reverse proxy removes the ADFS dependency on every version.

Can external users authenticate with MFA against on-prem SharePoint?

Yes. On-prem SharePoint has no native B2B guest model, so every native option requires provisioning external users into a directory your farm can resolve. A proxy with built-in MFA avoids that: external users sign in with their existing SharePoint credentials and are challenged for a second factor before access to the application is granted — no AD, ADFS, or IdP required.

Will MFA protect an unpatched SharePoint farm from CVE-2026-56164?

Partially, and only under specific conditions. A reverse proxy that authenticates every request before forwarding it prevents unauthenticated traffic from reaching the SharePoint web front end, which removes the network path a missing-authentication flaw requires. It only helps for traffic that must traverse the proxy, and it is a compensating control rather than a patch.

How long does a reverse-proxy deployment take?

Documented SharePoint deployments with Datawiza typically complete in under an hour, because no changes are made to the SharePoint servers themselves.

Next step

If you're running SharePoint 2016 or 2019 past end of support, or evaluating how to handle MFA on Subscription Edition without a re-permissioning project, the SharePoint SSO and MFA walkthrough covers the full configuration. For an architecture review of your specific farm and extranet setup, get in touch.

Related reading:

• Integrating Entra ID with SharePoint On-Premises