User Lifecycle Automation Coverage Across MSP IAM Stacks

Most managed service providers sell identity and access management as if it's one product. It isn't, and that distinction matters because authentication is the visible half of the job. Authentication (SSO, MFA, directory sync) is the visible half of the job. Lifecycle automation decides whether an identity should exist at all and what it's allowed to touch, and that is what gets skipped, even though it actually governs risk over time.

The framework for that second half has a name: joiner, mover, leaver, or JML. Three separate triggers, not one continuous process. A joiner event fires on hire and provisions access. A mover event fires on a role change and should adjust access up or down. A leaver event fires on departure and should revoke everything, everywhere, immediately. Each one needs its own workflow, its own trigger source, and its own audit trail.

Compare that to what SSO and MFA actually do. Those two govern proof: does this person logging in really work here, and can they show a second factor to prove it? That's a login-time question. It says nothing about whether the account behind that login should still have access to the finance system six months after a demotion, or whether it should exist at all three weeks after termination. Lifecycle automation governs that second question, and it's a fundamentally different piece of engineering.

MSP stacks lean toward authentication for a plain reason: it's the part clients notice. A client feels MFA the moment they get a push notification on their phone. Lifecycle gaps don't announce themselves the same way. An orphaned account just sits there, quiet, until someone finds it during an audit or, worse, until an attacker finds it first. Vendor ecosystems reflect that asymmetry too. SSO, MFA, and directory sync are mature, well-packaged, and heavily marketed. Joiner/mover/leaver tooling is scattered across a dozen half-solutions, none of which fully cover the problem on their own.

The industry term for the layer above IAM is ILM, Identity Lifecycle Management. The industry term for the layer above IAM is ILM, Identity Lifecycle Management. Most MSP definitions of "IAM" never reach it. Per TruGrid, IAM in the MSP context typically just means MFA, SSO, and password management. Full stop. Lifecycle automation isn't part of the working definition most MSPs are selling against, which means it's rarely part of what they're actually built to deliver.

How bad the gap is: orphaned accounts, identity sprawl, and the last-mile problem

The clearest number on this comes from The 2025 State of NHIs and Secrets in Cybersecurity: 91% of former employee tokens remain active after offboarding. That's not a rounding error. That's the direct, measurable output of a leaver process that isn't automated, where deprovisioning depends on a technician remembering to revoke access instead of a system doing it automatically.

Identity sprawl makes the problem worse before anyone even gets to offboarding. The State of Multi-Cloud Identity Survey found that 75% of organizations manage two or more identity providers, and 11% juggle five or more. Manually tracking a departing employee's access across five separate identity systems is a math problem. It's a math problem. At some point the number of systems outpaces the number of hours in the day.

Then there's the last-mile gap. Stitchflow's research puts it at roughly 40% of apps in a typical stack that standard identity providers simply cannot touch. No SCIM connector, no API, no SSO integration. That means even a properly configured Entra or Okta deployment, humming along and doing exactly what it's supposed to do, still leaves nearly half the app stack unmanaged at the exact moment offboarding matters most.

Picture the ordinary version of this at an MSP: a new hire starts, and technicians manually configure Active Directory, email, and whatever line-of-business apps the client runs. That's normal onboarding. The failure becomes visible on the other end. Miss one application during deprovisioning, and that account doesn't get flagged, it doesn't get logged, it just keeps existing. Active, credentialed, unmonitored. That's exactly the kind of account attackers look for, because nobody's watching it.

And credentials are cheap to come by right now. According to a review of MSP identity management software by josys.com, 1.8 billion credentials were compromised in early 2025. One compromised orphaned credential inside an MSP's environment doesn't stay contained to one client. It's a foothold that can move across the entire client base the MSP serves, because MSP tooling by design touches many tenants at once.

The size of the gap isn't constant. It shifts depending on which platform is anchoring the stack.

What Microsoft Entra ID Governance covers in the JML stack, and where it stops

Entra's lifecycle coverage rests on four pieces working together: lifecycle workflows, entitlement management, access reviews, and Privileged Identity Management (PIM).

Where it earns its reputation: inside the Microsoft 365 and Azure ecosystem, joiner provisioning and leaver deprovisioning are genuinely automated. Deprovisioning runs on SCIM synchronization cycles, typically every 20 to 40 minutes after a user is disabled or pulled from a provisioning group. That's near-real-time revocation, not instant, but close enough that the exposure window shrinks dramatically compared to a manual ticket queue. For an MSP managing dozens of client tenants, Entra ID Governance means writing an access policy once and applying it consistently everywhere, instead of logging into each tenant separately to chase down stale permissions one client at a time.

The weak leg is the mover case. Role-change workflows depend on entitlement management being configured with real care, and a lot of MSP deployments skip that step or configure it loosely. The result is access that accumulates instead of adjusting.

