Whose Tool Is It Anyway? The Co-Managed IT Stack, Split

Co-managed IT breaks the moment nobody can say who owns the RMM agent. The split sounds simple. Your internal team handles some of the work, an outside provider handles the rest. But the friction never lives in the org chart - it lives in the tools.

This guide maps every core IT tool category to one clear owner: your internal team, the MSP, or shared.

TL;DR: Who Owns the Co-Managed IT Stack

• Identity and the tenant. Your internal team owns these outright - global admin and the Microsoft 365 or Entra tenant never move to the MSP.
• RMM and PSA. The MSP brings and runs both; you get read access and a written data-export clause.
• ITSM and documentation. Shared, but your team holds the master copy and export rights so nothing traps you.
• Security and backup. MSP-run day to day, but recovery decisions and restore testing stay on your side of the line.

The Co-Managed Split Is a Tools Problem, Not a People Problem

Co-managed IT is a model where an internal IT team and a managed service provider share responsibility for the same environment. It sits between two extremes. Fully managed IT services hand everything to the provider. A pure in-house team owns it all and burns out trying. Co-managed IT support splits the load: the internal team keeps the work that needs business context and institutional memory, and the MSP covers depth, after-hours coverage, and the tools no small team can staff around. If you're still mapping out which functions to split in the first place, our co-managed IT overview covers what stays in-house versus what goes to the MSP.

The model is growing because regulated and mid-market firms often can't fully outsource. In legal, accounting, and healthcare especially, the split is a compliance requirement - our guide to co-managed IT for regulated firms covers why. They need someone inside who understands the business and someone outside who can scale. In long-running r/msp and r/sysadmin threads on co-managed setups, the same complaint surfaces over and over: the partnership didn't sour over personalities or SLAs. It soured because two teams reached for the same tool with no agreement on who controlled it. One side disabled a monitoring agent the other side depended on. A patch window collided. A documentation platform renewed under the MSP's account and the client couldn't export a thing.

None of that is a people failure. It's an ownership gap. So before you compare vendors, draw the lines. Every tool in the stack belongs to exactly one owner, even when both teams touch it daily.

The Ownership Map: Every Category, One Owner

Here's the default split that holds up across most co-managed arrangements. Treat it as a starting point, then write your specific version into the agreement.

What Your Internal Team Must Own Outright

Two categories should never leave your hands, no matter how much you trust the provider.

The first is identity. Your identity provider - Microsoft Entra ID, Okta, or JumpCloud - is the single point that governs access to email, files, finance systems, and every SaaS app you run. Whoever holds the global admin role can read anything, lock anyone out, and grant access to themselves. In a healthy co-managed relationship, the MSP gets a delegated or privileged role scoped to what they support, with conditional access and logging on top. The break-glass global admin account stays with your business. If a provider asks for permanent global admin "to make support easier," treat it as a red flag, not a convenience.

The second is the tenant and endpoint management layer that sits on it. Microsoft Intune and similar UEM tools are wired directly into your Microsoft 365 tenant and your device enrollment records. If the MSP owns the tenant, switching providers means rebuilding your entire device fleet's management from scratch. Keep tenant ownership in your name, your billing, and your domain. Let the MSP operate inside it. The work can be theirs; the keys can't be.

This is the part the ranking guides on co-managed IT services skip. They frame the model as a service tier. It's really a question of which administrative roles you're willing to delegate and which you keep behind glass.

What the MSP Brings: RMM and PSA

Two tools belong to the provider, full stop.

Remote monitoring and management is the engine an MSP runs its service on. The provider deploys agents, watches for alerts, pushes scripts, and remediates at scale. Expecting your internal team to co-own the RMM platform usually backfires: you pay for seats you barely use, and you create a second hand on the kill switch. The better arrangement is MSP-owned RMM with read-only visibility for your team plus, critically, a clause that says you can export device inventory and historical data if the relationship ends. If you want to understand how the major platforms differ before you sign, our breakdown of RMM tools for MSPs covers pricing and total cost in detail. RMM software is a commodity layer now; the lock-in lives in the data it holds, not the agent itself.

PSA is the one tool internal teams most often confuse. Professional services automation - ConnectWise PSA, Autotask, HaloPSA, SuperOps - runs the MSP's business: time tracking, billing, contracts, and their own ticket queues. You don't need a seat in your provider's PSA, and you shouldn't want one. It isn't built for your workflow. What you need is your own ITSM or ticketing system that the MSP can plug into. If you're evaluating what the provider runs behind the scenes, the PSA tools MSPs run day to day post lays out the field. The rule of thumb: PSA is theirs, ITSM is yours, and the two integrate at the ticket level.

The Shared Layer: ITSM, Ticketing, and Patch Management

The shared categories cause the most friction precisely because both teams have a legitimate claim.

Start with ITSM and ticketing. In most co-managed setups the internal team handles tier-one requests and the things that need a hallway conversation, while the MSP takes escalations and specialized work. That only functions if both sides work the same queue with clear routing rules. Pick one ITSM platform - ServiceNow for larger shops, Freshservice or Jira Service Management for leaner ones - and give the MSP a scoped queue inside it rather than a separate system. Helpdesk automation matters here too: shared ticket deflection, auto-routing, and status sync keep the two teams from stepping on each other. If you're choosing a platform, our ITSM software comparison breaks down the options by team size and budget. The system can be owned by your internal team; the MSP just needs a documented seat in it.

