Secure VPN access by placing multifactor authentication directly in the VPN login flow, preferably through a SAML identity provider such as Microsoft Entra ID or Okta. Require phishing-resistant MFA, limit access to approved users and devices, remove password-only fallbacks, and monitor every authentication attempt.

Reviewed on. This guide covers 2 common deployment paths: direct SAML federation and RADIUS-based MFA.

If the VPN cannot use SAML, connect it to an MFA-enabled RADIUS service such as Microsoft NPS with the Microsoft Entra MFA extension or a RADIUS MFA proxy such as Cisco Duo. Microsoft recommends direct SAML federation over the NPS extension when the VPN supports it because SAML can provide broader policy controls, including Conditional Access and device compliance.

VPN capability Recommended MFA method Best use
SAML-enabled SSL VPN or cloud VPN Direct federation with an identity provider Modern VPN deployments
RADIUS-only VPN RADIUS MFA proxy or NPS MFA extension Legacy appliances and traditional remote-access VPNs
High-security administrative VPN FIDO2 security key, passkey or smart card with device controls Privileged administrators and sensitive systems
Temporary deployment without phishing-resistant MFA Number-matching authenticator app Interim protection while stronger MFA is deployed

CISA recommends phishing-resistant MFA for VPNs and other systems that provide access to company networks. FIDO and WebAuthn authentication, including security keys and passkeys, are designed to resist common credential phishing attacks.

1. Identify How the VPN Authenticates Users

Before configuring MFA, identify the VPN's current authentication method:

  • SAML or another identity-provider integration
  • RADIUS
  • LDAP or Active Directory
  • Local VPN accounts
  • Client certificates
  • Pre-logon or machine authentication

The existing method determines how MFA should be added.

Use Direct SAML Federation When the VPN Supports It

A SAML-capable VPN redirects the user to an identity provider for authentication. The identity provider validates the password, enforces MFA and evaluates access policies before returning an authentication assertion to the VPN.

This setup centralizes:

  • User and group management
  • MFA enforcement
  • Device compliance checks
  • Conditional Access rules
  • Sign-in risk policies
  • Authentication logging
  • Account revocation

FortiGate can act as a SAML service provider for SSL VPN while Microsoft Entra ID, Okta or FortiAuthenticator acts as the identity provider. Palo Alto GlobalProtect also supports SAML authentication for remote-access VPN deployments.

Use RADIUS MFA for Legacy VPNs

RADIUS is appropriate when the VPN appliance cannot redirect users to a SAML identity provider.

A typical RADIUS MFA flow works as follows:

  1. The user enters a VPN username and password.
  2. The VPN sends the request to a RADIUS server or MFA proxy.
  3. The RADIUS service validates the primary credentials.
  4. The MFA service sends a second-factor challenge.
  5. The user approves the request or supplies a code.
  6. The RADIUS service returns an access-accept response.
  7. The VPN establishes the tunnel.

Microsoft NPS can act as a RADIUS server for VPN authentication, and the Microsoft Entra MFA NPS extension can add a secondary authentication challenge. Cisco Duo uses a similar design by placing its Authentication Proxy between the VPN and an existing Active Directory or RADIUS server.

2. Create a Dedicated VPN Access Group

Do not grant VPN access to every directory user by default.

Create a dedicated group such as:

  • VPN-Users
  • Privileged-VPN-Users
  • Third-Party-VPN-Users

Assign access according to job role and business need. Use separate groups for:

  • Standard employees
  • IT administrators
  • Contractors
  • Vendors
  • Managed service providers
  • Temporary users

The VPN should authorize access through group membership from the identity provider or directory. Disable local VPN accounts where possible, except for tightly controlled emergency access.

3. Require Strong MFA Factors

Use the strongest authentication method supported by the VPN and identity provider.

Preferred MFA Methods

  1. FIDO2 security keys
  2. Passkeys using WebAuthn
  3. Platform authenticators such as Windows Hello or Touch ID
  4. Smart cards or client certificates combined with a second factor
  5. Authenticator apps with number matching
  6. Time-based one-time passwords
  7. SMS codes only when stronger options are unavailable

CISA describes number matching as a stronger interim option than ordinary push approval because it helps reduce push-bombing attacks. SMS is not phishing-resistant and should not be the preferred factor for privileged VPN access.

Require phishing-resistant MFA for administrator access instead of a generic push notification. A security key or passkey binds authentication to the legitimate website or application, making stolen passwords and fake VPN login pages less useful to attackers.

4. Apply an Identity-Provider Access Policy

Configure the identity provider to require MFA for the VPN application.

A strong VPN access policy should:

  • Require MFA for every VPN connection
  • Require phishing-resistant MFA for administrators
  • Allow access only to assigned VPN groups
  • Require compliant or managed devices where possible
  • Block disabled, suspended or unregistered accounts
  • Block high-risk sign-ins
  • Restrict access by country or network when appropriate
  • Require reauthentication for sensitive administrative access
  • Prevent users from registering unapproved authentication methods

Microsoft Entra ID can apply a Conditional Access policy to the Azure VPN Client application and require multifactor authentication for selected users or groups. Microsoft identifies Conditional Access as the recommended way to apply granular MFA controls to Azure VPN access.

A dedicated VPN policy is easier to review than a general organization-wide MFA policy. It also allows stricter rules for privileged users and creates a clear record that remote network access is protected.

5. Configure the VPN to Prevent Bypasses

MFA does not protect the environment if users can reach the same network through an unprotected authentication path.

Check the VPN configuration for:

  • Local users that bypass the identity provider
  • A secondary VPN gateway without MFA
  • Clientless web access with weaker authentication
  • Emergency accounts accessible to ordinary administrators
  • Separate authentication paths using different directories
  • Old VPN profiles distributed to users
  • Unauthenticated pre-logon access
  • Password-only machine tunnels
  • Legacy protocols that remain enabled

