How to give an MSP access to your UniFi network — without handing over ownership

Sign in at unifi.ui.com with the account you believe is yours and open your console’s admin list (Admins & Users). Three things to establish:

• Who carries the Owner label. The admin list names every account with access and its role. One of them is the Owner. If it is not you, everything else in this article is downstream of fixing that.
• Whose email the owning account is registered to. A UI account belongs to whoever controls its email inbox and its multi-factor prompts — not to whoever wrote the check for the hardware. An account created on the provider’s email, even “for you,” is theirs in every way that matters at 2 a.m.
• Whether you can see and remove other admins. If you can open the admin list and the remove action exists for the provider’s entries, you hold the controlling seat. If you have never signed in at unifi.ui.com at all and reach your own network only through the provider, treat that as the finding.

If the audit comes back wrong — the provider is the Owner, or the owning account lives on their email — the fix is a conversation, not a confrontation. Ubiquiti publishes an ownership-transfer flow: the current Owner opens the console’s Control Plane, chooses Transfer Ownership, and selects the new Owner from the console’s admins (adding them first if needed).³ Ask for it at a calm moment, while the relationship is good. That is precisely when a professional provider will say yes without friction.

The grant that keeps you in control is an ordinary admin invitation, sent from your account to theirs:

1. They bring their own UI account. Admins are invited by email and must hold their own account at ui.com.¹ A provider who instead asks to sign in as you, or to “set up the account for you,” is asking for the seat this article is about.
2. You send the invite. From unifi.ui.com, open your console’s Admins & Users screen and add an admin with the provider’s email address.
3. You choose the role — and it does not have to be everything. UniFi’s role model scopes an admin per application: a provider managing your network does not automatically need admin rights over your cameras, door access, or phone system.² Grant what the engagement covers. Widening a role later is one edit; so is narrowing it.
4. Your account keeps its own protections. The owner account stays on your email with multi-factor authentication you control. Nobody needs your password to manage your network — that is what their own admin seat is for.

A full admin role is genuinely full working access: the provider can configure, monitor, update, and troubleshoot everything the engagement needs. Nothing about keeping the Owner seat makes you harder to work for. It changes exactly one scenario — the one where you and the provider part ways.

Recent Site Manager versions (5.9 at the time of writing, with parts labelled Early Access) added a construct built for exactly this relationship: Managed Service Providers and customer Fabrics. A Fabric groups the sites you own under one umbrella with centrally managed people and permissions⁴; an MSP account is what a provider runs on their side, with their own operator team.

The detail that matters is the direction of the handshake. Having set this flow up ourselves, on consoles we own: the provider cannot pull your network into their MSP account. The customer sends the invite. Your Fabric — your sites, your ownership — attaches to their MSP account because you attached it, their operators appear in a list you can read, and the relationship is visible on your side rather than buried in their tooling. For a provider serving many clients, it also replaces a drawer of shared logins with named operators and, for larger organizations, identity enforced against a directory (the settings expose Microsoft Entra, Google Workspace, and LDAP options).

Because parts of this surface are Early Access, expect labels and screens to shift. The governance it encodes is the part to hold onto: the ownership stays where it was, and the grant flows from customer to provider — the same direction this whole article recommends.

The payoff for doing the grant correctly arrives the day the relationship changes: you open the admin list and remove the provider’s entries, and detach the Fabric if you attached one. While you are there, review everything the list shows — engagements accumulate accounts, and an offboarding is the natural moment to remove seats that no longer map to a person you work with. If the provider held credentials for anything local to the hardware, have those rotated as part of the handoff.

Run the same comparison for the other arrangement: if the provider owns the console, your offboarding is an ownership transfer that only they can initiate.³ Most providers cooperate. The point of this article is that “most” is a strange word to accept in a sentence about your own network.

1. Which account will be the Owner of the console, and is its email one that I control?
2. Will your company access it as an invited admin from your own account?
3. Which applications does your admin role cover, and why those?
4. Where are the local device credentials documented, and do I hold a copy?
5. When the engagement ends, what exactly do I remove, and can I do it without you?
6. If you become unreachable — acquisition, closure, dispute — what do I lose access to, and for how long?

A provider who works the way this article describes has short answers to all six, because the answers are “yours,” “yes,” and “nothing.” The questions are not a loyalty test. They are how both sides find out, cheaply and early, whether the arrangement was designed or defaulted.

It is not saying managed networks are a mistake — a good provider watching your network is worth paying for, and the flows above give them everything that work requires. It is not saying a provider who owns your console is acting in bad faith; in most installs it happened because the setup flow made it the path of least resistance. And it is not saying UniFi is unique here — every managed platform has an equivalent of the Owner seat, and the same question is worth asking wherever your network lives.

It is saying the grant should be deliberate, scoped, and reversible by you. That standard is how ShiftCTRL works: clients own their consoles, we operate as invited administrators with the narrowest role the engagement needs, and ending our access never requires our permission.