Enabling RADIUS over TLS on Microsoft NPS for Secure Remote Authentication

Goal: Encrypt RADIUS Traffic with TLS on NPS

The objective is to encrypt RADIUS traffic between remote clients, the Network Policy Server (NPS), and downstream RADIUS servers so that authentication credentials are not exposed in clear text.

Prerequisites

• Windows Server 2012 or later, through Windows Server 2022, with the Network Policy and Access Services role installed.
• A server-authentication X.509 certificate whose subject matches the fully qualified domain name (FQDN) that clients use to reach the NPS server, issued by a certificate authority (CA) the clients trust.
• Administrative rights on the NPS server.
• TCP port 853 reachable between clients and NPS, and between NPS and any downstream RADIUS servers.

Procedure

1. In the NPS Microsoft Management Console (MMC) snap-in, import the server-authentication certificate.
2. Bind the imported certificate to the NPS service so that NPS presents it during the TLS handshake. The exact console path can vary by Windows Server version; confirm the binding location in the NPS documentation for your release.
3. On each RADIUS client, select the TLS transport option and configure the client to connect to the NPS server on TCP port 853.
4. Ensure the client trusts the CA that issued the NPS certificate, or install the NPS server certificate into the client's trusted root store.
5. Apply the client configuration and restart the client service if required by the client platform.

Expected Checks

After a test client connects, verify that the TLS handshake succeeded.

• Open the Windows Event Viewer on the NPS server and check the Application log under the source Microsoft-Windows-NPS-Auth. A successful TLS handshake is recorded as Event ID 5026.
• Run the following PowerShell command on the NPS server (as Administrator) to confirm the server-side TLS flag:

Get-NpsConfiguration | Select-Object -ExpandProperty EnableTls

The expected result is True. If the flag is not set, TLS is not active on the server.

Diagnostic Decisions

If authentication fails, use the following decision path:

• No Event ID 5026 in the NPS Application log: check whether TCP 853 is blocked by a firewall or NAT device, or whether the client is still using standard RADIUS over UDP 1812.
• Event ID 5026 is absent but the client reports a certificate error: verify that the certificate is unexpired, the subject name matches the client-configured FQDN, and the client trusts the issuing CA.
• Handshake timeouts on WAN links: investigate network latency, because high latency can prevent the TLS tunnel from establishing.

Recovery Options

If TLS prevents authentication, temporarily revert the client to standard RADIUS over UDP 1812 while you correct the certificate or network path. Because this restores clear-text RADIUS, treat it as a short-term recovery step. Re-enable TLS on the client once the root cause is resolved and confirm that Event ID 5026 appears again.

Limitations

• NPS versions before Windows Server 2012 do not support RADIUS over TLS; a supported operating system upgrade is required.
• Expired certificates, hostname mismatches, or weak cryptography cause handshake failures and may expose credentials if a client falls back to non-TLS RADIUS.
• Firewall blocks on TCP 853 or high network latency can prevent the TLS tunnel from establishing.