IAM and IGA Basics: Identity Management and Governance

Identity is the control plane for almost every access decision an organisation makes. Identity and access management (IAM) decides who or what can get in and what they can do; identity governance and administration (IGA) makes sure those decisions stay correct, justified and provable over time. This guide explains the core concepts in plain English, compares the main authorisation models, and shows how governance has to extend beyond employees to the service accounts, API keys, workloads and AI agents that now make up most of the identity estate.

Key takeaways

IAM enforces access; IGA governs it. IAM authenticates and authorises in real time. IGA manages the lifecycle, the approvals, the reviews and the evidence that show access is appropriate.
Authentication and authorisation are separate problems. Proving who a caller is says nothing about what it should be allowed to do, and most serious access failures are authorisation failures.
No single authorisation model wins. RBAC, ABAC, policy-as-code and ReBAC solve different problems, and mature programmes combine them.
Machines are identities too. Non-human identities (NHIs) need inventory, named owners, lifecycle events and decommissioning just as people do, but human-style access reviews rarely work for them unchanged.
Zero Trust makes identity the perimeter. NIST SP 800-207 treats every access request, from a person or a workload, as something to authenticate and authorise dynamically.

Core concepts: identity, account and credential

Three words are often used interchangeably, and separating them clarifies most IAM discussions.

Identity: the entity itself, and the set of attributes that describe it. For a person, that might be an employee record with a department, manager and job title. For a machine, it might be a payment service, a CI/CD pipeline or an AI agent, described by its owner, purpose, environment and the system it belongs to.
Account: the representation of an identity inside a particular system. One person may hold a directory account, a cloud console account, a database login and a SaaS account. One workload may hold a cloud service account, a Kubernetes service account and an OAuth client registration. Accounts multiply; identities should not.
Credential: what the account presents to prove it is genuine: a password, a passkey, a certificate, an API key, a client secret or a signed token.

The distinction matters because governance happens at the identity level while risk accumulates at the account and credential level. An organisation can have a clean list of employees and still carry many unowned accounts and credentials that nobody can map back to a person or a purpose. That gap is where non-human identities live: service accounts, API keys, OAuth applications, bots, workloads and agents that act without a human at the keyboard. The differences between human and non-human identities shape every control discussed below.

Authentication versus authorisation

Authentication answers “is this caller who it claims to be?” Authorisation answers “is this caller allowed to perform this action on this resource, now?” They are separate steps, performed by separate components, and they fail in different ways. Weak authentication lets an attacker become someone else. Weak authorisation lets a legitimate caller, or an attacker holding a legitimate credential, do far more than intended.

For people, authentication usually combines a password or passkey with a second factor. NIST SP 800-63-4, Digital Identity Guidelines, sets out requirements for identity proofing, authentication and federation of users. Machines cannot answer a prompt, so they authenticate by presenting a key, secret, token or certificate; the NHI Authentication Guide covers those methods in depth. Either way, authentication only establishes identity. Every subsequent request still needs an authorisation decision.

Directories, identity providers and federation

A directory is the authoritative store of identities, attributes and group memberships. An identity provider (IdP) authenticates users and issues assertions or tokens that other applications trust. Cloud platforms such as Microsoft Entra ID, AWS IAM and Google Cloud IAM each govern their own resources, so most organisations run several identity stores at once.

Federation lets one system trust identities asserted by another. Single sign-on (SSO) is the user-facing result: one authentication at the IdP grants access to many applications. OpenID Connect Core 1.0 describes itself as a simple identity layer on top of OAuth 2.0 and is the common modern protocol for federated sign-in. Federation also applies to machines: workload identity federation lets a pipeline or workload exchange a platform-issued token for cloud access without holding a stored key.

The identity lifecycle

Every identity, human or machine, passes through the same broad stages: request or creation, provisioning of accounts and entitlements, use, change as responsibilities or code change, periodic review, and deprovisioning. For people, HR events usually drive the lifecycle. For machines, nothing drives it by default: a service account created during a project often outlives the project, the team and the person who created it. The Ultimate Guide describes the lifecycle processes for managing NHIs, and governance is largely the discipline of making each stage happen on purpose.

Authorisation models compared

An authorisation model is the logic used to decide whether a request is allowed. Four models dominate current practice.

