Get the inside scoop with LoginTC and learn about relevant security news and insights.
May 03, 2024 •

Last reviewed: October 2026 | Reading time: about 9 minutes
Azure Multi-Factor Authentication Server is deprecated. Microsoft’s official guidance is to move to cloud-based Entra multifactor authentication. However, if your organization cannot move MFA to the cloud, Microsoft’s guidance does not apply to you, and you still need a supported on-premises MFA server. This post covers your real options: RADIUS appliances, Windows logon MFA, and fully air-gapped deployments.
Moving off Azure MFA Server? Book a 30-minute walkthrough of on-premises MFA for your RADIUS, Windows logon and AD FS integrations.
Most blog posts about Azure Multi-Factor Authentication Server tell you it’s deprecated and then point you at Entra ID. That advice works for maybe half the organizations running it. The other half operate air-gapped networks, OT environments, regulated data centers, or RADIUS-attached gear that cloud MFA simply cannot reach. If your organization cannot move MFA to the cloud, Microsoft’s guidance does not apply to you, and you still need a supported on-premises MFA server. This post is for you.
Most blog posts about Azure Multi-Factor Authentication Server tell you it’s deprecated and then point you at Entra ID. That advice works for maybe half the organizations running it. The other half operate air-gapped networks, OT environments, regulated data centers, or RADIUS-attached gear that cloud MFA simply cannot reach. If your organization cannot move MFA to the cloud, Microsoft’s guidance does not apply to you, and you still need a supported on-premises MFA server. This post is for you.
No. Azure Multi-Factor Authentication Server is not available for new deployments and is officially deprecated. Microsoft’s own documentation states: “Azure Multi-Factor Authentication Server (MFA Server) isn’t available for new deployments and is deprecated. Customers who are using MFA Server should move to using cloud-based Microsoft Entra multifactor authentication.” [Source: Microsoft Learn, “Migrate from MFA Server to Microsoft Entra multifactor authentication”, last updated 4 March 2025, https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-migrate-mfa-server-to-azure-mfa]
Azure MFA Server is end of life. It receives no new features and Microsoft does not recommend running it in production.
For many IT admins, this is not news. You already know it’s deprecated. The harder question is what you do when the recommended replacement, cloud-based Entra multifactor authentication, is not an option for your environment. That is the question the rest of this post answers.
Deprecated does not mean the software stops working overnight. It means Microsoft has stopped active development, the product receives no new feature updates, and security patches may be limited or eventually discontinued. In practice, this means your risk surface grows every month you stay on Azure MFA Server without a migration plan. More importantly, if you need to add new users, integrate new systems, or expand your deployment, you are working against the grain of a dead product.
Azure MFA Server was specifically built to integrate with on-premises Active Directory, and it did this well through RADIUS, LDAP, and Windows Authentication. The cloud-based replacement, Microsoft Entra multifactor authentication, works with Active Directory too, but it requires hybrid identity, meaning your AD must sync to Entra ID via Microsoft Entra Connect. That adds a dependency on internet connectivity and Microsoft’s cloud infrastructure.
Organizations with on-premises Active Directory can still use MFA, but the integration path depends entirely on whether your environment has reliable internet connectivity and meets Microsoft’s hybrid identity requirements. If you are keeping Active Directory on-premises, our on-premises MFA for Active Directory setup guide walks through the deployment.
Hybrid identity with Entra ID fails in several common scenarios. Air-gapped networks, by definition, have no route to Microsoft’s cloud. Some regulated sectors, including certain defense contractors and critical infrastructure operators, prohibit synchronizing directory credentials to any external cloud service. Others run disconnected sites, such as offshore platforms or remote industrial facilities, where internet uptime cannot be guaranteed. In all these cases, cloud-based Entra multifactor authentication is not a viable path. A self-contained, on-premises multi-factor authentication solution becomes the only compliant option. We cover the fully disconnected case in more detail on our air-gapped MFA page.
You have two realistic paths: move to Microsoft Entra multifactor authentication, or deploy a supported third-party on-premises MFA server. The right answer depends on your environment’s constraints. For a side-by-side of the two deployment models, see cloud vs. on-premises MFA.
If your environment supports hybrid identity, migrating to Entra multifactor authentication is Microsoft’s recommended route. You sync your on-premises Active Directory to Entra ID, configure Conditional Access policies, and users authenticate through Microsoft Authenticator or other supported methods. This works well for organizations whose users and applications all have reliable internet access. For detailed guidance on how Entra fits into your authentication stack, see our breakdown of external authentication methods in Microsoft Entra ID.
This is the path most posts ignore. A third-party on-premises MFA server runs inside your perimeter, talks directly to your Active Directory, and has no dependency on any external cloud. It can serve RADIUS clients like VPN concentrators and firewalls, protect Windows logon and RDP, and integrate with legacy line-of-business applications through LDAP. A properly deployed on-premises MFA server can replicate nearly every capability Azure MFA Server provided, using supported, actively maintained software.
This option matters most for the following environments:
Yes. Keeping MFA fully on-premises is a legitimate, compliant, and in many regulated environments the only permissible approach. On-premises MFA is not a workaround. For air-gapped networks, OT environments, and sovereign data requirements, it is the correct architecture.
RADIUS is the protocol that most VPN concentrators, firewalls, and network access controllers use to pass authentication requests. Azure MFA Server had a built-in RADIUS server that made this integration straightforward. Entra multifactor authentication does not natively receive RADIUS requests. As a result, organizations that migrated to Entra and assumed their VPN MFA would carry over often discovered their VPN no longer enforces a second factor.
A third-party on-premises MFA server with a RADIUS interface solves this directly. Your VPN or firewall sends authentication requests to the on-premises MFA server, which challenges the user for a second factor and returns an Accept or Reject to the network device. No internet dependency. No cloud roundtrip. Our RADIUS appliance documentation covers the specific integration patterns in detail.
Remote Desktop Protocol sessions and Windows workstation or server logons are another common failure point after a cloud migration. Entra multifactor authentication can protect these scenarios, but only when the machine is Entra-joined or hybrid-joined and has internet access at the time of authentication. A disconnected Windows server in a secure facility does not meet those conditions. On-premises MFA for Windows logon and RDP operates as a credential provider, intercepting authentication locally without requiring any cloud connection. See our guide on how to use offline MFA authentication for Windows logon and RDP for configuration specifics, or the Windows logon and RDP MFA product page for supported methods.
Many organizations run line-of-business applications built on older authentication protocols, typically RADIUS or LDAP. These applications cannot be redirected to a modern SAML or OIDC identity provider without significant development work. Azure MFA Server handled these through its LDAP proxy and RADIUS server components. A third-party on-premises MFA solution with equivalent proxy capabilities can replace those integrations directly, without requiring application changes. Two integrations that come up in almost every Azure MFA Server migration are AD FS and Exchange Server on-premises.
Microsoft Entra multifactor authentication is a capable platform for cloud-native and hybrid environments. However, it has specific limitations that affect a significant portion of enterprise environments.
Every Entra MFA challenge requires a round-trip to Microsoft’s cloud. If a device, application, or site cannot reach the internet at authentication time, the challenge fails. This is not a configuration issue. It is a fundamental architectural constraint of cloud-based authentication.
Entra multifactor authentication does not include a native RADIUS server. Microsoft offers the Network Policy Server (NPS) extension as a workaround for some scenarios. However, the NPS extension requires the authenticating server to have internet access, introduces latency, and adds an additional failure point. It also does not support all MFA methods in all configurations. For environments with dozens of RADIUS clients, managing NPS extensions across multiple servers adds operational complexity with no compensating benefit over a purpose-built on-premises solution.
Entra MFA does not support offline authentication. If a user’s device cannot reach Microsoft’s infrastructure, either because the site is air-gapped or because connectivity has failed, Entra MFA cannot complete. Some on-premises MFA solutions support offline one-time passcodes specifically for these scenarios, where the MFA challenge is generated and validated locally without any network call.
Sending authentication events to a cloud service operated by a foreign entity may violate data residency requirements in some jurisdictions. Entra ID stores data in Microsoft’s data centers, and while Microsoft offers specific region choices, authentication metadata still flows through Microsoft-operated infrastructure. Organizations subject to strict sovereignty requirements need MFA infrastructure they own and operate, with authentication data that never leaves their perimeter.
Migrating from Azure MFA Server to a supported third-party on-premises MFA server is a well-understood process. The high-level steps are consistent across most environments, though the specifics vary by integration type.
Before touching anything, document every system that currently authenticates through your Azure MFA Server. This includes RADIUS clients (VPNs, firewalls, switches), LDAP-connected applications, Windows servers protected by the MFA agent, and any custom SDK integrations. This audit determines your migration scope and your testing priorities. Most teams find more integrations than they expected.
Select a third-party on-premises MFA server that supports RADIUS, LDAP proxy, Active Directory integration, and a Windows credential provider. Deploy it in your environment. Configure its connection to your Active Directory. At this stage, the new server is live but not yet receiving production traffic.
Start with lower-risk integrations: internal applications, test VPN profiles, or non-production servers. Validate that authentication challenges are delivered correctly and that Access-Accept responses return to the RADIUS client. Next, move higher-risk systems: production VPNs, RDP gateways, and any application with a large user base. Keep the old Azure MFA Server running in parallel until every integration is tested and confirmed on the new platform.
User enrollment is often the most time-consuming part of a migration. Most modern on-premises MFA solutions support self-service enrollment portals. Some support TOTP tokens compatible with existing authenticator apps, which can reduce re-enrollment friction. Plan this phase carefully, communicate with users in advance, and provide a helpdesk escalation path for enrollment issues.
Once all integrations are running on the new platform and user enrollment is complete, you can retire the Azure MFA Server. Keep it available in a powered-off state for a short period in case an undocumented integration surfaces post-migration. After a clean period, decommission it fully.
LoginTC is designed specifically for environments like this. It runs entirely on-premises, integrates with Active Directory via LDAP, includes a built-in RADIUS server, and supports offline authentication for disconnected sites. Learn more about our approach to on-premises multi-factor authentication.
Azure MFA (Entra multifactor authentication) can protect some on-premises applications through the NPS extension or application proxy, but it requires internet connectivity at authentication time. Applications using RADIUS or LDAP natively are not directly supported without additional middleware. For environments with legacy on-premises applications and no reliable internet access, a third-party on-premises MFA server is the more reliable path.
You can use Entra multifactor authentication to protect Windows servers that are hybrid-joined to Entra ID, provided those servers have internet access during logon. Servers in air-gapped environments, isolated network segments, or disconnected sites cannot complete an Entra MFA challenge. For those scenarios, an on-premises MFA server with a Windows credential provider is the correct solution. Our guide to on-prem MFA for Windows Server covers Windows Server 2012 R2 to 2025.
Yes. Azure Multi-Factor Authentication Server is deprecated and not available for new deployments. Microsoft’s official documentation states customers should move to cloud-based Microsoft Entra multifactor authentication. The server receives no new feature development. Organizations that cannot move to the cloud should replace it with a supported third-party on-premises MFA solution rather than continuing to run deprecated software.
Microsoft no longer offers a supported on-premises MFA server of its own. The only supported Microsoft option is cloud-based Entra multifactor authentication, which requires internet connectivity. Organizations that need on-premises MFA should deploy a third-party solution that integrates with Active Directory via LDAP or RADIUS, runs entirely inside the network perimeter, and requires no cloud dependency for authentication to complete.
Yes, but with conditions. Entra multifactor authentication works with on-premises Active Directory through Microsoft Entra Connect, which synchronizes identities to the cloud. Authentication challenges still travel to and from Microsoft’s cloud infrastructure. If your Active Directory cannot sync to Entra ID due to air-gap requirements, data sovereignty rules, or policy restrictions, a third-party on-premises MFA server that connects directly to Active Directory via LDAP is the correct alternative.
For air-gapped networks, cloud-based Entra multifactor authentication is not an option. The replacement is a self-contained, on-premises MFA server deployed inside the air-gapped environment. It must integrate with Active Directory via LDAP, serve RADIUS clients directly, and support offline one-time passcodes for scenarios where even internal network connectivity cannot be guaranteed. LoginTC supports all of these deployment patterns without any cloud dependency.
Need On-Premises MFA After Azure MFA Server?
LoginTC runs entirely inside your perimeter, no cloud dependency required, ever.