Azure MFA NPS Extension: Limitations, Costs & On-Prem Alternatives (2026)

Posted By Anna on Jul 9, 2026 | 0 comments

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 — and when it doesn’t, the failure mode is usually a structural one, not a configuration problem you can fix with a registry tweak.

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.

TL;DR / Quick Answer

The Azure MFA NPS Extension is a Microsoft-provided plugin for Windows Server NPS that adds a second authentication factor to RADIUS-authenticated services — 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.

Four structural limitations define where it stops working:

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

If any of those four points describes your environment, an on-premises RADIUS proxy may be a better fit.

What the Azure MFA NPS Extension Does

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 — it carries years of connection request policies, remote access policies, and accounting configuration.

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.

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.

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

The problems emerge at the edges of that “straightforward environment” assumption.

Key takeaway: The NPS Extension doesn’t replace Microsoft NPS. It adds MFA after successful primary authentication and relies on Entra ID for every authentication request.

Where the NPS Extension Falls Short

Cloud and Entra ID Dependency

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

This creates a hard dependency that affects several real-world scenarios:

Internet outage or degraded connectivity. 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.

Regulated environments with outbound traffic restrictions. Industries with strict network segmentation — financial services, healthcare, defense contractors — 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.

Latency-sensitive authentication. 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.

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.

No Real Hardware Token Support

This is the limitation that comes up most often in practice. Hardware TOTP tokens — physical devices that generate time-based one-time passwords without a smartphone — are a requirement in several scenarios:

• Users without smartphones (warehouse staff, manufacturing floor workers, certain regulated roles)
• Environments where personal devices are prohibited
• Air-gapped or physically secure facilities
• Organizations that prefer physical tokens for privileged access accounts

The NPS Extension’s support for hardware tokens is narrow. OATH TOTP tokens are supported, but only through Entra ID’s hardware token upload process, which requires Entra ID P1 or P2 licensing. The upload process itself is cumbersome: administrators export a seed file from the token vendor, format it as a CSV, and import it into Entra ID through the portal. Re-programming tokens isn’t supported — each token is tied to its factory seed.

For organizations running OATH-compatible hardware tokens — including programmable tokens that can be re-seeded — the NPS Extension cannot accommodate them without the Azure licensing overhead and import workflow.

Limited MFA Methods

The NPS Extension supports two second-factor methods: Microsoft Authenticator (push notifications and TOTP via the app) and OATH TOTP hardware tokens via Entra ID. That’s it.

No SMS OTP. No email OTP. No chatbot delivery (Telegram, Viber).

For most corporate environments, Microsoft Authenticator push covers the majority of users. But exceptions exist — users without smartphones, users in poor cellular coverage areas who can’t receive push reliably, users in regions where the Microsoft Authenticator app has compatibility issues. Those users have no supported fallback within the NPS Extension other than hardware tokens, which circle back to the licensing and workflow issues above.

On-Premises AD Requires Entra ID Connect

The NPS Extension authenticates against Entra ID, not directly against on-premises Active Directory. For organizations with hybrid identity — Entra ID Connect syncing on-prem AD to Azure — this works. Entra ID has a synchronized copy of the user accounts, and the extension can find them.

For organizations running purely on-premises Active Directory without Entra ID Connect, the extension doesn’t work without first setting up the sync. That’s not a trivial addition: Entra ID Connect requires an Azure subscription, a sync server, and ongoing maintenance. For organizations that have deliberately stayed off Azure — whether for cost, compliance, or architectural reasons — this is a significant prerequisite, not a quick configuration step.

LDAP directories (OpenLDAP, custom LDAP implementations) are not supported at all.

Azure MFA NPS Extension vs On-Prem RADIUS MFA

The table makes the trade-off concrete. The NPS Extension wins on simplicity for organizations already deep in the Microsoft ecosystem with Entra ID licenses in place. The RADIUS proxy is a better fit for organizations that need air-gapped deployments, broader hardware token support, non-Azure AD directories, or a fully on-premises MFA architecture.

