During an incident review, an analyst lists every account that touched a compromised file server in the past month: fourteen employees, two domain administrators, a backup service account, an HVAC contractor's remote support login and an account named emergency-admin that nobody remembers creating. Each is a different kind of account, attacked in a different way, and each needs different controls.
On the CompTIA Security+ SY0-801 exam, account types are part of objective 4.5, which expects you to apply identity and access concepts to scenarios. This lesson covers user, privileged, service, third-party and emergency access accounts: what each is for, how each tends to be abused, and which control a question expects for each.
User accounts belong to one person and carry no administrative rights
A standard user account represents one named person. It's created and removed through the joiner, mover and leaver process, protected with MFA, and limited to the access that person's role needs. It has no administrative rights on servers and, in a well-run environment, none on the user's own laptop either. Software installs go through a managed deployment tool instead.
The one-person rule matters because accounting depends on it. When five receptionists share a frontdesk login, the logs can say only that "frontdesk" did something. Where a shared login truly can't be avoided, such as a kiosk in a lobby, the account should be locked to that device, restricted to one application and kept away from sensitive data.
Two related account types are usually disabled. Windows ships with a built-in Guest account that is disabled by default and should stay that way. Devices such as printers, cameras and network appliances often ship with default accounts and passwords published in their manuals, and those must be changed or disabled before the device goes on the network.
On the exam, a user account question usually points at one of three fixes: give each person a unique account, remove administrative rights from everyday accounts, or require MFA.
Privileged accounts differ by reach: global administrators and local administrators
A privileged account can change system configuration, security settings or other accounts. The exam objectives divide privileged accounts into global and local, which comes down to how far that power reaches.
Global privileged accounts have rights across the whole environment. Examples include members of Domain Admins or Enterprise Admins in Active Directory, the Global Administrator role in Microsoft Entra ID and the root user of a cloud account. One compromised global admin means the attacker controls everything, so these accounts get the strongest treatment:
- Keep membership tiny. Microsoft, for example, recommends fewer than five Global Administrators in a tenant.
- Give administrators a separate admin account with no mailbox or web browsing, used only from hardened admin workstations.
- Never sign in to an ordinary workstation with a domain admin account. Credentials left in that machine's memory or credential cache can be harvested by an attacker who has, or later gains, local admin there.
- Require phishing-resistant MFA, and prefer elevation on request over standing membership, covered in the access control models lesson.
- Alert on changes to privileged groups. Windows logs event 4728 when a member is added to a security-enabled global group such as Domain Admins, and 4732 for a local group.
Local privileged accounts have administrative rights on a single machine: the local Administrators group on a Windows laptop, or root on one Linux server. Their reach is smaller, but they're far more numerous, and they fail in a predictable way. When every workstation is built from the same image, every workstation has the same local Administrator password. An attacker who dumps the password hash from one machine can reuse it on all the others, a pass-the-hash technique that turns one infected laptop into hundreds.
The fix is Windows LAPS (Local Administrator Password Solution). It gives each machine a unique random local Administrator password, rotates it on a schedule, and stores it in Active Directory or Entra ID where only authorized administrators can read it. Removing everyday users from local Administrators closes the other half of the problem.
Many organizations put privileged credentials in a privileged access management (PAM) system, which keeps them in a vault, releases them after approval, records the session and changes the password when the session ends.