Azure MFA Server Retirement: Move NPS, RADIUS and AD FS MFA to Entra

Azure Multi-Factor Authentication Server (MFA Server) is deprecated, and Microsoft's own documentation states that from 30 September 2024 MFA Server deployments no longer service multifactor authentication requests, so any VPN, RADIUS client or AD FS farm still pointing at it is either failing or protected by something other than what its owners believe. Many organisations migrated their web sign-ins years ago but left a residue: a Citrix or VPN gateway talking RADIUS to MFA Server, an AD FS farm with the MFA Server adapter still registered, hardware OATH tokens whose seed files are lost, or a Microsoft Identity Manager self-service password reset portal. This guide covers the official status, how to find what still depends on MFA Server, the migration paths for the NPS extension, RADIUS VPNs and AD FS, how to test and roll back, and the risks of leaving the residue in place. It is written for identity engineers and infrastructure teams finishing the move. For general AD FS hardening see the AD FS Security Guide; this page does not repeat it.

This is an independent guide from NHI Mgmt Group, based on Microsoft's public documentation as of November 2026. It is not sponsored or reviewed by Microsoft. Product features change, so confirm settings against Microsoft's current documentation.

Key takeaways

• The service date has passed. Microsoft announced deprecation in September 2022 and states that from 30 September 2024 MFA Server deployments no longer service MFA requests, which could cause authentications to fail.
• Residue is the real problem. RADIUS clients, AD FS adapters, MIM SSPR and hardware tokens are the dependencies most often left behind after the headline migration.
• The NPS extension is a bridge, not a policy engine. It does not evaluate Conditional Access, it always uses the user's default method, and it requires users to be registered for Entra MFA first.
• Staged Rollout plus the Migration Utility gives a reversible path. Users move by group, and the federatedIdpMfaBehavior setting is the final, cutover switch.
• Prefer modern protocols over RADIUS. Microsoft recommends federating VPNs as SAML apps where possible so Conditional Access applies; RADIUS with NPS is the fallback.

What is changing and why

MFA Server was the on-premises component that performed second-factor checks for RADIUS, IIS, LDAP and AD FS integrations, with its own user database (PhoneFactor.pfdata), its own mobile app registrations and its own OATH token store. Microsoft replaced it with cloud-based Microsoft Entra multifactor authentication, where policy is set in Conditional Access and the Authentication methods policy rather than on a server you patch yourself.

The migration documentation now states plainly that MFA Server "isn't available for new deployments and is deprecated" and that customers using it should move to cloud-based Microsoft Entra MFA. The deployment page adds that only existing customers that activated MFA Server before 1 July 2019 could download updates and generate activation credentials. The practical change for defenders is a shift of control plane: second-factor decisions move from a local server, where logging and method choice were local, into Entra ID, where sign-in logs, Authentication methods policy and Conditional Access govern them.

Official timeline and current status

All dates below are as stated on Microsoft Learn pages checked on 8 November 2026. Microsoft has not published a separate "what happens next" page; treat any remaining MFA Server as unsupported and not servicing requests.

The migration guides were last updated on 4 March 2025 and the deployment page on 14 January 2025, as shown in their page footers. If Microsoft revises any of these pages, the dated wording above may change.

Who and what is affected

Any authentication flow where MFA Server was the second factor is affected. The common integrations and their target states are below.

• Users: phone numbers held only in MFA Server may be stale. Microsoft advises every user registers for combined security information rather than relying on migrated numbers.
• Administrators: configuring the AD FS farm needs Enterprise Administrator in Active Directory; the Migration Utility script runs as Application Administrator and its app needs admin consent; the NPS configuration script needs a Global Administrator.
• Licensing: the NPS extension needs MFA rights included with Entra ID P1 or P2 or Enterprise Mobility + Security. Consumption-based per-user or per-authentication MFA licences are not compatible.

Finding affected systems and identities

Inventory before you change anything. MFA Server tends to survive in places no one owns.

