External Authentication Methods Give the Campus Its Keys Back

By Raymond Todd Blackwood, President of QuickLaunch

This spring, one of the largest university systems in the country told its people to take their hardware security tokens to an electronics recycler. Not to a drawer. Not to a spare-parts bin. To the recycler. Purdue retired Duo across all of its campuses and moved every university account to Microsoft MFA, and Purdue's own knowledge base spells out the rest: the old university-issued hardware tokens are not compatible with the new system, so drop them at any e-recycling center at your convenience. Real keys, headed for the shredder, because the new lock does not take them.

I have been staring at that bin all week, because nothing about it is unusual. The University of Miami made the same move, Duo out and Microsoft Authenticator in, citing simpler access management. Consolidation into the suite is the strongest current in campus authentication right now, and I understand the pull. Fewer apps. Fewer prompts. Fewer helpdesk tickets during drop/add. But another road opened this year, called external authentication methods, and almost nobody put it on the migration slide.

So let me answer the question underneath this week's title directly. External authentication methods are a generally available capability in Microsoft Entra ID that lets an institution keep Entra as the control plane for access decisions while handing the MFA challenge itself to the provider the institution chooses. QuickLaunch EAM registers QuickLaunch as one of those methods, which makes the QuickLaunch prompt your students already know the same prompt they complete for Microsoft 365. One MFA authority for the whole stack, without throwing your keys in the bin. What this does not do is make a weak factor strong, and it does not make depending on a single authority free. We will spend real time on both limits, because your security architect will ask about them first, and she will be right to.

Last week I wrote about how institutions identify fraudulent students with Smart Access, and I promised this companion piece. Same locksmith, different door. This week it is the front door.

Nobody Chose the Two-App Campus. It Accumulated.

No CIO ever stood at a whiteboard and drew two parallel MFA stacks on purpose. This is how identity debt gets made in higher ed. The Microsoft tenant arrived with A3 or A5 licensing and brought its authenticator along. The campus identity platform came earlier, or later, and brought its own. Each decision was defensible on the day it was made. Together they became a tax collected every semester: two enrollment flows for every incoming class, two factor-reset queues, two compliance reports that never quite reconcile, and a user population trained to approve authentication prompts as ambient noise. Ask anyone who has read a phishing retrospective what prompt fatigue buys you.

So the consolidation instinct is healthy. But there are two decisions hiding inside that instinct, and the current keeps washing them together. Collapsing two apps into one prompt is a user experience decision, and a good one. Deciding that your MFA authority should live inside your application suite is an identity governance decision, and most campuses are making it by accident, as a side effect of the first one. Purdue's recycling-bin guidance is the tell. When the suite's lock does not take your existing keys, you do not rekey the lock. You throw away the keys. That is what inheriting your key authority from a license bundle looks like in practice.

Microsoft Conceded the Point: The Keys Can Live Outside the Suite

Here is what changed, and why this column exists this week. Microsoft took external authentication methods to general availability in Entra ID, under the name External Multifactor Authentication. Microsoft's documentation states the intent plainly: organizations can meet their MFA requirements while continuing to use their preferred MFA provider, and Entra ID remains the identity control plane, performing full policy evaluation, real-time Conditional Access enforcement, and sign-in risk assessment on every sign-in. The old duct-tape path, the custom controls that institutions used for years to bolt outside MFA onto Entra, is deprecated and scheduled for retirement, with a published migration guide pointing at the new mechanism.

Sit with the structural fact before any vendor pitch, mine included. The company that owns the largest application suite in higher education has shipped, documented, and committed to a first-class mechanism whose entire purpose is letting the keys live outside the suite. Control plane and key authority are now officially separable jobs. That is not a feature announcement. That is an architecture concession, and it is the correct one.

QuickLaunch EAM is our walk through that door, generally available in our latest releases. Registered as an external authentication method in Entra ID, it makes QuickLaunch the single MFA authority across both ecosystems. A student signs in to Microsoft 365, Entra evaluates its policies and hands the challenge to QuickLaunch, and the student completes the same prompt she uses at the portal and the SIS. The factors already live in her QuickLaunch profile, whether that is a passkey, a YubiKey, an emailed one-time password, or security questions, so there is no second enrollment and no separate Microsoft Authenticator setup to shepherd every incoming class through. One policy. One prompt. One console when the auditor asks how MFA is enforced. And your existing hardware keys stay keys instead of becoming e-waste.

