Every identity roadmap in 2026 has the same slide: passwordless within two years. Microsoft is pushing passkeys and Windows Hello for Business through Entra ID, FIDO2 keys are finally cheap, and every new laptop ships with a fingerprint reader. What the slide never shows is week one of the rollout at your helpdesk.
John O'Neill Sr.'s recent Redmond Magazine piece, What It Really Takes To Go Passwordless, names the part everyone underestimates: the new sign-in method is the easy part. Recovery, legacy applications, and user support decide whether the rollout succeeds — and all three of those funnel straight into your support queue.
If you run internal IT or you are the MSP tech holding a dozen client tenants together, accept this early: passwordless is not primarily a security project. It is an operations project with a security deadline, and your helpdesk is the front line.
Passwordless Doesn't Kill Password Tickets — It Mutates Them
Industry surveys have long put password-related issues at 20–50% of helpdesk volume, and analysts have pegged a single assisted reset at $70 or more once technician time is counted. The mistake teams make is assuming passwordless deletes that workload.
It does not. It transforms it:
- I got a new phone and cannot approve sign-ins (Authenticator re-registration)
- I left my FIDO2 key at home, in my other laptop, in a drawer
- My Windows Hello for Business PIN broke after a BIOS or driver update
- The accounting app on the terminal server still wants a password, and now it fails
- My Temporary Access Pass expired before I finished enrollment
None of these are security failures. All of them are tickets. During an enrollment wave — say, 400 users migrating over a month — your queue can double for two to three weeks even when the rollout is going well.
Recovery Is Where Rollouts Go to Die
The sharpest point in the Redmond piece is recovery. Passwordless without a tested recovery path means the user who lost their phone and their key in the same week has exactly one way back in: a manual admin intervention.
On paper you have Temporary Access Pass, SSPR, and break-glass accounts. In practice, in most shops, recovery lives in the head of one senior admin and a runbook nobody has touched since the pilot. Issuing a TAP means the Entra portal. Re-registering Authenticator might mean clearing a method in another console. A WHfB key-trust issue means checking msDS-KeyCredentialLink in Active Directory. Three tools for one ticket, with the clock running on a user who cannot work.
Multiply that by an MSP supporting twelve clients with different identity stacks, and every lockout becomes a 30-minute swivel-chair session before the tech even starts the actual fix.
Legacy Apps Are the Landmines You Planted Yourself
Every environment has them: the line-of-business app on a terminal server that only speaks NTLM, the VPN gated by NPS/RADIUS, the copier scanning to email with basic-auth SMTP, the vendor appliance running under a local service account. Tighten authentication policy and these break — usually in production, usually discovered by the first user who calls the helpdesk rather than by your change process.
Here is the worst version of the story, and every sysadmin has lived some variant of it: the monitoring tool knew. The NPS service on the RADIUS box stopped at 6:47 AM. A standalone monitoring platform emailed a distribution list. At 8:15 the phones lit up with cannot-connect-to-VPN calls. Nobody correlated the alert with the ticket queue. The tech who picked up was working a ticket that said only "user cannot log in" — no device health, no service status, no alert history. So he opened the RMM console, the Entra portal, ADUC, and the helpdesk. Four tools, zero shared state.
Root cause: one dead service. Damage: 60 duplicate tickets, three hours of interrupted sign-ins across the org, and an SLA report nobody trusts because it was reconciled by hand between two systems that disagree on timestamps. The problem was never the passwordless method. The problem was monitoring, helpdesk, and remote access living in three disconnected systems.
How AlertMonitor Closes the Gap
This is the exact workflow AlertMonitor was built around: the monitoring alert and the support ticket are the same object, not two events in two tools.
When the NPS service on nps01 stops, AlertMonitor does not just send an email. It raises an alert against the device, automatically creates a ticket, and assigns it based on device, client, and alert type — before the first end user calls. The technician opens a context-rich ticket that already contains:
- The full alert history for that device, so he knows NPS flaked twice last month too
- Live device health: CPU, disk, services, pending patches on that box
- One-click remote access into the server to restart the service or pull logs
- The client and SLA clock already running
Compare the two workflows:
Old way: First user calls at 8:15, tech triages blind across four consoles, root cause found at 9:40 by whoever thought to check the RADIUS box, 60 tickets closed one by one with copy-pasted notes, SLA numbers assembled from a spreadsheet a month later.
AlertMonitor way: Alert fires at 6:47, ticket exists at 6:48 in the identity queue, tech remediates by 7:10, the handful of user calls that do come in get linked to the root-cause ticket, and SLA data is already in the platform — not reverse-engineered afterward.
The same pattern covers the whole identity stack: AD FS service health, Entra Connect sync failures, domain controller issues, certificate expiries, and disk pressure on the auth servers themselves. And because AlertMonitor's RMM and patch management run in the same platform, your DCs and federation servers stay patched on schedule — so the certificate that kills federation is never the one that expired because nobody touched the box for six months.
End users get faster resolutions. Technicians stop swivel-chairing. IT managers finally get real SLA reporting instead of a reconciliation exercise.
Practical Steps: Prepare the Helpdesk Before the Passwordless Wave
1. Monitor the identity stack like the production system it is. These four checks catch the failures that generate the most lockout tickets. Run them on a schedule, point AlertMonitor's monitoring at the results, and let each failure auto-create an assigned ticket.
Check AD FS token-signing certificate expiry — the most common silent federation killer:
# Run on an AD FS server (requires the ADFS PowerShell module)
Get-AdfsCertificate -CertificateType "Token-Signing" |
Select-Object CertificateType, NotAfter, Thumbprint,
@{Name = 'DaysRemaining'; Expression = { ($_.NotAfter - (Get-Date)).Days }}
Verify Entra Connect sync is enabled and scheduled — when password hash sync stops, passwordless sign-ins and SSPR start failing in confusing ways:
# Run on the Entra Connect server (requires the ADSync module)
Get-ADSyncScheduler |
Select-Object SyncCycleEnabled, NextSyncCycleStartTimeInUTC
Confirm a user's Windows Hello for Business key is actually registered in AD before you blame the client device:
# Key trust: WHfB credentials live in msDS-KeyCredentialLink
Get-ADUser -Identity jsmith -Properties msDS-KeyCredentialLink |
Select-Object SamAccountName, msDS-KeyCredentialLink
Sweep an auth server for any certificate expiring in the next 30 days:
Get-ChildItem Cert:\LocalMachine\My |
Where-Object { $_.NotAfter -lt (Get-Date).AddDays(30) } |
Select-Object Subject, NotAfter, Thumbprint
And confirm the core services are running on your federation and RADIUS boxes:
Get-Service -Name ADFSSrv -ComputerName adfs01 # AD FS service
Get-Service -Name IAS -ComputerName nps01 # NPS / RADIUS
2. Inventory legacy auth dependencies before you tighten anything. Talk to application owners, not just the security team. Every NTLM dependency, RADIUS integration, and basic-auth SMTP endpoint you find now is one less 8 AM fire during rollout week.
3. Build the recovery runbook into the helpdesk, not a wiki. TAP issuance, FIDO2 key replacement, WHfB PIN reset, Authenticator re-registration — document each as a procedure attached to the ticket type, pair it with a canned response, and give techs one-click remote access so a recovery takes minutes instead of a conference call.
4. Make identity tickets their own category. When the enrollment wave hits, you will see the surge in real time and can staff for it. Afterward, you will have the SLA data to show the true operational cost of the rollout — the number every IT manager wishes they had for their last big project.
5. Pilot with one friendly department and watch the ticket categories for two weeks. Your queue will tell you the truth about your legacy apps faster than any discovery scan.
The Bottom Line
O'Neill's core message is the one your helpdesk already knows: recovery, legacy applications, and user support decide whether passwordless succeeds — not the sign-in method. The teams that roll this out cleanly are the ones whose monitoring, helpdesk, and remote access work as one system. In those shops, a certificate nearing expiry becomes a ticket thirty days before the outage instead of sixty panicked phone calls after it.
Related Resources
AlertMonitor Helpdesk & End-User Support AlertMonitor Platform Overview Book a Demo Helpdesk & End-User Support Resources
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.