Identity and access management (IAM) is the discipline (and the set of technologies) that ensures the right identities have the right access to the right resources at the right time, and that everything they do can be accounted for. It spans authentication (proving who someone is), authorization (deciding what they can do), and the full lifecycle of an account from creation to removal.

Every security program leans on IAM, whether it says so or not. If you can’t reliably answer "who is this and what are they allowed to touch," almost nothing else in your security program holds up.

The building blocks of IAM

Most IAM programs rest on a handful of primitives:

• Identification, the claim of an identity (a username, an email, an employee ID).
• Authentication: proving that claim with factors: something you know, have, or are.
• Authorization, mapping the authenticated identity to permissions, often through roles (RBAC) or attributes (ABAC).
• Lifecycle management: provisioning accounts when people join, adjusting access when they change roles, and deprovisioning promptly when they leave.
• Auditing and governance, the logs and reviews that prove access is appropriate, which auditors and regulators require.

Workforce IAM versus customer IAM

The word "IAM" gets stretched to cover two jobs that pull in opposite directions. Workforce IAM governs a known population (employees, contractors, service accounts) and its north star is control: least privilege, segregation of duties, clean audit trails. You can compel an employee to enroll in MFA and use a managed device.

Customer-facing identity (CIAM) inverts several of those assumptions. The population is anonymous and enormous, you can’t mandate anyone’s security posture, and a clumsy login directly costs revenue. That’s why treating customers with a workforce IAM tool tends to break down: it wasn’t built for the scale, the experience bar, or the fraud pressure. Understanding IAM well is the fastest way to understand why CIAM had to become its own category.

Where IAM is heading

Two shifts matter. First, the perimeter dissolved; identity became the primary control plane, which is the core premise of zero trust, verify explicitly, every time, rather than trusting a network location. Second, non-human identities (services, workloads, and now AI agents) are exploding in number and often outnumber human accounts, which stretches classic IAM assumptions about how identity is provisioned, scoped, and revoked.

The identity lifecycle in IAM: joiner, mover, leaver

Much of the day-to-day work of IAM is captured in three moments, often shortened to JML. A joiner needs the right access provisioned quickly so they’re productive on day one, no more, no less. A mover changes role, and their access must change with them; the classic failure here is "privilege creep," where people accumulate entitlements across roles and never shed the old ones. A leaver must be deprovisioned promptly, because orphaned accounts (still active after someone has gone) are a favorite foothold for attackers. Automating JML through a connection to the HR system is what keeps access accurate at scale; doing it by hand is where errors and audit findings pile up.

IAM and zero trust

The old security model trusted anything inside the network perimeter. That model broke as work went remote, apps moved to the cloud, and breaches routinely originated inside the "trusted" zone. Zero trust replaces location-based trust with identity-based verification: every access request is authenticated, authorized, and evaluated for risk, every time, regardless of where it comes from. That makes IAM the backbone of a zero-trust architecture: identity becomes the new perimeter. In practice it means strong, ideally phishing-resistant authentication, least-privilege authorization enforced per request, and continuous evaluation rather than a single gate at login.

Privileged and non-human identities

Two categories deserve special care. Privileged accounts (administrators, root access) are high-value targets, which is why privileged access management (PAM) layers on extra controls: tighter monitoring, just-in-time elevation, and session recording. And non-human identities (service accounts, API keys, workloads, and increasingly AI agents) now vastly outnumber human ones in many organizations. They authenticate with secrets and certificates rather than passwords, and a leaked or over-privileged machine credential can be as damaging as a compromised human account. Managing their lifecycle, scoping their access tightly, and rotating their credentials has become a fast-growing part of modern IAM.

Frequently asked questions

What are the core functions of IAM?

Authentication, authorization, identity lifecycle management (provisioning and deprovisioning), and auditing/governance.

What’s the difference between authentication and authorization?

Authentication proves who you are; authorization decides what you’re allowed to do.

Is IAM the same as CIAM?

No: IAM traditionally secures the workforce and internal systems, while CIAM secures external customers with a very different emphasis on scale, experience, and fraud.

What is RBAC in IAM?

Role-based access control assigns permissions to roles rather than individuals, so access is granted by job function.

What is JML in IAM?

The joiner-mover-leaver lifecycle: provisioning access when people join, adjusting it when they change roles, and removing it promptly when they leave.

How does IAM relate to zero trust?

Identity becomes the control plane: zero trust verifies every request by identity and risk instead of trusting a network location, making IAM its foundation.

Related: CIAM · IAM vs. CIAM · Authentication vs. Authorization · Single Sign-On (SSO) · Authorization · Zero Trust