NPS Event 6273 Reason Code 16 or 22: A Read-First Policy, EAP Type, Certificate, and Account Triage

Helpdesk: "Since the patch weekend, about a third of the laptops can't join the CORP-SECURE Wi-Fi, and some new Always On VPN users get rejected too. The NPS server's Security log is full of Event 6273. Most say reason code 16, a few say reason code 22. The users swear their passwords are right, and half of them don't even type one. A forum post says to tick Ignore user account dial-in properties, add a policy that accepts users without validating credentials until it's sorted, and reissue the NPS certificate. Can we start with that?"

Not yet. Event 6273 doesn't mean NPS is broken. It means NPS received the request, ran it through its policies, and refused it, and the event itself records which policy, which EAP type, and which reason. Microsoft's Event 6273 message is "Network Policy Server denied access to a user." Reason code 16 is "Authentication failed due to a user credentials mismatch. Either the user name provided does not match an existing user account or the password was incorrect." Reason code 22 is "Network Policy Server was unable to negotiate the use of an Extensible Authentication Protocol (EAP) type with the client computer." Neither one says the password was wrong for certain. Reason 16 also shows up when a certificate can't be mapped to an account, and reason 22 shows up when the client and the policy never agreed on a method, often because of the NPS server's own certificate (our reading, Steps 4 and 6). Ignoring dial-in properties doesn't touch either of those, and an accept-without-credentials policy opens the network to everyone. Work through it as a chain: which network, which users or devices, since when → is NPS auditing on, and is it 6273 or something else? → read one 6273 end to end (policy names, authentication type, EAP type, account, reason) → reason 22: did the client and the policy agree on an EAP type, and is the NPS server certificate valid and bound? → reason 16 with passwords: is the account real, unlocked, and reachable on a DC? → reason 16 with certificates: does the certificate map to the account (strong mapping since February 2025)? → does the request reach the policy you think it does? → is the NPS server itself registered, logging, and healthy? auditpol, Get-WinEvent, the NPS accounting log, Get-ADUser, the certificate store, and certutil are the sources for that chain. Accept everyone and you'll be finding out later which devices got on while it was open.

If the Wi-Fi or VPN profile never reached the device, Intune Wi-Fi Profile Not Applying starts earlier in the chain. If the rejections began when a CRL expired or a CA changed, Revocation Server Was Offline reads the chain first. This post covers "NPS (Network Policy Server) on Windows Server rejects 802.1X Wi-Fi, wired 802.1X, or VPN connections with Event 6273 and reason code 16 or 22, and you need a read-first path before you loosen policies, accept unauthenticated users, roll back security updates, or reissue every certificate."

TL;DR

• The event names the policy that rejected the request. Microsoft's 802.1X guide: "NPS event log entries contain information about the connection attempt, including the name of the connection request policy that matched the connection attempt and the network policy that accepted or rejected the connection attempt." (Step 3).
• Password or certificate decides which reason-16 path you take. Microsoft's 6273 page: "Use the information provided in Event Viewer to determine whether the authentication method that applies to the user connection is password- or certificate-based." (Steps 5 and 6).
• Reason 22 is often the NPS server certificate. Microsoft: "In Network Policy Server (NPS) on Windows Server, the server certificate that you bind to a network policy isn't updated automatically when it expires." (Step 4).
• Certificate users rejected since early 2025 need a strong mapping. Microsoft's KB5014754 on Full Enforcement mode: "Authentication will be denied if a certificate cannot be strongly mapped." (Step 6).
• Policies are an ordered list. Microsoft: "NPS checks each connection request against the first rule in the list, then the second, and so on, until a match is found." (Step 7).
• Certificates are the usual 802.1X break. Microsoft: "Most 802.1X authentication issues are because of problems with the certificate that's used for client or server authentication." (Steps 4, 6, 9).

Where in the chain did it break?

Step 1: Capture the symptom (read-only)

Write these on the ticket first:

Then branch on what you see:

Step 2: Confirm auditing, then find the events (read-only)

Microsoft's NPS troubleshooting checklist starts with the audit policy:

:: Read-only. On each NPS server: is the Network Policy Server audit subcategory on?
auditpol /get /subcategory:"Network Policy Server"

Microsoft says auditing is on when that shows Success and Failure, or Failure. If it shows No Auditing, the fix is Microsoft's auditpol /set line in Step 10, and Microsoft adds: "Even if audit policy appears to be fully enabled, it sometimes helps to disable and then re-enable this setting." Microsoft's audit page notes "This subcategory generates events only if NAS or IAS role is installed on the server."

