Two incidents from the same eight week stretch explain the problem better than any vendor category diagram.
In February 2024, ConnectWise disclosed an authentication bypass in ScreenConnect. It carried the highest possible severity score. An attacker with network access to the management interface could create an administrator account on a self hosted server without any credentials at all. Huntress recreated a working exploit the same day. Within a week, researchers were counting hundreds of attacking IP addresses, and ransomware operators were using the flaw for initial access. The software was widely deployed by managed service providers, which meant one bug opened a path into every downstream client estate.
A few weeks earlier, Microsoft detected an intrusion in its own corporate tenant. The entry point was a password spray against a legacy test tenant account with no MFA. The actual damage came next. Microsoft's own writeup describes how the attacker found a legacy test OAuth application that still held elevated access to the corporate environment, then used it to register new applications and grant itself full mailbox access across the organization.
Neither of these is a story about a firewall or an endpoint agent. Both are stories about identities that no human being ever logs into. A remote access server. A forgotten application registration. Nobody owned them. Nobody reviewed them. Nobody deleted them.
MSPs know this. Most of them have already run the search in a client tenant and found forty application registrations they cannot account for. The struggle is not awareness. The struggle is that the tools built to solve this problem were designed for a company managing one estate, and an MSP manages sixty.
The tools are priced and scoped for a single enterprise
Start with the money, because that is where most evaluations die.
Microsoft Entra Workload ID Premium is the native answer for service principals and managed identities in a client tenant. It gives you Conditional Access for workload identities, risk detection, and access reviews for the applications sitting in the directory. It costs $3 per workload identity per month, and it is a standalone SKU that is not bundled into any Microsoft 365 or Entra plan. Not Business Premium. Not E5. If a client has 60 service principals eligible for premium controls, that is a new line item on their invoice, and someone at the MSP has to justify it.
AWS follows the same shape. The unused access analyzer in IAM Access Analyzer is genuinely useful, and it is the correct starting point for finding stale roles and keys. External access findings are free. Unused access analysis is billed per IAM role or user analyzed per month, currently twenty cents each. That is trivial for one account and awkward when you are the one explaining a new recurring charge to thirty clients who each thought security was already included.
Now multiply the operational side. Each tenant is a separate purchase decision, a separate console, a separate set of findings, and a separate approval from a client who did not budget for it this year. The MSP absorbs all of that coordination and bills none of it. The economics of the channel run on repeatable delivery across many clients. Native identity tooling is priced and scoped for one company securing itself.
There is no machine identity object in the MSP operating stack
Walk through the actual systems an MSP runs a business on.
The PSA holds tickets, contracts, and client contacts. ConnectWise, Kaseya, and HaloPSA all model a client, a configuration item, and a user. The RMM holds devices and agents. NinjaOne and Datto tell you what is patched and what is offline. Documentation lives in IT Glue or Hudu. Identity work runs through the directory.
Point to the record for a service account in any of those systems. There isn't one. A service principal is not a device, so the RMM ignores it. It is not a person, so it never appears in an onboarding or offboarding workflow. It is not a contract line, so the PSA has no reason to track it.
This is why the failure is so consistent. An MSP's offboarding checklist is usually excellent for humans. Disable the account, revoke sessions, reassign the license, forward the mailbox, wipe the device. Every one of those steps has an owner and a ticket template. Then the integration engineer who left had created an API key for a backup job three years ago, and that key is not on the checklist, because the checklist was built around a person and the key was built around a process.
Machine identities are created during projects, and projects close. The identity keeps running long after the ticket is marked resolved.
Detection is easy and deletion is political
Suppose the scan runs and comes back clean in the sense that it produced results. You now have a list of 340 findings across 28 tenants. Unused roles, keys that have not been rotated in two years, applications with permissions nobody consented to on purpose.
The technician picks one and asks the only question that matters. Can I delete this?
Nobody knows. The client's internal IT lead left in 2023. The vendor who built the integration is no longer under contract. The AWS role has a name like svc-prod-etl and no tag telling you which system it belongs to. Deleting it might break payroll. So the finding goes into a document, the document goes into the quarterly review, and the identity stays alive for another year.
This is the part most tooling gets wrong. Discovery is the cheap half. Ownership attribution and safe removal are the expensive half, and neither of them is a scanning problem. They are process problems that require an owner, an approval path, and a rollback plan that a level one technician can actually execute at 4pm on a Thursday.
The MSP is itself a concentration of machine identities
There is one more layer that makes this uniquely hard for the channel.
An MSP does not just manage client machine identities. It creates them. Every RMM agent is a privileged identity on a client endpoint. Every delegated admin relationship into a client tenant is a standing grant of authority. Every connector between the PSA, the RMM, the backup platform, the email security tool, and the SIEM is a token held by the MSP on the client's behalf.
Microsoft's move away from blanket delegated admin privileges toward granular, time bound delegated access was a direct response to this exposure. It helped. It did not eliminate the underlying fact that a mid sized MSP holds more standing privilege across more organizations than most Fortune 500 security teams, with a fraction of the staff to govern it.
That is what the ScreenConnect incident actually demonstrated. Attackers were not interested in one remote access server. They were interested in the trust relationships flowing through it.
What works instead
The MSPs handling this well are not running better scanners. They built a process and attached it to systems they already operate.
Assign ownership at creation, not at review. Every service principal, IAM role, and API key gets a tag or notes entry recording the owning system, the requesting party, and an expiry date. This costs two minutes during a project and saves the impossible archaeology later. Make it a line in the project closeout template so it cannot be skipped.
Eliminate secrets where the platform allows it for free. Workload identity federation and managed identities are included at no additional cost in Azure. Every client secret you remove is a rotation date you never have to track, and it sidesteps the premium licensing question entirely for a meaningful share of your inventory.
Put findings into the PSA as tickets against a client, not into a PDF. A finding with no ticket has no owner and no due date. A finding that lands in the same queue as everything else gets triaged like everything else.
Make the review a billable deliverable tied to a framework the client already cares about. CMMC, SOC 2, HIPAA, and cyber insurance renewal questionnaires all ask about service accounts and privileged access in some form. That reframes the conversation from a new cost to an existing obligation, which is the only version of this pitch that survives a client budget meeting.
Score by blast radius, not by count. A dormant read only key in a development subscription and a live application with mailbox wide permissions are not the same finding. If your report treats them the same, the technician will treat both as noise.
The real gap
The tools are not incapable. Entra, AWS, and the secrets platforms all do serious work inside a single estate. The gap is that none of them were built for someone who has to do this across sixty clients, with no client side identity owner, on a fixed monthly fee, using technicians who are not identity specialists.
That is a channel problem, and it needs a channel shaped answer. That is the problem we work on at Avistar: machine identity discovery and risk scoring designed to run across a book of business rather than one tenant at a time, priced so an MSP can deliver it as a service line instead of a project.
The identities are already there. The only real question is whether anyone can name their owner.