QCecuring - Enterprise Security Solutions

Why New Employees Can't Connect to WiFi (The Certificate Angle)

Certificate Lifecycle Management 13 Aug, 2026 · 05 Mins read

802.1X onboarding failures, machine certificate provisioning gaps, RADIUS/NPS certificate dependencies, Intune/SCCM enrollment issues, and proven fix patterns for enterprise wireless authentication.


“IT Set Up My Laptop But WiFi Doesn’t Work”

It’s a familiar helpdesk ticket. A new employee received their laptop, logged in, connected to the corporate WiFi network… and nothing. The connection fails silently or throws a vague “can’t connect to this network” error.

The IT team re-images the device, resets network settings, checks the wireless profile — everything looks correct. But the connection still fails.

The root cause, more often than not: a certificate issue.

Enterprise WiFi (802.1X) depends heavily on certificates — both on the client device and on the RADIUS/NPS server. When any part of this certificate chain breaks, wireless authentication fails and users simply cannot connect.

How Enterprise WiFi Authentication Works

The EAP-TLS Certificate Dance

┌──────────┐         ┌──────────────┐         ┌──────────────┐
│  Client  │         │  Access Point │         │  RADIUS/NPS  │
│  Device  │         │  (802.1X)    │         │  Server      │
└────┬─────┘         └──────┬───────┘         └──────┬───────┘
     │                      │                        │
     │── Association ──────▶│                        │
     │                      │── RADIUS Access-Req ──▶│
     │                      │                        │
     │◀── EAP-Request/Identity ─────────────────────│
     │── EAP-Response/Identity ─────────────────────▶│
     │                      │                        │
     │◀── EAP-TLS ServerHello + Server Certificate ─│
     │                      │                        │
     │── EAP-TLS ClientHello + Client Certificate ──▶│
     │                      │                        │
     │     [Server validates client cert]            │
     │     [Client validates server cert]            │
     │                      │                        │
     │◀── EAP-Success + MPPE Keys ──────────────────│
     │                      │                        │
     │══ CONNECTED (encrypted) ═════════════════════╗│
     │                      │                        │

Three certificates are in play:

  1. Server certificate — on RADIUS/NPS, proves network authenticity
  2. Client certificate — on user’s device, proves device identity
  3. Root/Intermediate CA — trusted by both sides for chain validation

EAP-TLS Failure Impact by Scenario

Users affected and mean time to resolve for common cert failures

🔴 A single expired RADIUS server certificate can disconnect every wireless client in the organization simultaneously.

The Five Common Certificate Failures

Failure 1: Client Certificate Not Enrolled

Symptoms:

  • New device, freshly imaged
  • Joins domain successfully
  • WiFi profile pushed but connection fails
  • Event log shows: “EAP TLS requires a client certificate but none was found”

Root Cause:

The machine certificate hasn’t been issued yet. In many environments, auto-enrollment runs on a schedule (every 8 hours by default), and the WiFi profile is pushed before the certificate arrives.

Timeline of failure:
  09:00 - Device imaged and domain-joined
  09:05 - WiFi profile pushed via GPO/Intune
  09:06 - User tries WiFi → FAILS (no client cert yet)
  09:10 - User reports to helpdesk
  
  ... 8 hours later ...
  
  17:00 - Auto-enrollment triggers, certificate issued
  17:01 - WiFi would now work, but user has gone home

Fix:

# Force immediate certificate enrollment
certutil -pulse

# Or trigger Group Policy processing which includes cert enrollment
gpupdate /force

# Verify the certificate was issued
Get-ChildItem Cert:\LocalMachine\My | 
  Where-Object {$_.EnhancedKeyUsageList.FriendlyName -contains "Client Authentication"} |
  Select-Object Subject, NotAfter, Issuer

Failure 2: RADIUS Server Certificate Expired

Symptoms:

  • ALL users suddenly can’t connect (not just new employees)
  • Existing connections may persist, but reconnections fail
  • Supplicant log shows: “Server certificate validation failed”
  • NPS event 6273: “The certificate chain was issued by an authority that is not trusted”

Root Cause:

The NPS/RADIUS server’s certificate expired. Even though the server still presents it, clients refuse to trust an expired certificate.

NPS Server Certificate Status:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Subject:    CN=nps01.company.internal
Issuer:     CN=Company-CA
Not After:  2026-07-16 23:59:59 UTC  ← EXPIRED
Template:   RAS and IAS Server
Status:     ❌ EXPIRED

Impact radius:

ServiceAffectedUsers Impacted
Corporate WiFi (EAP-TLS)✅ YesAll wireless users
Wired 802.1X✅ YesAll wired 802.1X users
VPN (PEAP)✅ YesIf using same NPS
Guest WiFi❌ NoUses different auth
DirectAccessDependsIf NPS-dependent

