Using the same user with administrator privileges for everything is one of the most common security errors In Windows, both at home and in professional environments, separating your daily work account from high-privilege accounts and having a thorough understanding of internal system accounts is key to reducing risks, protecting privacy, and curbing malware.
Throughout this article you will see, step by step, how Create and manage secure local accounts for everyday useWhat types of accounts exist in Windows (including hidden system accounts), how to configure them in Windows 10 and Windows 11, what has changed in recent versions, and what policies and best practices you should apply if you manage multiple computers or an entire classroom.
What exactly is a local account in Windows and why is it useful to use it?
In Windows you can log in with a Microsoft account or with a local accountA Microsoft account is linked to an email address (Outlook, Hotmail, Live, etc.) and integrates with OneDrive, the Microsoft Store, settings syncing, Xbox, Office, and other cloud services. All of this is great, but it also means more data exposure and reliance on your online identity.
The local account, on the other hand, is an account that It only exists on that deviceThe user has their profile folder, documents, pictures, desktop, etc., but settings and files are not synchronized with the Microsoft cloud. This approach offers a greater degree of privacy and reduces the attack surface in scenarios where you don't need or want integration with the company's online services.
In environments with multiple users sharing a PC (large family, office, classroom, laboratory, or small business), creating separate local profiles prevents Some look at other people's dataIt isolates settings, browser history, and installed applications for each user, simplifying compliance with data protection policies.
Windows 8, 10, and 11 still allow local accounts just like in previous versions, even though the system tries to push you to use them. Microsoft accounts for everythingYou can switch between your Microsoft account and your local account at any time, without losing data if you do it correctly.
Local user and system accounts: what types there are and what they are used for
Windows automatically creates a series of default local accounts When you install the system, some are user-specific and others are system-specific, used internally by Windows itself and certain services. They don't behave the same way or have the same permissions, so it's important to understand them to avoid breaking anything or leaving vulnerabilities.
Default local user accounts
The default local user accounts are built-in accounts that the system generated during installationThey cannot be deleted, although they can be renamed or disabled in some cases. They all reside on the computer and only have rights over that device, without automatic access to network resources.
To view and manage these accounts, in Pro editions and higher you can use the console. Device administration > Local users and groups > UsersFrom there you can create custom users, change passwords, disable accounts, etc. In Home editions, many of these tasks are performed from the Settings app or using commands.
Administrator Account
The built-in local administrator account is the one that has the total control of the teamYour SID ends in 500 It is the first account that is generated during the installation of Windows, although in modern versions it is usually disabled and another account with administrator permissions is created for the main user.
With this account you can modify any file, service, permission, or settingThis allows them to take control of resources, change user rights, and assign privileges. Precisely for this reason, it's a very attractive account for attackers and malware, and its existence is well-known in virtually all versions of Windows.
For security reasons, you cannot delete the Administrator account, but you can rename it or disable itMicrosoft recommends not using this account for regular logins and limiting the number of accounts belonging to the Administrators group as much as possible. A good practice is to always work with a standard account and only use elevated privileges (Run as administrator and User Account Control) when necessary.
Guest Account
The Guest account is intended for users occasional or single use They need quick access to a computer without creating their own account. Its SID ends in 501, it has very limited permissions, and by design, it's for temporary sessions without extensive customization.
By default, the Guest account comes disabled and without passwordThis poses a serious risk if activated carelessly, as it can offer anonymous access. It is the only member of the Guests built-in group (SID S-1-5-32-546), which only has the rights necessary to log in locally.
If you do enable it for any reason, it is advisable to restrict it as much as possible, not allowing its use over the network. prevent them from viewing event logs and review your activity frequently to prevent someone from using it to unintentionally leave services or resources open.
DefaultAccount (DSMA)
DefaultAccount, also known as Default System Managed Account (DSMA), is a standard system-managed account that is introduced to support multi-user applications (MUMA) and certain modern scenarios (e.g., Xbox or shared session environments).
This account is usually disabled by default On Windows desktops and servers with desktop experience, it has a known RID (503) and belongs to the special group of system managed accounts (SID S-1-5-32-581). Windows itself creates it in the Security Account Manager (SAM) the first time the computer starts.
From a permissions standpoint, it behaves like a standard user, but it is designed so that applications that need to remain in the background, reacting to user session changes, can... run in a context independent of that of human usersMicrosoft advises against modifying its default settings, as this could break current or future security scenarios without providing any real security benefits.
WDAGUtilityAccount
WDAGUtilityAccount is another built-in local account, used by Windows Defender application protection (Windows Defender Application Guard). Its SID is known (ends in 504) and, by default, does not belong to any group.
This account is used to isolate browsing or execution environments that the system protects in containers. Under normal circumstances, you should not touch it. Windows enables and configures it automatically. when required.
WSIAccount
WSIAccount appears in Windows 11 and is geared towards the Web-related activities from the lock screen or login screenIt is used, for example, to access credential provider pages when you want to reset a password or use web-based authentication before fully logging in.
It has a known SID ending in 1001 and, by default, is part of the Users group. Again, it is a service account that It should not be used interactively. nor modify manually unless Microsoft documents it for a specific case.
HelpAssistant account
HelpAssistant is a local account that Windows Enabled only during Remote Assistance sessionsWhen a user requests help via invitation (by email, file, etc.), the system creates this account with limited permissions so that the person assisting can connect and control the equipment under supervision.
The account remains disabled until there are any pending remote help requests. It is managed by the Remote Desktop Help Session Manager service and is part of groups related to Remote Desktop and Terminal Server (for example, groups with SID S-1-5-13 and S-1-5-14, which include users of Remote Desktop and Remote Interactive Logon services).
In Windows Server, Remote Assistance is not installed by default and is a optional componentThe HelpAssistant account doesn't really come into play until it's installed and used.
Local system accounts: SYSTEM, Local Service, and Network Service
In addition to user accounts, Windows has several internal system accounts which are not intended to log in as a normal user, but to allow the system and its services to function.
The most powerful one is the account SYSTEM (SID S-1-5-18). It is used by the operating system kernel and numerous services that require maximum permissions, including installation tasks. It does not appear in the User Manager nor can it be added to groups, but you will see it in the NTFS permission lists, where it usually has full control over all files of the local volumes.
The check Local service (LOCAL SERVICE, SID S-1-5-19) It is designed to run services with minimal privileges on the machine and anonymous credentials on the network. This way, if a service using this account is compromised, the attacker has less room to maneuver.
Meanwhile, the account Network Service (NETWORK SERVICE, SID S-1-5-20) It runs services that need to use the computer's own credentials when communicating with other remote servers. Thus, the service presents itself to the network as the computer, not as a regular user, but maintains relatively limited privileges locally.
Create secure local accounts for everyday use in Windows 10 and Windows 11
Beyond integrated accounts, the usual practice is to create standard local users For daily use, you can have one or more administrator accounts that are only used when you need to install software, modify global settings, or perform maintenance. Windows offers several ways to create these accounts, depending on whether you prefer a graphical interface or the command line.
Create from the Settings app
In Windows 10 and 11, the most "user-friendly" route for most users is the app Settings > AccountsFrom there you can create both local accounts and Microsoft ID-based accounts, and later change their type (Standard User or Administrator).
The typical flow is: go to Accounts, enter Family and other users (on Windows 10) or on Other users (in Windows 11), click on Add account and, when the system asks for an email or phone number, choose the option I don't have this person's login detailsIn the next step, instead of opening a new Microsoft email, choose Add a user without a Microsoft account.
From there, you just need to indicate Username and passwordRepeat your password for security and set up three security questions. recovery responsesIt's possible to leave the password blank, but it's a bad idea in almost any real-world scenario. Once created, the account appears in the other users section, and you can change its type to Administrator if needed.
Creating a family member account (with a Microsoft account)
If you want to create accounts for minors or users to whom you want to apply parental controls and screen time rulesYou can use the Family option. In this case, a Microsoft account is required because control is centralized through the Family Safety service.
A user with administrator privileges who is signed in with a Microsoft ID can go to Accounts > Family, add a member, and indicate whether they will be Organizer or Member and link your email address (or create a new one for a child). All subsequent settings (filters, limits, reports) are managed later through the Microsoft Family Safety website.
Creation from Device Management
In more technical environments, Team Management is a very convenient tool for quickly create multiple local users, especially in Windows Pro or Enterprise.
From the context menu of the Start button, open Computer Management, expand Local Users and Groups > Users, and use the option to New UserThis section defines the username, optional full name, description, and password. You can require a password change upon first login, prevent users from changing their password, or set it to never expire.
After clicking Create, the window remains open in case you need to create multiple users in a row, which is very useful in classrooms or labs with many students. This method only creates local users, not Microsoft accounts, and from each user's properties you can assign group membership (for example, Users or Administrators).
Created with Netplwiz
Netplwiz is a classic Windows tool for manage accounts and login optionsIt is launched from Run by typing netplwiz and allows you to add accounts, change passwords, and configure whether a user must enter a password when logging in.
From the Users tab, click Add and the wizard will offer to create a Microsoft account or, if the appropriate option is chosen, a local account without MicrosoftAlthough it's somewhat hidden, the procedure is similar to that of the Settings app: name, password, and, if applicable, group membership.
Creating from the console: net user and PowerShell
When managing many teams or working in safe mode, the console is your ally. With the classic command net user You can create a user with a single line, for example:
net user operator SecurePassword123! /add
If you later want that account to belong to a specific group, you can use:
net localgroup Administrators operator /add To assign administrator privileges, or add it to the Users group if it should only be a standard user. This method is ideal for scripts and automated deployments.
In PowerShell, the cmdlet New-LocalUser It allows for more control and a modern syntax. You can create the account and define a secure password converted to SecureString, and then use Add-LocalGroupMember to add it to the corresponding group. This is especially useful for system administrators when combined with automation tools or the Microsoft.PowerShell.LocalAccounts module.
Recent changes in Windows 11: OOBE, commands, and creating local accounts
In recent versions of Windows 11, especially from build 24H2 onwards, Microsoft has been closing “unofficial” routes to bypass the requirement to use a Microsoft account during the initial installation.
The well-known trick OOBE \ BYPASSNROThe feature that until recently allowed you to force the local account option in the Out-of-Box Experience (OOBE) wizard has stopped working. When trying to use it in 24H2, the system simply restarts the wizard and returns you to the same screen, without offering the local account shortcut as before.
However, effective alternatives still exist. One of the cleanest is to use the following on the screen indicating that an internet connection is required: Shift+F10 to open a console and execute an internal command like OOBE: start ms-cxh:localonlywhich makes the assistant show the local account creation path without associating it with an email.
Another classic option is Install Windows offlineDisconnecting the network cable or disabling Wi-Fi before or during the setup wizard can also help. In many builds, if the computer doesn't detect an internet connection, it automatically offers the option to create a local account as part of the initial setup process, without requiring any additional steps.
Finally, there is always the option of Install with a Microsoft account and then create a local account From Settings or the console, move your daily usage to that account and, if desired, convert the Microsoft account to a local account from Accounts > Your info > Sign in with a local account. It's a bit more involved, but fully supported and stable.
Security and best practices in the daily use of local accounts
Having many accounts is useless if their configuration is lax. For local accounts to truly provide security, they need to be combined. good usage practices with the correct configuration of UAC, permissions, and group policies, especially in corporate environments.
Use a standard account for everyday use
The general recommendation from Microsoft and any security expert is clear: use a Standard account for daily tasks (browsing, email, office applications, games, etc.) and reserve accounts with administrator privileges only for those actions that truly require them, and, whenever possible, activate multi-factor authentication.
El User Account Control (UAC) This helps a lot. Even when logging in with an account that belongs to the Administrators group, UAC applies an "administrator approval" model: the user functions in standard mode until an action requires elevation, at which point the system displays a warning and asks for confirmation or credentials.
UAC also affects how local accounts behave when used for remote or network accessFor example, when logging in via a network logon (NET USE, shared connections, etc.), Windows can issue a standard user token without elevation capabilities, preventing that account from accessing administrative resources such as C$ or ADMIN$. This reduces the attack surface for lateral movement following a credential theft.
Restrict remote use of local accounts with administrative rights
One of the most common attacks on Windows networks is lateral movement, taking advantage of reused password hashes on multiple computers. If the local administrator account has the same password on several PCs, an attacker who compromises one can use those credentials to spread to the rest.
To mitigate this risk, there are several complementary strategies. The first is deny login from the network and Remote Desktop Services login to local accounts that are members of the Administrators group. This is done through group policies, using the following policies:
- Deny network access to this device, configured for “Local account and member of the Administrators group”.
- Deny login through Remote Desktop Servicesalso pointing to “Local account and member of the Administrators group”.
These policies are applied in Computer Configuration > Windows Settings > Security Settings > Local Policies > User Rights Assignment and are distributed via GPO to the organizational units that contain workstations and servers that you want to protect.
Another key measure is to control UAC behavior on remote access by configuring the registry value Local Account Token Filter Policy Under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System. Through a GPO based on Registry Preferences, this value can be defined as a REG_DWORD with data 0 to enforce token filtering and limit the elevation of local accounts over the network.
Unique and random passwords for privileged local accounts
Reusing the same local administrator password on all computers is a enormous riskAny leak of that password, or its hash, opens the door to compromising all identically configured machines in a chain reaction.
The solution involves establishing unique and random passwords for each local account with privileges. This makes pass-the-hash attacks extremely difficult, since a stolen hash is only valid on the machine where it was obtained, not on the others.
Microsoft offers several ways to automate this randomization. The most recommended method today is to implement LAPS (Local Administrator Password Solution)This software generates and rotates complex passwords for local administrator accounts and stores them encrypted in Active Directory, accessible only to authorized administrators. Other options include acquiring enterprise tools from privileged password management or develop custom scripts that generate strong passwords periodically. The important thing is to avoid shared static passwords and the temptation to "use the same one for everyone to remember it."
Protecting sensitive credentials and processes: LSASS and Credential Guard
Windows stores credentials and security secrets during the process LSASS (Local Security Authority Subsystem Service)which controls user sessions and validations. If an attacker manages to read LSASS's memory, they can extract password hashes and Kerberos tickets for lateral movement. Furthermore, it is advisable Check if your credentials have been leaked and act quickly.
Therefore, on modern workstations and servers, it is advisable to configure LSASS as a Process Protection Light (PPL)reinforcing its isolation from unreliable processes. Additionally, many current systems allow activation Credential Guard, which uses hardware-based virtualization to isolate credentials and secrets, also reducing the surface area for hash theft.
These measures, along with proper segmentation of local accounts, the use of unique passwords, and the restriction of remote logins, result in an environment that is much more resilient to escalation and lateral movement attacks.
Advanced local account management and remote administration
On domain controllers, domain accounts are managed through Active Directory and the usual tools, but it is also possible to use Local users and groups to manage accounts on remote computers that are not domain controllers, provided that the network and policies allow remote administration.
In addition to the GUI, administrators have classic utilities such as NET.EXE USER and NET.EXE LOCALGROUP for managing local users and groups using scripts, and the Microsoft.PowerShell.LocalAccounts module to automate the creation, modification, and deletion of accounts with PowerShell.
Assign correctly user rights and access permissions It is also fundamental. Rights (such as backing up files, shutting down the computer, logging in locally or over the network) are defined in local or domain security policies, while permissions are applied to specific objects (files, folders, printers) through ACLs.
On domain controllers, Local Users and Groups cannot be used to manage local accounts on the controller itself, but it can be used to direct administration to remote member computers. This separation helps maintain the well-defined domain security versus the local accounts of each machine.
Taken together, a thorough understanding of integrated accounts, the use of standard local accounts for daily operations, strictly limiting administrative accounts, enforcing remote login restriction policies, protecting LSASS, and ensuring unique passwords lay the foundation for the local accounts are a safe and reliable tool both at home and in business networks, classrooms or laboratories where many users share equipment but should not share risks or data.