One nuance worth noting: a RADIUS proxy doesn’t replace the existing RADIUS infrastructure — it sits in front of it. In architectures that use a backend RADIUS server such as Microsoft NPS, MFA can be enforced by the proxy before authentication requests are forwarded onward. This approach allows organizations to introduce MFA while continuing to use their existing RADIUS infrastructure.

When an On-Prem RADIUS Proxy Is the Better Fit

Four scenarios consistently make an on-premises RADIUS proxy a better fit than the NPS Extension:

Air-gapped and network-isolated environments. If authentication traffic cannot leave the network perimeter — whether due to regulatory requirements, physical security constraints, or network architecture — the NPS Extension is simply not an option. A RADIUS proxy deployed on-premises handles the entire MFA flow internally, with no outbound calls to any cloud service. This covers defense contractors, certain healthcare environments, financial infrastructure, and industrial control system networks.

Hardware token requirements. When a significant portion of users needs physical TOTP tokens — and especially when programmable or re-seedable tokens are required — the NPS Extension’s OATH import process doesn’t scale. A RADIUS proxy with direct OATH TOTP support handles any OATH-compatible token without the Entra ID intermediary and without P1/P2 licensing overhead.

Off-Azure or hybrid-avoidance architectures. Some organizations have made a deliberate decision to stay on-premises for identity infrastructure — cost, compliance, data residency, or simplicity. For those environments, introducing Entra ID Connect as a prerequisite for NPS MFA is not acceptable. A RADIUS MFA proxy that authenticates directly against on-premises AD or LDAP fits into the existing architecture without pulling it toward Azure.

Broader MFA method coverage. Environments that need SMS OTP as a fallback, email OTP for users without smartphones, or chatbot delivery for specific user populations can’t get there with the NPS Extension. A RADIUS proxy that supports SMS, email, chatbots, and physical OATH hardware tokens covers those edge cases from the same platform and the same enrollment workflow.

Organizations that need MFA for Active Directory, Windows logon, RDP, and RADIUS-based authentication from a single on-premises MFA platform may also benefit from a unified deployment model with centralized user and token management.

FAQ

Does the Azure MFA NPS Extension work without Entra ID?

No. The NPS Extension requires a live connection to Entra ID (Azure AD) for every authentication event. Organizations without Entra ID, or with on-premises AD that hasn’t been synced to Entra ID via Entra ID Connect, cannot use the extension. A RADIUS proxy that authenticates directly against on-premises AD or LDAP is the alternative for those environments.

Can the NPS Extension use hardware tokens?

Yes, with significant constraints. OATH TOTP hardware tokens are supported through Entra ID’s token import process, which requires Entra ID P1 or P2 licensing. The import process requires a seed file from the token vendor, formatted as a CSV and uploaded via the Azure portal. HOTP (counter-based) tokens are not supported. Programmable tokens that can be re-seeded are difficult to manage in this workflow.

Does the NPS Extension work in air-gapped networks?

No. Every MFA verification requires an outbound call to Entra ID. Air-gapped networks — where no traffic is permitted to leave the perimeter — cannot use the NPS Extension. On-premises RADIUS proxy solutions handle the full authentication flow locally with no external dependencies.

What’s the practical difference between NPS Extension and a RADIUS proxy?

The NPS Extension is a plugin installed directly on the Microsoft NPS server. It adds MFA by routing secondary authentication to Entra ID while keeping NPS as the RADIUS server. A RADIUS proxy is a separate component that performs MFA before forwarding authentication requests to a backend RADIUS server. This architecture allows organizations to introduce MFA without relying on a cloud identity provider and can be integrated into existing on-premises RADIUS deployments.

Is the Azure MFA NPS Extension free?

The extension itself is free to download and install. However, using it effectively requires Microsoft Entra ID (formerly Azure AD). For hardware token support, Entra ID P1 or P2 licensing is required, which adds per-user monthly cost. For organizations not already paying for Entra ID P1/P2, the “free” extension comes with a licensing prerequisite that may not be free at all.