Skip to main content
Identity Authority
Category: Privileged Access

Local Admin

Also known as: Local Administrator, Local Administrator Account, Local Admin Account
Simply put

A Local Admin is an account that has full control over a single computer, letting it install software, change settings, and manage other accounts on that machine. Unlike a domain account managed centrally, a local account exists only on the specific computer where it was created. This power is limited to that one machine and does not extend to other systems on the network.

Formal definition

A Local Admin (local administrator) is a user account that is a member of the local Administrators group on an individual Windows host, granting full administrative authority over that machine's operating system, local resources, and other local accounts. Because every computer acts as its own security authority, a local account and its privileges are scoped to that host and, in most deployments, do not confer rights on other machines or domain resources. On a domain controller, the conventional local Administrator context is effectively replaced by domain-level administration, so members of Domain Admins hold the equivalent authority; on domain-joined workstations, local admin membership is distinct from domain group membership and should be evaluated separately. Note that this evidence addresses the Windows account model specifically; equivalent local privileged accounts on other operating systems are out of scope here.

Why it matters

Local Admin accounts represent a persistent and often under-governed source of privileged access. Because every Windows computer acts as its own security authority, each machine can carry local administrator accounts whose privileges are scoped to that host but are nonetheless complete over that host's operating system, local resources, and other local accounts. In large environments, the sheer number of these accounts, one or more per endpoint, creates an administrative surface that is easy to lose track of and difficult to certify consistently.

The risk is compounded when local administrator credentials are shared or reused across multiple machines. If the same local admin password is set identically on many hosts, an attacker who compromises one machine can potentially reuse that credential to move laterally to others, even though each account is technically local to its own host. This dynamic is a well-understood driver behind the practice of randomizing and rotating local administrator passwords per machine. Note that this evidence addresses the Windows account model specifically; the digest does not provide named incident data, and no specific breach figures should be inferred here.

Because local admin membership on a domain-joined workstation is distinct from domain group membership, the two must be evaluated separately during access reviews and audits. Treating a local admin account as equivalent to a centrally managed domain account can leave gaps in governance, accounts that exist only on the endpoint and may never surface in directory-centric reviews if they are not deliberately included in scope.

Who it's relevant to

System Administrators
Administrators create, configure, and maintain local admin accounts on individual Windows hosts to perform machine-level tasks such as software installation and settings changes. They need to understand that these accounts are scoped to a single machine and are managed separately from centrally administered domain accounts.
Security Architects
Architects must account for local administrator accounts as a distinct privileged surface, since every computer is its own security authority. Design decisions around credential uniqueness per host and separation of local versus domain privilege paths directly affect the lateral-movement risk of these accounts.
Identity Governance Leads
Because local admin membership on domain-joined workstations is distinct from domain group membership, governance leads should ensure both are evaluated separately within access reviews and certification. Directory-centric reviews may otherwise omit machine-local accounts entirely.
Compliance Officers and Auditors
Auditors reviewing privileged access should distinguish the machine-scoped authority of a local admin from the broader authority of Domain Admins, particularly on domain controllers where the local context is effectively replaced by domain-level administration. Confirming that local accounts are in scope for review is essential to a complete privileged-access picture.

Inside Local Admin

Local Account Scope
A local administrator account exists and is authenticated against a single host or endpoint rather than a central directory, meaning its credentials and privileges are recognized only on that specific machine. This is distinct from domain or directory-based administrative accounts that authenticate against systems such as an LDAP directory.
Elevated Authorization
Local admin rights grant broad authorization on the host, typically including software installation, configuration changes, service management, and access to protected system resources. This is an authorization concern (what the principal may do on the machine) and is separate from the authentication step that verifies who the account holder is.
Built-in Administrator Principal
Most operating systems ship with a default built-in local administrator principal. Depending on configuration, this account may be enabled, disabled, or renamed, and its exact behavior varies by operating system and version.
Local Group Membership
Membership in a local administrators group typically conveys administrative privileges on the host. This resembles a role-based (RBAC) grouping at the machine level, where membership in the group determines the privileges available.
Credential Storage on Host
Local admin credentials are generally stored and validated on the endpoint itself rather than by a central authority. In most deployments this makes each host an independent authentication boundary for its local accounts.

