Managing remote access security requires a decision most teams avoid until something goes wrong: where exactly should MFA be enforced? At the network edge, or on the host itself? The answer isn’t binary \u2014 but getting the layer wrong means either leaving critical servers exposed after a perimeter breach, or blocking legitimate administrators from getting in when the network stack misbehaves.<\/p>\n\n\n\n
This article breaks down the two enforcement models, what each one actually protects, and when using both together is the right call.<\/p>\n\n\n\n
There are two distinct layers where MFA can be enforced in a Windows environment:<\/p>\n\n\n\n
The fundamental difference between host-level and network-level MFA comes down to where in the access chain the second factor is checked.<\/p>\n\n\n\n
Host-level MFA<\/strong> sits inside the operating system. A Credential Provider agent installed on a Windows machine intercepts the logon process \u2014 whether that’s a local console login or an inbound RDP session. The MFA check happens before the Windows shell loads, meaning an attacker who reaches the login screen still can’t get in without the second factor.<\/p>\n\n\n\n Network-level MFA<\/strong> sits in front of your infrastructure. A RADIUS proxy receives authentication requests from a RADIUS-enabled service or device, validates the user’s password against Active Directory or LDAP, and then issues a second-factor challenge before returning an Access-Accept to the network device. The host never sees the unauthenticated connection attempt.<\/p>\n\n\n\n Neither layer is a substitute for the other. A network-level MFA deployment alone does not protect Windows logon or direct RDP authentication on the target host. If an attacker reaches the login screen through another path, host-level MFA remains the final control preventing unauthorized access. And according to Mandiant’s 2026 threat intelligence report (covering IR cases from 2025), attackers used RDP for lateral movement in approximately 85% of intrusions after gaining initial access. Stopping them at the VPN gateway doesn’t help if they got in through a different path.<\/p>\n\n\n\n Host-level MFA integrates directly into the Windows Authentication Architecture. The Protectimus Winlogon component<\/a> installs a custom Credential Provider on each Windows machine, intercepting the logon process immediately after primary credential submission and before the session is established.<\/p>\n\n\n\n When a user attempts to log in \u2014 via RDP or a physical console \u2014 the Credential Provider agent intervenes. It pauses the Windows logon sequence until MFA verification completes. If the user provides a valid OTP or approves a push notification, the agent releases the handshake and the Windows shell loads. If MFA fails or times out, access is denied regardless of whether the password was correct.<\/p>\n\n\n\n This happens at a level below the Windows session, which means it applies to every interactive authentication path, including local logon and Remote Desktop, before Windows establishes the user session.<\/p>\n\n\n\n LA Compatibility<\/p>\n\n\n\n Network Level Authentication (NLA) pre-authenticates the RDP connection before a full desktop session is established, which reduces the attack surface for pre-auth exploits. The Protectimus Winlogon component is fully compatible with NLA \u2014 it handles the MFA step within the NLA handshake, not after it. NLA should remain enabled; disabling it to accommodate an MFA solution is the wrong trade-off.<\/p>\n\n\n\n In environments where the Protectimus MFA server is temporarily unreachable \u2014 network outage, maintenance window, infrastructure failure \u2014 the Winlogon agent supports offline authentication. Pre-configured offline codes allow administrators to authenticate without a live connection to the MFA server. This is a meaningful operational advantage over RADIUS-dependent approaches for machine-local access.<\/p>\n\n\n\n For environments with more than a handful of machines, the Winlogon component supports GPO-based deployment from a domain controller, which means you can roll out host-level MFA to hundreds of servers without touching each one individually. Group Policy also handles configuration: which users require MFA, which machines are in scope, offline mode settings, and trusted device policies.<\/p>\n\n\n\n The MFA for Remote Desktop<\/a> page covers the RDP-specific deployment in detail, including configuration for RD Gateway environments and Remote Desktop Services farms.<\/p>\n\n\n\n The Coalition 2025 Cyber Claims Report found that remote access services were the entry point in 87% of ransomware incidents. But entry is only the first step. Once inside, attackers move laterally \u2014 and RDP is the tool of choice. Microsoft’s Digital Defense Report 2025 notes that RDP credentials appear in 53% of remote access listings on criminal marketplaces, which tells you exactly where post-breach attackers look first.<\/p>\n\n\n\n Host-level MFA breaks that pattern. Even with valid credentials \u2014 stolen, phished, or extracted from memory \u2014 an attacker hitting an RDP login prompt on a protected server still needs the second factor.<\/p>\n\n\n\n Network-level MFA shifts the verification burden to the perimeter. The Protectimus RADIUS MFA proxy<\/a> sits between your RADIUS clients and your identity source (Active Directory or LDAP), enforcing a second factor before authentication requests are approved. This model supports a wide range of RADIUS-enabled services, including VPN, VDI, PAM, and Linux authentication.<\/p>\n\n\n\n The flow is straightforward. A VPN gateway sends a RADIUS Access-Request to the Protectimus proxy. The proxy validates the user’s credentials against AD\/LDAP. If the password is correct, the proxy issues a RADIUS Access-Challenge \u2014 prompting the user for their OTP. The user enters the code; the gateway receives an Access-Accept and establishes the tunnel.<\/p>\n\n\n\n For network devices that don’t support RADIUS Access-Challenge (some older firmware versions handle authentication as a single round), Protectimus supports Inline Mode: the user enters their password and OTP together in a single field using a configured separator. The proxy parses the combined input, validates each component separately, and returns the appropriate response.<\/p>\n\n\n\n <\/p>\n\n\n\n Verizon DBIR 2025 data shows that exploitation of edge and VPN devices grew approximately 8x year-over-year, with 22% of breaches involving edge infrastructure \u2014 firewalls, VPN concentrators, and remote access gateways. Of the systems targeted, only about 54% were patched within the median 32-day window.<\/p>\n\n\n\n Network-level MFA doesn’t patch vulnerabilities, but it raises the bar significantly for credential-based attacks. Rapid7 and Cisco PSIRT documented that ransomware groups Akira and LockBit ran brute-force campaigns against Cisco ASA VPN endpoints \u2014 and found zero confirmed cases where a correctly configured MFA deployment was bypassed.<\/p>\n\n\n\n RADIUS is a standard protocol, but vendor implementations vary. A few specifics worth knowing before deployment:<\/p>\n\n\n\n Authentication timeout.<\/strong> Some VPN platforms use a default RADIUS timeout that is too short for users to retrieve and enter a one-time password. Increasing the timeout (typically to 30 seconds or more) is often required to avoid failed authentications.<\/p>\n\n\n\n Access-Challenge support. <\/strong>While most modern RADIUS clients support the Access-Challenge exchange required for interactive MFA, some legacy devices only support a single authentication round. For those systems, Protectimus supports Inline Mode, allowing users to enter their password and OTP together in one field.<\/p>\n\n\n\n Vendor-specific implementation details. <\/strong>Although RADIUS is a standard protocol, administrative interfaces and configuration workflows differ between vendors. Always follow the integration guide for your specific platform<\/p>\n\n\n\nHost-Level MFA: The Credential Provider Approach<\/strong><\/h2>\n\n\n\n
Technical Implementation<\/h3>\n\n\n\n
\nLocal console or Remote Desktop (RDP)<\/small>\n<\/div>\n\n
\nIntercepts the Windows logon process<\/small>\n<\/div>\n\n
\nOTP, Push, Hardware Token, Email or SMS<\/small>\n<\/div>\n\n
\nAccess granted<\/small>\n<\/div>\n\n<\/div>\n\n
\nWindows session is never created<\/small>\n<\/div>\n\n<\/div>\n\n<\/div>\n\n<\/div>\n\n<\/div>\n\n\n\n<\/h3>\n\n\n\n
Offline Mode<\/h3>\n\n\n\n
Deployment at Scale<\/h3>\n\n\n\n
Why Host-Level MFA Matters for Lateral Movement<\/h3>\n\n\n\n
Network-Level MFA: The RADIUS Proxy Approach<\/strong><\/h2>\n\n\n\n
Technical Implementation<\/h3>\n\n\n\n
\nEnters username and password in VPN \/ Wi-Fi client<\/small>\n<\/div>\n\n
\nVPN gateway, firewall, Wi-Fi controller, or RADIUS client<\/small>\n<\/div>\n\n
\nReceives the request and validates the first factor<\/small>\n<\/div>\n\n
\nActive Directory \/ LDAP validates the credentials<\/small>\n<\/div>\n\n
\nReturns a RADIUS Access-Challenge and prompts the user for an OTP<\/small>\n<\/div>\n\n
\nProtectimus verifies the one-time password<\/small>\n<\/div>\n\n
\nThe VPN tunnel or network session is established<\/small>\n<\/div>\n\n<\/div>\n<\/div>\n\n\n\nWhat Network-Level MFA Protects<\/h3>\n\n\n\n
\n
Why Network-Level MFA Matters for Perimeter Defense<\/h3>\n\n\n\n
Integration Realities: Where Things Get Complicated<\/h3>\n\n\n\n
Comparison<\/strong><\/h2>\n\n\n\n