1. Find the servers: search your CMDB, endpoint inventory and software inventory for the Multi-Factor Authentication Server product and the PhoneFactor service, and list primary and secondary servers in the replication group.
2. List RADIUS clients: export the RADIUS client list configured in MFA Server and in any NPS servers in front of it. Each IP is a VPN, gateway or network device. Record the authentication protocol it uses (PAP, MS-CHAPv2 or EAP), because that decides which Entra MFA methods will work.
3. Check network flows: firewall and flow logs showing UDP 1812 or 1645 traffic to MFA Server hosts identify RADIUS clients that are not documented.
4. Check AD FS: on each AD FS farm, list registered additional authentication providers and access control policies. Microsoft's utility guidance says to review AD FS access control policies so none requires on-premises MFA.
5. Check the federation setting: read the domain federationConfiguration in Microsoft Graph; federatedIdpMfaBehavior shows whether Entra ID still accepts or enforces MFA from the federated IdP.
6. Identify user populations: from the MFA Server user list, find users whose only registered method is an OATH token or a phone number not present in Entra ID. These are the users who will be locked out first.
7. Find service and shared accounts: RADIUS integrations often authenticate shared network operations accounts or break-glass device admins. Those are non-human or shared identities that cannot complete a push, so decide their control before cutover. See the RADIUS Security Guide.

Measure progress with: number of RADIUS clients still pointing at MFA Server; percentage of in-scope users registered for Entra MFA; count of users with no usable Entra method; count of AD FS relying parties still on AD FS; and NPS extension authentication failures per day after cutover.

Migration options

Option A: move MFA and user authentication to Entra ID

Microsoft's recommended path is to move both MFA and user authentication to Azure, ending with MFA Server and AD FS both decommissioned. Apps move to Entra ID first, then users move to Entra MFA. This gives Conditional Access, risk-based policy and a single sign-in log. The AD FS to Entra ID Migration guide covers the application side.

Option B: keep federation, move MFA

Where user authentication cannot leave AD FS yet, upgrade to AD FS on Windows Server 2019 at farm behaviour level 4, which lets you select the authentication provider by group membership. On Windows Server 2016 at FBL 3 the migration is less seamless: users are prompted to choose between MFA Server and Entra MFA until migration completes.

Option C: RADIUS with the NPS extension

For VPNs and network devices that cannot speak SAML or OpenID Connect, deploy NPS with the Microsoft Entra MFA extension. Constraints from Microsoft's documentation that shape the design:

• No Conditional Access: the extension does not use Conditional Access policies, so every request reaching that NPS server requires MFA.
• Default method only: the request goes to the user's default method, even if that method is disabled in tenant policy. The user cannot choose another.
• Protocol limits: with PAP, phone call, text message, app notification and verification codes work; with MS-CHAPv2 and EAP, only phone call and app notification. Number matching is not supported over NPS, and Microsoft points to TOTP instead.
• Registration first: unregistered users fail. The REQUIRE_USER_MATCH registry value set to FALSE lets them through during onboarding; Microsoft says to remove it before production.
• Timeouts: set RADIUS client timeouts to at least 60 seconds, raising to 90 or 120 if duplicate requests are discarded.
• Certificate: the setup script creates a self-signed certificate valid for two years, used by the extension to authenticate to Entra ID. Track its expiry like any other machine credential. See the Network Policy Server Security guide.

Small organisations with a single VPN and no AD FS usually go straight to a SAML-federated VPN. Large organisations commonly run all three options at once, with Option C confined to a short, owned list of devices. For phishing-resistant targets see the Phishing-Resistant MFA Guide.

Testing and rollback

