Is RADIUS/EAP-TLS supported for native Windows Always On VPN Device Tunnel before user sign-in?

Hello,

I would like to confirm whether native Windows Always On VPN Device Tunnel can use RADIUS/NPS with certificate-based authentication through Azure VPN Gateway.

My requirement is specifically automatic connectivity before any interactive user sign-in, not an Always On User Tunnel that connects after sign-in.

Current working configuration

This configuration has been tested successfully: the Device Tunnel connects after a restart, before anyone signs in.

The relevant excerpt from the working profile is shown below; the server address and routes are omitted:

<VPNProfile>
  <NativeProfile>
    <NativeProtocolType>IKEv2</NativeProtocolType>
    <Authentication>
      <MachineMethod>Certificate</MachineMethod>
    </Authentication>
  </NativeProfile>

  <AlwaysOn>true</AlwaysOn>
  <DeviceTunnel>true</DeviceTunnel>
</VPNProfile>

This follows the authentication model shown in Microsoft’s Azure Device Tunnel configuration guide.

A separate User Tunnel uses Azure VPN Client, OpenVPN and Microsoft Entra ID. That tunnel is outside the scope of this question.

What we would like to change

We would like to keep certificate-based device authentication and pre-sign-in connectivity, but have NPS evaluate access policies, such as AD computer-group membership and certificate revocation, rather than relying solely on Azure Certificate authentication and the gateway’s revoked-certificate list.

The proposed NPS would run on a domain-joined Azure VM with connectivity to our existing AD DS domain controllers. We would retain the Intune/AD CS certificate issuance workflow and adjust the certificate template if necessary.

Potential protocol blocker

The documentation appears to describe two different authentication paths:

1. Azure VPN Gateway with IKEv2 and RADIUS

The RADIUS configuration article explicitly states:

“If you're using IKEv2 with RADIUS, only EAP-based authentication is supported.”

2. Native Windows Device Tunnel

The VPNv2 CSP reference lists Certificate as the allowed value for NativeProfile/Authentication/MachineMethod, while EAP is listed under UserMethod.

My understanding is therefore that native Device Tunnel performs certificate authentication directly in the IKEv2 IKE_AUTH exchange, using certificate/authentication payloads, rather than performing EAP-TLS that Azure VPN Gateway can forward to NPS. Please confirm whether this interpretation is correct.

I have also reviewed “Configure a VPN client for point-to-site: RADIUS – certificate authentication.” It documents -AuthenticationMethod EapTls, -RadiusRootCert and -ClientRootCert, but I cannot find confirmation that the resulting configuration supports native Windows DeviceTunnel=true and pre-sign-in operation.

There is an additional ambiguity: the VPNv2 CSP page contains a NativeProfile SyncML example that sets MachineMethod to Eap, despite its allowed-values table listing only Certificate. Is that example outdated or inapplicable to Device Tunnel?

Questions

1. Is the following exact combination supported on current Windows 11 and Azure VPN Gateway? Native Windows VPN client + DeviceTunnel=true + IKEv2 + RADIUS/NPS + machine-certificate authentication, with automatic connection before user sign-in.
2. If it is unsupported, where is the limitation? Is it the native Windows Device Tunnel authentication method, Azure VPN Gateway’s EAP-only RADIUS integration, or both? Does Azure VPN Gateway offer any supported alternative in which it authenticates the machine certificate directly through IKEv2 and then performs a separate RADIUS authorization check?
3. If it is supported, could you provide a working configuration example? Specifically, the required ProfileXML authentication section, relevant NPS policy settings, and certificate/account-mapping requirements for authorizing an AD computer account, not a user account.
4. Could you provide an explicit Microsoft supportability statement or a product-team clarification? General confirmation that Azure supports RADIUS and certificate authentication does not resolve the specific Device Tunnel / EAP compatibility question.

The Azure Certificate-based Device Tunnel is already working. I am seeking confirmation of the proposed RADIUS architecture.