What Is Identity Management?

Identities and accounts

A digital identity is the collection of information a system uses to represent one subject: a person, but also a server, an application or a device. It consists of identifiers that must be unique (an employee number, a sign-in name, an email address, an internal security identifier), descriptive attributes (name, department, manager, job title, location), credentials that prove the identity (a password, a passkey, a certificate) and the access that has been granted to it.

An account is narrower: it is the record of that identity in one particular system, the thing you actually sign in to. One person usually has many accounts. A new network engineer at Kestrel Energy, the fictional energy supplier used throughout this site, may get all of these in the first week:

Identity management is largely the work of keeping those accounts tied to the one identity behind them. When the engineer moves to another team, every account should change with them; when they leave, every account should be disabled on the same day. An account that no longer belongs to a living identity is exactly what attackers look for (see The Identity Lifecycle).

Local user accounts on a single computer are covered in Users and Permissions. This topic is about identities managed centrally, for many systems at once.

Authentication, authorization and accounting

Every access decision follows the same three steps, together called AAA. They are usually preceded by identification: claiming an identity by typing a user name or presenting a badge.

• Authentication (often shortened to AuthN) proves that the subject really is the identity it claims to be, with one or more factors. Passwords, factors and multi-factor authentication (MFA) are explained in Passwords and Authentication; the identity-specific methods such as FIDO2 and Windows Hello for Business in MFA and Passwordless.
• Authorization (AuthZ) decides what the authenticated subject may do: which resources, which actions, under which conditions. See Authorization Models.
• Accounting records what the subject did and when (sign-ins, changes, data access), so that actions can be traced, investigated and billed. In identity platforms this means sign-in logs and audit logs.

A practical example: a service desk analyst signs in to the virtual private network (VPN) in the morning.

Identity stores and identity providers

Two roles appear in every identity system. They are often the same product, but it helps to keep them apart.

The identity store

An identity store is the authoritative database of identities: it holds the accounts, their attributes and group memberships, and the information needed to check credentials (such as password hashes). Most identity stores are directories, databases built for many fast reads of small records (see Directory Services and LDAP). Examples:

• Active Directory Domain Services (AD DS), Microsoft's on-premises directory for Windows networks (see Active Directory Fundamentals).
• Microsoft Entra ID (formerly Azure Active Directory), Microsoft's cloud directory (see Microsoft Entra ID).
• LDAP directories such as OpenLDAP, 389 Directory Server and FreeIPA, common in Linux environments (see Linux and Identity).
• The user database of a cloud identity service such as Okta or Google Cloud Identity.

An identity store is not the same as the HR system, even though HR often is the source of truth for who works there. In a well-run organization, HR records feed the directory, not the other way around.

The identity provider

An identity provider (IdP) is the service that authenticates users and then vouches for them to other applications, usually with a signed token or assertion that says "this is user X, signed in at 08:57 with MFA, member of these groups". The application trusts the IdP instead of checking passwords itself. That is what makes single sign-on and federation possible, explained in detail in Single Sign-On and Federation.

Microsoft Entra ID, Okta, Google, Ping Identity and Keycloak are widely used IdPs; Active Directory acts as one inside a Windows domain through Kerberos (see Kerberos and NTLM), and Active Directory Federation Services (AD FS) can extend it to web applications. The choice between them is a matter of environment and licensing; the concepts on these pages apply to all of them.

A map of the topic

The diagram shows how the pieces fit. People and machines are stored in an identity store; an identity provider authenticates them and issues tokens; applications rely on those tokens and make their own authorization decisions. Around all of it sits governance: processes that create, change, review and remove access.

The pages of this topic follow that map: directories and Active Directory (pages 2–8), cloud identity, single sign-on, MFA and conditional access (pages 9–12), privileged access and the identity lifecycle (13–14), non-human identities and Linux (15–16), and finally attacks, monitoring and troubleshooting (17–18).

IAM and identity governance

Identity and access management (IAM) is the umbrella term for the processes and technology that make sure the right identities get the right access to the right resources. Day to day, IAM is operational: create the account, reset the password, add the group, enforce MFA, issue the token.

Identity governance and administration (IGA) is the part of IAM that asks whether access is still correct and can be proven to be correct. It covers the identity lifecycle (joiners, movers and leavers), access requests with approvals, periodic access reviews, separation-of-duties rules and the reports auditors ask for.

Small organizations do IGA with a spreadsheet and a calendar reminder; larger ones use dedicated tools (Microsoft Entra ID Governance, SailPoint, Saviynt, Omada and others) that connect to HR and to the target systems.

Identity as the new perimeter

In the classic network model, the firewall was the boundary: inside was trusted, outside was not. That boundary has largely dissolved. Email, files and business applications run as cloud services that are reachable from anywhere; people work from home, trains and customer sites; and a laptop on the office network may be no safer than one at home.

What every one of those requests still passes through is a sign-in. So the controls that matter most move there: strong authentication, checks on the device and the risk of the sign-in, and the smallest possible set of permissions. That is why identity is called the new perimeter, and why it is the foundation of zero trust (see Conditional Access and Zero Trust).

Incident reports from many sources agree that stolen, guessed or phished credentials play a part in a large share of breaches; the exact percentage differs per report and per year. A well-documented example: in January 2024 Microsoft disclosed that the group it calls Midnight Blizzard had gained initial access through a password spray against a legacy, non-production test account that did not have MFA, and then abused an old OAuth application to read corporate mailboxes. No firewall rule was broken: the attacker signed in.

Human and non-human identities

Not every identity belongs to a person. Applications, scripts, scheduled tasks, servers, containers and pipelines also sign in, and in many organizations they outnumber the people. Common forms:

• Service accounts in Active Directory and on servers, which run a service or a scheduled job.
• Service principals and managed identities in the cloud, which let an application or a virtual machine get tokens without a stored password.
• Federated workload identities, such as a GitHub Actions workflow that signs in to a cloud with OIDC instead of a stored key.
• Identities for AI agents, which act on behalf of a user or on their own. As of 2026, Microsoft lists Entra Agent ID as a separate identity type for agents.

Non-human identities need the same care as people, and often more: they cannot use MFA in the usual way, their secrets are copied into configuration files, and nobody "leaves" when a project ends. See Identity for Applications and Machines.

Identity for citizens and businesses

Identity management is not only an internal IT matter. Governments run identity systems for citizens and companies, and the same ideas apply: an identity provider authenticates you at an assurance level, and the service you use trusts that result.

The same principles return inside companies: proof at a level that fits the risk, and sharing only the attributes that are needed.