1. Back up first: back up PhoneFactor.pfdata before installing the MFA Server update that contains the Migration Utility. The update does not start migration automatically.
2. Register the utility: run Configure-MultiFactorAuthMigrationUtility.ps1 as Application Administrator and grant admin consent. Allow outbound access to graph.microsoft.com and login.microsoftonline.com.
3. Use separate groups: Microsoft recommends one set of Entra groups for syncing data with the utility and another for Staged Rollout. Staged Rollout supports up to 10 groups of 50,000 users each.
4. Sync, then pilot: the utility copies phone numbers, up to five mobile app devices and hardware OATH tokens into Entra ID. It is one-way and does not change where users perform MFA. Add a pilot group to Staged Rollout so Entra ID performs MFA for those users instead of sending them on-premises.
5. Check method policy: methods must be enabled in the Authentication methods policy or users cannot use them; the utility sets a disallowed default to the most secure allowed method.
6. Expand in batches: move by region, department or role, starting with test and pilot groups, as Microsoft advises.
7. Cut over: set federatedIdpMfaBehavior to rejectMfaByFederatedIdp so no user is redirected on-premises for MFA. Allow up to 24 hours to take effect.
8. Roll back if needed: uninstall MFA Server 8.1, restore the backed-up pfdata file, reinstall the previous version, set federatedIdpMfaBehavior back to enforceMfaByFederatedIdp and turn Staged Rollout for Entra MFA off. Changes users made to their methods in Entra ID are lost on rollback. Note that rollback returns you to a server Microsoft says no longer services MFA requests, so it is a short-term safety net during the migration window, not an end state.

For RADIUS, test with one VPN profile pointing at a new NPS server with the extension, a registered test account and the production client timeout before moving the load balancer pool.

Risks of doing nothing

• Silent loss of MFA: a RADIUS chain configured to fail open, or an AD FS policy that no longer requires a second factor because the adapter errors, leaves password-only access to remote access systems. Adversaries actively target MFA handling on these paths (ATT&CK T1556.006 Modify Authentication Process: Multi-Factor Authentication).
• Outages: where the chain fails closed, VPN and VDI access stops for every user still homed on MFA Server.
• Unpatched infrastructure: MFA Server and its web portal stay on the network as unsupported internet-adjacent components (NIST SP 800-53 SA-22 Unsupported System Components).
• No central visibility: second-factor events on MFA Server are absent from Entra sign-in logs, so MFA fatigue patterns (T1621 Multi-Factor Authentication Request Generation) go unseen. See the MFA Fatigue and Bypass Guide.
• Lost tokens: if hardware OATH seed files are gone, Microsoft states the secret keys cannot be exported from MFA Server, so those users need new tokens.

Practitioner checklist

• Confirm whether any MFA Server instance is still running and receiving traffic, and name an owner for each.
• Export every RADIUS client and record its protocol and preferred target (SAML, OIDC or NPS extension).
• Require combined security information registration for all in-scope users before moving them.
• Back up PhoneFactor.pfdata, install the latest update and register the Migration Utility.
• Pilot with Staged Rollout groups, then expand by batch with a written rollback step.
• Set federatedIdpMfaBehavior to rejectMfaByFederatedIdp once all groups are moved.
• Remove REQUIRE_USER_MATCH = FALSE from every NPS server after onboarding.
• Record the NPS extension certificate expiry and renew it on each server before it lapses.
• Replace or re-seed hardware OATH tokens whose seed files are lost.
• Decommission MFA Server hosts, remove the AD FS adapter and close the firewall rules.

Standards and references

• Microsoft Learn: Migrate from MFA Server to Microsoft Entra multifactor authentication
• Microsoft Learn: Getting started with the Azure Multi-Factor Authentication Server
• Microsoft Learn: MFA Server migration utility
• Microsoft Learn: Integrate your existing NPS infrastructure with Microsoft Entra multifactor authentication
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls
• NIST: Cybersecurity Framework 2.0
• MITRE ATT&CK: T1556.006 Modify Authentication Process: Multi-Factor Authentication
• CIS: Critical Security Controls v8.1

Related NHI Mgmt Group resources: AD FS Security Guide · Entra Per-User MFA to Conditional Access · Conditional Access Guide · RADIUS Security Guide · MFA Guide