In this article, we'll explore how local accounts work in Windows, the different types available, how to create accounts for everyday use, how to strengthen their security , and the advanced options available if you manage multiple computers (classroom, lab, office, etc.). Everything is explained in clear language, with practical tips and best practices that you can apply to a single PC or an environment with dozens of machines.
What exactly is a local user account in Windows?
A local user account is an identity that is created and stored directly on a specific computer. It only exists on that device and can only receive permissions and rights on that same computer , not on the network in general (unlike domain accounts or Microsoft accounts synchronized in the cloud).
These accounts are used to control who can access the computer and which specific resources : files and folders , printers, services, administrative tasks, etc. Each account has a set of user rights (actions it can perform on the system) and permissions (what it can do on each object, such as read, write, modify, or delete).
Local accounts, both built-in and those you create yourself, are managed from the Local Users and Groups console (Computer Management MMC) on systems that include it, or from the Accounts options in the Settings app, as well as command-line tools such as NET.EXE or PowerShell.
Default local user accounts in Windows
When you install Windows, the system creates several built-in local accounts that you cannot delete. Their function is to support computer administration and certain internal services, and they do not provide access to network resources like domain users.
These built-in accounts, along with any you create, are stored in the Users folder within the local security database (SAM) and are displayed in the Local Users and Groups section of the Computer Management console. Controlling which accounts are enabled, their group memberships, and their passwords is crucial for a secure environment.
Integrated local administrator account
The Administrator account is the classic local administrative account. Every Windows computer has an account with a well-known security identifier (SID ending in -500), and for years it has been a favorite target for attackers because it is known to almost always exist.
This account has full control over the computer : it can access and modify any file, folder, service, registry key, scheduled task, as well as create and delete local users, change their rights and permissions, and take ownership of any resource when needed.
Although you can't permanently delete or block the built-in account, Windows allows you to change its name or disable it . In fact, in modern installations, the setup wizard disables the built-in Administrator account and creates another local account that's a member of the Administrators group for you to use instead.
Users belonging to the Administrators group can run applications with elevated privileges without always needing to use "Run as administrator," since the system can elevate their permissions through User Account Control (UAC) . In practice, this means that any user in that group has full control over the system.
Group membership and best practices with the Administrator account
By default, the Administrator account is a member of the Local Administrators group and cannot be removed from it. Therefore, it is recommended to keep the number of Administrator accounts to a minimum , as any user in that group can significantly alter the system.
As an additional measure, many administrators change the Administrator account name to make automated attacks more difficult. Even so, the SID remains the same, and a skilled attacker can still detect it. The crucial point is to keep it disabled except when absolutely necessary.
The recommended practice is to use a standard (non-administrator) local account for everyday tasks and resort to elevation functions ("Run as administrator", UAC) only when you need to perform administrative tasks, such as installing programs or modifying global Windows settings.
Administrator account security and group policy
Because it's such a powerful and well-known account, it's advisable to strengthen its security using Group Policy Objects (GPOs) . With GPOs, you can enforce control over the use of the Local Administrators group, require User Account Control (UAC), restrict remote access with local administrator credentials, and generally limit the lateral movement of a potential attacker who might steal a password or hash.
In business or educational environments, it is common to block remote login with local administrator accounts and limit their use to very specific interactive logins, all orchestrated from the Group Policy Management Console (GPMC).
Guest Account
The Guest account is intended for occasional users who need to use the computer in a very limited way without having their own account. By default, it is disabled and has a blank password.
Activating it grants very restricted rights and permissions, but at the same time the account can pose a risk : it allows a certain type of anonymous access, can be used for abuse, and, if configured incorrectly, can give more visibility than it should to internal computer resources.
The Guest account is usually the only member of the local Guests group (SID S-1-5-32-546). It is recommended to keep it disabled unless absolutely necessary , and if enabled, carefully review the permissions it can access and, above all, prevent its use over the network.
Another critical point is that the Guest user should not have access to event logs or sensitive audit information. If you decide to activate this account, it's advisable to monitor it frequently to ensure that no resources are accidentally exposed.
HelpAssistant account
The HelpAssistant account is automatically generated when someone initiates a Remote Assistance session on your computer. Its purpose is to provide the person assisting you with limited access during the support session, and it is managed through the Remote Desktop Help Session Manager service.
When there are no pending remote assistance requests, this account is automatically disabled . However, it still has several associated security identifiers (SIDs) from special groups related to remote logins, such as the Terminal Server Users group and the Remote Interactive Logon group , both applied to users connecting via Remote Desktop or Terminal Services.
In Windows Server domains, the HelpAssistant account is typically located in the container CN=Users, DC=<domain> , with no default members, but it can also be a member of guest groups. It is not recommended to delegate its administration to non-specialized personnel or move it out of its default container unless there is a very clear reason and the consequences are fully understood.
On Windows servers, Remote Assistance is an optional component that isn't always installed . If you don't use it, it's a good idea to keep it disabled to reduce your attack surface.
DefaultAccount (DSMA)
The DefaultAccount , also called the Default System Managed Account (DSMA) , is a special account that Windows uses to run multi-user or user-independent applications.
From a permissions standpoint, DefaultAccount behaves like a standard user , but the system uses it for things like "multi-user manifest" (MUMA) applications, which need to be always running and react when users enter or leave the device, as happens in Xbox or other shared session environments.
This account is disabled by default in both desktop editions and many server editions with desktop experience. It has a known RID (503), so its SID follows a predictable format like S-1-5-21-<ComputerIdentifier>-503 . Additionally, it is a member of the special System Managed Accounts group (SID S-1-5-32-581).
Windows can grant permissions to DSMA even before the account physically exists in the database, preparing it for offline scenarios. Both the account and the group are then created on the machine's first boot within the Security Account Manager (SAM).
On domain controllers created directly with Windows Server 2016 or later, DefaultAccount is automatically deployed to all domain controllers . In older domains, it is created when the PDC emulator role is moved to a Server 2016 domain controller and is subsequently replicated to the rest. Microsoft advises against changing its default state : it is safer to leave it disabled, as forcing changes can break future scenarios that depend on it.
Default local system accounts
In addition to local user accounts, Windows uses several internal system accounts that aren't managed like regular users, but which you'll see in NTFS permission lists or service settings. These aren't used for logging in as an interactive user and often don't even appear in the graphical user management interface.
SYSTEM Account
The SYSTEM account is the internal identity used by the operating system itself and many of its services. It is used, for example, during Windows installation and in tasks where the system needs the highest possible level of privilege.
You won't see it listed in the User Manager, nor can you add it to groups from there, but it does appear in the Security and NTFS file and folder permissions tabs. It typically has full control over the entire NTFS volume , an access level comparable to or even higher than the local administrator.
This account is managed exclusively by Windows, so you shouldn't attempt to modify its permissions lightly . Tampering with SYSTEM's permissions often results in strange system behavior, boot failures, or problems with critical services.
Network Service Account
The NETWORK SERVICE account is a predefined local identity used by the Service Control Manager (SCM) when starting certain services. This account operates with limited privileges on the local computer , but when connecting to other computers on the network, it can present the machine's credentials, allowing it to authenticate as if it were the local machine.
It is used for services that need to communicate with other servers without exposing the context of a real user, and keeping it with its default permissions is important for network services to function correctly and securely.
Local Service Account
The LOCAL SERVICE account is also used by the Service Control Administrator. It has very limited privileges on the computer and, when communicating over the network, presents itself as an anonymous user, meaning it has virtually no privileges.
It is used for services that do not require their own identity on the network or elevated permissions, reducing the impact if a service is compromised. It is best not to modify its configuration or grant it more privileges than necessary.
How to securely manage local user accounts
All local user accounts, both built-in and those you create, are managed at the computer level. From the Local Users and Groups console (when available), you can assign rights and permissions, define who can perform backups, shut down the computer, change the time, and so on.
A “user right” is the ability to perform actions on the system (shut down, log in remotely, make backups, etc.), while a “permission” is associated with a specific object (file, folder, printer) and defines what specific operations a user can perform on that object : read, write, delete, change permissions, etc.
On domain controllers, you cannot manage local users on the domain controller itself using this console, but you can connect to other computers on the network to manage their local accounts. You also have tools such as NET.EXE USER /LOCALGROUP and PowerShell cmdlets available to automate account creation, modification, and auditing.
Create secure local accounts for everyday use in Windows
For secure daily use, it is ideal to have at least two types of accounts on each computer : one or more standard accounts for everyday work and, separately, an administrator account (or membership in the Administrators group) that is only used when it is necessary to elevate privileges.
In Windows 10 and Windows 11, you can create local accounts from Settings → Accounts → Family & other users . Under “Other users,” you’ll see the option to Add account . The system will first try to get you to use a Microsoft account (email, phone), but if you choose “ I don’t have this person’s sign-in details ” and then “ Add a user without a Microsoft account ,” you can set up a classic local account with a username, password, and password hint.
Once created, you can change its type from the same panel, under “ Change account type ,” switching from “Standard user” to “Administrator” if needed. For daily use, it's best to keep it as a standard user , as this prevents it from installing programs for all users, modifying computer security settings, or creating or deleting other accounts.
When you restart or log out, you'll see the new account in the bottom left corner of the login screen. Simply select it, enter your password, and Windows will create your profile for the first time , with its own desktop, documents, downloads, and settings.
Practical scenario: classroom or laboratory with Instructor and Student accounts
In an environment like a classroom with 12 computers managed by Intune , it is very common to want to have two distinct types of accounts: one for Instructor with elevated permissions (powerful user or local administrator) and another for Student without administrative privileges.
The usual idea is that the Instructor account can install or update software, manage the necessary settings for the class , and that, when finished, it is possible to delete the Students' data without touching applications, Windows patches, or security software.
To achieve this, you can combine several strategies: use Intune to deploy standardized applications and configurations , apply policies to ensure students only have standard accounts, and use profile cleanup or user state restoration tools between classes. The Instructor account can be created as a local user or as an Intune-managed profile, ensuring that only authorized personnel have administrative privileges.
Create local accounts during Windows 11 installation (OOBE)
In Windows 11, especially in Home editions, Microsoft tries to force the use of Microsoft accounts during the initial setup (OOBE) . However, it's still possible to create purely local accounts using a few workarounds.
In Pro versions, you can still see the clear option to create an account without Microsoft . In Home, things are more complicated, but there are several ways:
- Force local account only mode with a special command in the OOBE.
- Simulate a connection failure or network service so that the assistant allows you to continue without a Microsoft account.
- Using fake Microsoft credentials so that, after the error, it offers to create a local user.
For some builds, when you reach the "Let's connect you to a network" screen, you can press Shift + F10 to open a command prompt and run `start ms-cxh:localonly` . The Microsoft account window will open, but this time it will let you choose a local account.
Another technique commonly used in recent versions (22H2 and later) is to run the command `oobe\bypassnro` in the same console . After restarting, the wizard will launch again, but now the option " I don't have an internet connection " will appear. Selecting this option will allow you to create a local administrator user on the computer without associating it with a Microsoft account.
If the command fails for any reason, you can always create a local account from the console and add it to the administrators group using command-line tools . Then, after the OOBE is complete, that account will be available to log in.
Create local accounts using scripts and PowerShell
If you are a technician or manage many computers, the most efficient way is to use PowerShell or .NET commands to create and manage local accounts automatically.
For example, with PowerShell you can create a local user like this:
New-LocalUser -Name "operator" -Password (Read-Host -AsSecureString "Password") -FullName "Plant Operator" -Description "Local account without Microsoft"
Then you can decide whether to add it to the Administrators group or the Users group with:
Add-LocalGroupMember -Group "Administrators" -Member "operator" (or replacing Administrators with Users for a standard user).
With classic NET commands you would have something like:
net user operator SecurePassword123 /add
net localgroup Administrators operator /add
This is very practical when you want to create the same account structure across multiple computers or integrate it into deployment scripts, OSD, Intune tasks, or other management tools, including password management with KeePassXC.
Restrict and protect local accounts with administrative rights
One of the most frequent threats in Windows networks is the so-called lateral movement : an attacker steals the credentials of a privileged local account (or its hash) on one computer and reuses them to log into other computers that share the same account and password.
To reduce this risk, it's advisable to avoid using accounts with administrative privileges for daily use and instead rely on User Account Control (UAC) and multi-factor authentication . UAC treats administrator accounts as standard users until explicit elevation is requested, prompting you for confirmation or a password.
In addition, several strategies can be applied using Group Policy to block remote use of these local administrative accounts and further harden the environment.
Apply local account restrictions for remote access using UAC
User Account Control (UAC) not only alerts you when an application wants to make significant changes; it can also restrict the use of local administrative accounts at the network level . For example, when a local account connects remotely to another computer using network login (such as with NET USE ), Windows can issue a standard user token without elevation privileges.
In this way, even if the local user is an administrator on their own computer, they will not be able to access shared administrative resources such as C$ or ADMIN$ or perform remote administration on other computers.
To reinforce this model, from the GPMC you can create a GPO and configure policies such as:
- User Account Control: Run all administrators in administrator approval mode (enabled).
- User account control: Administrator approval mode for the built-in administrator account (enabled).
And at the Registry level, using Group Policy Preferences, you can set the LocalAccountTokenFilterPolicy value = 0 under the key HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System , which prevents local account privilege elevation over the network.
Once the GPO is defined, the normal procedure is to link it to the OU where the workstations are located , test that the business applications continue to function correctly, and then extend it to the rest of the OUs that contain computers and servers, adjusting if necessary.
Deny network login to all local administrator accounts
Another very effective measure is to explicitly deny network login to local accounts that are members of the Administrators group. This prevents a stolen local password hash from being used to compromise other computers via network access or Remote Desktop.
In Group Policy, under Computer Configuration → Windows Settings → Security Settings → Local Policies → User Rights Assignment , at least two key policies can be configured:
- Deny network access to this device → Add “Local account and member of the Administrators group”.
- Deny login through Remote Desktop Services → also add “Local account and member of the Administrators group”.
The GPO is then linked to the workstation OU , everything is checked to ensure it works correctly, and if there are no problems, it is extended to the other relevant OUs. This way, even if someone obtains a local administrator's password, they will not be able to use it to connect to other computers over the network.
Unique passwords for local accounts with administrative rights
In many organizations, the same password is reused for the local administrator account on all computers, or worse, the default password is left as is after installation. This is a huge risk : compromising just one computer gives an attacker the master key to the rest.
The solution is to use long passwords (at least 12 characters) or easy-to-remember but difficult-to-guess passphrases for local accounts with administrative privileges . If you use Windows Pro or Enterprise, enabling BitLocker and storing your recovery key in a safe place helps protect your data if someone steals your computer.
It's very important to separate administrator accounts from everyday user accounts : the former should be used only for specific administrative tasks, while the rest of the time you should work with a standard account. This drastically reduces the impact of malware, human error, or browser-based attacks.
Before making significant changes to permissions, groups, or security settings, it's very helpful to have a restore point or backup . That way, if something goes wrong, you can quickly revert to a stable state.
Final considerations
Finally, it's a good idea to periodically review which local accounts exist on each computer, which ones are enabled, and which groups they belong to . This brief periodic audit helps detect old accounts that are no longer in use, forgotten test accounts, or insecure configurations that have crept in over time.
By properly managing integrated accounts, creating standard local users for daily work, and implementing policies such as strict User Account Control (UAC), long passwords per computer, and remote access restrictions, even environments with many computers, like classrooms and labs, can function efficiently while maintaining a much higher level of security than simply leaving everything at its default settings. Share this information so more users can learn about this topic.