Both accounts sit in the local Administrators group and can change anything on the PC, but they behave very differently in one key way: the built-in Administrator runs everything with a full administrative token and never sees a User Account Control prompt, while an admin account you create yourself runs with a restricted token and gains full rights only after you approve an elevation. Nearly every practical difference between the two follows from that design choice.
One privilege level, two kinds of token
When a member of the Administrators group signs in, Windows builds two access tokens: a full one carrying every privilege, and a filtered one with administrative rights stripped out. The desktop and most programs start under the filtered token, so everyday work happens with standard-user rights. Only when you approve a UAC prompt or use Run as administrator does Windows launch a process with the full token. This is Admin Approval Mode, and it is enabled by default for every administrator account you create.
The built-in Administrator is the exception. It receives the full token at sign-in, so everything it launches — including anything a malicious download manages to execute — runs elevated without asking. There is no elevated versus non-elevated state to keep track of, which sounds convenient but removes the last checkpoint between a rogue installer and system-wide change.
What sets the built-in Administrator apart
The built-in account, known internally by the relative ID -500, has a fixed set of traits:
- Disabled by default. It ships inactive; it is usually only active if someone enabled it manually or an unattended installation did.
- Cannot be deleted. Windows refuses to remove it, though renaming it is allowed and is a common hardening step.
- Well-known SID. Its security identifier always ends in
-500, while the first account you create typically gets-1000and later ones count upward. - No UAC filtering. No consent prompts and no filtered token, ever.
- Blank password by default. If you enable it without setting a password first, anyone at the keyboard becomes an unrestricted admin.
- Hidden when inactive. A disabled account doesn't appear on the sign-in screen, so many users never notice it exists.
Checking which accounts exist on your PC
An elevated Command Prompt or PowerShell window answers this quickly. List the local accounts with:
net user
Check whether the built-in account is active by looking at the Account active line in:
net user Administrator
PowerShell shows names, status and SIDs in one shot:
Get-LocalUser | Format-Table Name, Enabled, SID
An SID ending in -500 is the built-in Administrator; -1000 and above are accounts created during setup or later. To enable the built-in account — for recovery work, say — set a password first, then activate it:
net user Administrator *
net user Administrator /active:yes
Which account belongs in daily use
For daily work, your own administrator account is the better choice, and an ordinary standard account is better still. The UAC prompt is a small price for forcing every elevation into the open, and it quietly defeats a lot of malware that expects to install itself without a click. The built-in Administrator works best as a dormant safety net: because it cannot be deleted, it can rescue you if your normal profile is corrupted or you lock yourself out. Leave it disabled and turn it on only from another admin session when needed.
If you do activate it
- Set a strong password with
net user Administrator *before anything else. - Rename the account so scripts that assume the default name fail.
- Deactivate it again afterwards:
net user Administrator /active:no. - If it must be a daily driver, you can restore UAC for it with the policy User Account Control: Admin Approval Mode for the Built-in Administrator account in
secpol.msc(Pro and above only) — though at that point it behaves like any other admin account, so simply creating a normal one is simpler.
Frequently Asked Questions
Can I delete the built-in Administrator account?
No. Windows protects it from deletion because it anchors local account security. Disabling and renaming it is the supported way to neutralize it.
Why does my own admin account keep asking for permission?
That's Admin Approval Mode working as intended. Your account holds a filtered token for everyday tasks and only exercises full rights after you approve an elevation.
Is the built-in Administrator more powerful than my admin account?
Not in what it may do — both can do everything. It is more dangerous, though, because nothing it runs is ever restricted or prompted.
Does signing in with a Microsoft account change any of this?
No. A Microsoft account with admin rights behaves like a local admin account: filtered token, UAC prompts, deletable. The built-in Administrator is always a local account.
How can I tell the two apart at a glance?
Check the SID: the built-in account always ends in -500. Alternatively, run net user Administrator — if that account exists and is active, it's the built-in one.