Always On VPN Authentication Failed Reason Code 16

Strong authentication is essential for remote access to on-premises resources over the public Internet. Using the Protected Extensible Authentication Protocol (PEAP) in combination with user certificates issued by the organization’s internal certification authority (CA) provides high assurance for remote user authentication. It includes the added benefit of making the Always On VPN connection completely seamless for the user, as their certificate is presented to the authentication server transparently during VPN connection establishment. Using PEAP with user certificates is the recommended authentication method for Always On VPN deployments.

Reason Code 16

When configuring Always On VPN to use PEAP with client authentication certificates, administrators may encounter a scenario in which a user has a valid certificate. Yet, their authentication request is rejected by the Network Policy Server (NPS) server when attempting to connect remotely. Looking at the Security event log on the NPS server, administrators will find a corresponding event ID 6273 in the Network Policy Server task category from the Microsoft Windows security auditing event source. In the Authentication Details section, you’ll find that the reason code for the failed request is Reason Code 16, with the following reason specified.

“Authentication failed due to a user credentials mismatch. Either the user name provided does not map to an existing user account or the password was incorrect”.

Password Incorrect?

The reason code indicates the user may have entered an incorrect password. However, the user does not enter their password when using PEAP with client authentication certificates, so there’s no chance the password was entered incorrectly.


I have increasingly encountered this scenario with many customers deploying Always On VPN over the last year or so. This error is often caused by a known issue with older TPM models. Specifically, those with a TPM specification sub-version of 1.16 and earlier. You can view these TPM details by opening the Windows Settings app and entering ‘security processor’ in the search field.


These older TPM models seem to have an issue with RSA-PSS signature algorithms, as described here. If possible, administrators should upgrade devices with older TPM versions to ensure the highest level of security and assurance for their remote users. However, in cases where that is not feasible, administrators can remove RSA-PSS signature algorithms from the registry, which forces the use of a different signature algorithm and seems to restore functionality.

To do this, open the registry editor (regedit.exe) and navigate to the following registry key.


Double-click the Functions entry and remove the following algorithms from the Value data section.


Once complete, reboot the device and test authentication once again.

Intune Proactive Remediation

Administrators using Intune Proactive Remediation will find detection and remediation scripts to make these changes published on GitHub.



Additional Information

Windows TPM 2.0 Client Authentication in TLS 1.2 with RSA PSS

Always On VPN NPS Auditing and Logging

Always On VPN NPS RADIUS Configuration Missing

Always On VPN NPS Load Balancing

Leave a comment


  1. Ryan Winn

     /  February 24, 2023

    Thanks for publishing this, Richard. As you know we struggled with this for some time before we found the PSS issue. Our traces looked a bit different than the example article. The Client Hello for the initial TLS connection would show the signature hash algorithms for the PSS ones as “Unkown”. We ended up using a remediation script in Intune that would watch for user tunnels not connecting and getting the 16 error, then it would remove the PSS entries from the registry value. Worked like a charm!

    • Thanks for the insight. Excellent idea to use Intune and Proactive Remediation to remove those ciphers on affected endpoints selectively. Thanks for the tip!

      • Jaroslav H.

         /  March 24, 2023

        Hi. We have also encountered this problem and ended up with quite a lot of stations. If you have a working remediation script would it be possible to share? Thank you.

      • Funny you should ask. 😉 I’m working on this as we speak. I hope to have this wrapped up in the next few days, time permitting. I’ll respond here again with the link once it is published.

  2. Jaroslav H.

     /  March 24, 2023

    Hi. We have also encountered this problem and ended up with quite a lot of stations. If you have a working remediation script would it be possible to share? Thank you.

  3. Aleksandar Ristovski

     /  March 25, 2023


    I’m having same Reason Code: 16 on NPS server.

    On end user side error 860 (user tunnel) when trying to establish connection.

    AOVPN servers are in Azure, on them i have following:

    The following error occurred in the Point to Point Protocol module on port: VPN1-999, UserName: [email protected].
    The connection was prevented because of a policy configured on your RAS/VPN server. Specifically, the authentication method used by the server to verify your username
    and password may not match the authentication method configured in your connection profile. Please contact the Administrator of the RAS server and notify them of this error.

    Laptop that i have is fairly new, and TPM chip is 01/28/2021

    Tried also registry edit, no progress:

    Checked and recreated network and connection policies, nothing works so far.

    NPS is Server 2019 standard, VPN servers also Server 2019 standard. Client is Windows 10 Enterprise 22H2

    All worked fine till 2 days ago.

    Any suggestion is appreciated, i’m out of ideas what went wrong and why this is happening….



Leave a Reply

Discover more from Richard M. Hicks Consulting, Inc.

Subscribe now to keep reading and get access to the full archive.

Continue reading