Skip to main content

Local Admin Accounts Need an Operating Model, Not Just a Password Vault

Nick Ross6 min read

TL;DR

  • Local admin governance is more than password storage: it covers dedicated accounts, 15+ character complexity, 30-day rotation, encryption, just-in-time access, and audit logging.
  • Most local admin activity reduces to two moments, troubleshooting and application installs, so any solution must be operationally workable in both.
  • Windows LAPS passwords are encrypted with AES256 at rest in the cloud and protected over HTTPS in transit, a long way from the plain-text attribute storage of legacy Active Directory.
  • As of August 2024, Intune EPM at $3 and Remote Help at $3.50 per endpoint per month make the Microsoft-native stack roughly 33% more expensive than comparable MSP-friendly third-party tools.
  • GDAP plus PIM-enabled groups can give technicians just-in-time access to local admin passwords in Intune instead of standing access.

Ask an MSP how they manage local admin passwords and you usually get a storage location: the RMM, IT Glue, a password manager. That answers the wrong question. Storage is one line item in a governance model that also has to cover who gets an account, how strong and how fresh the password is, who can elevate and when, and what evidence exists afterward. Mismanage any of those and a single compromised endpoint can become a much bigger incident.

This post lays out the whole operating model: the failure patterns, the standards worth enforcing, the workflows the standards have to survive, and the honest pros and cons of Microsoft's first-party stack versus the third-party tools most MSPs run today, as of August 2024.

Where local admin programs actually fail

Three patterns account for most of the risk we see:

Password reuse across devices. If one device is compromised, every device sharing that password is compromised with it. The blast radius of a single breach multiplies for free. Most of the industry has moved past this, but it still turns up in real environments.

Insecure storage and access. Where do those passwords live today, and who can read them? In most cases, the storage platform itself is not the weak point; the missing ACLs around technician access are. If every tech can read every local admin password, the vault is a formality.

Weak passwords and no rotation. How complex are the passwords, and how often do they rotate, if at all? Rotation is the biggest gap in most shops, because without automation it is unfeasible by hand.

The six standards worth enforcing

Dedicated admin accounts. Confirm that end users across customers do not hold local admin rights, and that each device carries a dedicated, documented admin account with proper audit logging tied to it, so there is something to investigate when a breach happens.

Complex passwords, 15 characters minimum. Weak passwords fall to brute force, so complexity and length should be non-negotiable. In Windows, the password complexity setting "Large letters + small letters + numbers + special characters (improved readability)" is generally available, and it fixes the old pain of unreadable generated passwords. (You know this pain if you have been there.) We cover the Intune policy settings later in this post.

Rotation at least every 30 days. Unfeasible manually, easy with the first-party and third-party solutions below, which can also rotate a password automatically after each use.

Encryption at rest and in transit. Legacy Active Directory stored these passwords as a plain-text attribute on records. Today they can be encrypted at rest and are natively encrypted in Microsoft Entra: Windows LAPS passwords are always protected in transit over HTTPS when sent from the managed device to the cloud, and passwords stored in the cloud are always encrypted with AES256.

Just-in-time (JIT) access. Grant admin privileges only when needed and revoke them immediately after the task completes, minimizing the window during which credentials are live. Generally speaking, this has only been achievable through third-party solutions.

Audit logging. Capture who accessed which resources and when, so unauthorized activity gets detected and answered promptly. This remains a common industry gap.

Design around the two moments admin rights get used

Assuming all users run as standard accounts, the highest-volume elevation activity reduces to two buckets:

  • Troubleshooting and break-fix
  • Application installs and program changes

This matters because the most secure solution on paper fails if your team cannot operationalize it in those two moments. Evaluate every option below against both the security bar and the daily workflow.

Prevention first, then a plan for the exceptions

Our standard across customers leans preventative rather than betting on being excellent at reacting. For the question of why anyone needs elevated privileges on a device in the first place:

Zero-trust mentality. Every access request gets authenticated, authorized, and encrypted. Any process, application, or system changing a device earns trust rather than holding it by default.

Controlled folder access. Protects sensitive directories from unauthorized modification and ransomware. Available through attack surface reduction rules in Business Premium.

Application whitelisting and ringfencing. The common industry control for limiting which applications can be installed or can make changes to a device.

Process manipulation blocklists and allowlists. Same principle, applied at the process level.

And the recurring question: is EDR enough? In a defense-in-depth model, no. An EDR tool like SentinelOne or Defender for Business may well detect a malicious file or process after it is already in motion. We would much rather have controls preventing that initial attack altogether.

Prevention never reaches 100%, though. It is impossible to whitelist and pre-approve every process and app that needs elevation, and locked-down devices create real friction when users cannot install what their job requires. Troubleshooting needs elevation too. So written process definitions for two workflows are mandatory:

  • Elevation control management
  • Remote access management