A few other cracks appear at the edges. Automatic provisioning generally requires a P1 or P2 license, a cost threshold that plenty of smaller MSP clients never clear. Apps outside the Microsoft ecosystem without SCIM connectors fall straight into the last-mile gap; Entra has no reach there without extra tooling layered on top. And multi-tenant management at MSP scale, dozens of client tenants running side by side, needs deliberate architectural planning, because Entra wasn't originally built with service-provider workflows in mind.

Pairing Entra with an endpoint management platform can add automatic user creation and deactivation tied to Azure AD changes, plus group-to-role mapping at the device level. That's endpoint compliance. It's a useful layer, but it's not app-layer lifecycle automation, and treating it as a substitute for JML coverage is a mistake.

Okta's Coverage and Its Complicated MSP Story

Okta's lifecycle strengths are real and well-documented. Okta Lifecycle Management gives MSPs low-code and no-code JML automation through Okta Workflows, a logic builder for constructing custom joiner/mover/leaver sequences without writing scripts from scratch. Behind it sits the Okta Integration Network, with more than 7,000 pre-built integrations, representing extensive pre-built SCIM and SSO connector coverage. Universal Directory centralizes user profile management across connected apps and directories, and Okta's MFA options span push notifications, SMS, biometrics, and hardware tokens.

Pricing starts around $6 per user per month, billed annually, though that cost climbs fast at MSP scale, and smaller clients tend to push back hard on per-user pricing once the bill scales with headcount.

The complication for MSPs specifically is architectural. Okta was built with single-tenant enterprise deployments as the design center. Multi-tenant management, the actual day-to-day reality of an MSP running identity across dozens of unrelated clients, is a secondary use case bolted on rather than the foundation. The same 40% last-mile gap that appears with Entra persists here too: apps without SCIM or Integration Network connectors still need supplemental tooling to close the gap. And while mover workflows are technically possible through custom Workflows logic, building and maintaining that logic per client adds a significant configuration burden for MSP teams.

The tools built to close the gaps Entra and Okta leave open

Three distinct approaches show up in the 2026 research, and each one is aimed at a different failure mode rather than competing head-on for the same job.

Last-mile provisioning for non-SCIM apps. Stitchflow works as a bridge between an identity provider and the apps that have no API, no SCIM support, and no SSO hook to plug into. It uses a secure, policy-driven headless browser to automate provisioning, deprovisioning, and access changes on apps that would otherwise require a human to log in and click through manually. Rula, a national behavioral healthcare provider, adopted Stitchflow and found over 200 orphaned accounts sitting in the environment, most of them tied to disconnected apps sitting entirely outside identity-provider visibility. Turing, a global developer platform, used it to eliminate hundreds of manual offboarding tickets across more than 25 SaaS apps, closing 312 offboarding gaps in the process. It also keeps full video-recorded audit trails of every user action taken, which matters directly for MSPs working under SOC 2 or HIPAA compliance requirements.

Multi-tenant, MSP-native lifecycle management. Josys is built from the ground up for multi-client environments, not as a single-tenant platform with an MSP mode bolted on after the fact. It consolidates provisioning, license management, and access control into one pane of glass across every client environment, while keeping tenant separation intact. Its automation engine flags unused licenses and access anomalies at the same time, which hits both the security gap and the quieter problem of SaaS cost leakage that orphaned accounts cause. New hires get onboarded across every SaaS app in minutes based on role policy, and departures trigger instant deprovisioning rather than a ticket sitting in a queue.

Non-SCIM and non-human identity coverage. Redblock uses agentic AI to automate lifecycle management, privilege governance, and credential rotation across apps with no APIs and no SCIM support. It also extends governance to non-human identities: service accounts, bots, API keys, machine identities, the exact category traditional IAM tools were never built to see. That matters because an OAuth app, a bot, or an API token needs an owner, an expiration date, and a regular review cycle, just like an employee account does, and most MSP IAM stacks have no policy covering any of that today.

One Identity's standing backs up how fast this category is professionalizing: its Active Roles and Safeguard products were ranked #1 and #2 among non-human identity management solutions by PeerSpot in 2026, the company appears in the 2025 KuppingerCole Identity Fabrics Leadership Compass, and it was named a Visionary in the 2025 Gartner Magic Quadrant for Privileged Access Management. Non-human identity governance is becoming its own evaluation category, not a feature checkbox buried inside a bigger platform.

The mover problem: why mid-tenure role changes are the lifecycle gap MSP stacks handle worst

Joiners and leavers both have hard, unambiguous triggers: a hire date, a termination date. Movers don't work that way. A role change happens inside the business, sometimes quietly, and there's no guarantee it ever gets reported to the identity system.

The result is over-privileged users piling up across the org chart. An employee moves from support into sales engineering, picks up new access for the new role, and keeps every permission from the old one because nothing forced a reconciliation. Most organizations are still handling this with static rules, tickets, or fragmented scripts, which means access updates lag the actual role change by days or weeks while the old permissions sit there unused but still valid.