Common questions

Answers to the questions practitioners most commonly ask about Local Admin.

Is having local admin rights the same as being authenticated to a system?
No. Authentication verifies who a principal is, while local admin rights are an authorization concern that determines what an already-authenticated principal may do on a specific host. A user can authenticate successfully to a machine and hold only standard-user privileges, or authenticate and hold local admin privileges. The two steps are distinct: identification and authentication establish the identity, and the local admin grant is a separate authorization decision layered on top of that identity.
Does local admin on one machine grant administrative control across the domain or other systems?
Not inherently. Local admin is scoped to the individual host where the privilege is assigned; it does not by itself confer domain-wide or cross-system authority. In practice, however, local admin on a machine can sometimes be leveraged toward broader compromise depending on configuration, such as when cached credentials, shared local account passwords, or trust relationships exist. The privilege itself remains local, but its practical blast radius depends on the surrounding environment and how accounts and credentials are managed.
How should local admin accounts be managed to reduce standing privilege?
A common approach is to avoid persistent, always-on local admin membership and instead grant elevation only when needed. Depending on the deployment, this is often handled through just-in-time elevation, time-bound assignments, or privileged access management workflows that provision and later remove the privilege. Randomizing and rotating local administrator account passwords per host is also typical to prevent a single shared credential from being reused across machines. These are administration and lifecycle controls rather than runtime enforcement mechanisms.
How do access reviews and certification apply to local admin entitlements?
Local admin membership is an entitlement that typically falls within identity governance and administration scope, so it can be included in periodic access reviews and certification campaigns. Reviewers confirm whether each principal still requires the privilege, and unneeded grants are revoked. Correlating local admin assignments with segregation-of-duties policies may also be relevant where holding both administrative and other conflicting privileges is a concern. This is distinct from runtime enforcement of what the account can do once elevated.
What is the relationship between local admin accounts and privileged session monitoring?
Because local admin represents elevated privilege, sessions performed under such accounts are often subject to additional monitoring, logging, or session recording depending on the deployment and applicable requirements. This helps produce an audit trail of privileged activity for later review. The monitoring controls are typically separate from the mechanism that grants the privilege, and their coverage varies by tooling and configuration.
How can local admin usage be logged and attributed to a specific individual?
Attribution generally depends on how the local admin privilege is consumed. Where shared local administrator accounts are used, attributing actions to a specific individual can be difficult, which is one reason many deployments favor named accounts elevated on demand or brokered access through a privileged access workflow that records who requested elevation. Combining host-level audit logs with the elevation or checkout records is a common way to tie privileged actions back to an individual, though the completeness of this trail depends on configuration.

Common misconceptions

A local administrator account is the same as a domain or directory administrator account.
They differ in scope. A local admin is recognized and authenticated only on a single host, while a directory or domain administrator authenticates against a central directory and may hold privileges across many systems. Confusing the two overstates the reach of a local account.
Having local admin means the user has been more strongly authenticated.
Local admin is an authorization state describing what the account may do on the host, not a statement about how strongly the account holder was authenticated. Identification, authentication, and authorization remain separate steps; broad privileges do not imply multi-factor or otherwise stronger authentication.
Managing local admin accounts is purely a runtime enforcement task.
Local admin management spans both governance concerns (such as provisioning, periodic access reviews, and certification of who holds local admin) and runtime concerns (such as validating credentials at logon). Treating it only as runtime enforcement neglects the lifecycle governance side.

Best practices

Minimize standing local admin rights by granting them only where required and, where possible, providing elevation on demand rather than persistent membership.
Include local admin group membership in regular access reviews and certification cycles so that holders of elevated host privileges are periodically validated.
Disable, rename, or otherwise restrict default built-in administrator accounts according to your operating system and configuration guidance, and verify the actual behavior on each platform.
Treat each host's local admin credentials as an independent authentication boundary and avoid reusing the same local admin password across multiple endpoints.
Separate the authorization decision (who should hold local admin) from the authentication controls protecting those accounts, and apply stronger authentication where the configuration supports it.
Document and monitor local admin provisioning and deprovisioning so that lifecycle changes are captured rather than left only to runtime enforcement.
Promotional banner for the Pentest Readiness checklist download