A Wi-Fi authentication error in Windows 11 — where the device connects to the router but then fails with “authentication error” or “can’t connect to this network” — means the password exchange failed. The device and router tried to establish the secure connection and something went wrong in that process. If you want the full context, see our Complete Guide to Fixing Windows, Browser, and Software Errors.
The single most effective first step: forget the network and reconnect. Wi-Fi icon → click the arrow next to the network → Forget → turn Wi-Fi off → wait 10 seconds → turn Wi-Fi on → click the network → enter the password.
This works because the stored network profile can become corrupted — usually after a router change, password update, or Windows update — and the stored credentials fail authentication even when the password is correct. Starting fresh with a clean profile resolves this for the majority of cases.
Wrong password is more common than people admit
Check the router’s admin panel or a device that successfully connects and confirm the exact current Wi-Fi password. Case-sensitive. No trailing spaces. Passwords that include similar-looking characters (0/O, 1/l, |) are particularly prone to entry errors. This is worth verifying before spending time on driver fixes.
Security protocol mismatch
The most common non-obvious cause: the router is using WPA3 or WPA2/WPA3 mixed mode, and the Windows 11 Wi-Fi adapter’s driver doesn’t fully support WPA3. Authentication fails not because the password is wrong but because the security handshake protocol isn’t completing correctly.
Test: log into the router admin panel (typically 192.168.1.1) → Wireless settings → Security → temporarily change from WPA3 or Mixed to WPA2-Personal only → save → try connecting the Windows device. If it connects successfully, WPA3 compatibility is the issue.
The permanent fix is updating the Wi-Fi driver from the laptop manufacturer’s support page — manufacturer drivers have better WPA3 implementation than the generic Intel/Qualcomm/Realtek drivers Windows Update provides. After the driver update, switch the router back to WPA3 or Mixed and test again.
Delete all saved profiles for the network
Beyond the UI-based “Forget network”: sometimes the profile isn’t fully removed and partial data remains. Administrator Command Prompt:
netsh wlan delete profile name="[NetworkName]"
Replace [NetworkName] with the exact SSID. This completely removes all saved data for that network. Reconnect fresh after running it. The command-line deletion is more thorough than the UI forget option on some Windows 11 builds.
Wi-Fi driver update
Authentication errors that appear without any router changes and without any router changes by others are often driver issues. An outdated driver handles the authentication handshake differently from the current specification, causing failures on routers that recently updated their firmware.
Manufacturer’s support page for the specific laptop model → download Wi-Fi driver → install → restart → reconnect. The improvement in authentication reliability between old and new driver versions is often significant, particularly for WPA3.
Network stack reset
Corrupted networking components can prevent authentication from completing even when the driver and password are correct. The reset clears accumulated state:
netsh winsock reset
netsh int ip reset
ipconfig /flushdns
Administrator Command Prompt, then restart. After the reset, reconnect to the Wi-Fi network. This resolves authentication errors caused by network stack corruption — particularly common after VPN software changes, Windows updates, or antivirus network component changes.
Date and time
Authentication protocols validate timestamps. If the system clock is significantly wrong, authentication fails because the timestamps in the handshake don’t align with expected values. Right-click the clock → Adjust date and time → Sync now → confirm the date and time are correct. This takes 30 seconds and eliminates a subtle but real cause.
Router authentication timeout
Some routers have aggressive authentication timeout settings — if the authentication handshake takes longer than the router expects (due to slow adapter initialisation, network congestion, or driver overhead), it rejects the connection attempt. The device tries, the router says no, Windows reports authentication error.
If multiple attempts usually result in eventual connection: this pattern suggests timeout rather than authentication failure. In the router admin panel → Wireless → look for “Authentication timeout” or “Association timeout” settings → increase them if available.
Corporate WPA2 Enterprise (802.1X)
If the network uses WPA2 Enterprise with username/password or certificate authentication (common in offices and universities), the error message is the same but the cause is different. Authentication fails because the certificate has expired, the username/password is incorrect for the RADIUS server, or the client’s certificate isn’t trusted by the network’s authentication server.
For these networks: contact IT rather than adjusting local Windows settings. The authentication happens on the network’s RADIUS server, not locally, and fixes require server-side changes or certificate renewal.
Our guide on Wi-Fi repeatedly asking for password covers the related scenario where authentication completes but sessions don’t persist — the power management and DHCP causes there are different from authentication errors at connection time. For completely empty Wi-Fi network lists (adapter not scanning), the Wi-Fi not showing networks guide covers the WLAN AutoConfig and adapter detection issues. Microsoft’s Wi-Fi troubleshooting documentation covers the WLAN-AutoConfig event log where authentication failure events are recorded with specific error codes that identify whether the failure is credential, protocol, or infrastructure related.
FIPS mode and authentication compatibility
Windows has a “Use FIPS compliant algorithms for encryption, hashing, and signing” setting (in Local Security Policy) that restricts the cryptographic algorithms Windows can use. When this setting is enabled and the Wi-Fi network uses authentication algorithms that don’t meet FIPS requirements — common with some WPA2 configurations — authentication fails.
Check: Win+R → secpol.msc → Local Policies → Security Options → “System cryptography: Use FIPS compliant algorithms” → if this is enabled, try disabling it and reconnecting. Note: this is a security setting and should only be disabled after confirming it’s appropriate for your environment. On personal machines it’s rarely intentionally enabled, but it can be enabled by corporate policy push or accidentally.
MAC address filtering on the router
Routers with MAC address filtering enabled only allow connections from pre-approved device MAC addresses. If the router has filtering enabled and the Windows machine’s MAC address isn’t in the approved list, every connection attempt fails with an authentication-like error even when the password is correct — because the router rejects the connection before the password exchange completes.
Check: router admin panel → Wireless → MAC filter or Access Control → confirm filtering is either disabled or that the Windows machine’s MAC address is in the approved list. The machine’s MAC address: Command Prompt → ipconfig /all → “Physical Address” for the Wi-Fi adapter. If MAC filtering is on and the MAC isn’t listed, add it or disable filtering temporarily to confirm this is the cause.
Hidden SSID authentication quirks
Networks with hidden SSIDs (not broadcasting their network name) are more prone to authentication errors than visible networks. Windows must maintain the SSID name in the profile to connect to hidden networks, and if this stored name has any encoding issue — unusual characters, encoding mismatch — authentication appears to fail when the problem is actually that Windows is connecting to the wrong SSID or providing an incorrect SSID during the connection attempt.
For hidden networks: delete the profile → manually add the network (Settings → Network and internet → Wi-Fi → Manage known networks → Add network) → enter the SSID, security type, and password precisely. Manual addition for hidden networks is more reliable than the automatic profile creation from a connection attempt.
Random MAC address causing repeated authentication failures
Windows 11 has a “Random hardware address” feature that changes the device’s MAC address periodically for privacy. When this is enabled and the router recognises devices by MAC address — particularly in enterprise setups with strict DHCP management — the router sees what appears to be a new, unauthorised device on each connection and rejects authentication.
Settings → Network and internet → Wi-Fi → your network → Random hardware addresses → change from “On” to “Off” for this specific network. With random MAC disabled, the device presents a consistent MAC address, and the router recognises it correctly across sessions.
Authentication timeout after sleep
A specific pattern: authentication errors appear specifically after waking from sleep rather than on fresh connections. The Wi-Fi adapter wakes from sleep and tries to re-authenticate using the stored session state, but the router has expired that session during the sleep period. The adapter’s reconnection attempt uses authentication parameters that no longer match the router’s state.
Fix: Device Manager → Wi-Fi adapter → Properties → Power Management → uncheck “Allow the computer to turn off this device to save power.” Also: Control Panel → Power Options → Advanced → Wireless Adapter Settings → Power Saving Mode → Maximum Performance. These settings prevent the adapter from entering deep sleep and maintain the authentication session across sleep periods, eliminating the wake-up authentication failure.
Checking WLAN event log for specific error
Windows logs every Wi-Fi connection event with detailed error codes. Event Viewer → Applications and Services Logs → Microsoft → Windows → WLAN-AutoConfig → Operational. Look for “Authentication failed” events timed around when the connection attempt failed. The event details include a “Reason” field with a specific numeric code:
- Reason 2 or 22 — Incorrect password
- Reason 8 — AP rejected the authentication request (MAC filtering or RADIUS rejection)
- Reason 15 — 4-way handshake timeout (often WPA3 compatibility or driver issue)
- Reason 45 — Invalid cipher (FIPS or protocol mismatch)
Each reason code maps to a specific fix. This 5-minute check in Event Viewer often immediately identifies the cause rather than working through all possible fixes sequentially.
Router firmware update
Authentication protocols evolve. A router running old firmware may not correctly implement WPA3 or newer WPA2 handshake extensions that current Windows drivers attempt to use. Updating router firmware resolves authentication failures caused by protocol version mismatches between the router’s implementation and Windows’ current Wi-Fi stack.
Log into router admin → Administration or Maintenance → Firmware Update → check for and install any available update. After updating, factory reset the router’s wireless settings (not the full factory reset — just wireless configuration) to ensure the new firmware applies its default wireless configuration rather than inheriting potentially inconsistent settings from the old version.
The diagnostic flow for Wi-Fi authentication errors: forget and reconnect → verify password on another device → WPA3 compatibility test (switch router to WPA2-only temporarily) → driver update → network stack reset → WLAN event log for specific reason code. Most authentication failures resolve within the first three steps. The event log check is the most efficient next step when those three don’t work, because the reason code immediately identifies which of the remaining fixes is relevant rather than needing to try all of them.
One thing worth noting: if the authentication error is on a specific device while other devices on the same network connect fine, the issue is definitively on the Windows machine rather than the router or network. Conversely, if multiple devices suddenly can’t authenticate after a router firmware update or configuration change, the router is the problem and all local fixes will fail until the router issue is addressed. This cross-device comparison is the fastest way to confirm which side of the connection has the problem.
Band preference and authentication failure correlation
Dual-band routers broadcast on 2.4 GHz and 5 GHz. Some Wi-Fi adapters handle authentication differently on the two bands — particularly with WPA3, where band-specific implementation differences can cause authentication to succeed on 2.4 GHz and fail on 5 GHz (or vice versa). The router appears to have the correct password and settings but authentication fails because the specific band the adapter is trying to connect to has a compatibility issue.
Test: Device Manager → Wi-Fi adapter → Properties → Advanced → Preferred Band → change from “5GHz” to “2.4GHz” (or vice versa) → reconnect. If authentication succeeds on the other band, the adapter has a band-specific authentication issue with the current driver. Updating the Wi-Fi driver typically resolves this, as band-specific authentication bugs are among the improvements driver updates address.
Mesh network nodes with inconsistent security settings
In mesh Wi-Fi systems (Google Nest, Eero, Orbi), all nodes should have identical security configurations. When a node is added or replaced with different firmware, or when a firmware update applies to some nodes but not all, authentication settings can differ between nodes. The device authenticates to the main node successfully but fails when it roams to a secondary node that has different authentication parameters.
The pattern: connection works near the main router but fails in other areas of the home where secondary nodes are located. Check the mesh system’s app for any out-of-sync nodes — most mesh apps show which nodes have current firmware and flag any that are inconsistent. Updating all nodes to the same firmware version and ensuring uniform wireless settings across the mesh resolves authentication failures caused by node inconsistency. Our guide on DNS_PROBE_FINISHED_NXDOMAIN covers an adjacent issue.






