One Forgotten Account, 4,000 Patient Records: Why Offboarding Is an MSP Operations Problem

A contractor at a dental organization needed access to patient records. Instead of going through onboarding, they set up their own account — one with access to roughly 4,000 patient records. Then they left the company, and the account stayed behind. No offboarding process owned it: it appeared on no termination checklist, matched no HR record, and sat with live access to sensitive health data until someone finally noticed. The Register ran the story under the headline "Toothless security," which is generous.

If you run IT for a single company, this story should make you want to run an account audit tomorrow. If you run an MSP, it should make you want to run one across every client domain you touch — and then be honest about how long that would actually take with the tools you have.

This is not primarily a security failure. It is an operations failure. And operational excellence across many client environments is exactly what an MSP is supposed to be better at than anyone.

What the Story Actually Exposes

Strip away the dental specifics and you get a pattern that plays out in nearly every environment you manage:

1. An account exists that nobody asked for. A contractor, a vendor, a former employee's test login, a service account someone stood up on a Friday afternoon. It is functional, often privileged, and undocumented.
2. The person leaves. HR runs their offboarding checklist. The checklist covers the AD account, maybe the M365 license, maybe the badge. It does not cover accounts nobody knew existed.
3. The gap sits open. Weeks, months, sometimes years. IBM's Cost of a Data Breach research has consistently put the identify-and-contain window for credential-related incidents at roughly 200 days. The dental contractor's account would fit comfortably inside that window.
4. Discovery comes from the outside. An audit, an insurance questionnaire, a breach notification. Never from the monitoring stack — because the monitoring stack was watching disk space and services, not identities.

Every sysadmin reading this has seen a version of item #1. The real question is whether your tooling would catch it at step 1 or at step 4.

The Problem in Depth: Offboarding Is a Ticket That Closes, Not a Process That Verifies

Here is how offboarding actually works at most MSPs, because the tooling forces it to work that way: HR sends an email, a tech disables the AD account, the ticket closes. Your PSA — ConnectWise, Autotask, HaloPSA, pick yours — shows a closed ticket with a clean timestamp and the SLA report looks great. What actually happened is that one identity out of dozens got one action applied to it.

Nobody checked:

• Local administrator accounts on the client's servers and workstations
• Service accounts running line-of-business applications
• VPN profiles and firewall logins — that SonicWall or FortiGate admin account a vendor needed two years ago
• RMM and remote-access tool accounts, including your own former techs' accounts still valid inside client tenants
• Line-of-business SaaS portals — like the practice management system at the center of the dental story
• Standing privileged access split between on-prem AD and Entra ID, where offboarding touched one and not the other

Why doesn't anyone check? Because the tools make checking expensive. Your RMM — NinjaOne, Datto RMM, ConnectWise RMM — knows about endpoints, not identities. Your helpdesk knows about tickets, not assets. Your standalone monitoring platform knows about uptime, not accounts. The identity truth lives in AD, Entra, and a dozen LOB apps that have no relationship with your PSA. Reconciling them is manual work, so it happens at audit time instead of continuously — if it happens at all.

Now multiply by the MSP model. Thirty clients, each with its own domain, its own exceptions, its own office manager who "knows the admin password." A former tech's domain admin credential still active in Client #14. A vendor account in Client #7 that outlived the vendor relationship by eighteen months. Nobody is tracking this across tenants because no single tool you own can see across tenants. You would have to log into each client's environment individually, run the same checks, and paste results into a spreadsheet. That is a day of work per quarter you don't have, so it doesn't happen.

What it costs when it fails:

• Breach exposure per client. One forgotten account with access to ePHI is a HIPAA reportable event in the US or an ICO/GDPR matter in the UK — and as the MSP, expect to answer for what your monitoring caught and when.
• Audit and insurance drag. Cyber insurance renewals and client security questionnaires increasingly demand offboarding evidence and access reviews. If your answer is 'we disable AD accounts when tickets come in,' you are attesting to a control you cannot demonstrate.
• Technician hours burned on archaeology. When someone finally asks "who has access to this client's systems?", the answer takes a tech two days of console-hopping. That is two days of billable project work gone.
• Trust. The client who reads the dental contractor story will ask you, their MSP, whether this could happen to them. "We'd probably catch it" is not an answer. A scheduled report is.

How AlertMonitor Closes the Gap

The dental contractor scenario survives on exactly one condition: nobody is looking. AlertMonitor's model is built so that something is always looking — across every client, simultaneously.

One multi-tenant inventory instead of thirty disconnected ones. Every device, agent, and monitored system across all of your clients lives in a single NOC view with per-client isolation. When a client or an auditor asks what a client environment contains and who administers it, you answer from one screen instead of logging into five consoles. When a client relationship ends, you can see in seconds whether any of their agents are still checking in — no orphaned endpoints phoning home with no owner.

