The UK government just did something your clients will eventually ask you about: it started killing passwords. GOV.UK's One Login programme — covering 23 million user accounts — has begun rolling out passkeys, and Whitehall gets a welcome side benefit: roughly £600 a day off its SMS one-time-passcode bill. Do the maths on working days and that is about £150,000 a year saved by not sending text codes.

If you run a service desk or an MSP NOC, two things should register when you read that story. First: password resets, account lockouts and MFA issues are almost certainly the single biggest source of low-value, high-frequency work in your queue. Second: when big platforms move to passkeys, the operational fallout — endpoint readiness audits, patch levels, fallback procedures, user comms — lands on you, across every client tenant, at the same time.

If your RMM, helpdesk, monitoring and patching tools do not talk to each other, that migration becomes yet another five-tab fire drill. Here is what the password's slow death actually means for your team, and how to get ahead of it instead of drowning in it.

The Problem: Identity Work Lives in the Gaps Between Your Tools

Ask any helpdesk lead what share of tickets are password-related. Industry figures have hovered around 20-40% for a decade, and the classic ~$70-per-reset cost still holds when you price technician time at MSP billing rates. If your desk closes 2,000 tickets a month and a conservative quarter are identity-related, that is 500 tickets at roughly 12 minutes each — 100 hours of skilled technician time every month spent on work that should not need a human at all.

Now layer on the multi-client reality. Every client you manage has a different identity setup:

• One on-prem AD domain on Windows Server 2019 because "the migration is next year" (it has been next year since 2022)
• Two Microsoft 365 / Entra ID tenants with different MFA policies
• A Google Workspace shop
• A legacy line-of-business app with its own local accounts
• Firewall and switch credentials nobody dares touch

None of this lives in your RMM, because RMMs think in devices. It does not live in your standalone monitoring tool, because those think in interfaces, disks and services. It half-lives in your PSA or helpdesk, which is a ticket database with no telemetry attached. So a single "I can't log in" call can mean touching AD, Entra ID, the VPN appliance and the LOB app — across four browser tabs — before you even know which system is the culprit.

Worse: the ticket only exists once the user calls. Your helpdesk SLA clock starts when a human notices a problem. Nothing in your stack is watching for the account lockout storm caused by one service account with an expired password on a Tuesday morning — the kind of quiet event that takes down a print server, a backup job and an app pool simultaneously while your dashboard sits there green.

Then month-end arrives and the client asks for an SLA report. Your PSA says one thing, your monitoring says another, and your RMM shows you knew about the failed service in 90 seconds even though "response time" shows as 40 minutes. You cannot reconcile the numbers because the data lives in three systems with three different clocks.

This is the structural issue the GOV.UK story illuminates: passkeys remove an entire category of human toil at the identity layer, permanently. Most MSP tool stacks cannot even see the identity layer, let alone automate it. Siloed architecture is not a design choice anyone made deliberately — it is the residue of vendors selling point products in 2010 and bolting integrations on ever since.

How AlertMonitor Closes the Loop

AlertMonitor was built multi-tenant from day one for exactly this model of work, and several things follow from that:

• One NOC view across all clients. Isolated per-client dashboards plus a unified view, so a tech supporting 20 clients stops living in browser tabs.
• Alerts create tickets automatically. A failed service, a lockout spike or an endpoint going offline in any client generates a ticket in the same platform — with client, device and context attached. No swivel-chair copy-paste between monitor and PSA.
• Per-client SLA thresholds and alert routing. The client paying for 24/7 gets paged; the 8x5 client's low-severity alert waits until morning. Accurate SLA reporting falls out of the same data instead of being assembled by hand every month.
• RMM script execution from the alert. See the alert, run the saved remediation script, attach the output to the ticket. One screen.
• Patch management next to alert and ticket data. This matters enormously for the passkey wave, because passkey support on Windows depends on reasonably current builds (Windows 10 22H2 or Windows 11 with current cumulative updates, Entra ID or hybrid join, and a WebAuthn-capable browser).

Compare the workflows for the most common ticket you handle:

Old way: user calls → triage guesses at the system → tech alt-tabs through RMM, AD, M365 admin center → resets the right credential → emails the user → documents in the PSA → closes. Fifteen to twenty-five minutes, and the next tech starts from zero.

