UniFi Identity for MSPs: Offboarding Is the Real Scope

UniFi Identity for MSPs sounds like the tidy version of access management: one-click VPN, one-click Wi-Fi, Door Access, and identity provider sync from Microsoft Entra, Google Workspace, or LDAP.

That is useful. It is also where the scope can get dangerously fuzzy.

Quick answer: MSPs should treat UniFi Identity as an access policy and offboarding project, not just a checkbox inside Site Manager. The implementation work includes identity provider setup, group mapping, VPN and Wi-Fi policy, Door Access permissions, logs, exclusions, break-glass access, and a client-approved owner for offboarding.

If the client hears "the IdP handles it" and your agreement does not say who audits exceptions, retrieves logs, disables access, and reviews stale users, you have not finished the project. You have only connected the system.

What UniFi Identity actually changes

Ubiquiti positions UniFi Identity around one-click access to doors, Wi-Fi, VPN, and SaaS SSO. The newer UniFi Fabrics model matters because it lets teams centralize people and permissions across multiple UniFi sites under a shared trust domain.

Ubiquiti's help docs say UniFi Fabrics can bind to Microsoft Entra, Google Workspace, Active Directory, LDAP, and JumpCloud LDAP. Once the identity provider is bound, Ubiquiti says the Identity Sync Service acts as the SAML authentication broker for people using UniFi Endpoint services such as Wi-Fi, VPN, and Door Access. The same docs say SCIM sync can facilitate automated employee onboarding and offboarding.

That last phrase is the trap.

Automated sync is not the same thing as owned offboarding. Sync moves identity state. The MSP still has to define the policy, group structure, exceptions, emergency access, audit cadence, and support boundary.

If you have not already scoped the broader management layer, start with our UniFi Fabrics guide for MSPs. Identity is not a side feature. It changes who can touch client networks, doors, and remote access.

The implementation work MSPs should quote

A clean UniFi Identity rollout has more than one setup step. Scope it as a project with named workstreams.

Workstream	MSP task	Client decision
Fabric readiness	Confirm UniFi OS version, supported consoles, ownership, and site grouping	Which sites belong in the trust domain
Identity provider setup	Configure Entra, Google Workspace, LDAP, or JumpCloud LDAP	Which directory is authoritative
Group mapping	Map groups to access roles for users, admins, VPN, Wi-Fi, and doors	Who approves role design
Endpoint services	Configure UniFi Endpoint access for VPN, Wi-Fi, and Door Access	Which services are in scope
Offboarding	Define disablement path, timing, checks, and audit evidence	Who owns the final access review
Exceptions	Document service accounts, contractors, shared devices, emergency access, and exclusions	Who accepts the exception risk
Logging	Define what logs are reviewed, retained, exported, and shown to the client	What evidence the client expects
Pricing	Confirm paid plan, minimum user count, add-ons, and client billing owner	Who pays for licenses and admin labor

That table is the real sale. Not "we turned on identity." The value is a client-ready access model that does not leave VPN, Wi-Fi, and doors in three separate support stories.

IdP setup is not just an IT admin task

The identity provider decision shapes the whole rollout.

For Microsoft Entra, Ubiquiti's guide says the setup uses SAML-based authentication and automated user lifecycle management across Wi-Fi, VPN, and Door Access through the UniFi Endpoint app. It also notes that syncing groups from Entra into UniFi requires Microsoft Entra ID P1 or P2, and email-based invitations require Exchange Online.

For Google Workspace, Ubiquiti lists supported editions and documents a SAML setup flow. Google edition fit matters before the quote goes out, because a client on the wrong subscription can turn a neat implementation into a licensing discussion.

For LDAP and Active Directory, the question is not only "can it connect?" It is whether the client has clean groups, clean ownership, and a process for user lifecycle changes.

MSPs should ask these before implementation:

• Which directory is the source of truth for each client?
• Which groups map to VPN, Wi-Fi, Door Access, and admin roles?
• Who approves new group membership?
• What happens when HR, Microsoft 365, and the client contact disagree?
• Which accounts must never be synced automatically?
• Who reviews stale users every month or quarter?

If the client cannot answer, that is not a technical blocker. It is scope. Put it in the statement of work.

One-click access still needs policy ownership

One-click VPN and Wi-Fi are attractive because they reduce user friction. Door Access is attractive because it ties physical access to the same identity story.