Model	How decisions are made	Strengths	Weaknesses	Typical fit
RBAC (role-based)	Permissions are grouped into roles; identities are assigned roles.	Easy to understand, audit and certify; maps well to job functions.	Coarse; role explosion as exceptions accumulate; weak at context such as time, location or data sensitivity.	Workforce access to business applications; cloud platform roles.
ABAC (attribute-based)	Policies evaluate attributes of the subject, the object, the operation and the environment.	Fine-grained and contextual; fewer roles to maintain.	Depends on accurate, trusted attributes; policies are harder to review and test.	Data access, multi-tenant systems, context-aware controls.
PBAC / policy-as-code	Rules are written in a policy language, versioned like code and evaluated by a policy engine separate from the application.	Consistent decisions across services; testable, reviewable, auditable in version control.	Needs engineering discipline; policy sprawl if ownership is unclear.	Microservices, Kubernetes admission, API gateways, infrastructure guardrails.
ReBAC (relationship-based)	Access follows relationships between subjects and resources, such as owner, member or parent folder.	Natural for sharing and hierarchies; scales to large numbers of objects.	Relationship graphs are hard to review; requires a dedicated authorisation service.	Collaboration platforms, document sharing, multi-tenant SaaS.

RBAC

Role-based access control is the model most IAM and IGA programmes start with. NIST’s Role Based Access Control project notes that its RBAC model was adopted as the American National Standard ANSI/INCITS 359. RBAC works well when job functions are stable. Its classic failure is role explosion: each exception becomes a new role until nobody can explain them and certification becomes a rubber stamp. Role mining, role owners and periodic role reviews are the countermeasures.

ABAC

NIST SP 800-162 defines attribute-based access control as a methodology where authorisation is determined by evaluating attributes of the subject, the object, the requested operations and, in some cases, environment conditions against policy. ABAC reduces role count but moves the risk to attribute quality: if a department attribute or classification tag is wrong, every dependent policy is wrong too, so attribute sources need owners of their own.

Policy-as-code and PBAC

“Policy-based access control” is used loosely across the industry; the useful idea underneath it is that policy should live outside application code, in a form that can be versioned, tested and reviewed. The Open Policy Agent documentation describes a general-purpose policy engine, a graduated CNCF project, that decouples policy decision-making from policy enforcement: software queries the engine with structured input and receives a decision. Policy-as-code often carries ABAC logic, and it gives auditors something concrete to inspect: the policy itself and its change history.

ReBAC

The OWASP Authorization Cheat Sheet describes ReBAC as granting access based on relationships between resources, for example allowing only the user who created a post to edit it, and recommends that ABAC and ReBAC should typically be preferred over RBAC for application development. OpenFGA, a CNCF project inspired by Google’s Zanzibar system, is one open-source implementation of this approach.

Principles that apply to every model

Least privilege: grant only the permissions needed for the task, for only as long as needed. The OWASP cheat sheet also warns about privilege creep, where access accumulates as people and systems change.
Deny by default: access should require an explicit permit, not the absence of a deny.
Check on every request: authorisation must be enforced consistently, not only at login or at the user interface.
Separation of duties (SoD): no single identity should be able to complete a sensitive process end to end, such as creating a supplier and approving payment to it. NIST SP 800-53 Revision 5 includes Separation of Duties (AC-5) and Least Privilege (AC-6) in its Access Control family.

IAM, IGA, PAM and CIAM: what each does

These four disciplines overlap in tooling but answer different questions.

Discipline	Core question	Main functions	Typical identities in scope
IAM (identity and access management)	Who or what is this, and may it do this now?	Directories, authentication, SSO, federation, MFA, runtime authorisation.	Employees, contractors, applications, workloads.
IGA (identity governance and administration)	Should this identity have this access, who approved it, and can we prove it?	Lifecycle provisioning, access requests, entitlement catalogue, certifications, SoD policy, audit reporting.	Workforce identities, and increasingly service accounts and other NHIs.
PAM (privileged access management)	How do we control and monitor the most powerful access?	Credential vaulting, just-in-time elevation, session brokering and recording, admin account control.	Administrators, break-glass accounts, privileged service accounts.
CIAM (customer identity and access management)	How do customers sign up and sign in safely at scale?	Self-registration, social and passwordless login, consent and profile management, fraud controls.	Customers, partners, consumers.

For deeper treatment of the first and third rows, see the Workforce Identity Security Guide and the Privileged Access Management Guide. The practical point is that IAM without IGA drifts: access is enforced correctly, but nobody knows whether the access being enforced is still right.

Core IGA processes

Joiner, mover, leaver provisioning

