Entra ID and VPN SSO done right: what really matters in a VPN deployment

Single sign-on for a VPN sounds like a checkbox. You wire Entra ID up to your VPN gateway as a SAML or OIDC application, users authenticate with their corporate identity instead of a local account, and everyone moves on. But the gap between a VPN that technically uses Entra ID SSO and one that’s properly secured is enormous.

A VPN is, by definition, a doorway into your internal network. It deserves more scrutiny than almost any other application you protect. Here’s what separates a deployment done right from one that merely functions.

Start with the threat you’re defending against

The whole point of putting Entra ID in front of your VPN is to stop an attacker who has a valid password from walking straight into your network. Password spray, credential stuffing, and phishing are not theoretical. They are a daily reality. Every design choice below should be measured against one question: if an attacker has my password right now, what stops them?

MFA every time

The single most important control is multi-factor authentication, enforced on the VPN every time a session is established. This is where a lot of deployments quietly fail. They turn on MFA, but they also leave generous “remember this device” and sign-in frequency settings in place, so in practice, the second factor was satisfied weeks ago and the VPN can connect on a cached token.

For a network-layer doorway, that’s too insecure. Configure a Conditional Access policy that targets your VPN application specifically and requires MFA, then pair it with a sign-in frequency control so the token can’t be silently reused for days. Many organizations set VPN sign-in frequency to a single workday or tighter, depending on risk tolerance. The trade-off is that users will re-authenticate more often, but a VPN is exactly the kind of high-value resource where that friction is justified.

Understand how tokens actually behave

This is the part many teams underestimate. When Entra ID issues credentials after a successful sign-in, it issues an access token, an ID token, and a refresh token. The access token is short-lived (typically about an hour). The refresh token lives much longer and is what silently mints new access tokens in the background, which is precisely why a “remembered” session can outlive your intentions.

For a VPN, you want to govern that lifetime deliberately rather than accept defaults:

• Use sign-in frequency in Conditional Access to force a fresh interactive authentication (and therefore a fresh MFA challenge) on the cadence you’ve chosen.
• Understand that Continuous Access Evaluation (CAE) can revoke access near-real-time when conditions change, such as a user is disabled, a token is flagged risky, or they move outside an allowed location, instead of waiting for the token to expire. Where your VPN stack supports it, CAE closes the window between “this account was just compromised” and “the session is killed.”
• Be intentional about token reuse. The goal is that a stolen token has the smallest possible blast radius and the shortest possible useful life.

Conditional access is the real control plane

SSO gets the user authenticated. Conditional Access decides whether that authenticated user is actually allowed in, under the current circumstances. This is where your VPN policy earns its keep.

Build a dedicated Conditional Access policy scoped to the VPN application and layer your conditions:

• Require MFA (covered above).
• Require a compliant or hybrid-joined device (more on this below).
• Block legacy authentication outright. Legacy protocols can’t enforce MFA and are a common bypass.
• Factor in sign-in risk and user risk if you have Entra ID P2, so a risky sign-in gets blocked or challenged before it reaches the network.

Conditional Access policies are evaluated together, so think in terms of layered grant controls. The user must satisfy all of MFA, device compliance, and location controls before the VPN session is granted. Each layer is one more thing an attacker with just a password cannot produce.

Location-based policy

Named locations and country-based rules are a valuable signal. Blocking sign-ins from countries where you have no employees, or flagging “impossible travel,” meaningfully cuts down noise and stops opportunistic attacks. For a VPN, a location condition that restricts access to expected regions is a reasonable layer.

But be honest about its limits. A VPN is, ironically, a tool for changing your apparent network location, and attackers route through compromised hosts in “trusted” geographies all the time. Treat location as one input among several, never as the thing standing between an attacker and your network. Location plus device compliance plus MFA is strong. Location alone is not.

One practical caution: when you scope location policies, make sure your own VPN egress IPs and admin break-glass accounts are accounted for, so you don’t lock yourself out the moment the policy goes live.

Managed machines and compliant devices

This is the control that most decisively answers “what stops an attacker with a password.” If your Conditional Access policy requires a compliant device managed by Intune (or a hybrid-joined device), then a stolen credential is far less useful, because the attacker also needs to be sitting on a corporate-managed, policy-compliant endpoint to get the VPN session.

Require device compliance as a grant control and let Intune define what “compliant” means: disk encryption on, firewall enabled, OS patched to a minimum build, antivirus healthy, no jailbreak/root. The device certificate and compliance state become part of the access decision. Now your VPN isn’t just “the right person,” it’s “the right person, on a trusted machine, in an expected place, who just proved a second factor.” That’s the combination worth building toward.

For unmanaged or BYOD scenarios, decide deliberately: either route them through a more restricted path (app proxy, web-based access with tighter session controls) or block them from the VPN entirely. Don’t let “compliant device required” quietly become optional through a forgotten exclusion group.

The bottom line

A VPN done right with Entra ID isn’t about getting SSO to work. The real work is the layered policy on top. MFA enforced on a sensible frequency, token lifetimes treated as security settings, Conditional Access as the control plane, location as a signal rather than a wall, and Intune-managed device compliance as the layer that makes a stolen password nearly worthless. Stack those together and your VPN stops being a single password away from your network.