Local admin rights are where small mistakes become big incidents. One stale help desk account or old installer can hand an attacker broad control over a device.

A solid local admin rights audit shows who can elevate, why they can, and when that access should end. It also helps Windows and macOS teams keep least-privilege policies honest.

If your current list lives in a spreadsheet from last quarter, it’s already behind. Start with live membership data, then compare it to a clear allowlist.

Start with a complete inventory, not a partial one

A useful audit starts with every path that can grant admin power. On Windows, that means the local Administrators group, nested domain groups, managed service accounts, support accounts, and the built-in Administrator account. On macOS, it means the admin group, local repair accounts, and any MDM-created admin user.

A quick side-by-side view helps expose gaps fast.

Platform	Quick check	What to flag
Windows	Get-LocalGroupMember -Group "Administrators"	Nested groups, unknown users, stale vendor accounts
macOS	dscl . -read /Groups/admin GroupMembership	Shared admin users, old repair accounts, unmanaged additions
Both	Export from MDM or RMM	Devices that do not report or exceptions without an owner

If a group expands into more groups, expand it again. Hidden membership is where many audits fail. For fleet-wide governance, governing local admin rights at scale gives you a good structure for the allowlist and exception process.

On Windows, don’t stop at the built-in Administrator account. A domain group can sit inside the local Administrators group and quietly grant access to hundreds of endpoints. On macOS, check both direct admin users and the management account your MDM created.

Use a repeatable audit flow across Windows and macOS

A good audit flow works the same way every time. First, pull device inventory from Intune, Jamf, or your RMM. You cannot audit what you cannot count.

Next, run the membership check. On Windows, Get-LocalGroupMember -Group "Administrators" | Select Name, ObjectClass gives a clean first pass. On macOS, dseditgroup -o checkmember -m "username" admin or a dscl script gives you the same answer.

Then compare each result with the approved list. Mark the owner, ticket number, and expiry date for every exception. That step matters more than the raw list.

Finally, flag anything new, expired, or unowned. That includes help desk accounts, temporary vendor access, and service accounts that show up in the admin group after a software install. If a user only needs elevation for one task, Endpoint Privilege Management is a better fit than permanent admin rights.

For macOS fleets, a script like List Local Admin Users shows how dscl output can feed MDM custom attributes. That makes fleet-wide reporting much easier than checking each device by hand.

Watch for signs of unauthorized privilege escalation, too. On Windows, group-change events, new local users, and sudden drift after support tooling runs are common clues. On macOS, MDM audit logs and regular snapshots catch the same pattern.

A report without an owner and an expiry date is only a screenshot.

Turn audit results into reports people will read

Recurring reports matter because privilege drift happens fast. A device can pass on Monday and fail by Friday. Your report should show the endpoint, current admins, source of the grant, owner, expiration, and last-seen time.

That data helps security, IT, and compliance teams speak the same language. It also maps cleanly to least-privilege controls in NIST 800-53 AC-6 and CIS Control 6. During SOC 2 or ISO 27001 reviews, auditors want proof that exceptions are tracked and removed.

For reporting, think in layers. MDM gives device state, RMM gives reach, PAM or EPM gives elevation context, and SIEM gives trend and alerting. CSV works for a smaller estate. JSON or API feeds work better when you need dashboards and historical comparisons.

If you need a model for Windows collection at scale, how to get local admins from all AD computers is a solid PowerShell reference. Use that pattern to schedule weekly drift checks and monthly review packs.

Fix service accounts and break-glass access without creating new risk

Service accounts should not sit in local Administrators unless the workload truly needs it. On Windows, prefer gMSA where possible, because it reduces password handling on endpoints. On macOS, keep support or install accounts tied to a managed process, not daily use.

Break-glass accounts need tighter control. Store them in a vault, log every use, rotate passwords, and test them on a schedule. Give each one a named owner and an expiry date. If nobody can explain why the account exists, it should not stay privileged.

A short remediation checklist keeps the work moving:

• Remove users who no longer need admin rights.
• Replace shared local admins with named accounts.
• Move service accounts to least privilege or gMSA.
• Review break-glass access after every use.
• Re-run the audit after remediation.

The goal is zero standing privilege wherever you can reach it. If your team needs help building the process around that model, Book a Discovery Call with Bud Consulting.

A strong local admin rights audit is less about finding one bad account and more about building a repeatable habit. When you track approved access, temporary exceptions, and drift on a schedule, the admin list stops being a surprise.

That habit protects Windows and macOS endpoints, supports compliance reviews, and gives your team a real path to least privilege.