That is what it does, and I am deliberately not walking you through the protocol plumbing underneath it. The plumbing is not the point. The point is who holds the keys, and this is the part QuickLaunch builds for Entra campuses: complete the suite, never compete with it.

One Keyring Only Helps if the Keys Are Good

Now the three paragraphs a more obedient product column would skip. One keyring to rule them all invites the obvious Tolkien warning, so let me name the limits myself before your security architect does.

First, unifying your MFA authority does not upgrade your factors. An emailed one-time password is exactly as phishable no matter who delivers the challenge. Security reporting documented a phishing campaign that compromised accounts at more than a dozen American universities by capturing sessions after the user completed MFA, using an off-the-shelf adversary-in-the-middle kit. The federal floor keeps moving the same direction: NIST's current digital identity guidelines push deliberately toward phishing-resistant factors, passkeys and hardware keys and credentials that bind the login to the real site. I put a prediction on the record this spring that one-time passwords over SMS and email would start being treated as a risk rather than a control. That prediction is still on the clock, and I run a company whose platform offers email OTP as a factor, because real campuses serve real populations that need fallbacks. Both things are true. The honest architecture is one authority pointed at the strongest factors each population can carry, with the weak factors scoped, monitored, and treated as exceptions. Consolidate around weakness and all you have unified is the weakness.

Second, there is a boundary inside Microsoft's own documentation that your team should design around rather than discover. Entra's authentication strengths policies, including the built-in phishing-resistant strength, do not currently accept external methods. If you gate privileged roles behind an authentication-strength policy, that gate still speaks Microsoft factors only. Map which roles those are before you flip anything.

Third, one authority is one dependency, and this year put the receipt on the record. In February, a Duo service outage broke Microsoft Entra sign-ins at integrated campuses for hours. Texas A&M's own status page logs the morning: Microsoft applications, Canvas, the Howdy portal, all failing at the second factor because the external challenge endpoint was timing out. That risk does not vanish in any architecture. In the two-stack world it is split across two vendors. In the suite-native world it is concentrated in the same company that runs your email. Under external authentication methods it is concentrated in the authority you chose. What changes is whether you chose it on purpose, and whether the vendor holding it will put an availability posture in writing before you sign. Any vendor asking to be your single MFA authority owes you that answer, QuickLaunch included. Ask us. A locksmith who cuts your one keyring had better answer the phone at 2 a.m.

Key Authority Is a Decision About People, Not Products

Strip the vendor names away and every authentication moment has two jobs in it. The control plane decides whether this sign-in, on this device, at this risk level, gets access at all. Entra does that job well, and under this architecture it keeps doing it. Key authority decides what proves the human is the human, and that job touches every population your institution actually serves. The student who does not own a smartphone. The incarcerated learner in a prison education program with no device at all. The dual-enrollment sophomore whose high school locks phones in a pouch from bell to bell. Corporate identity design forgets these people because corporate IT never had to serve them. A campus that owns its key authority can answer for them, deliberately, factor by factor. A campus that inherited its key authority from a license bundle answers to whatever the bundle supports this year.

And the ground under this is still moving. The same concession that separated control plane from key authority points somewhere further out: students will eventually arrive carrying their own credentials, their own passkeys, their own identities, and expect your campus to say yes safely. I have that on the record as a prediction too, and it has not landed yet. When it does, the institutions that kept an independent key authority will be the ones positioned to say yes. File away where the hinge got installed this year.

So here is the working session, and it fits in an afternoon. Count the MFA prompts your users face; if the number is two or more, decide on purpose whether that is a strategy or an accumulation. Inventory every factor in use and sort the list by phishing resistance, per population, not per average user. Find the privileged roles sitting behind authentication-strength gates and write them down. Then make the control-plane decision and the key-authority decision as two separate decisions, eyes open, in that order. Not a transformation program. An agenda.

The institutions that own their keys will own their identity strategy when the next current arrives. And in this business, there is always a next current.

Take the Next Step