Alerting on the events that used to slip through, routed per client. AlertMonitor's intelligent alerting is not just "server down." Per-client alert policies cover the identity-adjacent events that historically nobody watched: a new account appearing in a client's AD, a configuration change on a monitored system, an agent going dark. The contractor's secret account becomes an alert on your NOC board within minutes of creation — not a finding in a breach investigation a year later. Routing rules send it to the tech who owns that client, with SLA thresholds you define per agreement.

Offboarding that verifies instead of assumes. Because the helpdesk is integrated with monitoring and inventory data, your offboarding ticket template is not a wish list — it is a checklist backed by live data. The verification task "confirm no active accounts for this user outside of AD" runs against actual inventory. The ticket doesn't close on faith; it closes when the checks ran.

Reporting that answers the audit question before it's asked. Per-client reports on active accounts, newly created accounts, and stale agents run on a schedule. The cyber insurance renewal that used to trigger a two-day fire drill becomes a PDF you already have.

One platform instead of four. The reason offboarding verification never happens is that it costs five logins and an afternoon. When monitoring, RMM, helpdesk, and patching live in one platform, verification costs nearly nothing — and things that cost nothing get done every single time.

Old Way vs. AlertMonitor

Practical Steps: What to Do This Week

You don't need to wait for a platform migration to shrink this risk. Run the sweep below across your client base now, then automate it.

1. Find enabled accounts with no recent logon, per client domain

This is the exact profile of the dental contractor's account: enabled, but no legitimate activity behind it.

Search-ADAccount -AccountInactive -TimeSpan '90.00:00:00' -UsersOnly |
    Select-Object Name, SamAccountName, LastLogonDate, Enabled |
    Sort-Object LastLogonDate |
    Export-Csv 'C:\Reports\ClientA_InactiveUsers_90d.csv' -NoTypeInformation

Anything Enabled with a LastLogonDate older than 90 days either gets a named owner or gets disabled. Run it for every client domain you manage — not just your own.

2. List accounts created in the last 30 days — and match them to tickets

Get-ADUser -Filter * -Properties whenCreated, Enabled, Description |
    Where-Object { $_.whenCreated -gt (Get-Date).AddDays(-30) } |
    Select-Object Name, SamAccountName, whenCreated, Enabled, Description |
    Sort-Object whenCreated -Descending

Every account on this list should trace back to an onboarding or change ticket. If it doesn't, that is your undocumented contractor — caught on day one instead of at discovery.

3. Reconcile AD against a source of truth

If you can get a simple HR export of active employees, this makes orphaned accounts unmissable:

$hr = Import-Csv 'C:\Exports\HR_ActiveEmployees.csv'
$adUsers = Get-ADUser -Filter { Enabled -eq $true } -Properties EmployeeID
$activeIds = $hr | Select-Object -ExpandProperty EmployeeID

$orphans = $adUsers | Where-Object { $activeIds -notcontains $_.EmployeeID }
$orphans | Select-Object Name, SamAccountName, EmployeeID |
    Export-Csv 'C:\Reports\OrphanedAccounts.csv' -NoTypeInformation
Write-Host "$($orphans.Count) enabled AD accounts have no matching active HR record."

EmployeeID is the cleanest join key. If your client doesn't populate it, making that happen is step zero.

4. Check local administrators on the client's servers

Domain accounts get the attention; local ones get forgotten:

$servers = 'SRV-FS01', 'SRV-APP01', 'SRV-SQL01'
Invoke-Command -ComputerName $servers -ScriptBlock {
    Get-LocalGroupMember -Group 'Administrators' |
        Select-Object @{n='Server';e={$env:COMPUTERNAME}}, Name, PrincipalSource
}

5. Same sweep for the Linux boxes you manage

# Accounts with no login in 90+ days, including never-logged-in accounts
sudo lastlog -b 90

6. Turn the annual scramble into a standing workflow

1. Build the offboarding ticket template in AlertMonitor's helpdesk with the verification checks above baked in as required tasks — the ticket cannot close until they run.
2. Create per-client alert policies for new account creation and agent-offline events, routed to the client's primary tech with the SLA threshold from your agreement.
3. Schedule the inactive-account and new-account reports monthly per client. That report becomes your evidence trail for audits, insurance renewals, and nervous client questions.

The Math on Why This Matters

Done manually: 30 clients × 20 minutes per sweep × monthly = 10 hours a month of the least glamorous work on your plate — which is exactly why it never happens. Done in AlertMonitor: the checks run on schedule, alerts fire on exceptions, and your techs touch only what gets flagged. The dental contractor's account would have lived for minutes, not months.

That story was not a zero-day. It was not an APT. It was an inventory problem — an account that existed outside every process anyone owned. Inventory problems are operations problems, and running operations across many clients from one pane of glass is what AlertMonitor was built for. The next version of this headline doesn't have to include your client's name.

Related Resources

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