What is identity and access management (IAM)?

Identity and access management (IAM) is the discipline of creating, maintaining and governing digital identities and controlling their access to resources through identity proofing, credentials, authentication, authorization, policy enforcement and lifecycle review throughout creation, use, change and retirement.

IAM operates across the relationship between an identity and a protected resource. It helps an organization decide which people, services and devices should have identities, how they prove those identities and which actions each authenticated identity may perform.

The objective is not unrestricted convenience or a one-time login. It is to give each subject appropriate access for a defined purpose, keep that access current as responsibilities change and remove it when the relationship ends. Weak lifecycle controls can leave former workers, abandoned service accounts or outdated privileges connected to sensitive systems.

Zero trust provides useful context for IAM because authentication does not create permanent trust. An access decision can also consider the requested action, resource sensitivity, device posture and current risk. This article places those decisions within the broader identity and device trust model.

Why identity and access management matters

Organizations need a consistent way to connect business relationships to technical access. An employee may need payroll and collaboration applications, a contractor may need one project workspace, and a service account may need permission to call a specific application programming interface. Those permissions should change when a role, project or risk level changes.

IAM makes that relationship explicit. The NIST Cybersecurity Framework 2.0 groups identity management, authentication and access control under one outcome: limiting access to physical and logical assets to authorized users, services and hardware in proportion to risk. Its NIST CSF guidance also calls for managing identities, credentials and access permissions throughout their lifecycles.

Without coordinated identity management, separate applications can accumulate inconsistent accounts, duplicated roles and unclear owners. Without coordinated access management, a valid identity may receive broader permissions than its work requires. IAM brings those concerns together while preserving the distinction between establishing an identity and authorizing an action.

How identity and access management works

IAM works as a lifecycle rather than a single authentication event. Implementations differ, but the logical sequence is usually the same.

1. Establish the identity. An authoritative process records a person, service or device and the attributes needed for its intended use. A workforce identity might originate from an approved employment record; a workload identity requires a different enrollment and ownership process.
2. Create accounts and assign credentials. Provisioning creates the necessary account or representation in each system and binds suitable credentials or authenticators. The identity record, account and credential are related but not interchangeable.
3. Authenticate the claimant. The system verifies that the claimant controls an accepted authenticator. Authentication establishes confidence in the claim; it does not decide every action the identity may perform.
4. Evaluate authorization. Policy compares the identity, requested resource, action and relevant attributes with assigned roles, entitlements or other rules. The result may allow, deny or constrain the request.
5. Enforce and record the decision. The application, gateway, operating system or other policy enforcement point applies the result and creates an event for support, investigation or audit.
6. Review and change access. Managers, resource owners or automated controls review access and update it when duties, risk or policy change.
7. Revoke access. Offboarding disables accounts, removes assignments, revokes sessions and credentials, and transfers ownership of resources that must remain available.

NIST's current digital guidelines separate identity proofing, authentication and federation into distinct assurance functions. That separation is useful beyond the publication's stated scope: proving who an applicant is, verifying a returning claimant and sending identity assertions between systems solve different problems and can fail independently.

Core IAM capabilities

Identity and access management combines administrative processes, policy and technical services. A complete program does not require every function to reside in one product.

• Identity records and directories maintain identifiers, account status and attributes used by connected systems.
• Identity proofing and enrollment establish an identity at an assurance level appropriate to the service and bind it to an account.
• Credential and authenticator management issue, register, rotate, recover and revoke passwords, keys, certificates, passkeys or other authenticators.
• Provisioning and deprovisioning create, update, disable and remove accounts and assignments as lifecycle events occur.
• Authentication verifies a claimant through one or more accepted factors or methods.
• Authorization evaluates whether an authenticated subject may perform a particular action on a resource.
• Federation and single sign-on let systems rely on identity assertions and authentication performed through an established trust relationship.
• Access governance assigns ownership, reviews entitlements, manages exceptions and helps identify incompatible or excessive access.
• Logging and monitoring preserve evidence of account changes, authentication events, policy decisions and privileged activity.

Some architectures centralize these functions, while others distribute them across human-resources systems, directories, identity providers, applications, endpoint platforms and governance tools. Responsibility should remain clear even when the technology is distributed.

How IAM uses device identity and posture

A user identity and a device identity answer different questions. User authentication can establish that Jordan controls an enrolled authenticator, while device identity can establish which laptop is involved. Device posture adds evidence such as management status, operating-system support, encryption state or security health. None of those signals is a substitute for the others.

