What Is IAM? Identity and Access Management Explained

TL;DR

• Identity and access management (IAM) is the discipline that decides which identities get access to which resources, under what conditions, and produces the record that proves it.
• Every IAM system has the same four jobs: lifecycle, authentication, authorization, and audit. Everything else, including single sign-on, multi-factor authentication, and federation, sits inside one of them.
• The vocabulary that confuses people (IGA, PAM, CIAM, CIEM, ITDR, IDaaS) describes different slices of the same discipline, not competing products.
• The population has shifted. Machine identities outnumber humans by somewhere between 17 and 144 to 1, depending on what gets counted. In the one survey that separates them out, most are AI agents.
• The hard part is rarely login. It is knowing where an access decision is made, where it is enforced, and whether anyone can explain it six months later.

---

The question that stops an access review

It is never "who can log in?"

It is the one somebody asks halfway through, pointing at a name on a list: why can this person still reach that system? The account works. Nobody in the room approved it. Nobody can say when it was granted, or whether it was ever meant to last this long.

Answering that is supposed to be somebody's job.

Identity and access management (IAM) is the discipline that decides which identities get in and what each one may touch once inside. It also produces the record that answers the question above.

The record is the hard part. Getting someone logged in is a solved problem with good libraries behind it. Explaining, eight months later, why a contractor could still read a customer database is nowhere near solved.

It has also stopped being a question about people. Most of the identities in a modern organization are software, and a growing share of those are AI agents.

The stakes are measurable. The Verizon 2026 Data Breach Investigations Report found credential abuse at some point in 39 percent of breaches, which puts it on top of every other technique in the dataset. The same report puts a clock on it. In 73 percent of ransomware cases, credentials had already leaked in the year before the attack, often through infostealer malware that quietly harvests saved passwords and session cookies. Half of those victims saw the leak within 95 days of the attack, which means the warning usually arrives while there is still time to act.

---

What is identity and access management (IAM)?

Identity and access management is the framework of policies, processes, and technologies that gives verified identities the access they need to do their work, and nothing beyond it.

A definition that short hides the interesting part. Underneath it are four jobs that run in order, each depending on the one before. A system can be strong at one of them and failing at another.

Identity lifecycle. Who exists in the first place. An account is created when someone joins, changed when they move teams, and removed when they leave. This is often called joiner, mover, leaver. Think of a keyring. Every internal move adds a key, and almost nobody is asked to hand the old ones back. That is why the mover step, not the leaver step, is where most organizations quietly accumulate risk.

Authentication. Whether they are who they claim to be. Single sign-on (SSO) lets one login serve many applications. Multi-factor authentication (MFA) adds a second category of proof, such as something you have or something you are, though they do not all resist phishing equally. Passwordless methods based on FIDO2 and WebAuthn replace the shared secret entirely.

Authorization. What they are allowed to do. Role-based access control (RBAC) assigns permissions to roles. Attribute-based access control (ABAC) evaluates properties such as department, region, or data classification. Relationship-based access control (ReBAC) evaluates the connection between an identity and a specific resource, for example whether Alice owns this document.

Audit and governance. Who approved it, and whether anyone can reconstruct the decision later. Decisions are recorded, access is reviewed on a schedule, and conflicts such as one person both raising and approving a payment are detected. This is the layer regulators care about most and engineering teams build last.

Being excellent at authentication and hopeless at audit is a common combination, and it usually surfaces during a review rather than during design.

---

Why identity got bolted on afterwards

There is a reason IAM feels like a layer rather than a foundation. It is one.

In 2005, Kim Cameron, then Microsoft's identity architect, opened his Laws of Identity with a sentence that still explains most of this industry:

The Internet was built without a way to know who and what you are connecting to.

Kim Cameron, The Laws of Identity, 2005

What filled the gap, in his words, was a patchwork of identity one-offs. Two decades later the patchwork is what most organizations actually run. Every SaaS tool arrives with its own user store. Every cloud brings its own permission model. Every acquisition brings a directory nobody wants to touch.

Standards narrowed the gap. Logging in once across many systems, and creating accounts automatically, are largely solved problems now. What no standard settled is what each tool does with an account once it arrives. Every one of them still defines its own roles, so the patchwork moved rather than disappeared.

IAM is the practice of making that patchwork behave like one system. It is less a product you install than a set of decisions you keep making.