The joiner-mover-leaver (JML) model ties access to lifecycle events. A joiner receives baseline (“birthright”) access from an authoritative source such as the HR system. A mover gains access for the new role and, critically, loses access from the old one; failing to remove old access on transfer is one of the most common sources of privilege creep. A leaver has all accounts disabled and credentials revoked promptly. Automated provisioning connectors, often using the SCIM protocol (RFC 7644), push these changes to target applications. NIST SP 800-53 Account Management (AC-2) expects organisations to be notified when accounts are no longer required or when users are terminated or transferred.

Access requests and approvals

Anything beyond birthright access should be requested, justified and approved by someone who understands the resource (usually its owner, not just the requester’s manager), ideally as a time-bound grant that expires automatically. Every approval becomes audit evidence.

Entitlement management

An entitlement is a specific permission in a specific system: a group membership, an application role, a cloud policy attachment, a database grant. Entitlement management builds a catalogue that describes each one in business language, with an owner and a risk rating. Without it, approvers and reviewers judge access they cannot understand.

Access certification and reviews

Periodic access certifications ask managers or resource owners to confirm that each identity’s access is still needed. AC-2 in NIST SP 800-53 includes reviewing accounts for compliance with account management requirements at an organisation-defined frequency. Reviews work best when they are risk-based (privileged and sensitive access reviewed more often), event-driven as well as scheduled, and enriched with usage data so reviewers can see which entitlements have not been used.

Segregation of duties

SoD policies define toxic combinations of entitlements. IGA tools check requests against those rules before approval (preventive) and scan existing access for violations (detective). Where a violation must be accepted, it should be recorded as a time-limited exception with a named approver and a compensating control.

Orphaned and dormant accounts

An orphaned account is one with no valid owner: its person has left, or its creator has moved on and nobody has taken responsibility. A dormant account still exists but is not used. Both are attractive to attackers because nobody notices when they start being used again. The Cloudflare breach is an instructive example: credentials believed to be unused were missed during rotation after the Okta compromise, and attackers used them to reach internal systems.

Audit evidence

Governance must be provable: lifecycle records, approval trails, completed certifications, SoD exceptions, and proof that revoked access actually disappeared from target systems. The regulatory and audit perspectives section of the Ultimate Guide explains how auditors increasingly expect the same evidence for machine identities.

Extending IGA to non-human identities

Most IGA programmes were designed around the HR record. Non-human identities do not have one, which is why they so often sit outside governance entirely. The Ultimate Guide’s key challenges and risks and the Top 10 NHI issues both point to the same gaps: incomplete inventory, missing ownership, stale accounts, excessive privilege and credentials that are never rotated. Industry research such as The Critical Gaps in Machine Identity Management also identifies unclear ownership and limited visibility as barriers to auditing machine identities.

Inventory

NHIs are spread across cloud IAM, Kubernetes, SaaS OAuth grants, CI/CD systems, directories, databases and secrets managers. For each one, the inventory should record the platform, credential types, permissions, last use and connections. Discovery must be continuous, because automation creates new NHIs constantly.

Ownership

Every NHI needs a named human or team owner accountable for its purpose, permissions and retirement, recorded at creation and reassigned automatically when the owner leaves. An NHI without an owner is, by definition, an orphaned account.

Lifecycle

Machine lifecycle events come from engineering, not HR: a service is deployed, an integration approved, a pipeline retired, a vendor contract ended. Governance hooks into those events so NHIs are created, changed and retired through a controlled path. The NHI Lifecycle Management Guide sets out the processes, from provisioning and discovery through classification, posture management and decommissioning.

Why human-style access reviews fail for machines

A quarterly campaign asking line managers to certify service accounts rarely produces a meaningful decision, for structural reasons:

The reviewer cannot judge the access. A manager can say whether an analyst needs the finance application; few can say whether a deployment role needs a particular storage permission.
Revocation fear. Removing access from a machine may break production, so reviewers approve everything.
Scale and churn. Machine identities are created and destroyed far faster than a periodic campaign can track.
Credentials matter as much as entitlements. A review of permissions says nothing about whether the key has leaked, is shared across applications or has never been rotated.

What works better is evidence-driven review sent to the technical owner: actual usage compared with granted permissions, last-used timestamps, credential age and exposure, and where the credential is stored. Unused permissions can then be removed with data rather than guesswork, and review frequency can follow risk. Third-party OAuth grants deserve particular attention; the Salesloft Drift OAuth token breach showed how tokens issued to an integration can be reused to reach connected customer environments.

Human use of machine identities

