For years, a district that wanted a second factor Microsoft did not offer had two options. It could federate its whole sign-in to another identity provider, or it could live with what Entra had. Microsoft's external MFA feature, which it calls external authentication methods, adds a third option. Entra stays in charge of sign-in and Conditional Access, and hands only the second-factor step to another provider.
The feature spent a long stretch in public preview and became generally available in 2026. For K-12 IT, that means it is now a supported part of Entra rather than an experiment.
How a sign-in works
From the user's side, very little changes. From the tenant's side, the flow looks like this:
- The user signs in at Microsoft with their normal account and password.
- A Conditional Access policy decides this sign-in needs a second factor.
- Entra redirects the browser to the external provider.
- The provider verifies the user in whatever way it was built to.
- The provider sends a signed result back to Entra, and Entra finishes the sign-in.
The user never leaves the Microsoft sign-in flow, and every policy you already have in Conditional Access still applies. Nothing about your Microsoft 365 apps has to change.
External MFA does not replace Entra. It plugs a different second factor into the Entra you already run, which is why it fits districts that cannot or will not move identity providers.
What you need before you start
- Conditional Access. External methods are triggered by Conditional Access policies, which require Microsoft Entra ID P1. Many districts already have P1 through Microsoft 365 Education A3.
- A test group. Scope your first policy to a small pilot group so nobody else sees a change.
- A plan for registration. Microsoft now requires users to have the external method registered before they can use it. New users are prompted to register at sign-in, and admins can register users on their behalf. For thousands of students, admin registration is the path that scales.
Questions to ask any external MFA vendor
The Entra side of the setup is similar across providers. The differences are in what the provider asks your users to do and what it keeps about them. For a K-12 rollout, these are the questions worth asking:
- Does the factor work for a student who has no phone?
- Does it work on a shared Chromebook cart?
- Can it run in a log-only mode before it blocks anyone?
- When a student forgets their code, who resets it? Does that land on your help desk?
- What student data does it store, and will the vendor sign your data privacy agreement before any real student data is loaded?
- Can you test the full round trip in a sandbox tenant first?
A sensible rollout
Connect the provider to a test tenant and walk through a complete sign-in before touching production. Then add it to your real tenant, scope one Conditional Access policy to a single building or grade band, and leave everyone else alone. Watch sign-in logs and support requests for a few weeks. Expand when the numbers look boring.
If something goes wrong, turning off one Conditional Access policy puts everyone back where they started. That small blast radius is a big part of why this model suits schools.
For the full picture, from choosing a factor to rollout, see our student MFA guide for K-12 IT.
Built on Entra external MFA
DistrictID plugs into Microsoft Entra as an external MFA method, built for K-12 students. Entra stays your identity provider. Students get a second factor they can actually use.
See How DistrictID Works