IAM
In enterprise security, IAM is identity and access management: the systems that establish who or what an identity is, what it may access, and how that access is granted, reviewed and revoked. It covers human and non-human identities alike, and in most estates the non-human ones are now the larger and less governed population.
How it works
Four functions sit under the term and they are bought from different places, which is part of why the picture is rarely complete. Authentication establishes the identity. Authorisation decides what it may reach. Lifecycle management handles joining, moving and leaving, which is where most of the operational risk lives. Governance provides the evidence: who approved this access, when was it last reviewed, and can that be shown to an auditor.
Above those sit two specialisms. Identity governance covers certification campaigns, separation of duties and access requests. Privileged access management covers the accounts that can change the system itself. A regulator or an ISO 27001 or ENS assessor will ask for the governance evidence, not for the authentication design.
What goes wrong
The leaver process is the classic gap and it is still there. Human accounts are disabled reasonably well because somebody notices when a person leaves. What survives is everything else attached to them: the service account they created, the API key in a script, the personal access token in a repository, the third-party application they consented to. Nobody leaves, so nothing is revoked.
The second is the shape of the population. Service accounts, workload identities, API keys, machine credentials and now automated agents outnumber people substantially in a modern estate, and they have no manager, no starter form and no leaving date. That is where compromise happens, and it is why non-human identity is its own discipline rather than a footnote here.
The third is standing privilege. Access granted permanently because it was needed once is the raw material of every attack path we draw, and it accumulates precisely because removing it feels risky and granting it does not.
Where this shows up in an audit
In a cloud engagement we enumerate identities and their effective permissions rather than their assigned policies, since the two differ once inheritance, trust relationships and role assumption are resolved. The finding is usually a chain: this identity can assume that role, which can modify that policy, which grants administration. We also report the accounts nobody could name an owner for, because that list predicts the next incident better than any control gap. This is part of how we test identity and permissions in a cloud estate.