But the more services you put behind the identity layer, the more serious the owner model becomes.

A terminated employee losing Microsoft 365 access is one control. Losing VPN, Wi-Fi, building entry, camera sharing, and any admin path is a broader control. The MSP has to know whether disabling the IdP account is enough, whether local UniFi people remain, whether existing users kept credentials after integration, and whether any access lives outside the synced group model.

Ubiquiti's IdP binding article says existing users and admins are retained after integration, including permissions and credentials such as Touch Pass and NFC cards for UniFi Access. That is not a warning against using the feature. It is a reminder to audit the before-state.

A safe runbook should include:

1. Capture existing users, admins, doors, VPN users, Wi-Fi roles, and access credentials before IdP binding.
2. Bind the identity provider and validate SAML sign-in.
3. Confirm group sync and role mapping.
4. Test one user for VPN, Wi-Fi, and Door Access.
5. Test one removal or disablement flow in a controlled pilot.
6. Confirm logs show the change clearly enough for support and client review.
7. Document exclusions and local accounts that still exist after integration.

That last step is where many projects get sloppy. The client wants a cleaner access story. The MSP needs proof that the story is true.

Logs, exclusions, and break-glass access are not afterthoughts

Every identity rollout needs a boring section called "what happens when this breaks."

For UniFi Identity, that means defining break-glass access before the first real offboarding event. Who can get into Site Manager if the IdP is down? Which local admins remain? How are those accounts protected? Who reviews them? How do you prevent emergency access from becoming permanent backdoor access?

The logging question matters too. Ubiquiti's UID Enterprise plan page lists activity logging storage up to 90 days and door entry recording storage up to 90 days on the paid plan. That may be enough for some clients and too short for others. If a compliance-minded client expects longer evidence windows, the MSP needs to scope export, reporting, or another evidence process.

Exclusions deserve the same treatment. Contractors, shared devices, service accounts, owner accounts, door-only users, and seasonal workers can all fall outside the neat employee lifecycle path. If nobody owns that list, it becomes stale. If it becomes stale, offboarding is mostly theater.

Use the same discipline you would use for a shared responsibility matrix: name what the MSP owns, name what the client owns, and name what is excluded unless the client funds it.

Pricing and scope risk

The pricing conversation can get confusing because UniFi Endpoint is described as license-free, while UID Enterprise has a paid plan. Ubiquiti's UID Enterprise billing page lists a paid plan at $5 per user per month monthly, or $4.50 per user per month with annual payment, with a five-user minimum. It also lists features such as One-Click WiFi, One-Click VPN, phone-based Door Access, user lifecycle management, MFA, universal directory, IdP support, adaptive VPN, and custom roles.

Do not let the client reduce the project to a per-user line item.

The MSP quote should separate:

• Licensing and subscriptions
• Identity provider readiness
• Group cleanup
• Fabric and Site Manager setup
• VPN, Wi-Fi, and Door Access policy design
• Pilot testing
• Offboarding runbook creation
• Log review and reporting
• Exception review
• Quarterly access review

If the client is also refreshing gateways or centralizing more sites, connect this to the broader UniFi network roadmap. The Enterprise Firewall Core guide for MSPs covers why identity-aware policy can turn a hardware refresh into an operating model change.

If you need a cleaner way to turn access findings into project scope and client-ready quotes, join Scopable early access.

The short version

UniFi Identity can make access easier for users and cleaner for MSP administrators. It can also hide the hardest part of access management behind friendly one-click language.

Before you pitch it, decide who owns identity provider setup, group design, VPN policy, Wi-Fi access, Door Access, logs, local accounts, exceptions, break-glass access, and the offboarding proof trail. Then quote the work like a real access project.

The goal is not to connect another identity feature. The goal is to make sure a user who should no longer have access is actually out of the network, the building, and the support gray zone.

Sources

• Ubiquiti Help Center: Binding an Identity Provider to a UniFi Fabric
• Ubiquiti Help Center: Getting Started with UniFi Fabrics
• Ubiquiti Help Center: Integrating Microsoft Entra with UniFi Fabrics
• Ubiquiti Help Center: Integrating Google Workspace with UniFi Fabrics
• Ubiquiti Help Center: UniFi Endpoint Overview
• Ubiquiti Help Center: UID Enterprise Plan and Billing