{"id":9300,"date":"2026-07-09T15:28:16","date_gmt":"2026-07-09T12:28:16","guid":{"rendered":"https:\/\/www.protectimus.com\/blog\/?p=9300"},"modified":"2026-07-09T15:28:22","modified_gmt":"2026-07-09T12:28:22","slug":"azure-mfa-nps-extension-limitations-alternatives","status":"publish","type":"post","link":"https:\/\/www.protectimus.com\/blog\/azure-mfa-nps-extension-limitations-alternatives\/","title":{"rendered":"Azure MFA NPS Extension: Limitations, Costs & On-Prem Alternatives (2026)"},"content":{"rendered":"\n

The Azure MFA NPS Extension has been the go-to answer for adding a second factor to Microsoft NPS and securing VPN, Wi-Fi, and other network access protected by RADIUS authentication for years. It’s free (if you have the right license), it installs in under an hour, and it works. Until it doesn’t \u2014 and when it doesn’t, the failure mode is usually a structural one, not a configuration problem you can fix with a registry tweak.<\/p>\n\n\n\n

This article is for administrators who are already running the NPS Extension and have started hitting its ceilings: cloud dependencies that don’t fit your architecture, hardware token requirements that Azure can’t satisfy, or an air-gapped segment that simply can’t phone home to Entra ID. We’ll cover what the extension actually does, where it breaks down in practice, and what an on-premises RADIUS proxy alternative looks like side by side.<\/p>\n\n\n\n

TL;DR \/ Quick Answer<\/strong><\/h2>\n\n\n\n

The Azure MFA NPS Extension is a Microsoft-provided plugin for Windows Server NPS that adds a second authentication factor to RADIUS-authenticated services \u2014 VPN, Wi-Fi 802.1X, and dial-up. It works by intercepting successful primary authentication and triggering an Entra ID (formerly Azure AD) MFA challenge before returning an Access-Accept.<\/p>\n\n\n\n

Four structural limitations define where it stops working:<\/p>\n\n\n\n

    \n
  1. Cloud dependency<\/strong> \u2014 every authentication event requires a live connection to Entra ID. No internet, no MFA, no access.<\/li>\n\n\n\n
  2. No real hardware token support<\/strong> \u2014 OATH TOTP hardware tokens require Entra ID P1\/P2 licensing and have significant enrollment constraints.<\/li>\n\n\n\n
  3. Limited MFA methods<\/strong> \u2014 Microsoft Authenticator push and OATH TOTP only. No SMS, no email OTP, no chatbot.<\/li>\n\n\n\n
  4. On-premises AD requires Entra ID Connect<\/strong> \u2014 pure on-prem AD deployments need a sync layer to Azure before the extension functions at all.<\/li>\n<\/ol>\n\n\n\n

    If any of those four points describes your environment, an on-premises RADIUS proxy may be a better fit.<\/p>\n\n\n\n

    What the Azure MFA NPS Extension Does<\/strong><\/h2>\n\n\n\n

    Network Policy Server (NPS) is the built-in RADIUS server in Windows Server. It handles authentication for a wide range of services: RRAS-based VPN, Wi-Fi 802.1X via wireless access points, wired 802.1X, and dial-up. In most enterprise Windows environments, NPS is deeply embedded \u2014 it carries years of connection request policies, remote access policies, and accounting configuration.<\/p>\n\n\n\n

    The NPS Extension slots into this existing infrastructure as a post-authentication plugin. When a user’s password is validated successfully against Active Directory, the extension intercepts the authentication flow and calls out to Entra ID to trigger an MFA challenge. If the user approves the push notification or enters their OATH TOTP code, the extension signals NPS to return an Access-Accept. If MFA fails, the connection is denied.<\/p>\n\n\n\n

    From an architecture standpoint, this is elegant: you don’t change how NPS works, you don’t reconfigure your VPN gateway, and you don’t need a new RADIUS server. The extension adds one step to an existing flow.<\/p>\n\n\n\n

    The practical appeal is also clear. For organizations already in the Microsoft ecosystem \u2014 Entra ID licenses in place, Microsoft Authenticator rolled out to users, Entra ID Connect syncing on-prem AD \u2014 the extension is a fast, low-cost path to NPS MFA. Installation takes minutes, and for straightforward environments it works exactly as advertised.<\/p>\n\n\n\n

    The problems emerge at the edges of that “straightforward environment” assumption.<\/p>\n\n\n\n

    \n\n
    \n\n
    \n1. User<\/strong>\nStarts VPN or Wi-Fi authentication<\/small>\n<\/div>\n\n
    \n
    Username + password submitted<\/div>\n
    <\/div>\n
    \u25bc<\/div>\n<\/div>\n\n
    \n2. VPN \/ Wi-Fi Gateway<\/strong>\nForwards the RADIUS request to Microsoft NPS<\/small>\n<\/div>\n\n
    \n
    RADIUS Access-Request<\/div>\n
    <\/div>\n
    \u25bc<\/div>\n<\/div>\n\n
    \n3. Microsoft NPS<\/strong>\nValidates the primary credentials against Active Directory<\/small>\n<\/div>\n\n
    \n
    Password accepted by AD<\/div>\n
    <\/div>\n
    \u25bc<\/div>\n<\/div>\n\n
    \n4. Azure MFA NPS Extension<\/strong>\nInstalled on the NPS server as a post-authentication plugin<\/small>\n<\/div>\n\n
    \n
    Calls Entra ID for MFA verification<\/div>\n
    <\/div>\n
    \u25bc<\/div>\n<\/div>\n\n
    \n5. Entra ID<\/strong>\nTriggers MFA challenge via Microsoft Authenticator or OATH TOTP<\/small>\n<\/div>\n\n
    \n
    MFA approved<\/div>\n
    <\/div>\n
    \u25bc<\/div>\n<\/div>\n\n
    \n6. Access Granted<\/strong>\nNPS returns Access-Accept to the VPN or Wi-Fi gateway<\/small>\n<\/div>\n\n<\/div>\n<\/div>\n\n\n\n

    <\/p>\n\n\n\n

    Key takeaway:<\/strong> The NPS Extension doesn’t replace Microsoft NPS. It adds MFA after successful primary authentication and relies on Entra ID for every authentication request.<\/p>\n\n\n\n

    Where the NPS Extension Falls Short<\/strong><\/h2>\n\n\n\n

    Cloud and Entra ID Dependency<\/h3>\n\n\n\n

    The NPS Extension is not an on-premises MFA solution. Every authentication event \u2014 every VPN connection, every Wi-Fi 802.1X handshake \u2014 triggers an outbound call to Entra ID to validate the second factor. If that connection fails, authentication fails.<\/p>\n\n\n\n

    This creates a hard dependency that affects several real-world scenarios:<\/p>\n\n\n\n

    Internet outage or degraded connectivity.<\/strong> Remote office with a flaky WAN link? If Entra ID is unreachable, VPN authentication fails. Users working from a location with intermittent internet connectivity get locked out. The extension has a timeout and fallback mechanism, but “bypass MFA if Azure is unreachable” is not a security posture most organizations want to configure explicitly.<\/p>\n\n\n\n

    Regulated environments with outbound traffic restrictions.<\/strong> Industries with strict network segmentation \u2014 financial services, healthcare, defense contractors \u2014 often have outbound internet traffic tightly controlled or prohibited for certain network segments. The NPS Extension doesn’t work in those environments without firewall exceptions that may not be permissible.<\/p>\n\n\n\n

    Latency-sensitive authentication.<\/strong> The round-trip to Entra ID adds latency to every authentication. For most VPN connections this is imperceptible. For high-frequency authentication scenarios (automated processes, frequent session re-authentication), it accumulates.<\/p>\n\n\n\n

    The deeper issue is architectural: the NPS Extension converts what was an on-premises authentication decision into a cloud-dependent one. For organizations that chose on-premises NPS specifically to keep authentication traffic internal, this is a step backward.<\/p>\n\n\n\n

    No Real Hardware Token Support<\/h3>\n\n\n\n

    This is the limitation that comes up most often in practice. Hardware TOTP tokens \u2014 physical devices that generate time-based one-time passwords without a smartphone \u2014 are a requirement in several scenarios:<\/p>\n\n\n\n