TL;DR: Least privilege becomes materially harder for MSPs because technicians need privileged access across many client environments, which drives shared credentials, delayed rotation and wider blast radius when an account is compromised, according to Admin By Request. The governance problem is not policy intent but cross-client privilege containment under operational pressure.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Admin By Request's blog post: MSP privilege management breaks down when technicians rely on shared credentials and standing access across many client environments.
Why it matters: This matters because MSP access patterns turn one technician account or one shared secret into a multi-tenant blast-radius problem for both service providers and their clients.
Context
Least privilege is straightforward when one team controls one environment. It becomes far more brittle when the same people must administer many client estates, often at short notice and outside normal hours. That shift changes privilege from a local policy issue into a multi-tenant governance problem, where access scope, session traceability and offboarding discipline all matter at once.
The weak point is not the concept of least privilege. It is the operational habit of making privilege easy to reuse across clients, which undermines NHI lifecycle management and makes technician access harder to govern consistently.
Key questions
Q: Why do shared credentials create so much risk in MCP deployments?
A: Shared credentials erase accountability and make containment harder because every tool call appears to come from the same identity. In practice, that means one leaked key can expose multiple users, multiple agents, and multiple tools at once. Request-level identity is what preserves auditability and lets teams scope access correctly.
Q: Why does just-in-time privileged access reduce risk for remote workers and administrators?
A: Just-in-time privileged access reduces risk because it replaces persistent credentials with temporary authorization that exists only for the task at hand. That means there are fewer leave-behind secrets to steal or share, less chance of misuse after access is no longer needed, and stronger control over who can reach sensitive systems. It also improves accountability through individual audit trails.
Technical breakdown
Why shared technician credentials create a multi-client blast radius
Shared credentials collapse accountability because one secret can unlock many environments and many operators can reuse it without distinct identity evidence. In MSP settings, that means the credential becomes the control plane, not the technician’s identity. The problem is not just exposure if the password leaks. It is that the same access path is valid across many client estates, so compromise, misuse or employee departure all create the same downstream risk surface.
Practical implication: Replace shared admin credentials with per-technician identity and task-scoped access so access can be traced, limited and revoked cleanly.
How just-in-time elevation changes the control model
Just-in-time elevation shifts privilege from a persistent entitlement to an event-bound authorization decision. Instead of leaving technician access permanently available, the system grants elevated rights only for a defined task and then expires them automatically. That reduces standing privilege, narrows the time window an attacker can exploit, and creates a cleaner audit record than shared passwords or always-on admin accounts. In practice, it changes privilege from something stored to something issued. See the AI Agent Authorisation Guide.
Practical implication: Use just-in-time elevation for both remote access and endpoint administration so privileged rights exist only for the active task.
Why multi-tenant remote access needs session-level governance
Remote access across many client systems is not just a connectivity problem. It is a session governance problem because the provider has to control where the technician can reach, for how long, and with what evidence. Browser-based access with recording and expiry reduces persistent exposure, but only if the remote session is tied to a named identity and a bounded task. Without that, remote tools become another channel for privilege reuse across tenants. See the Privileged Access Management Guide.
Practical implication: Scope every remote session to a named technician, a specific client system and an automatic expiry condition.
Threat narrative
Attacker objective: The attacker’s objective is to turn one reusable MSP access path into broad client-environment access with minimal detection and maximum downstream impact.
- Entry occurs when technicians authenticate with shared credentials that can be reused across multiple client environments.
- Escalation follows when standing administrative access persists after the immediate task or after a technician has left the organisation.
- Impact expands across the client portfolio because one compromised technician identity or reused secret can expose many downstream environments.
Breaches seen in the wild
- Azure Key Vault Contributor escalation 2024: Datadog found Azure Key Vault Contributor could add itself to access policies and read every secret, key and certificate in a vault.
- ArtiPACKED 2024: Unit 42 found public GitHub Actions artifacts in major open source projects leaking live GITHUB_TOKENs, runtime tokens and cloud tokens.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
MSP privilege management is a cross-client containment problem, not a single-environment policy problem. The same control that is manageable inside one enterprise becomes fragile when one technician can touch dozens of estates. That changes least privilege from a static entitlement question into a tenancy and delegation problem, because the blast radius of failure is inherently larger.
Shared credentials are a governance debt, not just a convenience issue. They remove the link between a named person and a specific privileged action, which makes offboarding, investigation and accountability much harder. The operational cost of rotating them after departures is itself evidence that the control model is already misaligned with the environment. MSPs should treat this as a signal that identity reuse has outgrown the process built around it.
Just-in-time access is the more durable least-privilege pattern for MSPs because it changes what exists to be compromised. Standing admin access creates persistent exposure, while task-scoped elevation creates a short-lived authorization event. That is why the architectural question is not whether technicians can be trusted, but whether the privilege model depends on trust persisting longer than the work itself.
Task-scoped technician access is the right named concept for this problem. MSP governance fails when access is both multi-client and persistent, because the same privilege can be reused far beyond the task that justified it. The practitioners’ job is to design access so the identity and the task remain coupled for the shortest possible time.
Compliance pressure exposes the hidden weakness in MSP privilege models. When audit evidence depends on manual collection, the control is already too loose for a multi-client service model. A mature MSP privilege programme should produce traceable sessions, expiry evidence and named operator attribution as by-products of operation, not as a special project after the fact.
From our research library:
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to the Ultimate Guide to NHIs.
- Read next: Least Privilege Techniques Guide
What this signals
Task-scoped technician access: MSPs should treat least privilege as a service-delivery control, not only an internal admin policy. When one operator can reach many client estates, persistent access becomes a liability unless every elevation is named, time-bound and traceable.
The operational signal to watch is whether your privilege model still depends on shared credentials, delayed rotation or manual evidence collection. Those are all markers that the programme has not yet separated operator identity from client scope, which is where MSP risk compounds fastest.
Adopting session recording, automatic expiry and named technician identity changes the control from a trust-based model to an evidence-based one. That is the shift that matters when service-provider access crosses organisational boundaries.
For practitioners
- Enforce per-technician identity Stop using shared administrative credentials for client access and require each technician to authenticate as an individual before privilege is granted. See the IAM and IGA Basics.
- Move to task-scoped elevation Grant administrative rights only for a named task, then remove them automatically when the task ends or the approval window closes.
- Remove standing client access Audit technician accounts for persistent rights across client environments and eliminate any access that remains active without a current business reason.
- Record and review privileged sessions Require session recording for remote administration so every client-side action can be attributed to one operator and one task.
- Separate client scope from global reach Limit each technician session to the systems required for that engagement instead of allowing broad access to the full client estate.
Key takeaways
- MSP least privilege fails when technician access is reusable across many clients, because one compromised secret can cross organisational boundaries.
- Shared credentials, standing rights and delayed rotation are the main governance weaknesses exposed by the MSP operating model.
- The most effective control change is to tie every privileged action to a named technician, a defined task and an automatic expiry point.
Related NHI Mgmt Group resources: NHI Lifecycle Management Guide · Privileged Access Management Guide · AI Agent Authorisation Guide · Least Privilege Techniques Guide
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | MSP technician accounts are overprivileged when they can reach many client environments by default. |
| NHI-07 — Long-Lived Secrets | Shared admin passwords that persist across clients create the exact long-lived secret problem described here. | |
| NHI-10 — Human Use of NHI | MSP technicians relying on shared machine-style credentials is a human-use pattern that weakens accountability. | |
| Recommendation — Reduce standing technician access and scope elevation to the smallest client task possible. Eliminate long-lived shared credentials and replace them with short-lived, attributable access paths. Keep human operators on named identities and prevent people from borrowing reusable credentials. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Least privilege is the control principle at the centre of technician access and client-scope restriction. |
| Recommendation — Apply least privilege to technician accounts and remove rights that are not required for the active task. | ||
| CIS Controls v8 | CIS-5 — Account Management | The article focuses on how privileged account lifecycle and access reuse create MSP risk. |
| Recommendation — Manage technician accounts centrally and revoke client access immediately when it is no longer needed. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Shared credentials and broad technician reach enable credential-driven lateral movement across client estates. |
| Recommendation — Hunt for credential reuse and cross-tenant reach paths that let one account move between client environments. | ||
Key terms
- Just-in-Time (JIT) Access: Just-in-Time (JIT) Access grants permissions only when needed and removes them after use. In IAM and PAM, it reduces standing privilege by issuing time-bound access based on approval, context, or policy, limiting exposure for humans, service accounts, and non-human identities while improving auditability and control.
- Standing Privilege: Standing privilege is access that remains active even when no immediate task requires it. For NHI programmes, it is a common failure mode because long-lived credentials and persistent roles create unnecessary exposure. Reducing standing privilege usually means tighter expiry, on-demand access, and clearer review of who or what still needs access.
- Shared Credential: A shared credential is a single password, key, token, or certificate used by more than one person, system, or application. In identity security, it weakens accountability and access control because activity cannot be tied to one unique identity, complicating monitoring, rotation, revocation, and privileged access governance across human and non-human identities.
- Privileged Access Management: Privileged Access Management is the discipline of controlling who can use powerful accounts and what they can do with them. It governs administrator and service access through least privilege, approval workflows, session controls, credential rotation, and auditing, reducing the risk of misuse, lateral movement, and unauthorized changes across systems.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on November 4, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org