An IAM decision can consume device evidence alongside user, resource and session context. For example, policy may allow an authenticated employee to use email from an unmanaged device but require a managed, compliant laptop for a finance application. NIST describes dynamic access policy using the observable state of client identity and the requesting asset in SP 800-207.

Managed-device identity and posture therefore connect endpoint operations to IAM, but the responsibilities remain separate. Endpoint management maintains device records, applies supported configuration and reports posture; IAM evaluates identity and access policy; the target system enforces the result. Organizations evaluating the endpoint-management layer can review unified endpoint management without treating UEM as an identity provider or authorization system.

An IAM lifecycle example

Northstar Field Services, a fictional maintenance company, hires Priya as a six-month contractor. The approved contractor record is the starting state. An identity workflow creates Priya's workforce account, assigns the field-operations group, enrolls an authenticator and provisions access to scheduling and safety applications. It does not assign payroll administration or customer billing permissions.

Priya signs in from a managed company tablet and requests a safety manual. The identity provider authenticates her, the application receives the required identity attributes, and policy checks her current assignment, the requested resource and the tablet's recent posture. The request is allowed and the decision is logged.

Later, Priya joins a project that requires a client workspace. The project owner approves that additional entitlement with an expiry matching the project end date. This is a change to authorization, not a new proof of Priya's identity.

When the contract ends, the authoritative record triggers deprovisioning. The workflow disables the account, revokes active sessions and credentials, removes application assignments and transfers any shared project assets to an employee owner. A completion report identifies one legacy application that did not process the automated change, so an administrator removes that account manually and records the exception.

The example shows the full IAM mechanism: an authoritative relationship creates an identity, policy grants limited access, context affects each request, lifecycle events change entitlements and offboarding closes the remaining paths.

Benefits of identity and access management

IAM can improve both operational consistency and access control when its identities, policies and integrations are accurate.

• Consistent account lifecycles: Joiner, mover and leaver events can drive repeatable creation, change and removal processes.
• More precise access: Roles and attributes can connect permissions to a defined responsibility, resource and action.
• Stronger authentication: Organizations can apply authentication methods appropriate to the risk and recover or revoke credentials through governed processes.
• Reduced standing access: Reviews, expiry dates and approval workflows can remove permissions that are no longer justified.
• Central evidence: Account changes, authentication events and access decisions can support investigations and control reviews.
• Less manual duplication: Provisioning and federation can reduce repeated account administration across connected systems.

These are possible outcomes, not guarantees. Automation can distribute a mistaken role or stale attribute faster, and centralized services can increase operational impact when they are unavailable or misconfigured.

IAM risks and limitations

IAM controls access only as well as its identity data, policy design, integrations and enforcement points allow. Important failure conditions include:

• Incorrect source data: A wrong role, manager, contract date or account owner can produce incorrect access throughout connected systems.
• Orphaned accounts: Applications outside the lifecycle process may retain access after a user or service relationship ends.
• Excessive privileges: Broad roles, accumulated group memberships and permanent exceptions can exceed the access required for current work.
• Weak proofing or recovery: A strong sign-in method cannot compensate for an identity that was enrolled incorrectly or an account-recovery process that can be bypassed.
• Authentication without authorization: A successful login can be misread as permission to perform actions the identity should not have.
• Stale attributes and posture: Decisions based on old role, device or risk information can allow or block access incorrectly.
• Fragmented enforcement: Central policy has limited value when an application ignores the decision or maintains an unmanaged local account.
• Service dependency: Failure of a directory, identity provider or policy service can interrupt work and create pressure to bypass controls.
• Inadequate non-human identity controls: Service, workload and device identities need owners, scoped permissions, protected credentials and revocation paths suited to their use.
• Privacy overcollection: Identity profiles and access logs should be limited to justified purposes, protected appropriately and governed under applicable requirements.

IAM cannot prove that an authenticated endpoint is uncompromised, prevent every misuse by an authorized person or replace resource-level security. It supplies identity and policy context; endpoint security, application controls, data controls and incident response address different parts of the risk.

IAM and related concepts

Related identity terms describe different scopes or stages of an access decision.

An identity provider is often a central IAM component because it authenticates users and supplies assertions to applications. Multifactor authentication can strengthen that authentication. Neither capability alone provisions every account, reviews entitlements or guarantees that a resource enforces correct authorization.

Effective IAM connects an authoritative identity lifecycle to a specific resource decision. It establishes who or what is represented, verifies the claimant, limits the requested action, records the outcome and removes access when its justification ends. Conditional access extends that model by evaluating current device and risk context at the point of access.