A local account is a user account whose identity, credentials and group memberships are stored and verified on a single computer, without relying on a network directory, a domain controller or an online identity provider. In desktop operating systems, it is the most basic form of user accounts: the machine itself decides who may sign in and what each user may do, and the account exists only on that device.
Local accounts are found in every major desktop system, including Windows, macOS and Linux distributions. They remain essential for offline use, recovery, privacy-focused setups and small environments, even where cloud-linked or domain accounts have become the default sign-in method.
How a local account is stored and verified
Every local account is a record in a local account database maintained by the operating system. The record holds a unique security identifier, a username, a password hash rather than the password itself, group memberships and a reference to the user’s profile or home directory. When the user signs in, the system hashes the entered secret and compares it with the stored value entirely on the device.
Each platform keeps this database in a different place, protected so that ordinary users cannot read it. The table below lists the main storage locations and identifiers.
| System | Account store | Identifier | Password data |
|---|---|---|---|
| Windows | Security Account Manager (SAM) database | Security identifier (SID) | NT hash in the SAM |
| macOS | Local Directory Service node | UID and generated UUID | Salted hash in the user record |
| Linux | /etc/passwd and /etc/shadow | Numeric user ID (UID) | Salted hash in /etc/shadow |
Because verification happens locally, a local account works without any network connection. The same property means that no central system knows about it: another computer, even on the same network, has no record of the account unless an identical one is created there separately.
Privilege levels of local accounts
A local account is not a privilege level by itself; it is a storage and authentication model. Any local account can be configured as an administrator account, a standard user account or a restricted guest-style account, and its rights come from the local groups it belongs to.
| Role | Group membership | Typical rights |
|---|---|---|
| Local administrator | Administrators, admin or sudo/wheel | Install software, change system settings, manage other accounts |
| Standard local user | Users or staff | Run programs, change own files and settings |
| Restricted local user | Limited or custom groups | Selected programs only, often under parental controls |
| Built-in system account | Service-specific | Runs background services, no interactive sign-in |
Good practice is to use a standard local account for daily work and keep a separate local administrator account for maintenance. Combined with elevation prompts such as User Account Control or sudo, this limits the damage that malware or a mistake can cause under the everyday account.
Local account compared with domain and online accounts
The main alternatives to a local account move identity off the device. A domain account is managed by a directory service such as Active Directory, and an online or cloud account is verified by an identity provider over the internet. The device then caches credentials so that sign-in still works offline for a limited time.
| Property | Local account | Domain account | Online account |
|---|---|---|---|
| Where identity lives | On the device only | Directory server | Cloud identity service |
| Works offline | Always | With cached credentials | With cached credentials |
| Central management | None | Group policy, central admin | Cloud device management |
| Password recovery | Local reset or recovery key | Help desk or admin | Online recovery flow |
| Settings synchronization | None by default | Roaming profiles optional | Built-in cloud sync |
| Single sign-on to services | No | Yes, within the domain | Yes, with the provider |
In short, a local account offers independence and privacy at the cost of manual administration. Domain and online accounts trade some independence for central control, synchronization and easier recovery.
When a local account is the right choice
A local account suits situations where central identity adds little value or introduces unwanted dependence. It is also the account type that remains available when everything else fails, which makes at least one well-protected local administrator account part of sound recovery planning.
| Situation | Recommended account | Reason |
|---|---|---|
| Personal offline or privacy-focused PC | Local account | No data tied to an online identity |
| Shared family computer | Separate local accounts | Clean profiles and individual permissions |
| Kiosk or lab machine | Restricted local account | Simple lockdown without directory services |
| Company laptop fleet | Domain or cloud account | Central policy and auditing are required |
| Break-glass recovery | Local administrator account | Works when the network or directory is down |
Recent versions of some systems steer users toward an online account during setup. A local account can usually still be created afterward in the account settings, although the exact path changes between releases.
Security risks and common mistakes
The independence of a local account also makes it easy to neglect. Nobody enforces password rules or rotation unless the owner configures them, and forgotten local accounts can remain enabled for years.
- Identical local administrator passwords across many machines allow an attacker who cracks one hash to move laterally; tools that randomize the password per device address this.
- Weak or empty passwords expose the device to anyone with physical access, especially without disk encryption.
- Lost credentials without a recovery method can lock the owner out; on encrypted disks the data may become unrecoverable.
- Orphaned accounts left behind by former users widen the attack surface and should be disabled or removed.
- Daily work under the administrator account gives every program full control over the system.
Pairing a local account with full-disk encryption, a strong passphrase and a safely stored recovery key closes most of these gaps without giving up offline independence.
Stripped to the essentials
A local account is like a key cut for one specific door. The computer itself keeps the list of who may enter and checks your password on its own, without asking any outside service.
That makes it simple and private: it works without internet and nothing is linked to an online profile. The trade-off is that you are responsible for it. If you forget the password and have no recovery option, nobody elsewhere can unlock it for you.
Where it is applied
A small architecture office has five desktop computers and no server. Each workstation gets two local accounts: a standard account for the designer who uses it every day, and a separate local administrator account with a long, unique password stored in the office password manager.
When a printer driver must be installed, the designer enters the administrator credentials at the elevation prompt instead of working as an administrator all day. One weekend the internet connection fails, yet everyone signs in normally on Monday because verification never depended on the network. Disk encryption with recovery keys printed and stored in the office safe ensures that a stolen laptop reveals no client drawings.