Llama For managed service providers · LMID
LMID for managed service providers
LMID as the in-house OAuth provider for an MSP's own technicians — not as a wholesale IdP for client tenants.
You're operating a managed service provider — two-to-thirty technicians, a stable of SMB clients, a tooling stack you've built up over years of learning what works. This page is not about doing identity for your clients — that's Entra ID's job and it's not what LMID is for. Read the MSPs vertical page for the broader picture; this page goes deeper on one specific use case: your own staff sign-on across the internal-tools surface every technician touches every day.
LMID is OAuth 2.0. One account per technician, one place to disable on departures, one place to add MFA when the cyber-insurance renewal asks for it, one place to answer "who has access to what" when the auditor asks. The integration work is per-internal-tool — every SaaS app that speaks OAuth 2.0 sign-on (which is most of them in 2026) can point its login button at LMID once and stop maintaining its own password store.
The page below covers the technician-onboarding flow, the departure-rotation flow, the specific internal-tools surface where LMID slots in, and the honest "this isn't the right fit" block.
The problem this combination solves
Managed service providers spend their working hours managing identity for their clients' end users. Microsoft 365 tenants, Entra ID, conditional-access policies, the conversations with cyber-insurance underwriters about MFA enforcement. That stack is the day job and it's not what's broken.
What's broken is the MSP shop's own internal sign-on. The technicians need accounts in the documentation wiki, the password vault, the PSA, the RMM portal, the time-tracking tool, the on-call rotation app, the internal status dashboard, the shared Notion. A dozen-to-thirty SaaS logins per technician, each rotated independently when somebody leaves, each a candidate for the "we forgot to disable that account" failure mode that lands on next quarter's penetration test.
The cyber-insurance renewal asks the question once a year. The MSP's answer "we use Entra ID for clients but our own shop runs on twelve separate logins per tech" is the answer LMID exists to fix.
The technician onboarding flow with LMID
New technician starts Monday morning. The shape, with LMID in place:
1. Create the LMID account. One form. Name, work email, role group (technician / senior / lead / owner). The owner or operations lead does this Friday before the start date; takes 30 seconds.
2. The role group maps to OAuth scopes. The technician role group has read/write on the wiki, write on the PSA, read on the dashboard. The senior role group adds write on the dashboard and admin on the on-call app. The owner role group has admin everywhere. The scopes are configured once, in LMID, not per-app.
3. On Monday, the technician signs in. Visit each internal tool. Click "Sign in with Llama Monkey." Authenticate against LMID. Tool grants the scopes from the role group. Done.
4. Total elapsed time, technician's first morning, for SaaS access. 10–15 minutes for the dozen most-used internal apps. Compare to the "I'll send you the wiki invite, then the PSA invite, then the on-call invite ..." sequence spread across the technician's first week.
The technician departure flow with LMID
Technician's last day, end-of-day. The shape, with LMID:
1. Disable the LMID account. One click. The OAuth refresh tokens issued to each linked SaaS app are invalidated within the next refresh window (minutes, not hours, on the apps tested in pilots).
2. Run the departure checklist. Same checklist you ran before LMID — but instead of twelve rows of "disable the technician in app X," the checklist's identity-rotation section is now one row: disable the LMID account; verify sign-in failure on the three highest-sensitivity tools.
3. The audit trail. LMID logs the last sign-in per app per user. When the post-departure review asks "did anybody touch the password vault after the resignation was filed," the answer comes from one query against one log instead of twelve.
The compounding value is in the bad-departure case — the contested resignation, the for-cause termination, the partner you're winding down with. The shop that ran on twelve independent SaaS logins gets one of those wrong roughly once a year. The shop on LMID doesn't.
The internal-tool surface LMID covers (concretely)
The categories of internal tool a typical 5–25-technician MSP runs, and where LMID slots in:
Documentation. IT Glue, Hudu, BookStack, the team Notion, the team Confluence — every modern docs platform speaks OAuth-based SSO. LMID is the OAuth provider; the docs tool's login button points at it.
Password vault (the shop's own). Keeper, 1Password Business, Bitwarden Teams — all speak OAuth SSO on their business tiers. The shop's vault, not the client vaults; the client vaults remain on whatever client-side identity the contract specifies.
PSA, RMM, helpdesk. Autotask, ConnectWise PSA, HaloPSA, SyncroMSP, Atera all support OAuth 2.0 SSO either natively or via Microsoft / Google federation that LMID can sit in front of. The verification you'd run before joining the waitlist: open each PSA's auth-configuration page and check for "Generic OAuth 2.0" or "OpenID Connect" support.
Time-tracking, on-call, internal dashboards. Harvest, Toggl, PagerDuty, OpsGenie, custom internal admin apps you've built — OAuth 2.0 is the path. LMID is the provider.
NOT in scope. Client tenants. End-user identity for the clients you manage. Anything that would replace Entra ID inside a client's Microsoft 365 tenant. LMID is not that product and the roadmap doesn't move it toward being that product.
When this isn't the right fit for an MSP
You're looking for an IdP to resell to your clients. LMID is not a wholesale IdP. The technicians get accounts; the clients do not. If your business shape is "we sell our clients an identity-as-a-service surface," the right tools are Entra ID, JumpCloud, or — at the high end — Okta / WorkOS.
Your internal tools need SAML, SCIM, or directory sync. LMID is OAuth 2.0 only. No SAML, no SCIM provisioning, no LDAP, no Entra Connect-style directory sync. If your wiki or PSA only supports SAML, LMID doesn't help.
Your cyber-insurance underwriter requires SOC 2 / ISO 27001 reports for your identity provider. LMID is private beta; the audit reports are on the staged-GA roadmap but not in hand today. If the underwriter is asking now, this is the wrong timing.
You're more than ~50 technicians. The operational shape of LMID assumes the owner-operator knows the team by name. Past the point where new hires need a formal intake program with HR, the right answer drifts toward full-fat enterprise IAM.
You need conditional-access policies, device-compliance gating, or risk-based authentication on your own shop's sign-on. Entra ID P2 / Okta Identity Engine territory. LMID intentionally does not ship that surface.
Where this combination doesn't fit
LMID is private beta — onboarding runs through the waitlist and is hand-done today. Public OAuth-client registration lands as part of LMID's staged 2026 GA. If your shop needs production SSO with audit reports this quarter, Entra ID (free with M365) is the right call and there's no shame in that. If you're an MSP owner who's been quietly waiting for somebody to build the right shape of identity for the shop itself — not for the clients, just the staff — the waitlist is the door.
Last updated: 2026-05-19