Identity management (IDM) establishes who an actor is; access management manages the resources and the conditions under which that actor may access them. Actors are people or IT components such as program code, machines and connected things.

The central question of IAM is "who has access to what?", and it falls apart naturally into two halves:

• Identity management (IDM) answers the who: it establishes and maintains the identity of an actor, so that the system can recognise it again (registration, attributes, authentication).
• Access management answers the what and the under which conditions: it manages the resources (applications, data, systems) and the rules that decide whether a given actor may use them (authorisation, roles, policies).

The word actor (Akteur) is deliberately broader than "user". An actor is anything that requests access: a person, but just as well an IT component such as a script, a service account, a server, a machine on a factory floor or an IoT device. In modern environments the non-human actors often outnumber the human ones, and they need identities, credentials and permissions just like people do.

Tip: IDM without access management gives you a well-known stranger with no permissions; access management without IDM gives you permissions with nobody reliable to attach them to. IAM needs both halves.

Go deeper:

• Identity and access management (Wikipedia) — the two halves of IAM, and how identity management has grown to cover devices, servers and applications.

IAM technology is the set of building blocks (standards, protocols, IT components); IAM processes are what an organisation builds and runs with those blocks to manage identities and access day to day.

IAM can be studied from two sides:

The two depend on each other. A perfectly configured SAML federation is useless if nobody creates the account when a person joins or removes it when they leave; and the best-designed joiner/mover/leaver process still needs a protocol to deliver the result to the applications. In practice most IAM failures (orphaned accounts, permission creep, onboarding delays) are process failures, not protocol failures, which is why the process side deserves its own attention.

Go deeper:

• eCH-0107: design principles for IAM — the Swiss e-government standard that models an IAM landscape as stakeholders, actors, processes and information model, not just protocols (in German).