Is IAM just password management?

No. Passwords or other authenticators are one part of a wider identity and permission lifecycle.

Do software services need IAM?

Yes. Their identities and permissions can affect sensitive resources and need accountable management.

Does a role name prove access is appropriate?

No. The role's actual permissions, membership, and context must match the intended responsibilities.

AI Glossary / Data governance and quality / Intermediate

Identity and access management

Definition

Identity and access management, or IAM, is the coordinated management of digital identities and their access to systems, services, and information. It includes establishing and maintaining identities, authenticating requests, assigning and enforcing permissions, reviewing access, and removing it when no longer justified. IAM applies to people and also to software or service identities. Its purpose is to make access appropriate and accountable throughout the identity's lifecycle.

What it means

Knowing which account is making a request is different from deciding what that account may do. Authentication establishes confidence in a claimed digital identity under the chosen method; authorization decides whether a requested action is permitted. IAM connects these decisions with joining, role changes, departures, and operational review. A working login page is therefore only one part of IAM. The permissions behind it must continue to reflect legitimate needs.

How it works

Create identities from approved sources and assign suitable identifiers and authentication methods. Provision permissions according to defined responsibilities and policies. During use, enforce authentication and authorization at the relevant service boundaries and retain appropriate audit evidence. Review access when roles change and at suitable intervals. Revoke or adjust permissions and credentials when an identity is no longer needed or is compromised. Coordinate these activities across applications, directories, cloud services, and non-human workloads so changes do not leave overlooked access paths.

Three practical examples

Employee onboarding: a new analyst receives access to the reporting tools needed for the role without automatically becoming a database administrator.
Role change: an employee moving from sales to operations has old permissions reviewed instead of simply accumulating a second set.
AI automation: a model-deployment service uses a managed software identity with permissions limited to its release tasks and an accountable owner.

Think of it this way

Think of managing staff badges together with the doors and activities each badge permits, from arrival to departure. Confirming that a badge is genuine does not mean it should open every room. The analogy is limited because digital identities can represent software, operate across organizations, and use tokens or delegated permissions that require lifecycle management beyond one physical badge.

Worked example

In an original simplified example, Lina joins a team and receives permissions to read dataset D and run evaluation job E. She cannot publish a model to production. Later she becomes a release manager, so the organization grants the required publication permission after approval and reviews whether her previous dataset access remains necessary. When she leaves, disabling one central login is checked against application sessions, separate credentials, and local accounts according to the systems in use. The example shows that an IAM change is complete only when the intended effective access has changed, not merely when one directory field has been updated.

Illustrative case study

Fictional example: Alder Models maintains a service account for a nightly evaluation pipeline. The original owner leaves, but the account continues running with broad permissions and no review owner. The team identifies the workload's actual needs, assigns responsibility, and revises its credentials and access through the approved process. This invented case demonstrates that non-human identities need ownership and lifecycle controls even when no person logs in interactively.

Common misconceptions and mistakes

Do not equate successful authentication with permission to perform any action. Do not assume single sign-on removes the need for application-level authorization or automatically closes every session on departure. Avoid sharing one account across unrelated people when individual accountability is required. Also, permissions can accumulate through groups, roles, direct grants, and delegation. An access review must consider effective rights and actual use rather than checking only an account's display name or primary role.

Business use

IAM supports reliable access, smoother onboarding, and clearer responsibility for sensitive operations. For AI systems, include training services, data pipelines, deployment jobs, evaluation tools, and agents that act through connected systems. Define who may approve permissions and what evidence demonstrates they remain needed. Balance strong controls with usable recovery and support so people can complete legitimate work. Track unresolved orphaned identities, excessive privileges, and deprovisioning gaps as concrete operational issues rather than treating IAM as a one-time software purchase.

Check your understanding

A user passes a strong authentication check but requests a dataset outside their role. Should authentication alone permit the download?

Answer: No. Authorization must evaluate whether that identity is allowed to perform the action on the resource. Strong proof of identity does not create missing permission.

Related terms

Provisioning
Least privilege
Service principal
authentication
authorization
identity proofing
deprovisioning
role-based access control

Learn next

map a joiner, role-change, and leaver process for one application. Include both human and software identities. Identify where permissions are approved, enforced, reviewed, and removed, then check whether a change in the authoritative identity source reliably reaches every relevant access path.

Sources

Sources: NIST NCCoE, Identity and Access Management, SP 1800-2 Volume B, https://www.nccoe.nist.gov/publication/1800-2/VolB/ , provisioning and runtime-function excerpts consulted; NIST Digital Identity Guidelines, SP 800-63-4, https://pages.nist.gov/800-63-4/sp800-63.html , scope and authorization-related excerpts consulted; NIST Authentication introduction, https://pages.nist.gov/800-63-4/sp800-63b/introduction/ , definition consulted. Older references embedded in SP 1800-2 are not adopted as current authentication requirements. Examples are original; no particular IAM configuration or vendor feature is asserted.

Previous: Identifier Domain Next: Identity column