---

Authentication vs authorization

These two words get used interchangeably in conversation and they are not the same thing. Authentication is the ID check at the counter, and it happens once. Authorization is the question asked on every transaction afterwards: is this account yours, and is this amount within your limit?

	Authentication (AuthN)	Authorization (AuthZ)
Question answered	Who or what are you?	What are you allowed to do?
What it checks	Passwords, MFA, certificates	Roles, attributes, relationships, context
When it runs	Usually once, at the start of a session	Every time a protected action is attempted
Typical artifact	ID token or SAML assertion, saying who the user is	Access token or policy decision, saying what is allowed
Typical standard	OpenID Connect, SAML 2.0	OAuth 2.0 for API scopes; AuthZEN for decisions, adoption still early
Failure, too permissive	The wrong identity gets in	The right identity reaches the wrong data
Failure, too restrictive	The right identity is locked out	The right identity is blocked from its own work

The permissive failures are the quiet ones. They produce no alert, no failed login, and no anomaly in the sign-in logs, and they look like normal traffic until someone reads the access review. The restrictive failures are loud, which is exactly why they get fixed by granting more access than intended. That is how the quiet failure gets built.

---

Who and what has an identity now

It helps to sort identities into four types. The names vary between platforms, but each type proves itself differently, which is why the distinction is worth keeping.

• Human identities. Employees, contractors, partners, and customers. Customer-facing identity has its own name, CIAM, because the requirements differ: self-registration, consent, scale, and a login page that does not lose you sales.
• Workload identities. Applications, services, scripts, and containers. These authenticate with certificates, client credentials, or workload identity federation rather than passwords.
• Device identities. Laptops, phones, and IoT sensors. Device posture often feeds into the access decision, which is how conditional access policies work.
• Agent identities. AI agents that act autonomously or on behalf of a user. This category barely existed three years ago.

The last three are usually grouped together as non-human identities, or NHI. How far they outnumber humans depends on who is counting, and the answers are far apart. Veza counts 17 per human, Rubrik Zero Labs 45, Palo Alto Networks 109, and Entro Labs 144 in cloud-native environments. Nobody neutral counts them, and the spread comes mostly from what gets counted. Some cover cloud-native environments only and others the whole estate. They also disagree on whether a service account, a certificate, and an API key are three identities or one. What none of them dispute is the direction. Palo Alto's 2026 survey of 2,930 security leaders adds the detail that matters most: 79 of its 109 are AI agents.

Agents break an assumption built into most IAM deployments. A classic access decision has one subject. An agent acting for a user has two: the agent itself and the human it acts for. Both have to be evaluated together, and a token that carries only the agent tells you nothing about tenant, role, or risk. We covered this in detail in why AI agents need fine-grained authorization.

---

The IAM vocabulary map

The acronyms around IAM are not competing categories. They are different slices of the same discipline, and most organizations end up owning several of them.

Term	What it covers	Question it answers	Where you meet it
IAM	The whole discipline	Who gets access to what?	Everywhere
IdM	Identity management, the identity half only	Who exists, and what are their attributes?	Directories, HR sync
IGA	Identity governance and administration	Who approved this, and should they still have it?	Access reviews, audits
FGA	Fine-grained authorization	Can this identity do this specific thing to this specific resource?	Per-record permissions, sharing models
PAM	Privileged access management	Who can act as an administrator, and for how long?	Root, domain admin, DBA accounts
Workforce IAM	Identity and access for employees and contractors	How do the people who work here get in, and lose access when they leave?	Corporate SSO, HR-driven provisioning
CIAM	Customer identity and access management	How do millions of external users register and log in?	Consumer apps, portals
CIEM	Cloud infrastructure entitlement management	Who has effective permissions in the cloud accounts?	AWS, Azure, GCP entitlements
ITDR	Identity threat detection and response	Is an identity being abused right now?	SOC, detection tooling
IDaaS	Identity as a service	A delivery model, not a capability	Vendor-hosted IAM

A practical way to read the table: IAM is the whole discipline, IdM is its identity half, and IGA is its governance layer. FGA, PAM, Workforce IAM, CIAM, and CIEM are all subsets, split by granularity, by risk, by population, and by environment. ITDR watches all of them for abuse. Only IDaaS sits outside that shape, because it describes how IAM is delivered rather than what it does.