Disable password-only access wherever practical. If a break-glass account is required, restrict it to a small number of administrators, protect it with a separate strong credential, monitor every use and rotate it after emergency access.

6. Restrict What Authenticated VPN Users Can Reach

Successful MFA should not provide unrestricted access to the corporate network.

Use network segmentation and least privilege to limit users to the resources they need. For example:

  • Finance users can access finance applications but not server administration networks.
  • Contractors can access a specific application subnet but not internal file shares.
  • IT administrators can use a dedicated privileged-access VPN profile.
  • Vendors can receive time-limited access to named systems.
  • Standard users can access business applications without reaching management interfaces.

Apply separate VPN address pools, firewall policies and routing rules for different user groups. A user who passes MFA should still receive only the network access authorized for that user's role.

7. Harden the VPN Gateway Itself

MFA does not compensate for an unpatched or poorly configured VPN appliance.

At minimum:

  • Keep the VPN gateway and client software supported and patched.
  • Use strong cryptography and disable obsolete algorithms.
  • Expose only the ports and services required for VPN operation.
  • Disable unused VPN features.
  • Restrict administrative access to trusted networks or dedicated administrator workstations.
  • Use secure certificates from a trusted certificate authority.
  • Set session and idle timeouts appropriate to the risk.
  • Revoke access quickly when an employee leaves or changes role.
  • Review VPN configuration changes through change control.

CISA recommends limiting external exposure of VPN gateways, using strong cryptography and disabling unused features. CISA also recommends phishing-resistant MFA for accounts that access company networks and sensitive administrative systems.

8. Configure Logging and Alerting

Record successful and failed VPN authentication events.

Useful log fields include:

  • Username
  • Source IP address
  • Device identifier
  • Geographic location
  • VPN gateway
  • Authentication method
  • MFA result
  • Group or role used for authorization
  • Connection start and end time
  • Assigned VPN address
  • Disconnect reason
  • Policy decision

Send VPN, identity-provider and MFA logs to a central security information and event management system.

Alert on:

  • Repeated failed VPN logins
  • MFA push-bombing patterns
  • Successful logins from an unusual country
  • Impossible travel between sign-ins
  • New device enrollment followed by VPN access
  • Access outside normal working hours
  • VPN logins from anonymous or suspicious networks
  • Use of emergency accounts
  • Sudden access by disabled or recently reactivated accounts

Review authentication logs alongside endpoint and identity logs. A successful MFA event does not prove that the device is safe.

9. Test the Complete Login and Recovery Process

Test with a nonproduction user before enforcing the policy for everyone.

Verify that:

  • Authorized users can connect.
  • Unauthorized users are denied.
  • MFA is required before the tunnel is established.
  • Group membership maps to the correct VPN profile.
  • Device compliance rules work as intended.
  • The VPN client supports the selected MFA flow.
  • RADIUS timeouts allow enough time for MFA approval.
  • A failed MFA challenge does not create a connected session.
  • Revoked users lose access promptly.
  • Backup authentication works without creating a bypass.
  • Help-desk recovery procedures require identity verification.

RADIUS deployments need particular attention to timeout values. Cisco Duo notes that out-of-band authentication may require the VPN client to wait at least 60 seconds for the user to complete the challenge.

Test these failure scenarios:

  • Identity provider unavailable
  • MFA service unavailable
  • RADIUS server unavailable
  • User loses their phone or security key
  • VPN gateway fails over to a secondary node
  • Certificate expires
  • User is removed from the VPN group
  • An attacker repeatedly sends MFA prompts

Choose fail-closed behavior for privileged and highly sensitive VPN access. A fail-open design grants access when the MFA service is unavailable and creates a direct bypass during an outage.

Microsoft Entra ID Implementation Example

For an Azure point-to-site VPN using Microsoft Entra ID:

  1. Enable Microsoft Entra authentication for the Azure VPN Client.
  2. Create a group for authorized VPN users.
  3. Assign the group to the Azure VPN enterprise application.
  4. Create a Conditional Access policy for the Azure VPN Client application.
  5. Require multifactor authentication.
  6. Add device compliance, sign-in risk or location conditions where appropriate.
  7. Configure the VPN client profile.
  8. Test with an authorized user and an unauthorized user.
  9. Review Entra sign-in logs and Azure VPN connection logs.

For an older RADIUS-based VPN:

  1. Deploy a supported RADIUS server or MFA proxy.
  2. Add the VPN appliance as a RADIUS client.
  3. Configure a strong shared secret.
  4. Connect the RADIUS service to Active Directory or another primary identity source.
  5. Enable the MFA integration.
  6. Set VPN authentication to use the RADIUS server.
  7. Configure sufficient timeout and retry values.
  8. Test successful, failed and unavailable-MFA scenarios.
  9. Monitor both RADIUS and MFA logs.

VPN MFA Security Baseline

Use this checklist as an acceptance test:

  • MFA is mandatory for every remote VPN connection.
  • Administrators use phishing-resistant MFA.
  • VPN access is assigned through dedicated groups.
  • Local password-only VPN accounts are disabled.
  • Devices are managed or checked for compliance where possible.
  • VPN users receive segmented, role-based network access.
  • The VPN gateway is patched and externally hardened.
  • Authentication events are centrally logged.
  • Emergency access is restricted and monitored.
  • MFA failure does not result in VPN access.
  • Access is reviewed regularly and revoked promptly.

Choose direct SAML federation for a new VPN deployment when the appliance supports it. Keep RADIUS MFA for appliances that cannot redirect users to an identity provider, and set a plan to replace that dependency when the VPN platform changes.