The Microsoft-native stack

Microsoft's first-party options for local admin account management and the workflows around them:

  • LAPS (opens in new tab): Windows Local Admin Password Solution, built into Entra and Intune, supporting both cloud-native and hybrid environments. Passwords are managed centrally in Intune, with policy-driven rotation on a schedule and after each use.
  • Intune EPM (opens in new tab): Endpoint Privilege Management, a newer paid add-on providing just-in-time elevation so users can take temporary privileges for tasks like app installs.
  • Intune Remote Help (opens in new tab): Intune's native remote access solution for technicians.
  • GDAP/PIM: using GDAP and PIM in your partner account, you can build limited, just-in-time access for technicians retrieving local admin passwords from Intune. Pair the Cloud Device Administrator or Intune Service Administrator role with a PIM-enabled group, and techs elevate into password access only when needed instead of holding it the other 99% of the time.

Our recommended LAPS policy settings:

Recommended Windows LAPS policy settings in Intune

Pros:

  • All native. No agents, no extension of third-party risk.

Cons:

  • Not multi-tenant capable.
  • Not tied into MSP tools like ticketing, which is a huge deal to operationalize.
  • GDAP/PIM may carry too much operational burden compared to keeping passwords in a documentation tool (though we consider that option less secure).
  • Cost. See Intune add-on pricing (opens in new tab). LAPS itself is free, but EPM ($3 per endpoint per month) plus Remote Help ($3.50 per endpoint per month) lands at least 33% above what most MSPs pay for friendlier third-party equivalents.
  • Maturity. EPM and Remote Help have only been out about a year as of August 2024, and like all Microsoft products, it takes time to trust there are no glaring gaps in consistent performance.
Comparison of first-party and third-party local admin management options

The third-party stack

For years the default was RMM plus PowerShell. Lately, several vendors target this exact problem with a much better experience. The ones we see most:

Pros (not exhaustive, but the ones that matter):

  • Multi-tenant capable
  • Extend to server and database password management, which no central first-party solution like Intune covers today
  • Integration with PSA ticketing and documentation tools
  • Heightened capabilities like JIT built in
  • Managed response offerings: some vendors will handle inbound elevation requests for you, offloading that support burden (for a fee, of course)

Cons:

  • Another agent on every device, the biggest downside in our view, and another increment of third-party risk
  • Some core features duplicate what LAPS does for free, which matters when you think about total cost of ownership

The verdict

Local admin governance is a pillar of any serious security stack, and the tooling to do it well exists on both sides of the first-party line. But until Microsoft makes the native stack cost-effective and MSP-operable, we expect most MSPs to keep choosing third party. Pick the tool after you have defined the standards and the elevation workflows, not before.

Frequently asked questions

Is an EDR tool enough to cover risky local admin usage?

No. An EDR like SentinelOne or Defender for Business can detect a malicious file or process after it is already in motion, but defense in depth means preventing the initial attack altogether with controls like application whitelisting and controlled folder access.

What is wrong with storing local admin passwords in a documentation tool?

Usually the access controls, not the storage itself. The platform may be secure, but if every technician can read every password with no ACLs, no rotation, and no audit trail of who accessed what, the governance has already failed.

Why do most MSPs still pick third-party tools over the Microsoft-native stack?

Operations and cost. Third-party tools are multi-tenant, integrate with PSA and documentation platforms, extend to server and database passwords, and build in JIT elevation. The Microsoft stack is native and agentless, but it is single-tenant, disconnected from MSP tooling, and roughly a third more expensive once EPM and Remote Help are added.

Which tenants would pass a local admin audit today?

CloudCapsule checks privileged access protections alongside 250+ Microsoft 365 controls per tenant in about 60 seconds, then keeps watching for the drift that quietly reopens old gaps.

Run a free scan
Nick Ross

Written by

Nick Ross

CEO · Microsoft MVP · Founder, T-Minus 365

Nick is not just a CEO, he's a respected thought leader and influencer in the MSP space. Tens of thousands of MSPs learn through his YouTube channel, T-Minus365. Nick has been honored as a three-time Microsoft MVP for his educational content; his expertise and influence are the backbone of our mission, ensuring that you are in the best hands when it comes to security.

Nick joined Pax8 in 2017, where he would ultimately oversee product management for PSA and Microsoft integrations. Following his tenure at Pax8, Nick has continued to demonstrate his leadership prowess as an executive at various MSPs, culminating in his most recent role at Sourcepass.

Nick holds a Bachelor's Degree in Business Management from Florida State University, as well as a Minor Degree in Entrepreneurship. In his free time, Nick is an avid hiker, reader, and fitness-junkie.

Keep reading