One caution, offered freely. New acronyms in this field appear faster than the problems they name, and a fresh three-letter category is often an old capability with a new price. Ask which of the rows above a new one actually replaces.

---

A note on AWS IAM, which is a different thing

Search for "IAM" and half the results describe something else entirely. AWS IAM is Amazon's service for controlling access to AWS resources. It has its own vocabulary: principals, policies, roles, and resource-based permissions. Azure and Google Cloud have equivalents. CIEM tools, from the table above, sit on top of this to work out what those permissions actually add up to.

The distinction matters when you are choosing tools. Cloud provider IAM secures your infrastructure. Enterprise IAM secures your applications and your workforce. They are connected through federation, so an engineer logs in once through the corporate identity provider and assumes a role in AWS. They are not substitutes for each other, and a team that has configured AWS IAM well has not yet solved application access.

That is the vocabulary. If you came here for the definition, you have it now. What follows is what this looks like once you are running it, and it gets more specific from here.

---

The standards you will meet, in one page

The standards below are what let systems from different vendors work together at all. They do not cover the ground evenly.

Standard	What it is for	When you meet it
OpenID Connect (OIDC)	Authentication and identity claims, built on OAuth 2.0	Modern web and mobile login
OAuth 2.0	Delegated authorization for APIs, scopes and access tokens	Any API that accepts a bearer token
OAuth 2.0 Token Exchange	Trading one token for another, carrying delegation in the act claim so a token names both the agent and the user it acts for	Agents and services acting on behalf of a user, cross-domain calls
SAML 2.0	XML-based enterprise federation	Enterprise SSO, older SaaS, government
Kerberos	Ticket-based authentication inside a trusted domain	Active Directory networks, internal services
LDAP	Directory lookups and authentication against a user store, by simple bind or by SASL, which is how Active Directory carries Kerberos	Active Directory, legacy applications
SCIM 2.0	Automated provisioning of users and groups between systems	HR to identity provider to SaaS synchronization
FIDO2 / WebAuthn	Phishing-resistant login with hardware or platform keys, as a second factor or on its own	Passkeys, security keys, biometrics
Shared Signals / CAEP	Security event signals between providers, so a live session can be revoked rather than left to expire	Continuous access evaluation, session revocation on password change or device risk
SPIFFE / SPIRE	Cryptographic identity for workloads, issued and rotated automatically	Kubernetes, service mesh, mTLS between services
XACML 3.0	An XML policy language plus a decision protocol for attribute-based access control	Enterprise ABAC, older policy engines
AuthZEN	Authorization API 1.0, a standard interface between enforcement and decision points	Decoupled policy decisions

Phishing-resistant, in the FIDO2 row, is doing real work. Codes sent by SMS or generated in an authenticator app can be relayed in real time by an attacker sitting between the user and the real login page. A FIDO2 credential resists that, because it is bound to the site it was created for and the private key never leaves the device.

The last row is the one to watch. Authentication has been interoperable for over a decade, so you can swap identity providers without rewriting applications. Authorization is the harder half. XACML 3.0 has been an OASIS standard since 2013, and the family since 2003, so the approach has had more than two decades to become the default. Its XML policies proved hard to write and harder to review, and it stayed a niche choice. AuthZEN, final since January 2026, tries the opposite: standardize only the interface between enforcement and decision points, and leave the policy language to the engines. Whether the engines take it up is the open question.

---

Where IAM breaks

Vendor glossary pages tend to stop at the benefits list. The interesting part is the failure modes, and they are consistent across organizations of very different sizes.

Roles multiply until nobody understands them. Role-based access control is the right starting point and it degrades predictably. Add tenants, regions, and delegation, and role counts grow multiplicatively rather than additively. We wrote about the mechanics in why RBAC breaks down at scale.

Authorization ends up scattered in application code. Login gets centralized in an identity provider. The access rules stay behind in seventeen different services as if statements. No single place can answer what a given user can do, so the answer has to be assembled by reading source code.

Identity silos form wherever systems are added. Clouds, acquisitions, and most applications each keep their own user list, and the lists drift apart.

Accounts outlive their owners. Orphaned accounts and privilege creep are the two findings that show up in almost every access review.

