Host-Level vs Network-Level MFA: Credential Provider (RDP/Windows Logon) vs RADIUS Proxy (VPN/Wi-Fi)

Posted By Anna on Jul 2, 2026 | 0 comments

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 — 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.

This article breaks down the two enforcement models, what each one actually protects, and when using both together is the right call.

TL;DR / Quick Answer

There are two distinct layers where MFA can be enforced in a Windows environment:

• Host-level MFA (Windows Credential Provider) intercepts authentication directly on the machine — at the Windows logon screen or during an RDP session. It protects the host regardless of how the user reached it. Works with NLA. Supports offline mode. Best for servers, jump hosts, and workstations.
• Network-level MFA (RADIUS proxy) enforces a second factor at the network edge for VPN, VDI, and other RADIUS-authenticated services before users reach internal resources. No agent required on individual hosts. Best for remote access and network perimeter.
• Strategy: most enterprise environments need both. Network-level MFA stops attackers at the perimeter; host-level MFA stops lateral movement after a perimeter breach.

The Two Enforcement Layers

The fundamental difference between host-level and network-level MFA comes down to where in the access chain the second factor is checked.

Host-level MFA sits inside the operating system. A Credential Provider agent installed on a Windows machine intercepts the logon process — 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.

Network-level MFA 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.

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.

Host-Level MFA: The Credential Provider Approach

Host-level MFA integrates directly into the Windows Authentication Architecture. The Protectimus Winlogon component installs a custom Credential Provider on each Windows machine, intercepting the logon process immediately after primary credential submission and before the session is established.

Technical Implementation

When a user attempts to log in — via RDP or a physical console — 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.

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.

LA Compatibility

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 — 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.

Offline Mode

In environments where the Protectimus MFA server is temporarily unreachable — network outage, maintenance window, infrastructure failure — 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.

Deployment at Scale

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.

The MFA for Remote Desktop page covers the RDP-specific deployment in detail, including configuration for RD Gateway environments and Remote Desktop Services farms.

Why Host-Level MFA Matters for Lateral Movement

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 — 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.

Host-level MFA breaks that pattern. Even with valid credentials — stolen, phished, or extracted from memory — an attacker hitting an RDP login prompt on a protected server still needs the second factor.

Network-Level MFA: The RADIUS Proxy Approach

Network-level MFA shifts the verification burden to the perimeter. The Protectimus RADIUS MFA proxy 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.

Technical Implementation

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 — prompting the user for their OTP. The user enters the code; the gateway receives an Access-Accept and establishes the tunnel.

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.

What Network-Level MFA Protects

• VPN access — any SSL VPN or IPsec gateway using RADIUS authentication: Cisco ASA/FTD, Fortinet FortiGate, Palo Alto GlobalProtect, SonicWall, Juniper, Check Point, F5 APM
• Virtual Desktop Infrastructure (VDI) — RADIUS-enabled remote desktop platforms such as VMware Horizon, Parallels RAS, Citrix ADC/Gateway, NetApp VDS, Nerdio, and NComputing vSpace.
• Privileged Access Management (PAM) — RADIUS-enabled administrative access platforms such as Wallix PAM.
• Linux systems — SSH and system logon protected through RADIUS authentication.

Why Network-Level MFA Matters for Perimeter Defense

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 — firewalls, VPN concentrators, and remote access gateways. Of the systems targeted, only about 54% were patched within the median 32-day window.

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 — and found zero confirmed cases where a correctly configured MFA deployment was bypassed.

Integration Realities: Where Things Get Complicated

RADIUS is a standard protocol, but vendor implementations vary. A few specifics worth knowing before deployment:

Authentication timeout. 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.

Access-Challenge support. 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.

Vendor-specific implementation details. Although RADIUS is a standard protocol, administrative interfaces and configuration workflows differ between vendors. Always follow the integration guide for your specific platform

Comparison

The table makes the complementary nature of the two layers obvious: network-level MFA stops attackers before they reach the internal network; host-level MFA stops them from moving laterally once they’re inside.

Using Both Together: The Architecture Strategy

Most enterprise environments don’t choose one layer — they deploy both and configure them so a single token enrollment covers everything.

The practical architecture: a Protectimus deployment with both the Winlogon agent (on Windows hosts) and the RADIUS proxy (protecting RADIUS-enabled services) means a user enrolls one authenticator app or hardware token and uses it for VPN login, Windows logon, and RDP sessions. One enrollment, one helpdesk workflow, centralized administration.

Microsoft’s data shows MFA blocks more than 99.2% of automated account compromise attacks. The remaining vectors — session hijacking, MFA fatigue attacks, SIM swapping — are harder to execute at scale and require targeted effort rather than automated tooling.

For organizations managing Active Directory at scale, adding a directory-level MFA layer via two-factor authentication for Active Directory extends protection to LDAP binds and AD-integrated applications — covering authentication paths that neither the Winlogon agent nor the RADIUS proxy touches directly.

For environments where some users require authentication without a smartphone — manufacturing floors, secure facilities, roles where personal devices aren’t permitted — hardware TOTP tokens work across both layers from a single enrollment.

Defense in Depth in Practice

Consider a realistic attack scenario: an attacker obtains valid VPN credentials through phishing. Network-level MFA stops them at the gateway — they have the password but not the second factor. Now consider a variant where the attacker compromises another account that has VPN access but isn’t protected by MFA due to a configuration gap. They get through the VPN.

At that point, host-level MFA is the next barrier. Every server they attempt to reach via RDP presents an MFA prompt. Without the registered second factor for those accounts, lateral movement stalls.

Neither layer alone closes both scenarios. Both layers together do.