Why MSP Security Models Keep Missing Machine Identity Risk

Nearly 46% of organizations have experienced breaches related to nonhuman identities, with the average enterprise suffering 2.7 incidents in the past year, according to AppViewX research. That is not a story about teams ignoring security. Organizations of every size run monitoring stacks, compliance checklists, and insurance programs, often through a managed service provider.

That is the uncomfortable part. The tools are there. The problem is that the operating model most MSPs work inside was designed for human users, human credentials, and human scale identity counts. That world no longer exists.

What follows is a breakdown of why the failure keeps happening, what it means for cyber insurance, and what a real fix looks like.

The scale problem: MSP service models were not built for machine identity counts

SailPoint research shows that 69% of companies manage more machine identities than human identities, with nearly half deploying 10 times as many. CSO Online reports that in some cases nonhuman identities outnumber humans as much as 50 to 1. For a mid market company running modern cloud infrastructure, that is the baseline, not an edge case.

MSP service agreements, staffing ratios, and tooling budgets were built around managing people: provisioning user accounts, enforcing password policies, and handling offboarding. A technician scoped to manage 200 endpoints for a client was never scoped to also track thousands of service accounts, API keys, and certificates across that same environment.

The ratio broke the model. When machine identities started multiplying, most service tiers stayed the same: the same per seat pricing, the same monitoring dashboards, the same staffing assumptions. The result is a coverage gap that grows every time a client adds a microservice, an integration, or a cloud workload.

The gap compounds automatically. Every new workload, API integration, and CI/CD pipeline generates new machine identities, and an MSP contract written two years ago almost certainly does not account for them.

The visibility gap: certificates, API keys, and service accounts live where standard monitoring does not look

Most MSP monitoring stacks are excellent at watching what people do. They log sign ins, flag anomalous access, and alert on privilege escalation for user accounts. Machine identities operate on a different surface, and that surface is largely invisible to the tools MSPs typically deploy.

Sectigo describes the core problem precisely: in most organizations, responsibility for public and private certificate management is divided across different teams, and that siloed approach creates visibility and communication gaps. Network or security teams own public certificates. Other teams own private ones. The MSP often owns neither completely and tracks both in spreadsheets.

The operational cost is measurable. In their 2022 State of Machine Identity Management research, Keyfactor and the Ponemon Institute found that 81% of organizations had experienced two or more disruptive outages caused by expired certificates in the past two years, and that recovery took more than three hours on average. An expired or misconfigured certificate is not only an availability problem. It is a signal that nobody is watching that identity.

API keys and service accounts compound the problem. They are often created by developers under deadline pressure, granted broad permissions for convenience, and then forgotten. Many never expire, and nobody gets an alert when they go stale.

The compliance trap: checkbox IAM gives leadership confidence the data does not support

Most IAM controls were written with people as the primary subject. SOC 2, ISO 27001, and NIST all cover access management, but audit questions tend to center on user provisioning, MFA enforcement, and role based access for employees.

Machine identities slip through because they are reviewed in aggregate, not in detail. A company can answer yes to having an identity management program while running thousands of service accounts with no named owner, tokens with far more permission than any workflow needs, and certificates expiring on dates nobody tracks.

SailPoint makes this concrete: 75% of surveyed companies have machine identities without a dedicated employee responsible for them. Entro Labs' 2025 research adds that 90% of tokens have excessive permissions, 62% of secrets are duplicated and stored in multiple locations, and 91% of former employee tokens are never revoked.

That last number is worth sitting with. Former employee tokens, still active and still credentialed, in production environments that passed their last audit. The checklist said access management: yes. The environment said something different.

The insurance exposure: what a claim reveals when machine identity hygiene is missing

Cyber insurers ask pointed questions about access. QBE's ransomware supplemental asks whether multifactor authentication is required for all internal, external, and vendor access to the applicant's network. Tata AIG's supplemental states that when information security is outsourced to a managed security provider, the applicant is understood to have verified its responses with that provider before submitting.

The coverage structure adds another layer of risk for MSPs. As Acronis notes, an MSP's cyber insurance coverage does not extend to client data or systems. It protects the MSP's own business. When an MSP helps a client complete an insurance application, any gap between what the MSP actually manages and what the application declares becomes a problem at claim time.

Consider a common scenario. A client is breached through a compromised service account and files a claim. The investigation finds the account had excessive permissions, no rotation schedule, and no named owner, while the application declared that identity and access controls were in place. The MSP had signed off on the security posture. The claim is disputed, errors and omissions exposure lands on the MSP, and the relationship ends badly for everyone.

These gaps are rarely found during underwriting. They surface during claims investigation, after the breach, which is the worst possible time to learn that machine identity hygiene was never in scope.

A practical accountability shift: the governance and contract changes that close the gap

The joint CISA and NCSC advisory on protecting MSPs and their customers is direct: service agreements should identify ownership of ICT security roles and responsibilities, and providers should segregate credentials across customer environments and apply MFA wherever possible. That guidance was published in 2022. Many MSP contracts still do not reflect it.

The practical starting point is a decision rights model. Every service account, API key, and certificate in a client environment needs two things named in writing: an accountable owner, the person or team that knows what breaks if the identity disappears, and a governing function, the team that runs discovery, sets policy, and executes revocation. As Lumos puts it in its nonhuman identity strategy guide, these are rarely the same people, and writing both into your program document is one of the most useful actions you can take in week one.

Beyond ownership, three operational changes matter most:

• Continuous discovery over periodic audits. Spreadsheet reviews miss the identities created between audit cycles. Recurring discovery catches the service account a developer created on a Tuesday afternoon.
• Time bound credentials with enforced rotation. Keys and tokens that never expire are a permanent attack surface. Set maximum lifespans and build revocation into offboarding for both people and the services they own.
• Contract language that names machine identity scope explicitly. If the MSP is not responsible for certificate lifecycle management or service account governance, write that exclusion into the agreement. Ambiguity is where errors and omissions claims live.

None of this starts with a new platform. It starts with a decision about accountability that many MSPs have deferred because the old model never forced the question. At today's machine identity counts, deferring is no longer a neutral choice.

Where tooling helps is keeping that accountability current. Avistar gives MSPs and security teams a read only inventory of the machine identities in each client cloud tenant, with owner, last activity, and blast radius for each one, so the decision rights you write down stay attached to the identities that actually exist.