AlertMonitor way: alert fires (service down, authentication failure pattern, endpoint offline) → ticket auto-created with full context → tech runs the saved script job from the same view → output attached to the ticket → verify and close. Two to three minutes, and the audit trail writes itself.

Scale that across 500 identity-adjacent tickets a month and you are not saving minutes. You are saving full technician headcount-days, every month, permanently.

Practical Steps You Can Take This Week

1. Quantify your identity ticket load

Pull a CSV export from your helpdesk and count it. Do not estimate — this number is your business case.

# Count password/MFA-related tickets from a helpdesk CSV export
$Tickets = Import-Csv 'C:/Exports/tickets.csv'
$Identity = $Tickets | Where-Object {
    $_.Subject -match 'password|reset|locked|mfa|2fa|login|sign.?in'
}
[PSCustomObject]@{
    TotalTickets    = $Tickets.Count
    IdentityTickets = $Identity.Count
    PercentIdentity = [math]::Round(($Identity.Count / $Tickets.Count) * 100, 1)
}

If that lands above 20%, you have a payroll-sized automation opportunity sitting in your queue.

2. Inventory which endpoints can actually do passkeys

Before any client asks about passwordless sign-in, know which of their machines are even capable. OS build is the gate.

# Report OS build and last boot across a client's endpoints
$Computers = Get-Content 'C:/Lists/ClientA_Endpoints.txt'
Invoke-Command -ComputerName $Computers -ScriptBlock {
    $os = Get-CimInstance Win32_OperatingSystem
    [PSCustomObject]@{
        Computer = $env:COMPUTERNAME
        Caption  = $os.Caption
        Build    = $os.BuildNumber
        LastBoot = $os.LastBootUpTime
    }
} -ErrorAction SilentlyContinue |
Export-Csv 'C:/Reports/ClientA_Builds.csv' -NoTypeInformation

Everything stuck on an old build goes on a patch ring before anyone mentions passkeys.

3. Find the endpoints sabotaging themselves: pending reboots

The number one reason feature updates and new auth stacks misbehave is a machine that has been "reboot pending" for three weeks. Sweep for it.

# Which endpoints are stuck pending a reboot
Invoke-Command -ComputerName (Get-Content 'C:/Lists/ClientA_Endpoints.txt') -ScriptBlock {
    $pending = Test-Path 'HKLM:/SOFTWARE/Microsoft/Windows/CurrentVersion/Component Based Servicing/RebootPending'
    [PSCustomObject]@{
        Computer      = $env:COMPUTERNAME
        RebootPending = $pending
    }
} -ErrorAction SilentlyContinue |
Where-Object RebootPending |
Export-Csv 'C:/Reports/ClientA_RebootPending.csv' -NoTypeInformation

4. Automate the checks you currently do by hand at 2am

The disk fills up. The service dies. These are the events that either reach you before users notice, or after. In AlertMonitor both are monitored thresholds with auto-ticketing and a one-click script run from the alert. The script behind it, if you are doing it manually today:

# Verify a critical service is running, restart it if not
Get-Service -Name 'Spooler' -ComputerName 'CLIENTA-PRINT01' |
    Where-Object Status -ne 'Running' |
    Restart-Service -Force -PassThru

bash

Linux box in the same client: service health + disk pressure in one pass

systemctl is-active nginx || systemctl restart nginx df -h / | awk 'NR==2 {print $5 " used on /"}'

5. Sequence the rollout per client, not per incident

Once readiness is visible, use per-client patch rings and SLA thresholds to roll forward in waves: patch a pilot group, watch alert volume in the NOC for a week, then expand. That is a filter-and-schedule exercise when monitoring, patching and ticketing share one platform — and a week of spreadsheet archaeology when they do not.

The Bottom Line

GOV.UK is retiring passwords for 23 million people because keeping them was costing real money every single day — in SMS fees, in phishing exposure, in support toil. Your MSP is paying an equivalent tax right now, except yours is denominated in reset tickets, context switching and end-of-month SLA arguments. That toil will not vanish on its own; the industry is only now dragging the identity layer into the platform era.

The MSPs who win the next few years will be the ones whose monitoring, RMM, helpdesk and patching operate as one system — so that when the industry moves again (passkeys today, whatever comes next year), the answer is "run a report and schedule the waves," not "spin up a project."

Related Resources

AlertMonitor MSP Operations & Team Efficiency AlertMonitor Platform Overview Book a Demo MSP Operations & Team Efficiency Resources