When people borrow service account credentials to bypass MFA or approval workflows, accountability disappears. OWASP lists this as NHI10:2025 Human Use of NHI, alongside NHI1 Improper Offboarding and NHI5 Overprivileged NHI. The Okta support system breach began with service account credentials that had been saved in an employee’s personal Google account, a reminder that governance must cover where credentials live, not only what they can do.

Rotation and decommissioning

Rotation limits how long a stolen credential stays useful, but it is operationally hard because dependencies are often unknown; the guide to NHI rotation challenges explains why. The stronger long-term move is replacing static secrets with dynamic, short-lived ones, so that expiry becomes the default. Decommissioning must be complete: disable the identity, revoke every credential and token, remove its entitlements and trust relationships, and confirm nothing still authenticates with it. The Internet Archive breach shows the cost of a token that stayed valid and unrotated in a configuration file, and the Microsoft Midnight Blizzard breach began with a legacy, non-production test tenant account without MFA, exactly the kind of forgotten identity that decommissioning should catch.

Zero Trust and identity

NIST SP 800-207, Zero Trust Architecture, assumes there is no implicit trust granted to assets or user accounts based solely on their physical or network location. Its tenets include granting access to individual resources on a per-session basis, determining access by dynamic policy, and enforcing all resource authentication and authorisation dynamically and strictly before access is allowed. The standard’s notion of a “subject” explicitly includes applications and other non-human entities, not just end users.

This makes IAM and IGA the foundation of Zero Trust. The policy decision point needs trustworthy identity and attribute data, which IGA supplies and keeps current. Per-session decisions favour short-lived tokens and just-in-time access over standing entitlements. Workloads need verifiable identities issued by the platform rather than copied static secrets, which is the purpose of frameworks such as SPIFFE and SPIRE. And monitoring of identity behaviour should feed back into policy, so unusual use of a credential triggers a fresh decision.

Metrics a programme can track

Track these metric types separately for human and non-human identities, because the baselines differ.

Coverage: applications connected to IGA; NHIs in the inventory; NHIs with a named, current owner.
Hygiene: orphaned, dormant and shared accounts; entitlements unused over a defined window; credentials past their rotation policy.
Lifecycle speed: time from leaver event or NHI retirement to full revocation; time to fulfil access requests.
Review quality: completion and revocation rates per campaign (a revocation rate near zero often signals rubber-stamping), and reviews supported by usage data.
Policy and risk: open SoD violations and exceptions, standing privileged entitlements, and secrets detected in code or tickets.

Maturity models can help set direction; the Machine-to-Machine Identity Maturity Model describes stages from basic to state-of-the-art for machine authentication practices.

Common failure patterns

Governance stops at the HR feed. Employees are well governed, while service accounts, API keys and OAuth apps are invisible to IGA.
Movers keep old access. Transfers add entitlements without removing previous ones, and privilege creep compounds over years.
Role explosion. Roles multiply to handle exceptions until nobody understands them, and certifications become meaningless.
Rubber-stamp reviews. Reviewers approve everything because they lack context or fear breaking something.
Deprovisioning that disables but does not revoke. An account is disabled in the directory, but tokens, keys and OAuth grants in downstream systems stay valid.
Shared and reused credentials. One secret serves several applications or environments, so it can never be safely rotated or attributed.
Authorisation enforced only at the edge. The gateway checks access, but internal services trust any caller that reaches them.

Practitioner checklist

Drive lifecycle events from authoritative sources (HR for people, service catalogues or deployment systems for machines), and remove old access on transfer.
Build an entitlement catalogue with business descriptions, owners and risk ratings.
Choose authorisation models deliberately: RBAC for stable job functions, ABAC or policy-as-code for context, ReBAC for sharing and hierarchies.
Enforce least privilege, deny by default and SoD rules, and check authorisation on every request.
Run risk-based, usage-informed access reviews, and measure revocation rates.
Build and continuously refresh an inventory of every NHI across cloud, SaaS, Kubernetes, CI/CD and directories.
Assign a named owner to every NHI and reassign automatically when owners leave.
Review NHIs with technical owners using usage, credential age and exposure data rather than manager campaigns.
Prohibit human use of service account credentials and monitor for it.
Replace static secrets with short-lived, platform-issued credentials where possible, and automate rotation where not.
Decommission completely: revoke credentials, tokens and trust relationships, then verify nothing still authenticates.
Keep audit evidence for people and machines: approvals, reviews, exceptions and proof of remediation.

IAM and IGA Basics