The complete guide to IAM.
A practitioner pillar covering all of identity and access management — authentication, authorization, IGA, PAM, the standards, compliance, and how to run a program. Updated 2026.
Contents · 8 chapters
- 01What IAM isIdentity and Access Management (IAM) is the discipline of ensuring the right identities have the right access to the right resources at the right time — and that you can prove it.
- 02AuthenticationAuthentication proves that an identity is who it claims to be. In 2026, the baseline is phishing-resistant MFA; the frontier is passwordless via passkeys.
- 03AuthorizationAuthorization decides what an authenticated identity may do. The models — RBAC, ABAC, ReBAC — and the shift toward externalized policy-as-code.
- 04Identity governance (IGA)Identity Governance and Administration manages the lifecycle of identities and access — joiner/mover/leaver, access certification, and segregation of duties.
- 05Privileged access (PAM)Privileged Access Management controls the small set of accounts that can change the system. The destination is zero standing privilege.
- 06The standardsThe protocols that make IAM interoperable — OAuth 2.1, OIDC, SAML 2.0, SCIM, FIDO2 — and when each applies.
- 07ComplianceThe regulatory frameworks that shape IAM controls — and how their identity requirements converge.
- 08Running an IAM programMaturity, evidence, operational resilience, and the patterns that separate programs that scale from programs that stall.
What IAM is.
Identity and Access Management (IAM) is the discipline of ensuring the right identities have the right access to the right resources at the right time — and that you can prove it.
A working definition
Identity and Access Management (IAM) is the set of policies, processes, and technologies that ensure the right identities — humans, services, and increasingly AI agents — have the right access to the right resources at the right time, with an auditable record of why.
That one sentence carries four obligations: authentication (proving who an identity is), authorization (deciding what it may do), administration (managing the lifecycle of identities and their access), and audit (proving the first three operated correctly). Every IAM program is an attempt to satisfy those four obligations at scale, under regulation, without slowing the business down.
- Authentication — proving identity (passwords, MFA, passkeys, certificates).
- Authorization — deciding access (RBAC, ABAC, ReBAC, policy-as-code).
- Administration — managing the lifecycle (joiner / mover / leaver, provisioning, certification).
- Audit — proving it worked (evidence, logs, attestation, certification history).
The four identity planes
Modern IAM operates across four planes, each with its own tooling, threat model, and regulatory exposure. Workforce identity covers employees and contractors. Customer identity (CIAM) covers the people who use your product. Privileged identity covers the small set of accounts that can change the system itself. And machine / workload identity covers the services, pipelines, and agents that authenticate without a human present.
Most programs are strong on one or two planes and weak on the rest. The mark of a mature program is that all four planes are governed with the same rigor — same lifecycle, same audit trail, same revocation guarantees.
Authentication.
Authentication proves that an identity is who it claims to be. In 2026, the baseline is phishing-resistant MFA; the frontier is passwordless via passkeys.
Factors and assurance levels
Authentication factors fall into three classes: something you know (passwords), something you have (a phone, a security key), and something you are (biometrics). Multi-factor authentication (MFA) combines two or more classes. NIST 800-63B defines authenticator assurance levels (AAL1, AAL2, AAL3) that map factor strength to risk.
Not all MFA is equal. SMS-based MFA is vulnerable to SIM swap. Push-based MFA is vulnerable to MFA bombing. Phishing-resistant MFA — FIDO2 security keys and passkeys — resists both, because the credential is cryptographically bound to the origin and cannot be replayed against a phishing site.
- AAL1 — single factor; acceptable only for low-risk.
- AAL2 — two factors; the workforce baseline.
- AAL3 — hardware-backed, phishing-resistant; required for privileged + high-risk transactions.
The move to passwordless
Passkeys — discoverable FIDO2 credentials synced across a user's devices — are the 2026 destination for both workforce and customer authentication. They remove the password as a shared secret entirely, which removes the entire class of credential-stuffing and phishing attacks that account for the majority of identity-vector breaches.
The migration is incremental: most programs run passkeys alongside existing factors, drive enrollment, then retire the password as a primary factor once coverage is high. The hard part is rarely the technology; it is the enrollment UX and the account-recovery flow.
Authorization.
Authorization decides what an authenticated identity may do. The models — RBAC, ABAC, ReBAC — and the shift toward externalized policy-as-code.
RBAC, ABAC, and ReBAC
Role-based access control (RBAC) grants access through roles. It is the workhorse of enterprise IAM because it maps cleanly to org structure and is auditable. Its weakness is role explosion: as exceptions accumulate, the role model drifts from reality.
Attribute-based access control (ABAC) grants access by evaluating attributes — of the user, the resource, and the environment — at request time. It is more expressive than RBAC but harder to audit. Relationship-based access control (ReBAC), popularized by Google's Zanzibar, models access as a graph of relationships and answers "can user X do Y to resource Z?" at scale; it is the model behind most modern fine-grained authorization systems.
- RBAC — roles → permissions. Best for org-aligned, auditable access.
- ABAC — attributes → decisions. Best for dynamic, context-sensitive access.
- ReBAC — relationships → decisions. Best for fine-grained, resource-level access at scale.
Externalized policy-as-code
The 2026 pattern is to externalize authorization decisions from application code into a policy engine — Open Policy Agent (OPA) with Rego, AWS Cedar, or a Zanzibar-style system like SpiceDB. The application asks a policy decision point (PDP) "is this allowed?" and the PDP answers based on policy that lives, versioned, outside the app.
This separates the people who write policy from the people who write features, makes authorization testable in isolation, and gives auditors a single place to read the rules.
Identity governance (IGA).
Identity Governance and Administration manages the lifecycle of identities and access — joiner/mover/leaver, access certification, and segregation of duties.
Joiner, mover, leaver
The joiner / mover / leaver (JML) lifecycle is the spine of IGA. When someone joins, access is provisioned to match their role. When they move, access is recalculated. When they leave, access is revoked — fully and quickly. Manual JML is where most audit findings live, because manual processes leave residual access behind.
Mature programs automate JML from an authoritative source (usually the HR system), provisioning through SCIM or vendor connectors, with the leaver path being the most security-critical: a departed employee whose access lingers is a standing risk.
Access certification + segregation of duties
Access certification (or attestation) is the periodic review where managers confirm that the access their people hold is still appropriate. Done badly, it is rubber-stamp theater. Done well, it is policy-defined, recommender-assisted, and exception-focused — reviewers see only what looks anomalous.
Segregation of duties (SoD) prevents one identity from holding a toxic combination of permissions (e.g., creating a vendor and approving its payments). SoD policy is foundational to SOX-defensible IGA.
Privileged access (PAM).
Privileged Access Management controls the small set of accounts that can change the system. The destination is zero standing privilege.
Vaulting, session control, and JIT
PAM starts by vaulting privileged credentials so no human knows the password directly. It adds session control — recording, monitoring, and the ability to terminate privileged sessions. And it moves toward just-in-time (JIT) access, where privilege is granted for a specific task and expires automatically.
The end state is zero standing privilege (ZSP): no account holds privilege at rest. Privilege is requested, justified, granted for a window, and revoked. ZSP shrinks the attack surface to near-zero between privileged operations.
- Vault — no human holds the privileged credential directly.
- Session control — record, monitor, terminate.
- JIT — privilege granted per-task, time-boxed.
- ZSP — no standing privilege at rest.
The standards.
The protocols that make IAM interoperable — OAuth 2.1, OIDC, SAML 2.0, SCIM, FIDO2 — and when each applies.
Federation: OIDC and SAML
Single sign-on relies on federation: one identity provider (IdP) asserts identity to many service providers. SAML 2.0 is the mature enterprise standard, XML-based, still dominant in B2B and legacy enterprise SSO. OpenID Connect (OIDC) is the modern identity layer on top of OAuth 2.0, JSON-based, the default for new builds and anything mobile or API-first.
In 2026 the rule of thumb: greenfield goes OIDC; SAML persists where the integration already exists and the renewal cost is high. Both will coexist for years.
Authorization + provisioning: OAuth 2.1 and SCIM
OAuth 2.1 is the consolidated authorization framework — PKCE everywhere, no implicit flow, sender-constrained tokens via DPoP and mTLS as the modern default. SCIM 2.0 is the provisioning standard that automates joiner/mover/leaver across systems via a common REST + JSON schema.
Together they cover the two machine-to-machine concerns: who is allowed to call this API (OAuth) and how do user accounts stay in sync across systems (SCIM).
Compliance.
The regulatory frameworks that shape IAM controls — and how their identity requirements converge.
The frameworks converge
NIST 800-53, ISO 27001, SOC 2, FFIEC, NYDFS Part 500, FedRAMP, DORA, HIPAA, PCI-DSS, and GDPR all impose identity controls. The good news for practitioners: the controls converge. Strong authentication, least-privilege access, periodic access review, privileged-access governance, and evidence of all of it satisfy most regulators simultaneously.
The practitioner question is rarely "which framework?" but "given that I must satisfy three of these, what is the minimum control set?" Build the control once; map the evidence to each framework.
Running an IAM program.
Maturity, evidence, operational resilience, and the patterns that separate programs that scale from programs that stall.
Maturity and evidence
IAM maturity is a journey from ad-hoc to optimized across the four obligations. The programs that scale treat evidence as a first-class product — versioned, dated, owned, retrievable for any historical date — rather than as an audit-cycle scramble.
They also resist role-model drift, ruthlessly retire legacy patterns (legacy MFA, deprecated flows, stale federation trusts), and define operational-resilience targets (RTO, RPO) for the IdP as a critical dependency.
The 2026 frontier
Two forces define the IAM frontier in 2026. First, identity threat detection and response (ITDR) — treating identity as a detection surface, not just a control. Second, AI agents as a new identity class — autonomous systems acting on behalf of humans that need their own primitives: short-lived, scoped, delegated, auditable.
Programs that build for both now — ITDR coverage and agent-aware identity — will be in far better shape as the threat model and the regulation harden over the next 24 months.
Common questions.
What is the difference between IAM and IGA?+
IAM (Identity and Access Management) is the whole discipline — authentication, authorization, administration, and audit across all identity types. IGA (Identity Governance and Administration) is the subset focused on the lifecycle and governance of identities and their access: joiner/mover/leaver automation, access certification, and segregation of duties. Every IGA program is part of IAM; not all IAM is IGA.
What is the difference between authentication and authorization?+
Authentication proves who an identity is (login, MFA, passkey). Authorization decides what that authenticated identity is allowed to do (roles, attributes, policy). Authentication happens first; authorization happens on every subsequent access decision.
Do I need PAM if I already have MFA on admin accounts?+
Yes. MFA proves the admin is who they claim to be; PAM controls what happens after — vaulting the credential so no human holds it directly, recording the privileged session, and ideally granting privilege just-in-time so it does not exist at rest. MFA and PAM solve different problems.
Is SAML dead in 2026?+
No. OIDC is the default for new builds, but SAML 2.0 remains dominant in established enterprise B2B SSO where the integration already exists and the renewal cost is high. Both will coexist for years. Greenfield goes OIDC; existing SAML persists until there is a reason to migrate.
What is the single highest-leverage IAM control to implement first?+
Phishing-resistant MFA on privileged accounts. It is cheap to implement, materially reduces breach risk, and is increasingly a finding-by-default at examinations if absent. After that: service-account vaulting and joiner/mover/leaver automation.
Turning the guide into a program?
We ship audit-defensible IAM programs across all four planes — workforce, customer, privileged, and machine. Two-week diagnostic; same engineers through handoff.