A properly built ILM platform should adjust access at every role change, not just at the beginning and end of employment. That requires real HR system integration, tied to actual personnel events rather than manual tickets, and a lot of MSP deployments simply haven't built that wiring.

Temporary access is the hardest version of managing movers whose permissions are never pulled back. An employee joins a project, gets elevated permissions for it, the project wraps up, and those permissions never get pulled back because no expiration policy or review process ever triggers. Entra's Privileged Identity Management is the closest native answer for that specific case, letting elevated access expire on a schedule. But it requires deliberate setup and appropriate licensing, and it only reaches as far as the Microsoft surface, leaving everything outside it uncovered. Access reviews, available in Entra and in mature identity governance platforms generally, act as the backstop when automation fails. Quarterly or annual review cycles are a weak substitute for automation running in real time, but they're better than no backstop.

Non-human identities: the lifecycle layer MSP IAM stacks weren't built to see

Identity in a modern SaaS environment isn't limited to people sitting in a directory. Service accounts, API tokens, OAuth app connections, and bots all create access paths that touch business data directly, and none of them appear in records the way a human employee record does.

The number bears repeating in this context: 91% of former employee tokens remain active after offboarding, per The 2025 State of NHIs and Secrets in Cybersecurity. Tokens outlive the people who created them. They become unowned, unmonitored paths into systems that nobody's watching anymore, because nobody assigned them an owner to begin with.

That's the structural issue. Non-human identities typically have no owner, no expiration date, and no review cycle, the exact three governance requirements that apply to any employee account. And the standard MSP IAM stack, MFA plus SSO plus password management by TruGrid's 2026 definition, has no architectural place for any of it. It's not an oversight inside the stack. It's outside the stack's scope.

The attack surface consequence is concrete. Per Huntress's SMB Threat Report, adversaries hijacked remote monitoring and management tooling supplied by an MSP or internal IT team in 65% of SMB incidents. Service accounts and API tokens tied to that same tooling are exactly the kind of high-value target that explains why. Tooling built to address this, including Redblock and One Identity, is drawing increasing attention as a distinct governance concern separate from traditional IAM platforms. It's not yet a standard line item in most MSP IAM conversations, but the gap it addresses is measurable and growing.

What access governance requires at the stack level, and what that means for how MSPs should evaluate IAM tools

Break the stack into its actual layers and the picture gets clearer fast.

Authentication (MFA, SSO, directory sync) is necessary and it's not optional, but it only proves identity at the moment of login. It says nothing about whether that identity should still hold the access it has.

Most stacks underbuild lifecycle automation: JML workflows tied to HR events, SCIM-based provisioning and deprovisioning, mover reconciliation when roles change, access reviews as a backstop, and time-limited privilege escalation for temporary work.

Last-mile coverage is the structural piece that no identity provider solves alone: provisioning into apps that lack SCIM or SSO support requires either a headless browser bridge, an agentic automation layer, or a purpose-built multi-tenant platform designed for exactly this problem.

Non-human identity governance is mostly invisible right now: service accounts, API tokens, and OAuth connections need a dedicated policy framework, because mainstream MSP IAM stacks don't currently carry one.

And multi-tenant architecture isn't a nice-to-have for an MSP, it's a requirement. Standard identity tools are built for single enterprises. Force a single-tenant tool into a multi-client workflow and technicians end up logging in and out of a dozen separate portals all day, which is exactly the manual friction lifecycle automation was supposed to eliminate. A SCIM-based, policy-driven, genuinely multi-tenant platform is the architectural baseline, not an upgrade.

That leaves a short, practical set of questions for evaluating any IAM tool against this framework. Does the platform automate all three JML stages, or does it stop at joiner and leaver and leave mover as a manual process? How does it handle apps that have no SCIM connector? Does it carry any policy at all for non-human identities and tokens? Is the multi-tenant support real architecture, or a management layer stitched on top of a single-tenant core? And what license tier unlocks the actual lifecycle automation, because that pricing math has to work across small-business clients too, not just the largest accounts on the roster.

Takeaways for SMBs Without a Security Team on the MSP IAM Lifecycle Gap

The gap described in this piece is invisible to the client paying for it. MFA friction is felt immediately, every login, every push notification. Lifecycle gaps sit quiet until an ex-employee's account, or an orphaned service token nobody remembered to review, gets found by the wrong person first.

That asymmetry is the whole reason this gap persists across the industry. Clients can feel authentication working. They can't feel a mover reconciliation that never happened, or a role change from eight months ago that left someone holding access they shouldn't still have. An SMB without a dedicated security team has no way to audit that gap on their own, so the questions worth asking an MSP aren't about MFA rollout or SSO setup. They're about what happens to an account the day someone changes roles, and what happens to it the day they leave.