User Account
A user account is the record an operating system or service keeps to represent one person, program or role, consisting of an identifier, credentials that prove identity, and the settings and permissions that define what that identity may do. It is what allows a single computer to be shared without everyone seeing one another's files, and it is the unit to which ownership, resource limits, audit logs and access decisions are attached.
An account is a bundle of identity data rather than a person, and its parts are worth separating. On Linux and other Unix systems, an account has a username for humans, a numeric user ID (UID) that the kernel actually uses, one or more group memberships, a home directory for personal files, a default login shell, and a password stored only as a salted hash in a protected file. Windows has an equivalent in a security identifier (SID) tied to a local or domain account. Accounts exist for more than people: web servers, databases and background daemons run under dedicated service accounts so that the damage from a compromised program is limited to what that account may touch. Because every process runs on behalf of some account, the account is what file permissions and access control lists are checked against.
Authentication and authorization are two different steps that account systems perform, and they are often confused. Authentication answers the question of who is making a request, by checking something known (a password), held (a hardware key or phone) or inherent (a fingerprint), with multi-factor authentication combining several of them. Authorization answers what that verified identity is allowed to do, and it is decided afterward by permissions, group memberships and policies. A correct password therefore grants identity, not unlimited power, and a system can authenticate someone successfully and still refuse every action they attempt. Password hashing, rate-limited login attempts and passkeys exist to strengthen the first step; roles and policies govern the second.
The root account on Unix-like systems (UID 0) and the Administrator account on Windows are privileged identities that bypass most permission checks, which is why the principle of least privilege governs how accounts are used. Least privilege means that every account, human or service, receives only the access needed for its task and for only as long as needed. Everyday work is therefore done from an ordinary account, and administrative power is borrowed briefly: the sudo command lets a permitted user run one command as root and logs it, while Windows introduced User Account Control with Windows Vista in 2007 to prompt before elevating. Browsing the web or reading email while logged in as an administrator is a classic mistake, because any malware that runs inherits that power.
Practical pitfalls include shared accounts, reused passwords and forgotten accounts, and the modern scale of accounts makes them central to security. A login shared by a team destroys accountability, since logs cannot say who acted, and a password reused across sites lets a breach at one service compromise the others, which a password manager and multi-factor authentication mitigate. Leftover accounts of departed employees, test users and unused service accounts remain valid attack paths until disabled. The same model scales up in cloud platforms, where identity and access management systems define users, roles and policies for thousands of resources, and in machine learning platforms, where a mis-scoped service account can expose training data or let a job spend compute without limits. Deleting an account also differs from disabling it, because files and processes owned by its UID remain.
Read a user account as the operating system's answer to the question of who is acting: a durable identity that authentication verifies, authorization limits, and least privilege keeps small, so that sharing one machine, or one cloud, does not mean sharing everything on it.