The events live in the Security log on the NPS server, from Microsoft-Windows-Security-Auditing (Microsoft's 6273 event details). Microsoft's checklist: "Check for events that have Event ID 6273 or 6274. Most authentication failures produce these events." And: "Check the reason codes of the authentication failure events. The reason code indicates the cause of the failure."

# Read-only. On the NPS server: the last 24 hours of NPS denials, grouped by reason code, policy, and EAP type
# (field labels from Microsoft's 6273 event template; the regex parsing is ours)
$since = (Get-Date).AddHours(-24)
$denied = Get-WinEvent -FilterHashtable @{ LogName = 'Security'; Id = 6273; StartTime = $since } -ErrorAction SilentlyContinue |
  ForEach-Object {
    $m = $_.Message
    [pscustomobject]@{
      Time          = $_.TimeCreated
      Account       = if ($m -match 'Account Name:\s+(.+)') { $Matches[1].Trim() }
      NetworkPolicy = if ($m -match 'Network Policy Name:\s+(.+)') { $Matches[1].Trim() }
      ProxyPolicy   = if ($m -match 'Proxy Policy Name:\s+(.+)') { $Matches[1].Trim() }
      AuthType      = if ($m -match 'Authentication Type:\s+(.+)') { $Matches[1].Trim() }
      EapType       = if ($m -match 'EAP Type:\s+(.+)') { $Matches[1].Trim() }
      RadiusClient  = if ($m -match 'Client Friendly Name:\s+(.+)') { $Matches[1].Trim() }
      ReasonCode    = if ($m -match 'Reason Code:\s+(\d+)') { [int]$Matches[1] }
    }
  }
$denied | Group-Object ReasonCode, NetworkPolicy, EapType -NoElement | Sort-Object Count -Descending | Format-Table -AutoSize

Account Name appears twice in the event (user and client machine); the first match is the user section (our reading of Microsoft's template). If one reason and one policy dominate, that's your chain. If the codes are spread out, take one user at a time.

The neighbors of 6273, each from Microsoft's audit page or NPS troubleshooting guidance:

Events 13 and 18 are in the System log (Microsoft's NPS troubleshooting guidance lists them as NPS events; the log is our reading). If neither 6273 nor 13 nor 18 appears while users fail, the request may not be reaching this server. Microsoft: "By default, NPS sends and receives RADIUS traffic by using User Datagram Protocol (UDP) ports 1812, 1813, 1645, and 1646."

# Read-only. On the NPS server: is NPS listening on the RADIUS ports, and which NPS servers does the NAS point at?
Get-NetUDPEndpoint -LocalPort 1812, 1813, 1645, 1646 -ErrorAction SilentlyContinue |
  Select-Object LocalAddress, LocalPort, OwningProcess
Get-NpsRadiusClient | Select-Object Name, Address, Enabled

Get-NpsRadiusClient "gets Remote Authentication Dial-In User Service (RADIUS) clients." Check that the access point, controller, switch, or VPN server sending the request is in the list with the address it actually uses (Microsoft's checklist item: "The RADIUS Clients and Servers list includes the radius client in question.").

Step 3: Read one 6273 end to end (read-only)

The reason code is one field out of more than twenty. Microsoft's 802.1X guide: "In the event message, scroll to the bottom, and then check the Reason Code field and the text that's associated with it." Read the rest of the event first, for one user who is failing right now:

# Read-only. On the NPS server: the newest 6273 for one account (the name is an example), full message
Get-WinEvent -FilterHashtable @{ LogName = 'Security'; Id = 6273 } -MaxEvents 500 |
  Where-Object { $_.Message -match 'jdoe' } |
  Select-Object -First 1 -Property TimeCreated, Message | Format-List

The fields, in the order Microsoft's event template lists them, and what each one decides:

Two things trip people up here. The reason text in current events can differ from Microsoft's 2008-era reason-code table: a 2024 Microsoft Q&A post quotes the reason 22 text as "The client could not be authenticated because the Extensible Authentication Protocol (EAP) Type cannot be processed by the server." Same code, same meaning. And a 6273 that names an unexpected network policy is a policy-order problem before it's a credential problem, whatever the code says (our reading).

Then the accounting log, which records every request and response, not only failures. Microsoft's Always On VPN guide: "NPS creates and stores the NPS accounting logs." Microsoft's accounting page: "The default location is the systemroot\System32\LogFiles folder." The file names start with IN (Microsoft's Always On VPN page shows the naming).

# Read-only. On the NPS server: the newest accounting log files, then every line for one account
$logs = Get-ChildItem -Path "$env:windir\System32\LogFiles" -Filter 'IN*' | Sort-Object LastWriteTime | Select-Object -Last 2
$logs | Select-Object Name, Length, LastWriteTime
$logs | Select-String -Pattern 'jdoe' | Select-Object -Last 20 | ForEach-Object { $_.Line }

Microsoft's Always On VPN page lists the database-format fields, including Packet-Type, User-Name, Calling-Station-ID, NAS-IP-Address, Client-Friendly-Name, Authentication-Type, Policy-Name, and Reason-Code. If your server writes the DTS Compliant (XML) format, the same names appear as elements (our reading of Microsoft's accounting page). Microsoft on the log: "The NPS logs can help you diagnose policy-related issues." A request with no response line at all, or nothing in the log for that user, sends you back to Step 2 (our reading).

Step 4: For reason 22, did the client and the policy agree on an EAP type? (read-only)

Reason 22 means the EAP conversation never got as far as the account. Three things decide it: which method the client offers, which methods the matching policy allows, and whether the NPS server can present a usable certificate for that method (our reading of Microsoft's reason-code and certificate pages).

The policy side. Microsoft's checklist item: "The network policy constraints list the correct authentication method." In the NPS console that's the policy's Constraints tab, Authentication Methods, EAP Types. A Microsoft-moderated answer on a 2018 reason 22 thread (community): "Please make sure you have selected PEAP-MSCHAPv2; not MSCHAPv2 as a supported authentication method in your NPS policy." Microsoft's Always On VPN page describes the same mismatch from the client side, for error 812: "You typically encounter this error when the NPS specified an authentication condition the client can't meet."

The client side. On a failing Windows client, the WLAN or Wired AutoConfig log shows the method and the reason Windows gave up. Microsoft: "On the client side, go to Event Viewer (Local)\Applications and Services Logs\Microsoft\Windows\WLAN-AutoConfig/Operational for wireless issues."

# Read-only. On a failing Windows client: the newest WLAN AutoConfig events (wired: Microsoft-Windows-Wired-AutoConfig/Operational)
Get-WinEvent -LogName 'Microsoft-Windows-WLAN-AutoConfig/Operational' -MaxEvents 30 |
  Select-Object TimeCreated, Id, LevelDisplayName, Message | Format-List

Read the EAP method the client used and compare it with the 6273's Authentication Type and EAP Type and the policy's list. PEAP on the client with only "Smart card or other certificate" in the policy, or EAP-TLS on the client with only PEAP in the policy, is a reason 22 by design (our reading). Microsoft also warns not to offer the same inner method both tunneled and untunneled: "When you deploy both a tunneled EAP method and EAP (which isn't protected), don't use the same authentication type."

The NPS server certificate. PEAP-MS-CHAP v2 needs one too. Microsoft: "With PEAP-MS-CHAP v2, PEAP-TLS, or EAP-TLS as the authentication method, the NPS must use a server certificate that meets the minimum server certificate requirements." And the part that breaks things on renewal day: "When the certificate applied to a policy expires, an administrator must manually update each policy that uses certificate-based authentication to reference a new, non-expired certificate. Until you update the policy, clients that rely on that policy can't successfully authenticate." Microsoft adds that this manual step "isn't required on NPS servers configured for certificate autoenrollment."

Microsoft publishes a read-only way to see which certificate a policy is bound to: export the configuration and pull the thumbprint from the policy's EAP blob. Microsoft's snippet, with the policy name as the only change:

# Read-only (writes one XML file). On the NPS server: which certificate thumbprint is bound to this network policy?
# Microsoft's snippet from "Manage certificates used with NPS"; the export contains RADIUS shared secrets in clear text, so delete it after reading
$PolicyName = "CORP-SECURE Wireless" # Change this to your policy name (case-insensitive)
$NPSConfigPath = "$env:TEMP\nps-config.xml"
Export-NpsConfiguration -Path $NPSConfigPath
$blob = (([xml](Get-Content "$env:TEMP\nps-config.xml" -Raw)).SelectNodes("//RadiusProfiles//*[@name]") | Where-Object { $_.name -ieq $PolicyName }).Properties.msEAPConfiguration.'#text'
$found = [regex]::Matches($blob, '14000000([0-9a-f]{40})') | ForEach-Object { $_.Groups[1].Value.ToUpper() } | Select-Object -Unique
if (-not $found) { "No certificate thumbprint found in policy '$PolicyName'" } elseif ($found.Count -eq 1) { "Bound certificate thumbprint:$found" } else { "WARNING: multiple candidate thumbprints found, manual review of $NPSConfigPath needed:`n$($found -join "`n")" }

Microsoft's caution on that file: "The exported NPS configuration file contains unencrypted shared secrets for RADIUS clients and members of remote RADIUS server groups." Then compare the thumbprint with what's actually in the machine store:

# Read-only. On the NPS server: certificates that can do server authentication, with expiry and names
Get-ChildItem -Path Cert:\LocalMachine\My -SSLServerAuthentication |
  Select-Object Thumbprint, Subject, NotAfter, @{ n = 'DnsNames'; e = { $_.DnsNameList -join ', ' } }, @{ n = 'EKU'; e = { $_.EnhancedKeyUsageList.FriendlyName -join ', ' } } |
  Format-List
# Anything expiring in the next 30 days
Get-ChildItem -Path Cert:\LocalMachine\My -ExpiringInDays 30 | Select-Object Thumbprint, Subject, NotAfter

The bound thumbprint missing from that list, or present with a past NotAfter, is your reason 22. Microsoft's server certificate requirements, each checkable in that output: "The Subject name contains a value."; the certificate includes "the Server Authentication purpose in EKU extensions (the object identifier (OID) for Server Authentication is 1.3.6.1.5.5.7.3.1)"; "The Subject Alternative Name (SubjectAltName) extension, if used, must contain the DNS name of the server." And it has to be trusted by the clients: it must "Be issued by a certification authority (CA) that is trusted by client computers." A new certificate from a different CA, or a client profile that pins the old server name or root, fails here even though the certificate itself is fine (our reading of Microsoft's client-side validation rules: "The name in the Subject line of the server certificate matches the name that's configured on the client for the connection.").

TLS settings. In the same 2018 thread, the poster found the cause in a hardening change: "I followed a document from microsoft increasing security by turning off SSL 2.0/3.0 and TLS 1.0/1.1 and only allowing TLS 1.2." That was Windows Server 2012 (community, old). On current builds, don't re-enable old protocols on that basis; read what changed under SCHANNEL and when, and compare with a server that works (our reading):

:: Read-only. On the NPS server: SCHANNEL protocol overrides (no output under Protocols = OS defaults)
reg query "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols" /s

Clocks matter at this step too: reason 264 is "The Security Support Provider Interface (SSPI) called by EAP reports that the system clocks on the NPS server and the access client are not synchronized." See Windows Time Not Syncing With Domain Controller for that read.

Step 5: For reason 16 with passwords, is the account real, usable, and reachable? (read-only)

This step is for PEAP-MS-CHAP v2 (the event's EAP Type says so). Microsoft's NPS troubleshooting page lists three checks for 6273 reason 16: "Check that the username and password for the user are valid.", "Check to see whether the user account is locked in Active Directory.", and "Check that the request is targeted to the correct domain controller and that the user account exists."

# Read-only. Any domain-joined machine with RSAT: the account NPS was asked about (the name is an example)
Get-ADUser -Identity jdoe -Properties Enabled, LockedOut, PasswordExpired, PasswordLastSet, BadLogonCount, LastBadPasswordAttempt, AccountExpirationDate, UserPrincipalName |
  Select-Object SamAccountName, UserPrincipalName, Enabled, LockedOut, PasswordExpired, PasswordLastSet, BadLogonCount, LastBadPasswordAttempt, AccountExpirationDate

BadLogonCount and LastBadPasswordAttempt come from the DC that answered, so read them on the DC that NPS uses (our reading). Disabled, expired, and locked accounts usually get their own codes (34, 35, 36), so a reason 16 with a healthy-looking account points at the password the client sent or the name it sent it under (our reading of Microsoft's reason-code table).

The DC's side of the same attempt. MS-CHAP v2 is validated by the DC, so the DC's Security log should show the attempt as Event 4776 (our reading; Microsoft: "This event generates every time that a credential validation occurs using NTLM authentication." and "For domain accounts, the domain controller is authoritative.").

# Read-only. On a DC (or remotely with -ComputerName): recent 4776 entries for the account
Get-WinEvent -ComputerName DC01 -FilterHashtable @{ LogName = 'Security'; Id = 4776; StartTime = (Get-Date).AddHours(-4) } -MaxEvents 2000 |
  Where-Object { $_.Message -match 'jdoe' } |
  Select-Object -First 10 -Property TimeCreated, Message | Format-List

The Error Code field, from Microsoft's 4776 table:

No 4776 at all on any DC for that attempt means NPS didn't get as far as a DC (Step 8) or the name went somewhere else, a trusted domain or a different realm (our reading).

Which name was sent. The 6273's Account Name and Account Domain show what the client sent. A UPN suffix NPS can't resolve, a saved credential from before a rename, or a personal device sending only jdoe with no domain all look like reason 16 (our reading; Microsoft's codes 7 and 8 are the explicit versions: the domain in the User-Name attribute doesn't exist, or the user account doesn't). Microsoft's best-practices page has one more: "Network Policy Server (NPS) does not support the use of the Extended ASCII characters within passwords." A few users with accented characters in new passwords is a pattern worth checking.

Computer authentication. If the Account Name is host/LAPTOP-123 or CONTOSO\LAPTOP-123$, the computer is authenticating with its machine account (our reading). Read the computer object:

# Read-only. The computer account behind a host/ authentication (the name is an example)
Get-ADComputer -Identity 'LAPTOP-123' -Properties Enabled, PasswordLastSet, whenCreated |
  Select-Object Name, Enabled, PasswordLastSet, whenCreated

A disabled or recently re-created computer object, or one restored from an old image, can fail where users on the same laptop succeed (our reading). AD Account Keeps Getting Locked Out covers the reverse case: NPS as the caller that keeps locking an account with a saved old password.

Windows 11 and Credential Guard. Microsoft: "Upgrades to Windows 11, version 22H2, and Windows Server 2025 have Credential Guard enabled by default unless explicitly disabled." And for Wi-Fi and VPN: "Devices that use 802.1x wireless or wired network, RDP, or VPN connections that rely on insecure protocols with password-based authentication are unable to use SSO to sign in and are forced to manually reauthenticate in every new Windows session when Credential Guard is running." Users who used to connect silently with "Automatically use my Windows logon name and password" now get a prompt, type something, and fail (our reading). Microsoft's check on the client:

# Read-only. On a failing Windows client: 1 in the output = Credential Guard is running
(Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard).SecurityServicesRunning

Microsoft's direction is clear: "Microsoft recommends moving away from MSCHAPv2-based connections (for example, PEAP-MSCHAPv2 and EAP-MSCHAPv2), to certificate-based authentication (for example, PEAP-TLS or EAP-TLS). Credential Guard doesn't block certificate-based authentication."

A pattern from the field (community). On a Microsoft Q&A thread about intermittent 6273 reason 16 for wired and Wi-Fi users, one admin traced it to a read-only DC in the NPS server's site: "Appears the root cause of this problem is related to NPS trying to authenticate to an RODC in the same site." Their fix was moving the RODC to its own site. If reason 16 comes and goes for healthy accounts, check which DCs share the NPS server's site (our reading of that thread; not Microsoft documentation).

Step 6: For reason 16 with certificates, does the certificate map to the account? (read-only)

This step is for EAP-TLS or PEAP-TLS. Microsoft's 6273 page: "If a certificate-based authentication method is used, examine the user or computer certificate to confirm that the user is providing the correct certificate for authentication." Reason 16's text says the user name "does not match an existing user account". With a certificate, the name comes from the certificate, so that's a mapping question (our reading).

The certificate itself. Microsoft's client certificate requirements: "The client certificate is issued by an enterprise CA or mapped to a user or computer account in Active Directory Domain Services (AD DS)."; it carries "the Client Authentication purpose in EKU extensions (the OID for Client Authentication is 1.3.6.1.5.5.7.3.2)"; "For user certificates, the Subject Alternative Name (SubjectAltName) extension in the certificate contains the user principal name (UPN)."; and "For computer certificates, the Subject Alternative Name (SubjectAltName) extension in the certificate must contain the fully qualified domain name (FQDN) of the client, which is also called the DNS name."

# Read-only. On a failing Windows client: client-auth certificates in the user and computer stores,
# with expiry, names, and whether the AD CS SID extension (1.3.6.1.4.1.311.25.2) is present
foreach ($store in 'Cert:\CurrentUser\My', 'Cert:\LocalMachine\My') {
  Get-ChildItem -Path $store |
    Where-Object { $_.EnhancedKeyUsageList.ObjectId -contains '1.3.6.1.5.5.7.3.2' } |
    Select-Object @{ n = 'Store'; e = { $store } }, Thumbprint, Subject, Issuer, NotBefore, NotAfter,
      @{ n = 'SAN'; e = { ($_.Extensions | Where-Object { $_.Oid.Value -eq '2.5.29.17' }).Format($false) } },
      @{ n = 'SidExtension'; e = { [bool]($_.Extensions | Where-Object { $_.Oid.Value -eq '1.3.6.1.4.1.311.25.2' }) } }
}

The store filter, Format($false) and the calculated properties are our forms. More than one client-auth certificate in a store is worth noting: Richard Hicks (Microsoft MVP, his Always On VPN blog, community) answers a reader that if an older certificate that isn't strongly mapped is still in the store, "Windows could be selecting the wrong one when it connects."

Strong mapping (the February 2025 change). Microsoft's KB5014754, on Full Enforcement mode: domain controllers "will move to Full Enforcement mode when the February 2025 Windows security update is installed. Authentication will be denied if a certificate cannot be strongly mapped." The rollback window is closed: "The option to move back to Compatibility mode will remain until the September 9, 2025 Windows security update is installed. After this date, the StrongCertificateBindingEnforcement registry key will no longer be supported." Hicks documented what that looks like for VPN: "The event log on the NPS server will also record event ID 6273 from the Microsoft Windows security auditing source with the following error message." His post shows reason code 16, and on a DC, Kdcsvc Event 39. His reading: "The above conditions indicate that a user attempted to authenticate to the VPN with a certificate that was not strongly mapped."

# Read-only. On each DC (or remotely with -ComputerName): KB5014754 mapping events from the KDC
# 39 = no strong mapping, 40 = certificate predates the account, 41 = SID mismatch (Windows Server 2008 R2 / 2008 use 41, 48, 49)
Get-WinEvent -ComputerName DC01 -FilterHashtable @{ LogName = 'System'; ProviderName = 'Microsoft-Windows-Kerberos-Key-Distribution-Center'; Id = 39, 40, 41 } -MaxEvents 50 -ErrorAction SilentlyContinue |
  Select-Object TimeCreated, Id, Message | Format-List

Microsoft lists the event source as Kdcsvc; the provider name in the filter is our reading (Hicks names it Kerberos-Key-Distribution-Center). If the filter returns nothing on a DC that should have events, open the System log and filter by event ID instead. Event 39's text: "The Key Distribution Center (KDC) encountered a user certificate that was valid but could not be mapped to a user in a strong way (such as via explicit mapping, key trust mapping, or a SID)." The event names the user, the certificate's subject, issuer, serial number, and thumbprint, so you can match it to the 6273.

What counts as strong, per Microsoft:

The last row is our reading of the KB's rule: "In general, mapping types are considered strong if they are based on identifiers that you cannot reuse." Microsoft on the CA side: "Enterprise Certificate Authorities (CA) will start adding a new non-critical extension with Object Identifier (OID) (1.3.6.1.4.1.311.25.2) by default in all the certificates issued against online templates after you install the May 10, 2022, Windows update." And: "Environments that have non-Microsoft CA deployments will not be protected using the new SID extension after installing the May 10, 2022, Windows update."

# Read-only. The account side: explicit mappings and creation time (the user name is an example)
Get-ADUser -Identity jdoe -Properties altSecurityIdentities, whenCreated |
  Select-Object SamAccountName, whenCreated, @{ n = 'altSecurityIdentities'; e = { $_.altSecurityIdentities -join '; ' } }

A certificate whose NotBefore is older than the account's whenCreated, with no strong mapping, is Microsoft's "Certificate predates account" case: "If the certificate is older than the account, reissue the certificate or add a secure altSecurityIdentities mapping to the account (see Certificate mappings)."

Intune-issued certificates. Microsoft's Intune support tip: the SCEP profile can add the SID as a SAN URI; "For device certificates, only Microsoft Entra hybrid joined devices will have SID information, so strong mapping changes are applicable only to Windows devices that are Microsoft Entra hybrid joined." And: "For other device types, like iOS or Android, strong mapping is not supported for device certificates, and user certificates should be used instead." Phones failing with device certificates while Windows laptops pass is that rule, not a bad profile (our reading). Intune SCEP Certificate Profile Failed covers the profile and NDES side.

The chain. A certificate that maps fine can still fail validation on NPS. Those usually arrive as their own codes (Step 9), but read the chain from the client's exported certificate before you assume (certutil -verify -urlfetch; Revocation Server Was Offline walks through that output). One community report on the same Q&A thread as Step 5: after KB5014754, certificates on the NPS server issued before the update were missing the SID extension, and the admin "renewed with new keys" all of them. That's one environment's finding, not Microsoft guidance.

Step 7: Does the request reach the policy you think it does? (read-only)

NPS evaluates two ordered lists. First the connection request policies: "RADIUS Access-Request messages are processed or forwarded by NPS only if the settings of the incoming message match at least one of the connection request policies configured on the NPS." Then the network policies, top to bottom, first match wins (TL;DR). Three rules decide most surprises:

• Conditions vs constraints. Microsoft: "Unlike the NPS response to unmatched conditions in the network policy, if a constraint is not matched, NPS denies the connection request without evaluating additional network policies." A broad policy higher in the list whose conditions match, but whose authentication methods don't, rejects the request before your intended policy is read (our reading of that rule).
• Disabled policies are skipped. "When you disable a network policy, NPS does not evaluate the policy when authorizing connection requests."
• Dial-in properties. "If the dial-in properties of the user account are set to deny access, the connection request is rejected by NPS." That's reason 65. And: "If NPS does not find a network policy that matches the connection request, the connection request is rejected unless the dial-in properties on the user account are set to grant access." That's reason 48.

Compare the 6273's Proxy Policy Name and Network Policy Name with the policy you meant. Then read that policy's conditions against the event's fields: NAS Port Type (Microsoft's example: "if the user is only allowed to connect through a wireless access point but is attempting to connect through a virtual private network (VPN) server, access will be denied"), Windows Groups, NAS IPv4 Address, Calling or Called Station ID. To list what's configured without touching it:

# Read-only (writes one XML file with shared secrets in clear text; delete it after). On the NPS server:
# the network policy names in the exported configuration (XPath from Microsoft's certificate snippet; listing names is our form)
$path = "$env:TEMP\nps-config.xml"
Export-NpsConfiguration -Path $path
([xml](Get-Content $path -Raw)).SelectNodes("//RadiusProfiles//*[@name]") | ForEach-Object { $_.name }
Remove-Item -Path $path

The processing order itself is the order of the list in the NPS console under Policies (read it there). For a Windows Groups condition, read the group the way NPS will:

# Read-only. Is the account (user or computer) in the group the policy's Windows Groups condition names? (names are examples)
Get-ADGroupMember -Identity 'WiFi-Users' -Recursive | Where-Object { $_.SamAccountName -in 'jdoe', 'LAPTOP-123$' } |
  Select-Object Name, SamAccountName, objectClass

Wi-Fi often authenticates the computer at boot and the user at sign-in; a group condition that only contains users rejects the computer pass (our reading).

Forwarding. If the matching connection request policy forwards to another RADIUS server, Microsoft's checklist: "The Remote Radius Server Groups list includes the radius server in question." Reason 112 says the remote server rejected it: "Check the event log on the remote RADIUS server to determine the reason that the connection request was rejected."

MAC authentication bypass policies. Microsoft notes that Calling Station ID "is typically used for Mac Address Bypass scenarios when the connection request policy is configured for 'Accept users without validating credentials'." That's the setting behind the forum's accept-everyone suggestion. A policy like that belongs on a narrow, MAC-limited set of devices, and it must sit where your 802.1X requests can't match it (our reading).

Step 8: Is the NPS server itself registered, logging, and healthy? (read-only)

Registered in AD. Microsoft: "NPSs must be registered in Active Directory so that they have permission to read the dial-in properties of user accounts during the authorization process. Registering an NPS adds the server to the RAS and IAS Servers group in Active Directory." And across domains: "To provide an NPS with permission to read the dial-in properties of user accounts in Active Directory, the NPS must be registered in the domain where the accounts reside."

# Read-only. Is each NPS server in RAS and IAS Servers in the users' domain? Is the service running?
Get-ADGroupMember -Identity 'RAS and IAS Servers' | Select-Object Name, objectClass
Get-Service -Name IAS | Select-Object Name, DisplayName, Status, StartType

IAS is the Network Policy Server service (Microsoft's certificate page calls it "the Network Policy Server (IAS) service").

Logging. Microsoft's 6273 page lists unavailable log files as a cause: "If NPS is configured to record accounting information in a log file on the local computer or a remote computer, check that the hard disk is not full." And the accounting page: "To prevent the log files from filling the hard drive, it is strongly recommended that you keep them on a partition that is separate from the system partition." Reason 80 is the explicit version: NPS couldn't write accounting data.

Domain controllers. Reasons 4, 5, and 261 are NPS failing to reach the global catalog, a DC in the user's domain, or AD DS at all. Microsoft's 6273 page: "Check that the domain controller is online." and "Check that network connections between the domain controller and NPS are working." Netlogon Event ID 5719 covers a server that can't find a DC.

Extensions (the NPS extension for Microsoft Entra MFA). Reason 21: "An IAS extension dynamic link library (DLL) that is installed on the NPS server rejected the connection request." Read what's installed before Microsoft's isolation step (Step 10):

:: Read-only. On the NPS server: the extension DLLs NPS loads (no values = no extensions)
reg query "HKLM\SYSTEM\CurrentControlSet\Services\AuthSrv\Parameters" /v AuthorizationDLLs
reg query "HKLM\SYSTEM\CurrentControlSet\Services\AuthSrv\Parameters" /v ExtensionDLLs

If the extension is there, its own log is under Applications and Services Logs > Microsoft > AzureMfa > AuthN > AuthZ (Microsoft's path).

More than one NPS server. Access points and switches usually list two, and each NPS server writes its own Security log. Run Steps 2, 4, and 7 on each; a certificate rebound on one server and not the other gives half-the-users symptoms (our reading).

Step 9: A different reason code? Read that one instead

Microsoft's reason-code tables (archived Windows Server 2008 R2 pages, still the published reference) cover 0 through 303. The ones that show up next to 16 and 22 most often, by our reading of the autocomplete data and forum threads:

Microsoft: "There are intentional gaps in the numeric sequence of reason codes." A code that isn't in the tables is worth searching as its own question rather than guessing from the neighbors.

Common false starts

Step 10: Change one link, then prove it

Only after Steps 1-9 agree on which link failed. Save the configuration first; Microsoft's best-practices page: "Save the NPS configuration with this command each time you reconfigure the NPS."

# Low-risk (writes files). On each NPS server: configuration and extension settings before any change
# The XML contains RADIUS shared secrets in clear text: keep it somewhere access-controlled
New-Item -ItemType Directory -Path 'D:\NPS-Backup' -Force | Out-Null
Export-NpsConfiguration -Path "D:\NPS-Backup\nps-config-$(Get-Date -Format yyyyMMdd-HHmm).xml"
reg export "HKLM\SYSTEM\CurrentControlSet\Services\AuthSrv\Parameters" "D:\NPS-Backup\authsrv-parameters.reg" /y

Auditing off (Step 2). Microsoft's command, on the NPS server:

:: Change. Turn on success and failure auditing for NPS
auditpol /set /subcategory:"Network Policy Server" /success:enable /failure:enable

NPS server certificate expired or replaced (Step 4). Microsoft's procedure, per policy that uses certificate-based authentication: Constraints > Authentication Methods > select the EAP type > Edit > pick the new certificate in Certificate issued to > OK > Apply. Repeat for every such policy, then Microsoft: "Restart the Network Policy Server (IAS) service for the change to take effect."

:: Change. On the NPS server, after rebinding every affected policy (Microsoft's command)
net stop ias && net start ias

Then re-run Microsoft's thumbprint snippet from Step 4 and confirm it returns the new thumbprint. For the next renewal, Microsoft's fix for this whole class of outage: "By using autoenrollment, the server certificate is renewed automatically before it expires, and NPS continues to use the renewed certificate without administrator intervention." Certificate Autoenrollment Not Working covers getting that working.

EAP types don't match (Step 4). Change one side, on purpose: either the policy's EAP Types list or the client profile. For domain-joined Windows, Microsoft's best practice: "Automatically configure all of your domain member 802.1X client computers by using Group Policy." For Intune-managed devices, Intune Wi-Fi Profile Not Applying covers the profile side. Add a method to the policy only if you mean to support it; don't remove the method the working devices use (our habit).

Password users (Step 5). Reset or unlock the one account, have the user forget the saved network and reconnect, and test. For a fleet moving to Windows 11 with Credential Guard, the durable fix is Microsoft's recommendation, certificate-based authentication, not disabling Credential Guard.

NPS remote access lockout (reason 64). Microsoft: "To manually reset a user account that has been locked out before the failed attempts counter is automatically reset, delete the following registry subkey that corresponds to the user's account name: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RemoteAccess\Parameters\AccountLockout\domain name:user name"

Certificates without a strong mapping (Step 6). The fix is new certificates that carry the SID, or an explicit strong mapping. Hicks: "Administrators must issue new certificates that are strongly mapped to resolve this issue." For AD CS, a re-enrollment against an online template on an updated CA picks up the SID extension (Microsoft's KB). For Intune SCEP, add the OnPremisesSecurityIdentifier variable as a SAN URI in a new profile; Microsoft: "Renew certificates in phases by creating a new SCEP profile and gradually targeting it to groups of users or devices." For Intune PKCS, Microsoft's order is connector update, the EnableSidSecurityExtension registry value set to 1, then a connector service restart, then reissue.

Where a certificate can't be reissued, Microsoft's manual strong mapping is X509IssuerSerialNumber in altSecurityIdentities. Issuer and serial are reversed from the forward format the certificate shows, and Microsoft warns: "Note that when you reverse the SerialNumber, you must keep the byte order." Microsoft's example, with a dry run added:

# Change (dry run first). Microsoft's KB5014754 example values; build your own string from the certificate's issuer and serial
Set-ADUser -Identity 'DomainUser' -Replace @{ altSecurityIdentities = 'X509:<I>DC=com,DC=contoso,CN=CONTOSO-DC-CA<SR>1200000000AC11000000002B' } -WhatIf

-Replace overwrites any existing mappings on that attribute; read them first (Step 6) and include the ones you keep (our habit).

Wrong policy matched (Step 7). Move the intended policy up, or narrow the broader policy's conditions, in the NPS console. One policy change, then a test from the same NAS and the same device type. Disable rather than delete a policy you think is unused, so it can come back (our habit).

NPS not registered (Step 8). NPS console: NPS (Local) > Register Server in Active Directory. For another domain, Microsoft's command form:

:: Change. Register an NPS server in another domain (domain and server names are examples)
netsh nps add registeredserver contoso.com NPS01

MFA extension suspected (Step 8, reason 21). Microsoft's isolation step is to back up the AuthSrv\Parameters key (done above), delete the AuthorizationDLLs and ExtensionDLLs values, and test. Microsoft: "If NPS authentication succeeds, then the issue might be specific to Microsoft Entra multifactor authentication." While those values are gone, the server isn't asking for MFA: do it in a window, with an owner, and import the .reg export when the test is done (our habit).

Then prove it. Microsoft's verification: "On a computer that is configured according to network access policy, log on to the network with a valid user account and valid credentials." Then read the success event and the policy it names:

# Read-only. On the NPS server: the newest grants and denials for the test account, side by side
Get-WinEvent -FilterHashtable @{ LogName = 'Security'; Id = 6272, 6273; StartTime = (Get-Date).AddMinutes(-30) } |
  Where-Object { $_.Message -match 'jdoe' } |
  Select-Object TimeCreated, Id, @{ n = 'Policy'; e = { if ($_.Message -match 'Network Policy Name:\s+(.+)') { $Matches[1].Trim() } } } |
  Format-Table -AutoSize

A 6272 naming the policy you intended is the pass. Then the next device type (another laptop model, a phone, a VPN client), because NPS caches TLS sessions: Microsoft notes "the default TLS handle expiry is 10 hours", so a device that reconnected may not have gone through the full check you just fixed (our reading).

When a change is justified

FAQ

What does NPS Event 6273 mean?
"Network Policy Server denied access to a user." NPS received the RADIUS request, ran it through its connection request and network policies, and rejected it. The event names the policy, the authentication and EAP types, the NAS, the account, and a reason code. Read all of them, not only the code.

What is NPS reason code 16?
"Authentication failed due to a user credentials mismatch." With passwords (PEAP-MS-CHAP v2), check the account, the password the device saved, and the DC's Event 4776. With certificates (EAP-TLS, PEAP-TLS), check the certificate's UPN or DNS name and whether it's strongly mapped; since the February 2025 domain controller update, a weak mapping is denied.

What is NPS reason code 22?
NPS couldn't agree on an EAP type with the client. Compare the client's method with the policy's EAP Types list, and check the NPS server certificate bound to that policy. Microsoft: it "isn't updated automatically when it expires."

Where are the NPS logs?
The events are in the Security log on each NPS server (6272 granted, 6273 denied, 6274 discarded), also under Custom views > Server roles > Network Policy and Access Services. The accounting log defaults to %windir%\System32\LogFiles, in files whose names start with IN. Auditing must be on: auditpol /get /subcategory:"Network Policy Server".

Should I select Ignore user account dial-in properties to fix 6273?
Only if the event shows reason 65 and you mean to let the network policy alone decide access. It doesn't change how NPS checks a password or a certificate, so it doesn't fix 16 or 22.

Related posts

• Intune Wi-Fi Profile Not Applying (the client profile side: assignment, EAP settings, and the certificate the profile needs)
• Revocation Server Was Offline (0x80092013) (when the 6273 is a revocation code, or the chain fails before mapping)
• Certificate Autoenrollment Not Working (so the NPS server certificate and client certificates renew on their own)
• Intune SCEP Certificate Profile Failed (where Intune-issued client certificates, and their SID, come from)
• AD Account Keeps Getting Locked Out (NPS as the caller behind repeated bad passwords)
• Windows Time Not Syncing With Domain Controller (the clock behind reason 264)
• Netlogon Event ID 5719 (when NPS, or any server, can't find a domain controller)

Free checklist

An accept-without-credentials policy added to every SSID before one laptop was tested against the fixed certificate binding is a change nobody tested where the connections happen. So is a Conditional Access policy enforced before anyone read the report-only results. The free Conditional Access pre-enforcement checklist keeps break-glass accounts, pilot groups, and report-only review on one page:

👉 https://cashflow4375.gumroad.com/l/ujkqxb?utm_source=devto&utm_medium=article&utm_campaign=aps_first_sale&utm_content=nps-event-6273-reason-code-16-22

If you want the rest of the Intune runway written down for the team (enrollment hygiene, compliance phasing, break/fix cards and read-only PowerShell snapshots), the Intune & M365 Admin Starter Pack pairs with this triage: https://cashflow4375.gumroad.com/l/joonf?utm_source=devto&utm_medium=article&utm_campaign=aps_first_sale&utm_content=nps-event-6273-reason-code-16-22

Admin Pack Studio; not affiliated with Microsoft. Steps 1-9 favor read-only checks: auditpol /get, Get-WinEvent, Get-NetUDPEndpoint, Get-NpsRadiusClient, Get-ChildItem on the accounting logs and certificate stores, Select-String, Get-ADUser, Get-ADComputer, Get-ADGroupMember, Get-CimInstance, Get-Service, and reg query. Export-NpsConfiguration writes a file that contains shared secrets in clear text; delete or secure it. Turning on auditing, rebinding the NPS certificate, restarting IAS, changing EAP types or policy order, account resets, altSecurityIdentities mappings, certificate reissue, NPS registration, removing extension DLL values, and the lockout registry key are deliberate changes. Change one link at a time, test from the failing network and device type, and check current Microsoft Learn for version-specific behavior.