# Keep MSP operator identities and customer administration out of the corporate collaboration tenant > An MSP identity exposed to ordinary email and browsing can become a route into customer administration. Separate privileged operators, devices, policies, secrets, and monitoring from collaboration activity. - Canonical URL: https://update.dsesecurity.com/updates/isolate-msp-operator-identities-customer-administration/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: Gavin Stewart - Published: 2026-08-17T13:24:00+00:00 - Modified: 2026-08-17T19:22:09+00:00 - Last reviewed by DSE: 2026-08-17 - Resource type: Guide - DSE priority: Important - Topics: Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know An MSP identity exposed to ordinary email and browsing can become a route into customer administration. Separate privileged operators, devices, policies, secrets, and monitoring from collaboration activity. ## Potentially affected MSP Microsoft Entra tenants; Partner Center; email and collaboration accounts; privileged administrator accounts; service identities; technician workstations; RMM and PSA access; vaults; and customer administration. ## DSE recommendation Create a dedicated privileged identity plane, separate administrative accounts from email identities, require protected devices and phishing-resistant authentication, prohibit shared accounts, monitor partner actions, and test containment. ## Article ## Source facts: MSP identities sit on a high-consequence trust path Microsoft’s [Cloud Solution Provider security best practices](https://learn.microsoft.com/en-us/partner-center/security/csp-security-best-practices) address the elevated risk around partner tenants and customer administration. The guidance calls for multifactor authentication, least privilege, removal of unused delegated access, monitoring, incident response, and stronger protection for identities that can act in customer environments. Microsoft also recommends separating privileged administrative accounts from ordinary productivity use and protecting privileged work through controlled devices and policies. CISA’s advisory on protecting managed service providers and their customers explains why this architecture matters beyond one vendor. Attackers can target an MSP’s centralized tools, credentials, and trusted relationships to reach multiple customers. CISA recommends hardening remote access, using strong authentication, restricting privileged access, separating internal and customer environments where appropriate, logging provider activity, and agreeing on responsibilities with customers. A separate identity plane does not have to mean that every tool is placed in one new tenant, and it does not make the provider immune to compromise. It means identities with customer impact are not routinely exposed to inbox links, general web sessions, collaboration applications, and unmanaged endpoints. The appropriate implementation depends on licensing, tool federation, customer contracts, availability requirements, and each vendor’s supported identity model. ## DSE recommendation: design a customer-administration identity plane Treat the MSP’s administrative identity system as production infrastructure for every customer it can affect. Its architecture should limit how far a single phished account, stolen token, malicious extension, or compromised workstation can travel. - Map privileged paths. Inventory Partner Center, GDAP, RMM, PSA, backup, documentation, password vault, firewall, cloud, registrar, security tooling, and customer-local accounts. Record identity provider, authentication flow, session duration, customer reach, owner, and recovery path. - Separate human identities. Give administrators distinct named accounts for customer work and corporate collaboration. Do not provision mailboxes, chat, social applications, or ordinary browsing access to privileged identities unless there is a documented operational need. Never use shared technician accounts. - Protect the device path. Require administration from hardened, managed devices or privileged access workstations. Limit browser extensions and local administrator rights, enforce device health, patch quickly, control removable media, and prevent privileged sessions from being copied into unmanaged environments. - Use strong, scoped authentication. Prefer phishing-resistant credentials, conditional access, short sessions, and time-bound elevation. Restrict source locations where practical. Store recovery material separately, protect break-glass accounts, and alert on changes to authentication methods and policies. - Constrain service identities. Replace embedded or shared secrets with managed, rotatable credentials where supported. Document every non-human account, permitted customers and actions, owners, expiry, and evidence. Do not let an automation identity inherit the combined reach of every technician. - Correlate customer-impacting activity. Send identity, Partner Center, vault, RMM, and administrative logs to protected monitoring. Associate high-risk actions with an operator, device, customer, ticket, and time. Alert on impossible travel, unusual customers, bulk changes, policy tampering, and access outside expected workflows. - Test containment. Run exercises for a phished collaboration account, stolen privileged token, lost workstation, compromised RMM identity, and disabled identity provider. Verify that responders can revoke sessions, isolate devices, disable customer paths, notify affected customers, and preserve evidence without destroying recovery access. Factual boundary: Microsoft and CISA publish security practices, not a universal requirement that every MSP create a particular tenant topology. Separation reduces shared exposure but also creates operational and recovery dependencies. Architecture must be tested against supported product behavior and customer obligations. Measure privileged identities with collaboration access, customer reach per identity, phishing-resistant enrollment, unmanaged privileged sessions, stale service accounts, log coverage, and containment time. The goal is a defensible boundary: compromising an ordinary corporate session should not immediately grant an attacker the provider’s customer-administration authority. ## Official references - Microsoft Learn, [Security best practices for Cloud Solution Provider partners](https://learn.microsoft.com/en-us/partner-center/security/csp-security-best-practices). - CISA, [Protecting Against Cyber Threats to Managed Service Providers and their Customers](https://www.cisa.gov/news-events/cybersecurity-advisories/aa22-131a). - Microsoft Learn, [Customer security best practices](https://learn.microsoft.com/en-us/partner-center/security/customer-security-best-practices). ## Primary reference - Name: Microsoft Learn: Security best practices for Cloud Solution Provider partners - Authority: Microsoft Learn - URL: https://learn.microsoft.com/en-us/partner-center/security/csp-security-best-practices - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Keep MSP operator identities and customer administration out of the corporate collaboration tenant,” DSE Security, https://update.dsesecurity.com/updates/isolate-msp-operator-identities-customer-administration/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved.