Skip to main content
Point-to-site (P2S) VPNs let individual devices create secure tunnels to an Azure virtual network. Choosing the right P2S authentication method affects security, manageability, and end-user experience. This document explains the three common P2S authentication options, how they work, typical use cases, and guidance for picking the right approach.

​
Overview

Three common P2S authentication methods:
  • Certificate-based authentication (device-level trust)
  • Microsoft Entra ID (cloud-based, modern identity)
  • Active Directory Domain (via RADIUS) (on‑premises credential validation)
Each method trades off between administrative overhead, security, and user convenience. Use the guidance below to match the method to your environment.

​
Azure certificate authentication

How it works
  • A trusted root certificate (public key) is uploaded to the Azure VPN gateway.
  • Client certificates, issued (signed) by that root certificate, are installed on each client device.
  • When a client connects, the VPN gateway validates the client certificate. Only devices with a valid signed client certificate are allowed to connect.
When to use it
  • You need device-level assurance (ensuring only managed devices connect).
  • You operate your own PKI or can centrally issue and manage certificates.
  • You want a solution that does not depend on online authentication services for each connection.
Pros and cons
  • Pros: strong device authentication, resilient to password-based attacks, good for controlled device fleets.
  • Cons: certificate lifecycle and distribution overhead, revocation management, less convenient for end users than username/password or cloud SSO.
Helpful links
  • Azure documentation: certificate-based P2S VPN authentication
  • Consider combining with Intune or other device management for certificate distribution.

​
Microsoft Entra ID authentication (modern, cloud-based)

How it works
  • Users authenticate with their Microsoft Entra ID (formerly Azure AD) work accounts.
  • The VPN gateway redirects authentication to Entra ID; Entra evaluates identity and any configured conditional access policies (MFA, device compliance).
  • Supports modern controls such as multifactor authentication (MFA) and conditional access.
Why it’s often chosen
  • Centralized identity in the cloud with no on‑premises authentication servers required.
  • Good user experience—users sign in with familiar credentials.
  • Enables conditional access and MFA for VPN access, improving security posture without additional infrastructure.
Entra Authentication is used here as the demonstration choice because it is simple to configure and lightweight for users.
A diagram titled "Point-to-Site Authentication Methods" showing an Azure VNET connected to an on‑prem VPN via IPsec/IKE site‑to‑site and a P2S VPN client tunnel, with on‑prem networks, RADIUS and AD Domain Services depicted. A banner at the bottom notes Microsoft Entra Authentication integration for MFA and conditional access.
Pros and cons
  • Pros: centralized administration, integrates with MFA and conditional access, simpler for cloud-first organizations, no on‑prem RADIUS servers required.
  • Cons: requires Entra ID accounts and configuration; organizations with strict on‑prem-only policies may prefer other methods.
Helpful links

​
Active Directory Domain (RADIUS) authentication

How it works
  • VPN clients authenticate using their on‑premises domain credentials.
  • The VPN gateway forwards credentials to a RADIUS server (deployed on‑prem), which validates them against Active Directory Domain Services (AD DS).
  • RADIUS can also integrate with secondary controls like MFA solutions (if deployed in your environment).
When to use it
  • You have an existing on‑premises AD environment and want to reuse domain users and passwords.
  • You want to keep authentication processing within your on‑prem infrastructure (hybrid scenarios).
Pros and cons
  • Pros: leverages existing AD accounts and policies, familiar admin model.
  • Cons: requires RADIUS infrastructure and connectivity from the VPN gateway to the RADIUS servers; higher on‑prem operational overhead.
A network diagram titled "Point-to-Site Authentication Methods" showing an Azure VNET connected to an on‑prem VPN via an IPsec/IKE site‑to‑site tunnel and to a VPN client via a P2S tunnel. It highlights Active Directory (AD) domain authentication using a RADIUS server to validate VPN users against on‑premises AD domain services.

​
Quick comparison

MethodAuthentication flowBest forProsCons
Certificate-basedClient certificate validates to VPN gatewayManaged device fleets, strict device assuranceStrong device-level trust; not password-dependentCertificate issuance & lifecycle management
Microsoft Entra IDEntra ID SSO/OAuth + optional MFA & conditional accessCloud-first organizationsCentralized identity, MFA & conditional access, good UXRequires Entra accounts & cloud integration
AD Domain (RADIUS)VPN gateway -> RADIUS -> AD DSHybrid environments reusing on‑prem credentialsReuses existing AD accounts; familiar admin modelRequires RADIUS servers and reliable connectivity

​
Summary and guidance

  • Certificate authentication: choose when you control a PKI or need strict device-based assurance.
  • Microsoft Entra ID authentication: a modern, scalable option that integrates with MFA and conditional access—recommended for cloud-first environments.
  • AD Domain (RADIUS) authentication: the right choice for hybrid deployments that must validate credentials against on‑premises AD.
Choose the P2S authentication method that matches your environment: use Microsoft Entra ID for cloud-integrated identity and conditional access, certificates for strict device authentication, and RADIUS/AD for hybrid setups that rely on on‑premises domain credentials.

Watch Video