To identify local administrator accounts, list the members of the local Administrators group on every Windows endpoint, not just the people you know you gave admin rights to. That group collects accounts from several places: the built-in Administrator, users added during setup, groups from Active Directory or Microsoft Entra ID, and entries left behind only as a security identifier (SID). Each member holds standing local admin, a right that works every day with no request and no time limit.
That is also why so many of these accounts go unnoticed. When elevation is granted on demand, the elevation log records each grant. Accounts that are already admins have no reason to request elevation, so they never show up in that log.
Why Local Administrator Accounts Go Unnoticed
Many standing admin rights are not handed out deliberately. They arrive with the way a device is set up and stay because nobody checks again.
- Defaults at setup. When a Windows device is joined to Microsoft Entra ID, the user who performs the join is added to the local Administrators group by default, together with two Entra roles, according to Microsoft. Microsoft notes that this happens only during the join, so later changes have to be made on the device itself. A laptop that its user set up keeps that user as an admin until someone removes it.
- Leftovers. An account added for one installation, a vendor visit or a support session rarely gets removed when the task is done.
- Unresolved entries. When an account or group is deleted, or comes from a directory the device cannot look up, the group can keep the entry as a bare SID. Nobody recognizes it, so nobody removes it.
The group does not show everything either. Microsoft states that users who hold the Entra role Microsoft Entra Joined Device Local Administrator are not listed in the group by name: their rights come with their sign-in token. The group tells you who is a member, not every account that can act as an admin.
How to Check Local Administrators With PowerShell
On a single device, one command lists the members of the group:
Get-LocalGroupMember -SID "S-1-5-32-544" |
Select-Object Name, SID, PrincipalSource, ObjectClassThe command uses the group’s well-known SID, S-1-5-32-544, instead of its name. On Windows in other languages, the group has a local name, such as Administratorer in Norwegian or Administrateurs in French, but the SID is the same everywhere.
The four columns answer four questions:
- Name: which account or group is a member. An entry the device cannot resolve may show only its SID here.
- SID: the security identifier. The built-in Administrator account is the one whose SID ends in -500.
- PrincipalSource: where the member comes from. Microsoft’s cmdlet reference lists Local, Active Directory, Microsoft Entra group and Microsoft Account. On an Entra-joined device, Entra members show as AzureAD.
- ObjectClass: whether the member is a user or a group. Entries the device cannot resolve can show as Other. A group needs a second look, because everyone in it is an admin too.
Read the result against a simple question: did someone decide that this member belongs here? A local account named after a person, or a user account from setup, usually did not.
One practical catch from the same reference: the module that provides the command is not available in 32-bit PowerShell on a 64-bit system, so the command fails in a script that a 32-bit tool launches. The older net localgroup Administrators command can leave out Entra members entirely, so it is not a reliable check on Entra-joined devices.
How to Identify Local Administrator Accounts Across Many Devices
To cover more than one device, run the same command remotely with Invoke-Command and collect the output in one file:
Invoke-Command -ComputerName PC01, PC02 -ScriptBlock {
Get-LocalGroupMember -SID "S-1-5-32-544"
} | Select-Object PSComputerName, Name, PrincipalSource |
Export-Csv -Path .\local-admins.csv -NoTypeInformationIt works, but it comes with three limits: it needs PowerShell remoting on every endpoint, devices that are offline when it runs are missing, and you only see the state on the day it ran. Someone also has to own the script and run it again next quarter.
If your organization uses Microsoft Intune, its Local user group membership profile can add, remove or replace members of the Administrators group on Windows devices. That is policy: it describes how the group should look. Checking what the group actually contains on each device is a separate question, and it is the one an inventory answers.
Approved, Not Approved, Unresolved: What to Look For
Reading the list is quick once you sort every member into one of three groups.
- Approved. Accounts and groups you have decided belong there, such as a managed built-in Administrator or a dedicated support group. Write the list down. Without it, every review starts from opinion.
- Not approved. Named accounts that are not on the list, typically users who got admin rights at setup or for one task. These are the accounts to remove first.
- Unresolved. Entries with a SID and no name. An unresolved SID may point to a deleted account, a directory identity the device cannot look up, or one of the Entra roles added at join, which belong there. Verify where each entry comes from before you remove it, and treat any that nobody can explain as a finding.
Repeat the review on a schedule, not only before an audit. New devices bring new defaults, and a list that was clean in spring can drift by fall.
How CapaOne Shows Local Administrators Across Windows Endpoints
In the CapaOne Endpoint Management Platform, Security Monitor holds the local administrators of every managed Windows endpoint up against a list you approve. The agent reports the group as part of the endpoint’s security inventory, so the view reflects what each endpoint last reported, without a script to run. The Local Administrators view shows how many endpoints are compliant, how many admins are not approved and how many entries are orphaned, the product’s term for unresolved SIDs. A list of endpoints gives the same counts per device, and opening an endpoint shows each account with its type, name and source.
An AI assistant can reach the same data through the CapaOne MCP Server. The server is in beta and answers questions from live CapaOne data, local administrators included, device by device. As with the console, security data like this requires Security Monitor.
From Finding to Removing Standing Local Admin
Finding the accounts is half the job. Removing them only lasts if users can still do the tasks that made someone grant admin rights in the first place, or the rights come back within a week.
Privilege Manager, part of the same platform, covers that half. It lets a policy decide which application or task gets admin rights, and for how long, and it records each elevation. Our endpoint privilege management page explains how to take standing admin away without stopping people’s work, the post on why to remove local admin rights shows what it means for attacks that switch off security tools, and the fields an auditor expects in an elevation log cover the evidence side.
The two products answer different questions. Security Monitor shows who holds admin rights today. Privilege Manager shows who used elevated rights, when, and for what. Together they cover both the standing rights and the temporary ones.
To stop new standing admins from appearing, change the default at setup. Microsoft’s guidance on Entra join describes how the device registration policy, or a Windows Autopilot profile, can prevent the user who joins a device from becoming a local administrator.