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. User starts Windows logon Local console or Remote Desktop (RDP) ▼ Protectimus Winlogon Agent Intercepts the Windows logon process ▼ MFA Verification OTP, Push, Hardware Token, Email or SMS Authentication Successful? Yes ▼ Windows Session Access granted No...