Primary: Start with the On-Ramp Lifecycle Audit, QuickLaunch's identity lifecycle assessment, and bring your MFA factor inventory to it. Current EAM capability detail lives in the release notes.

Secondary: Follow the weekly column on the QuickLaunch blog. Next week: temporary access codes, and how to grant exceptions without growing ghosts.

FAQ

What are external authentication methods in Microsoft Entra ID?

External authentication methods, generally available under the name External Multifactor Authentication, let an organization satisfy Microsoft Entra ID multi-factor authentication requirements using a non-Microsoft MFA provider. Microsoft Entra ID continues to evaluate Conditional Access policy and sign-in risk on every sign-in and hands only the MFA challenge to the registered external provider. The capability replaces Conditional Access custom controls, which Microsoft has deprecated, with edits blocked starting September 2026 and full retirement scheduled for early 2027.

What is QuickLaunch EAM and which factors does it support?

QuickLaunch EAM, generally available since the March 2026 releases, registers QuickLaunch as an external authentication method inside Microsoft Entra ID. When a user signs in to Microsoft 365 or another Entra-protected resource, Microsoft delegates the MFA challenge to QuickLaunch, so the user completes the same QuickLaunch prompt used across other campus applications. Supported factors are passkeys, YubiKey hardware keys, email one-time passwords, and security questions, drawn from the user's existing QuickLaunch profile with no separate Microsoft Authenticator enrollment, and MFA policy and compliance reporting consolidate in one console.

Does delegating MFA to an external provider weaken Microsoft 365 security?

No. Microsoft Entra ID remains the identity control plane and still evaluates Conditional Access policy and sign-in risk on every sign-in; only the multi-factor challenge is delegated to the external provider. Two planning realities matter: Microsoft's authentication strengths policies, including the phishing-resistant strength, do not currently accept external methods, so roles gated by authentication strength still require Microsoft-native factors, and the external provider becomes an availability dependency for every application it protects, as the February 2026 Duo outage demonstrated at integrated campuses.

Which MFA factors are phishing resistant?

Passkeys, FIDO2 hardware security keys such as YubiKey, and other credentials that cryptographically bind the login to the legitimate site and require deliberate user presence are phishing resistant. One-time passwords delivered by SMS or email, security questions, and simple push approvals are not, because attackers can capture or relay them in real time with adversary-in-the-middle kits. NIST SP 800-63-4 moves institutions deliberately toward the phishing-resistant end of that list.

References

• Migrating from DUO to Microsoft MFA authentication for all Purdue campuses - Purdue University IT Knowledge Base. https://service.purdue.edu/TDClient/32/Purdue/KB/Article/1783/Migrating-from-DUO-to-Microsoft-MFA-authentication-for-all-Purdue-campuses
• Multi-Factor Authentication Transition - University of Miami Information Technology. https://www.it.miami.edu/mfa-transition
• Microsoft Entra releases and announcements (External MFA general availability) - Microsoft Learn. https://learn.microsoft.com/en-us/entra/fundamentals/whats-new
• Migrate from custom controls to external MFA in Conditional Access - Microsoft Learn. https://learn.microsoft.com/en-us/entra/identity/conditional-access/how-to-migrate-custom-controls-external-mfa
• QuickLaunch Release Notes - QuickLaunch. https://quicklaunch.io/release-notes/quicklaunch/
• Phishing attack targets 18 US universities, bypassing MFA - SC Media. https://www.scworld.com/brief/phishing-attack-targets-18-us-universities-bypassing-mfa
• NIST Special Publication 800-63-4, Digital Identity Guidelines - NIST. https://pages.nist.gov/800-63-4/sp800-63.html
• Microsoft Entra External MFA Method Provider Reference - Microsoft Learn. https://learn.microsoft.com/en-us/entra/identity/authentication/concept-authentication-external-method-provider
• Microsoft login issues with DUO (incident record, February 23, 2026) - Texas A&M University IT Status. https://status.it.tamu.edu/incidents/1517ymrt6jgd
• What is Phishing-Resistant Multi-Factor Authentication? - Yubico. https://www.yubico.com/resources/glossary/phishing-resistant-mfa

Raymond Todd Blackwood is the President of QuickLaunch and writes about identity, agentic AI, and the messy reality of higher-ed IT. #ItsExistential