What zero standing privilege means, why it matters more for MSPs, and the eight phases that get you there.
An attacker who steals a technician's password gets everything that account can already do. If it's Global Administrator in every client tenant, there's nothing left to break into, and every one of those clients is exposed at once. That always-on access is called standing privilege, and it builds up quietly as clients, projects and technicians come and go.
Zero standing privilege removes it. Admin rights exist only while someone is doing an approved task, and they're taken away when the work is done. A stolen password then opens very little.
Three terms get mixed up here:
MITRE ATT&CK tracks the use of stolen or misused credentials as T1078, Valid Accounts, and lists privileged account management (M1026) as a core mitigation, including JIT tools that grant time-limited elevated permissions.
The groups doing the most damage go straight for admins. Microsoft's research on Octo Tempest (also tracked as Scattered Spider) describes it targeting "technical administrators, such as support and help desk personnel." On 31 August 2023, Okta warned that attackers were calling IT service desks to get every MFA factor reset on accounts with Super Administrator permissions.
For an MSP the effect multiplies. One technician account with standing rights across 40 client tenants is 40 environments behind one password. Clients, auditors and cyber insurers ask how admin access is granted, approved and logged because of it.
None of them uses the phrase "zero standing privilege." All of them describe it.
The phases run in order because each depends on the one before. You can't vault what you haven't found, and JIT only works once the standing rights it replaces have been cleaned up.
The goal: a complete, current inventory of every privileged account, human and non-human, in every environment you manage.
Look in Active Directory (Domain Admins, Enterprise Admins, nested groups), Entra ID roles, Microsoft 365 admin roles, Google Workspace admins, and local administrator groups on every Windows machine. Include service accounts, scheduled-task accounts and break-glass accounts. At an MSP, do it per tenant: the drift is different at every client.
Where teams stall: a one-off audit that is out of date a month later. Discovery has to repeat.
How Panthera handles it: it continuously finds every privileged identity, per tenant, from admin accounts to end users with hidden admin rights, service accounts, AI agents, and break-glass accounts.
The goal: remove what shouldn't exist before protecting what should.
Disable stale and orphaned accounts, including former technicians and ex-employees. Take admin rights off accounts that don't need them. Split admin work from daily work, as the CIS Controls require (Safeguard 5.4): a separate admin account, not the same account that reads email and browses the web.
Where teams stall: fear of breaking something. Remediation is where you find the service account nobody documented. Do it in batches, per client, with a rollback note.
How Panthera handles it: remediation of what discovery surfaces, including stale domain admins and over-privileged accounts, from the same console or the Prompt Terminalâ„¢. It can take an account out of a privileged group, disable it at the source rather than delete it, or delete it when it's no longer needed.
The goal: credentials that must exist, such as service accounts, break-glass accounts and shared admin logins, live in a vault, not in a spreadsheet, a documentation tool or a technician's browser.
A vault is only useful if access to it is controlled and logged. Restricting each credential to the technicians who need it, and logging every access, is better than a shared folder of passwords with a nicer interface.
Where teams stall: moving passwords out of IT Glue or Hudu and then leaving the old copies there.
How Panthera handles it: a zero-knowledge vault that restricts each credential to authorized technicians, logs who accessed it, and rotates it on a schedule or on demand. CyberQP can't see what is stored in it, and that holds through credential rotation.
The goal: a leaked privileged password stops working quickly.
A note on NIST: its current password guidance, published in July 2025, says verifiers "SHALL NOT require subscribers to change passwords periodically," but must force a change when there is evidence of compromise. That guidance is about people's own passwords. Shared and privileged credentials are different: many people have touched them, and you often can't prove they haven't leaked. Rotate them on a schedule and on demand, for example when a technician leaves, automatically, including everywhere the credential is used (Windows services, scheduled tasks).
Windows LAPS rotates a local administrator account's password on each device, backed up to Active Directory or Entra ID. It is a good start for local admin, and it doesn't cover domain service accounts or your technicians' access across tenants.
How Panthera handles it: zero-knowledge rotation of vaulted credentials on a schedule or on demand, across local admin, Active Directory, Entra ID, Microsoft 365 and Google Workspace, without the secret leaving the vault. A technician can also run rotation from the Prompt Terminal by describing the job in plain language.
The goal: every privileged sign-in needs a strong second factor, and admin accounts can't fall back to weak ones.
Microsoft's July 2025 guidance on Octo Tempest says to require phishing-resistant MFA for administrators. Mandiant's hardening guidance for the same group adds that administrative users shouldn't be able to register or use legacy MFA methods such as SMS, even where regular users still can.
Insurers check this too. In Travelers v. International Control Services (2022), the insurer asked a federal court to void a cyber policy after a May 2022 ransomware attack, alleging that the MFA the company attested to on its application wasn't in place. The parties agreed to rescind the policy, and the court dismissed the case in August 2022.
How Panthera handles it: technicians sign in to Panthera with SSO, MFA or a passkey, and remediation can reset a privileged identity's MFA or revoke its sessions. Help desk identity verification, which checks an end user before a password or MFA reset, is coming to Panthera.
The goal: nobody holds admin rights until they need them.
Technicians work from normal accounts and request elevation for a task. Routine requests can be pre-approved by rule, and sensitive ones need a second person. Each grant has a time limit and a reason.
In Microsoft-only environments, Entra Privileged Identity Management does this for Entra roles: an "eligible" assignment has to be activated, with optional approval and MFA, while an "active" assignment is standing privilege. PIM needs Entra ID P2 or ID Governance licensing and covers Entra, Azure and Microsoft 365 roles. For technicians working in client tenants, Microsoft supports PIM for Groups on granular delegated admin privileges (GDAP) security groups in the partner's own tenant, which gives JIT for delegated Entra roles. None of it covers on-premises AD groups or local admin on endpoints, which is where the rest of an MSP's standing privilege sits. The JIT admin access guide covers each native option and where it stops.
How Panthera handles it: each technician gets dedicated JIT accounts that are disabled by default, enabled for a task, can require a secondary approval, and are revoked automatically when the task ends. Each activation can be tied to a ConnectWise PSA ticket; Autotask and HaloPSA are coming to Panthera. JIT covers Active Directory, Entra ID and Microsoft 365, including Microsoft GCC tenants.
The goal: for every privileged action, you can say who, what, when, why and who approved it.
This is the phase that turns the first six into evidence. An auditor's question ("who had admin on that server last Tuesday?") should have an answer that takes a query, not a week. Alerts should fire on privileged changes made outside the process, because that is what an intruder looks like.
How Panthera handles it: auditing and logging of privileged account use, with alerts on privileged account changes, password rotations and account lockouts. You get the privileged-access evidence auditors ask for, generated on demand: not a GRC platform, a PAM system that proves its own controls.
The goal: end users aren't local admins, and they can still install the software they need.
A user who is a local admin gives any malware they run the same rights on that machine. The objection is always ticket volume. The answer is time-boxed elevation for a specific application, approved by policy for trusted software and by a technician for everything else.
How Panthera handles it: elevation for a specific application on Windows, approved by a technician or by rule, with risk scoring and application blocking included.
Most MSPs have done parts of this for some clients. The useful question is: which of the eight phases have you finished across your whole client base, and where did you stop? That stall point is where to start again. The usual ones:
Every "no" to 1, 2, 4 and 7, or "yes" to 3, 5, 6 and 8, marks a phase to finish.
A security model where no account holds privileged access by default. Rights are granted just in time for a task, approved and logged, then removed.
Discover and assess; remediation of privileged access; zero-knowledge credential vault; zero-knowledge credential rotation; MFA and secure access enforcement; just-in-time access and zero standing privilege; auditing, monitoring and alerting; and endpoint privilege management. Zero standing privilege is the result of completing all eight.
No. Least privilege limits what an account can do. Zero standing privilege also limits when: even correctly scoped admin rights exist only while they are being used.
Not on its own. For Entra, Azure and Microsoft 365 roles it largely can, with P2 or ID Governance licensing, and with GDAP it can also cover delegated roles in client tenants through PIM for Groups in your own partner tenant. It doesn't cover on-premises Active Directory groups, local admin on endpoints or service account rotation, which is where a lot of MSP standing privilege lives.
Not for privileged accounts. NIST's current password guidance says not to force periodic changes to individual users' own passwords. Shared and privileged credentials are a different case, and rotating them after use and on compromise is standard practice.
With discovery, per client tenant. You can't protect accounts you haven't found.
Sources: MITRE ATT&CK T1078 and M1026; NIST SP 800-207; CIS Controls v8.1; CISA advisory AA23-320A, Scattered Spider (16 Nov 2023); Microsoft, Octo Tempest (2023) and (2025); Mandiant UNC3944 hardening guidance; Okta, cross-tenant impersonation (31 Aug 2023); Travelers v. International Control Services, C.D. Ill. No. 2:22-cv-02145 (docket); NIST SP 800-63B-4 (July 2025); Microsoft Entra PIM; Microsoft Learn, GDAP FAQ; Windows LAPS.
Related: just-in-time admin access for MSP technicians, help desk social engineering, MFA fatigue and MFA reset attacks, webinar series: Reaching Zero Standing Privilege, just-in-time privileged access, Panthera free trial, book a demo.