What Is Identity and Access Management (IAM)?

Identity and access management is the discipline of ensuring the right people and systems have the right access to the right resources, and no more. It has become the primary security control surface, because in cloud and remote-working estates there is no network boundary left to defend.

The practical measure of an IAM programme is whether anyone can answer, quickly and accurately, who has access to a given system and why.

The components, and which are usually weakest

Authentication establishes identity and generally receives the most attention. Authorisation determines what that identity may do and is usually less well controlled. Administration covers how access is granted, changed and removed. Audit covers whether anyone can demonstrate what happened.

Administration is where most estates are weakest, and it is unglamorous work: the joiner, mover and leaver processes that determine whether access reflects current reality or a decade of accumulated decisions.

Movers are the gap, not leavers

Most organisations handle departures reasonably well, because there is a defined event and usually a checklist. Internal moves have no such trigger — access for the new role is added because the person cannot work without it, and access for the old role is left because removing it is nobody's task.

The cumulative effect is that long-serving employees are frequently the most over-privileged people in the organisation, holding the combined access of every role they have occupied.

Non-human identities now outnumber people

Service accounts, application identities, workload identities, automation credentials and machine-to-machine integrations typically outnumber human accounts substantially, and they are governed far less rigorously.

They have no manager, no joiner-mover-leaver process, no recertification and frequently no owner. See service accounts — this is where a growing share of real risk now sits.

Federation moved the boundary outward

Most organisations now authenticate to dozens or hundreds of external services through federation, and each one is a place where access exists outside the systems you administer directly. Where federation and automated provisioning are configured, a departure propagates; where an application keeps its own local accounts, it does not.

That second category is larger than most inventories suggest, because applications are frequently adopted by a department without any identity involvement. Establishing which of your business applications are federated, which are provisioned automatically, and which hold independent account stores is usually the fastest route to finding access nobody is managing.

Measuring the programme is worth thinking about early, because the obvious metrics are the least useful. Accounts provisioned and tickets closed describe activity rather than posture. Orphaned account count, time from departure to access removal, proportion of privileged accounts under managed control and proportion of applications federated all say something about whether access reflects reality, and all of them can be produced from data the identity platform already holds.

Where to start

Pick a system holding sensitive data and produce a list of every identity that can reach it, human and non-human, with a justification for each. The difficulty of producing that list is the honest measure of the programme.

See modern approaches to IAM. GuardsArm runs security risk assessments.