What is identity governance and administration?
Identity governance and administration (IGA) is the discipline of ensuring that the right identities — people, and increasingly machines and agents — have the right access to the right resources, and that this can be proven to an auditor. It joins two things that are often run separately: administration (provisioning and de-provisioning accounts and entitlements) and governance (deciding whether that access should exist and evidencing the decision).
What does IGA actually cover?
A working IGA program spans the access lifecycle:
- Joiner-mover-leaver (JML) — access granted on hire, adjusted on role change, and — critically — revoked on departure.
- Access reviews and certification — periodic attestation by managers and resource owners that standing access is still warranted.
- Role and entitlement management — grouping fine-grained permissions into roles so access is granted by intent, not by hand.
- Segregation of duties (SoD) — preventing toxic combinations of access (the person who creates a vendor should not also approve its payments).
- Audit and evidence — a defensible record of who had what access, when, and on whose authority.
Why is IGA hard at scale?
IGA is hard because access entropy is constant. People change roles and accumulate entitlements they no longer need (“privilege creep”); leavers slip through manual off-boarding; reviewers rubber-stamp certifications they do not understand; and non-human identities — service accounts, machine identities, and agents — now proliferate, often with weaker lifecycle control than human accounts. The result is a gap between the access that exists and the access that should exist — and that gap is exactly what an attacker or an auditor finds first.
What does a defensible IGA program produce?
The output of good IGA is not a dashboard — it is evidence. A defensible program can answer, for any resource and any point in time, who had access, why, who approved it, and when it was removed, without a fire drill. That last property — producing the answer on demand rather than reconstructing it under deadline — is the line between a program that passes an audit and one that survives an incident.
Access is one half of the Cloud Identity & FinOps question. A closely related primitive is how you protect the credentials that grant that access — see secrets management.