Decisions cannot be explained. An auditor asks why a specific user could approve a specific transaction on a specific date. Answering that from application logs and role assignments takes days, sometimes weeks.

Machine identities are managed by nobody. Service accounts get created during an incident and never removed. AI agents arrive faster still, because spinning one up takes no ticket and no approval. Even at the lowest published ratio of 17 to 1, an unmanaged population of that size is not an edge case.

Four of those six are engineering problems. Silos and orphaned accounts are not: they are one problem seen twice, cause and symptom.

Amin Maalouf, a novelist writing about people rather than systems, described the thing our tools violate every day:

The identity cannot be compartmentalized; it cannot be split in halves or thirds, nor have any clearly defined set of boundaries. I do not have several identities, I only have one, made of all the elements that have shaped its unique proportions.

Amin Maalouf, In the Name of Identity, 1998

Enterprise systems compartmentalize as a matter of routine. One person becomes an HR record, a directory entry, a VPN account, four SaaS logins, and a database user with their initials in it. Each fragment carries its own permissions and its own lifecycle. When that person leaves, the organization removes the fragments it remembers.

Orphaned accounts are not an operational slip. They are what happens when one identity has been split into pieces, and no piece knows about the others.

---

What teams try first, and why it stops working

Almost every organization walks the same path. The path is not wrong. It is just shorter than people expect.

Stage one: each application handles its own login. It works until you have three applications and one user who needs all of them. Password resets and inconsistent session handling drive the change.

Stage two: a central directory, with groups as permissions. LDAP or Active Directory becomes the source of truth. Group membership becomes the way to grant access. This holds well for a single-tenant organization with stable job functions.

Stage three: an identity provider and single sign-on. OIDC and SAML replace bespoke login code. Applications stop storing passwords. MFA gets enforced centrally. The celebration at this point is deserved. It is also early, because this is where many teams believe they are finished.

Stage four: the authorization wall. A customer arrives with delegated administration, where their own admin manages their own users but must never see another tenant. Now the questions get harder. Can this administrator manage that sub-organization? Can this user approve this specific invoice, given its amount and region?

We tried to answer those questions with role names first, on real deployments. It works for a while. Then a tenant dimension multiplies against a region dimension, and the role catalogue turns into something no human reviews honestly.

Nobody decides to build an unreviewable role catalogue. It arrives one reasonable request at a time.

The reason is structural rather than a modelling mistake. A role name is a single string, and it has nowhere to put the resource. Scoping the decision explicitly, rather than encoding scope in names, is what actually holds. We described that approach in tenant boundaries that role names cannot express.

The same lesson shows up at the other end of the scale. When we migrated more than 20 million identities to Keycloak, the volume was an engineering problem with a known shape. The access model underneath was the part that needed redesign, because migrating a broken permission structure faithfully just preserves it.

---

Decision and enforcement: where access is actually decided

Every access check has two separate roles. Something has to decide whether the action is allowed. Something else has to enforce that decision by letting the request through or blocking it. In policy language these are the decision point and the enforcement point. They have formal names. NIST SP 800-162 calls them the Policy Decision Point (PDP) and the Policy Enforcement Point (PEP).

A door with a bouncer is the everyday version. The bouncer enforces. The guest list decides. Trouble starts when the bouncer keeps the list in their head. Now there is nothing to review, no way to change the rules without finding them, and no record of why anyone was turned away.

Most software keeps the list in the bouncer's head. A line of code deep in a service both decides and enforces, which is why authorization logic is so hard to inventory. The decision was never a separate, observable event.

Pull them apart and three things change:

1. The policy becomes readable. Access rules live in one artifact you can review, version, and diff, instead of being distributed across services.
2. The decision becomes an event. Every allow and deny can be logged with its inputs and its reason, which is exactly what an auditor is asking for.
3. The rules can change without a release. Updating who may approve a payment stops being a code change in three services.

This is not just our preference. The Cloud Native Computing Foundation (CNCF) published an Identity and Access Management whitepaper in June 2026. It makes the separation a requirement of its reference architecture rather than an optimization.

The trade-off is real and worth stating. A separate decision point is another component in the request path, so it has to be fast, highly available, and close to the traffic it governs. Teams that put it far away from the request path pay for it in latency and in debugging time.