Fix:

# Check NPS server certificate
Get-ChildItem Cert:\LocalMachine\My | 
  Where-Object {$_.EnhancedKeyUsageList.OID.Value -contains "1.3.6.1.5.5.7.3.1"} |
  Select-Object Subject, NotAfter, Thumbprint

# Force enrollment of new NPS certificate
certutil -pulse

# If auto-enrollment doesn't work, request manually
certreq -enroll -machine "RAS and IAS Server"

# Update NPS configuration with new certificate
# (must be done in NPS console or via netsh)
netsh nps show config

# Restart NPS service
Restart-Service "IAS"

Failure 3: Intermediate CA Certificate Missing from Client

Symptoms:

  • Intermittent failures — some devices connect, others don’t
  • Freshly imaged machines fail; older machines work
  • Certificate chain validation fails on new devices
  • Works fine on wired network (which doesn’t use 802.1X)

Root Cause:

The client device doesn’t have the intermediate CA certificate in its trusted store. The server cert validates up to the intermediate, but the client can’t build the chain to the root.

Expected chain:     What client has:
Root CA             Root CA ✅
  └── Issuing CA      └── (MISSING) ❌
       └── NPS Cert        └── NPS Cert (can't validate)

Fix:

# Export intermediate CA cert from working machine
Export-Certificate -Cert "Cert:\LocalMachine\CA\$thumbprint" -FilePath "C:\temp\issuing-ca.cer"

# Deploy via GPO or Intune to all machines
# GPO: Computer Configuration > Windows Settings > Security Settings > 
#      Public Key Policies > Intermediate Certification Authorities

# Intune: Device Configuration > Trusted Certificate Profile
# Upload the .cer file, assign to all devices

Failure 4: Certificate Template Permissions

Symptoms:

  • New machines (specific model or OU) can’t get certificates
  • Auto-enrollment works for some devices, not others
  • PKI health looks fine, templates are configured
  • certutil -pulse shows “access denied” or “template not found”

Root Cause:

The certificate template’s security ACL doesn’t grant Enroll permission to the computer account (or its group/OU):

Template: "WiFi-Machine-Auth"
Security Permissions:
  Domain Computers      → Read ✅, Enroll ❌  ← PROBLEM
  WiFi-Enabled-Machines → Read ✅, Enroll ✅  ← New devices not in group

Fix:

# Check template permissions
certutil -CATemplates | findstr "WiFi"

# On the CA, verify enrollment permissions
# Open certsrv.msc > Certificate Templates > WiFi template > Security tab
# Ensure the appropriate group has "Enroll" permission

# Add new machine to enrollment group
Add-ADGroupMember -Identity "WiFi-Enabled-Machines" -Members "NEWPC01$"

# Force group membership refresh (requires reboot or re-logon)
# Then trigger enrollment
certutil -pulse

Failure 5: Intune SCEP/PKCS Profile Configuration Error

Symptoms:

  • Cloud-managed (Intune) devices can’t get WiFi certificates
  • SCEP profile shows “Pending” or “Failed” in device status
  • NDES server logs show enrollment failures
  • Certificate never appears in device store

Root Cause:

The Intune certificate profile is misconfigured — wrong SCEP URL, incorrect Subject Name format, or NDES service account permissions:

Common Intune SCEP Misconfigurations:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
❌ SCEP URL points to HTTP instead of HTTPS
❌ Subject Name Format uses {{OnPrem_Distinguished_Name}} for cloud-only device
❌ NDES challenge password expired
❌ Certificate template name has typo
❌ EKU doesn't include Client Authentication OID
❌ Trusted root certificate profile not deployed first

Diagnostic Steps:

# On NDES server, check recent enrollment requests
Get-WinEvent -LogName "Microsoft-Windows-CertificateServices-NDES-Operational" -MaxEvents 50 |
  Where-Object {$_.LevelDisplayName -eq "Error"} |
  Format-Table TimeCreated, Message -Wrap

# Verify NDES IIS application pool identity
Get-IISAppPool | Where-Object {$_.Name -like "*SCEP*"} | 
  Select-Object Name, ProcessModel

# Test SCEP URL accessibility
Invoke-WebRequest -Uri "https://ndes.company.com/certsrv/mscep/mscep.dll" -Method GET

The Complete Troubleshooting Workflow

New Employee WiFi Failure


┌─── Does device have a client cert? ───┐
│ NO                                   YES│
│                                         │
▼                                         ▼
Is device domain-joined    ┌── Is cert valid (not expired)?
or Intune-enrolled?        │ NO         │ YES
│                          │            │
├─ Domain: certutil -pulse │            ▼
├─ Intune: Sync device     ▼        Is RADIUS cert valid?
├─ Neither: Fix enrollment  Request   │ NO          │ YES
│                           new cert   │             │
│                                      ▼             ▼
│                               Renew NPS cert   Check chain trust
│                               Restart IAS      Is intermediate in
│                                                 client store?
│                                                 │ NO       │ YES
│                                                 │           │
│                                                 ▼           ▼
│                                            Deploy CA    Check NPS
│                                            cert via     Connection
│                                            GPO/Intune   Request Policy

Prevention: Ensuring WiFi Works for Day-1 Employees

Pre-Staging Approach

# Pre-provision script: Run during device imaging
# Forces certificate enrollment before WiFi profile is active

# 1. Join domain (or Intune enroll)
# 2. Force immediate cert enrollment
certutil -pulse
Start-Sleep -Seconds 30

# 3. Verify certificate received
$cert = Get-ChildItem Cert:\LocalMachine\My | 
  Where-Object {$_.EnhancedKeyUsageList.FriendlyName -contains "Client Authentication"}

if ($cert) {
    Write-Host "✅ WiFi client certificate enrolled successfully"
    Write-Host "   Subject: $($cert.Subject)"
    Write-Host "   Expires: $($cert.NotAfter)"
} else {
    Write-Warning "❌ Certificate enrollment failed - WiFi will not work"
    # Retry logic
    for ($i = 1; $i -le 5; $i++) {
        certutil -pulse
        Start-Sleep -Seconds 60
        $cert = Get-ChildItem Cert:\LocalMachine\My | 
          Where-Object {$_.EnhancedKeyUsageList.FriendlyName -contains "Client Authentication"}
        if ($cert) { break }
    }
}

Monitoring the RADIUS Certificate

# Scheduled task: Check NPS certificate weekly
$npsCert = Get-ChildItem Cert:\LocalMachine\My | 
  Where-Object {
    $_.EnhancedKeyUsageList.OID.Value -contains "1.3.6.1.5.5.7.3.1" -and
    $_.Subject -like "*nps*"
  }

$daysLeft = ($npsCert.NotAfter - (Get-Date)).Days
if ($daysLeft -lt 30) {
    Send-MailMessage -To "network-team@company.com" `
      -Subject "⚠️ NPS Certificate Expiring in $daysLeft days" `
      -Body "NPS cert on $env:COMPUTERNAME expires $($npsCert.NotAfter)" `
      -SmtpServer "smtp.company.com"
}

Key Configuration Items

ComponentSettingRecommended Value
Auto-enrollment intervalGPO or Intune syncEvery 1 hour (not 8)
RADIUS cert templateValidity period2 years max
Client cert templateValidity period1 year
RADIUS cert monitoringAlert threshold60 days before expiry
Trusted root deploymentMethodGPO + Intune (both)
WiFi profile dependencyCertificate requirementRequire valid cert before profile activates
NDES challenge passwordRotationEvery 7 days

About QCecuring

QCecuring helps enterprises prevent WiFi authentication failures by monitoring the entire 802.1X certificate chain — from RADIUS server certificates to client enrollment status. Our platform alerts you before NPS certificates expire and ensures auto-enrollment stays healthy across your device fleet.

Tags: 802.1X, WiFi authentication, EAP-TLS, RADIUS, NPS, certificate enrollment, Intune, SCEP, auto-enrollment, wireless security, network access, PEAP, machine certificates

Stay Ahead on Crypto & PKI

Monthly insights on certificate management, post-quantum readiness, and enterprise security.

Subscribe Free

Related Insights

Certificate Lifecycle Management

What a $0 Certificate Outage Prevention Strategy Looks Like

Free and open-source approaches to certificate monitoring using PowerShell scripts, certutil queries, cron jobs, and Prometheus exporters — when free is enough and when you've outgrown it.

By Mani sri kumar

18 Aug, 2026 · 06 Mins read

Certificate Lifecycle ManagementEnterprise Security

Certificate Lifecycle Management

The Difference Between Public Certificates and Internal Certificates

Public vs internal certificates explained — different CAs, different management approaches, different risks, and why managing one doesn't mean you manage the other.

By Mani sri kumar

17 Aug, 2026 · 05 Mins read

Certificate Lifecycle ManagementPKI Architecture

Certificate Lifecycle Management

How to Convince Your Manager You Need Certificate Visibility

Champion enablement content with talking points for budget approval, cost justification frameworks, risk framing, one-pager templates, and objection handling for certificate lifecycle management.

By Mani sri kumar

17 Aug, 2026 · 06 Mins read

Certificate Lifecycle ManagementEnterprise Security

Ready to Secure Your Enterprise?

Experience how our cryptographic solutions simplify, centralize, and automate identity management for your entire organization.

Stay ahead on cryptography & PKI

Get monthly insights on certificate management, post-quantum readiness, and enterprise security. No spam.

We respect your privacy. Unsubscribe anytime.