Patch management is shared by asset class, not by team. The clean split most groups land on: the MSP patches servers and infrastructure under a maintenance window, the internal team owns workstation and third-party app patching, and someone is named owner for every category in writing. Patch management software like Action1, Automox, or ManageEngine Patch Manager Plus can serve both sides, but the deployment rings and approval authority need an explicit owner. Unowned patching is how a co-managed environment ends up with a server nobody rebooted for nine months.

Documentation and Data: Where Lock-In Hides

Documentation looks harmless and quietly becomes the biggest trap in the whole arrangement.

When the MSP owns the only copy of your network diagrams, passwords, runbooks, and asset records in their IT Glue or Hudu instance, leaving that provider means walking away with nothing. You're not just switching vendors; you're starting your documentation from zero. The fix is structural. Documentation is shared, and your business holds the master tenant or, at minimum, a contractual right to a full export in a usable format on demand. Confluence, Hudu, and IT Glue all support this - the question is whose account the records live under.

This is where the broader lock-in conversation belongs. The tools that create the most switching pain in a co-managed setup are the ones that hold your data: identity, documentation, and backup. Tools that are easy to swap, like an RMM agent, create far less risk. When you choose a provider and a stack, weight the decision toward portability. An AI-native, all-in-one MSP and IT platform such as OpenFrame is built around that idea - native PSA included, your data exportable, and no contractual trap at renewal. It won't suit every shop, but the design goal is the right one: keep the tooling consolidated and affordable without surrendering control of your own records. Whatever you pick, the test is the same. Can you leave with your data intact? If the answer is no, the price on the quote isn't the real cost.

Security and Backup: Owned by the MSP, Verified by You

The last two categories follow the same pattern: the MSP runs them, and you keep verification rights.

Security operations and endpoint detection and response are where outsourcing earns its keep. A small internal team can't run a 24/7 SOC or triage alerts at 3 a.m. Let the MSP or a dedicated MSSP own SentinelOne, CrowdStrike, Microsoft Defender for Endpoint, or Huntress and the monitoring around it. What stays with you is the decision authority: who can isolate a machine, who approves a forced password reset across the company, and who gets called first during an incident. Write the incident-response chain of command before you need it, because an outage is a terrible time to discover that nobody agreed on who decides.

Backup and disaster recovery work the same way, with one hard addition. The MSP can own and run the Datto, Veeam, or Acronis platform. But the data is yours, and a backup you've never restored is a hope, not a plan. Keep two rights on your side: a documented recovery plan you've reviewed, and a recurring restore test you witness or run yourself. RTO and RPO targets should be your numbers, agreed in writing, not whatever the provider's default happens to be. Verification is cheap. Discovering a broken backup during a ransomware event is not.

How to Put the Split in Writing

A handshake split lasts until the first disagreement. Turn the ownership map into contract language so it survives staff turnover on both sides. At minimum, name the owner for each tool category, spell out the MSP's administrative scope in Microsoft 365, require a data-export clause for RMM, documentation, and backup, and define the incident-response decision chain. Add a quarterly access review so delegated roles don't quietly accumulate into shadow global admin. The goal isn't distrust. It's a record both teams can point to a year from now when the people who set it up have moved on.

Treat the first 90 days as a transition, not a finished state. Audit what the outgoing setup owns before the MSP touches anything: list every admin account, every tool license, and whose name sits on each contract. Most co-managed disputes trace back to an ambiguity that existed on day one and never got resolved. A short onboarding inventory, signed by both sides, turns the ownership map from a nice diagram into something enforceable when a tool, a person, or a provider eventually changes.

Frequently Asked Questions

What is co-managed IT?

Co-managed IT is a model where an internal IT team and a managed service provider share responsibility for the same environment. The internal team keeps work needing business context, and the MSP adds depth, after-hours coverage, and tools a small team can't staff around.

What's the difference between co-managed and fully managed IT services?

Fully managed IT services hand the entire environment to a provider with no internal IT staff. Co-managed IT keeps an in-house team in place and splits the work. The split makes co-managed the common fit for regulated and mid-market firms that can't fully outsource.

Who owns the RMM in a co-managed IT setup?

The MSP owns and runs the RMM platform, since it's their core delivery engine. Your internal team should get read-only visibility plus a written clause guaranteeing you can export device inventory and historical data if the relationship ends.

Should the MSP have global admin in Microsoft 365?

No. The break-glass global admin account stays with your business. Give the MSP a delegated or privileged role scoped to what they support, protected by conditional access and logging. Permanent global admin for a provider is a security and lock-in risk.

Does co-managed IT cost more than fully managed?

Not necessarily. You pay for internal salaries plus a lighter MSP scope, so the line items differ. For firms that need in-house staff for compliance or business context, co-managed often costs less than duplicating that depth inside a fully managed contract.

How do I avoid vendor lock-in with a co-managed MSP?

Keep ownership of identity, the Microsoft tenant, documentation, and backup data on your side. Require export rights in writing for every tool that holds your records, and favor consolidated, portable platforms over ones that trap data behind a renewal.

Co-managed IT doesn't fail because two teams share the work. It fails because nobody wrote down who holds the keys. Decide ownership before the first ticket, not during the first outage - and the model that looks messy on paper turns into the most resilient setup you'll run.