Enforcement can sit in several places: an SDK inside the application, an API gateway, a service mesh, or a dedicated enforcement point. The right choice depends on how polyglot your services are. What matters is that all of them ask the same decision point and emit the same decision trace. You can see how we approach the decision layer on our advanced authorization page.

If you remember one thing from this article, remember that authentication is a moment and authorization is a continuous decision. The newer work is making authentication continuous too.

---

Choosing a deployment model: SaaS, self-hosted, or open source

There is no universally correct answer here, and the honest comparison includes what each option costs you.

Model	Best for	Where identity data lives	The real cost	Where it hurts
SaaS identity platform	Small to mid-size teams, fast time to value	Vendor infrastructure	Per-user pricing that scales with headcount	Data residency limits, customization limits, migration difficulty
Self-hosted commercial	Regulated enterprises wanting vendor support	Your infrastructure	Licence plus operations	Upgrade cycles tied to the vendor
Open source self-hosted	Sovereignty, air-gapped, deep customization	Your infrastructure	Operations and expertise instead of licence fees	You own uptime, upgrades, and tuning

Keycloak is the best known open-source IAM server. It joined the CNCF as an incubating project in 2023, and it speaks OIDC, OAuth 2.0, and SAML 2.0 out of the box. It removes the licence question entirely and gives you full control over where identity data sits. We wrote a developer's introduction to it if you want the detail.

Keycloak is not only an authentication server. It also ships an authorization layer with resources, scopes, policies, permissions, and its own evaluation engine, which we covered in Keycloak's authorization services. The decision is evaluated by Keycloak itself, which puts the decision point where your identity data lives rather than next to the traffic it governs. That is the trade-off described earlier: it is a real decision point, and where you place it decides your latency and availability story.

It also hands you the operational burden. Starting Keycloak takes minutes. Running it for millions of users, with high availability, database tuning, and a hardened container image, is a different discipline, and that discipline never ends. It is the wrong choice for a small application and a strong one for an organization that already runs infrastructure. Choose it because you need the control, not because it looks free.

---

IAM and compliance: what auditors actually ask

GDPR, ISO 27001, PCI DSS, SOX, HIPAA, NIS2, DORA, and the EU Cyber Resilience Act all impose access control requirements, and the specific wording differs. Underneath, four questions come up in every one of them:

1. Who had access to this system or this data, and during which period?
2. Who approved that access, and on what basis?
3. When was it last reviewed, and by whom?
4. When someone left or changed roles, how quickly was access removed?

Notice that none of these are authentication questions. They are lifecycle, authorization, and audit questions. Strong authentication still matters, and some of these frameworks require it outright, but an organization can have complete MFA coverage and still fail an access review.

MFA coverage may be the most over-reported number in identity security. It is easy to measure, and easy to measure is not the same as important.

Segregation of duties belongs here too. The rule that one person should not both create and approve the same transaction cannot be expressed as a login policy. It is a constraint across permissions, and it needs a governance layer that can see all of them at once.

---

IAM is becoming the control plane

In infrastructure, the control plane is the layer that makes decisions and the data plane is the layer that carries them out. Identity is becoming the control plane for access.

When applications ran in one data centre behind one firewall, the network was the boundary. That boundary is gone. Users work from anywhere, workloads run across several clouds, partners integrate over APIs, and agents make calls at machine speed. Identity is the only boundary that still travels with the request.

That changes the question a security team has to answer. The old question was whether this user should be allowed in. The new one is what this actor may do right now, on this resource, in this tenant, given the current context. The first is a gate. The second is a continuous decision that has to be fast, explainable, and reviewable.

Whoever answers the access question ends up governing everything downstream of it.

---

One test for your own environment

Identity and access management is easy to describe and difficult to hold together, because the parts that fail are rarely the parts that get attention. Login is visible, well-standardized, and well-funded. The permission model underneath it is invisible until an auditor or an incident makes it visible.

Your systems will keep splitting people into fragments, because that is what systems do. The job is making sure something, somewhere, still knows the fragments add up to one person, and can say so out loud when an auditor asks.

Pick one user and one sensitive resource. Then find out how long it takes to answer whether that user can reach it, why, and who decided. If the answer takes more than an afternoon, the gap is in authorization and governance, not authentication.

If you are hitting the authorization wall described above, that is the problem we build for. Talk to us and we will walk through the decision flow on your own access model, not a generic demo.