Event 6273 with reason code 16 — "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." For password-based methods this is what it says. For certificate-based 802.1X (EAP-TLS), reason 16 frequently surfaces when the client certificate's identity cannot be mapped to an AD account — the 'password' framing is misleading there.
Reason code 16
NPS 6273 reason 16: credentials mismatch
What it means
Common causes
Wrong password (PEAP-MSCHAPv2 and other password methods) — including stale cached credentials on the client after a password change.
EAP-TLS: the certificate's SAN (UPN or DNS name) does not map to an existing user/computer account.
The client authenticates as user when the policy and account structure expect machine auth, or vice versa.
Account name ambiguity across domains, so the lookup lands on the wrong (or no) account.
How to fix it
Check the Account Name in the event first — it tells you which identity NPS tried, and whether it is user or
host/machine format.For password methods: reset/verify credentials and clear saved network credentials on the client (forget the network and reconnect).
For EAP-TLS: decode the client certificate and verify the SAN UPN matches the AD account's UPN exactly; re-issue the certificate if the template's subject settings are wrong.
Verify the client's 802.1X authentication mode (user, computer, or user-or-computer) matches what your policies expect.
Frequently asked
Why do I get reason 16 with EAP-TLS when there is no password involved?
NPS reports identity-mapping failures under the same reason code. With EAP-TLS it usually means the certificate's SAN (typically the UPN) did not map to an existing AD account — check the certificate identity, not passwords.