What Is IGA? Identity Governance and Administration

Pull the access report for any system that has been running for five years and you will find the same thing. Accounts for people who left in 2022. A marketing analyst who still has the finance permissions from a project that ended last spring. A service account that nobody can name, with admin rights, last used eight months ago. None of this is an attack. It is the residue of access granted correctly, then never revisited. Identity governance and administration is the discipline that exists to stop that residue from accumulating, and to prove, on demand, that it has not.

Identity governance and administration (IGA) is the framework for managing digital identities and their access across their entire lifecycle, and for governing that access so it stays appropriate, least-privilege, and auditable. It answers a different question than the login system does. The login system asks "can this person get in?" IGA asks "should this person still have this access at all, and can we prove who approved it?" This guide covers what IGA is, the identity lifecycle it manages, its core capabilities (access requests, role management, access certification, segregation of duties, policy and reporting), how it differs from IAM, the compliance pressure that drives it, and why it matters to a defender reading logs after an incident.

What is identity governance and administration (IGA)?

Identity governance and administration is the combination of two things the name spells out. Administration is the operational side: creating accounts, granting and removing access, fulfilling requests, keeping entitlement data accurate. Governance is the control side: defining policy for who may have what, reviewing access to confirm it is still justified, enforcing separation of duties, and producing the evidence that all of this happened. IGA is the layer that ties the two together so that every entitlement in the environment has an owner, a reason, and a record.

The unit IGA works on is the entitlement: a specific permission to a specific resource, like membership in a Active Directory security group, a role in an ERP system, or a policy attached to a cloud account. A single employee accumulates dozens or hundreds of these across the systems they touch. IGA's job is to keep the full set correct as the person joins, changes roles, and eventually leaves, and to answer two questions at any moment: who has access to what, and is that access still appropriate.

That second question is the one ordinary access systems cannot answer. A directory or an access control system enforces the decision it was given. It does not decide whether the decision was still correct six months later. IGA is the governance layer that sits above enforcement and asks that question continuously, because access that was right when it was granted becomes wrong as roles change and projects end, and nothing in the enforcement layer notices.

The identity lifecycle: joiner, mover, leaver

IGA is built around the identity lifecycle, usually called joiner-mover-leaver (JML). Every account passes through it, and each stage is a point where access has to change in step with the person.

Joiner. A new employee, contractor, or service account is created. IGA provisions the baseline access their role needs, ideally from a role definition rather than by hand, so the new hire starts with exactly what the job requires and nothing borrowed from whoever sat there before. Provisioning from an authoritative source, usually the HR system, is what keeps the identity data accurate from day one.

Mover. The person changes roles, teams, or managers. This is the stage most programs get wrong. The new access gets added because the person needs it to do the new job. The old access rarely gets removed, because nothing forces the question. Over a career of internal moves, this is how an account ends up holding the combined permissions of every job the person ever had, a pattern called privilege creep. IGA's answer is to re-derive access from the new role and revoke what the old role no longer justifies.

Leaver. The person departs. Their access must be revoked everywhere, promptly, including the accounts that are easy to forget: SaaS apps provisioned outside the central directory, local accounts, shared credentials, API keys. The leaver step is the single most skipped step in identity management, and the orphaned accounts it leaves behind are exactly the dormant, unmonitored credentials attackers look for. Automated deprovisioning triggered by the HR system is what closes this gap; manual offboarding is what leaves it open.

The lifecycle is the reason IGA exists as a continuous program rather than a one-time setup. Access is not granted once and left alone. It has to track a person who is constantly moving, and the cost of not tracking it is the access residue any old environment is full of.

Core capabilities of IGA

IGA platforms bundle a recognizable set of capabilities. Each one addresses a specific failure mode of ungoverned access.

Access requests and provisioning. A self-service way for users to request access and for the right owner to approve it, with the grant then provisioned automatically into the target system. The point is not convenience. It is that every grant now has a request, an approver, and a timestamp, instead of an access that appeared because someone emailed an admin. Automated provisioning also removes the manual step where access gets copied from a colleague ("give me the same access as Sarah"), which is how unowned entitlements spread.

Role management. Defining roles that bundle the entitlements a job function needs, so access is granted by role rather than permission by permission. This is role-based access control applied as a governance tool: a role gives you a clean, reviewable unit ("finance-analyst") instead of a sprawl of individual grants. Roles have to be maintained, or they drift into the same over-provisioning they were meant to prevent, but a well-kept role model is what makes the rest of governance tractable.

Access certification (recertification). Periodic reviews where managers or resource owners confirm that the access their people hold is still needed, and revoke what is not. This is the control that directly attacks privilege creep and stale access. A certification campaign puts every entitlement in front of someone accountable and forces a keep-or-revoke decision, on a schedule, with the result recorded. It is the governance answer to the access report full of permissions nobody remembers granting.

Segregation of duties (SoD). Policy that prevents one identity from holding a combination of entitlements that together enable fraud or error, even when each entitlement alone is fine. The classic example is the same person being able to both create a vendor and approve a payment to it, or both submit and approve an expense. SoD is a governance rule no single access decision can catch, because the risk lives in the combination, not the individual grant. IGA enforces SoD policy across systems and flags violations during requests and reviews.

Policy enforcement, analytics, and reporting. The evidence layer. IGA enforces the access policies an organization sets and produces the reports that prove it: who has access to what, who approved it, when it was last reviewed, which SoD rules are violated. This is what turns "we manage access carefully" into something an auditor, or an incident responder, can verify against a record rather than take on faith. The audit logs IGA generates are as much a deliverable as the access control itself.

IGA vs IAM: governance is not the login system

IGA and identity and access management (IAM) are related and frequently confused, and the confusion leaves a real gap. IAM is the operational machinery of access: it authenticates users, enforces single sign-on, issues tokens, and handles the runtime decision of whether a given login may reach a given resource. Its job is to make legitimate access work, in the moment, reliably.

IGA governs that machinery over time. It does not authenticate anyone or sit in the live access path. It decides what access should exist, ensures it gets provisioned and deprovisioned correctly, reviews whether it is still justified, and proves the whole thing to an auditor. IAM answers "can this identity log in and reach this resource right now?" IGA answers "should this identity have this access in the first place, who approved it, and is it still appropriate?"

The two need each other. IAM without IGA enforces access decisions that nobody governs, so privilege creep, orphaned accounts, and SoD violations pile up underneath a perfectly functioning login system. IGA without IAM is policy with no enforcement point. In practice IGA feeds IAM: governance decides and certifies the entitlements, and IAM enforces them at access time. A defender should treat them as two halves of one problem, because an attacker exploits the gap between them, a valid credential IAM happily honors, attached to access IGA should have revoked months ago.

Why IGA matters: compliance and audit

A large part of what drives IGA adoption is regulation. Several frameworks require organizations to control and prove who has access to sensitive systems and data, and IGA is the discipline that produces that proof.

SOX (the Sarbanes-Oxley Act) requires controls over financial reporting systems, including who can access and change financial data and enforced segregation of duties. SOX audits are a major reason access certification and SoD became standard IGA features.

HIPAA requires controls over access to protected health information, with the principle of minimum necessary access and the ability to account for who accessed what.

GDPR requires that access to personal data be limited and controllable, and that an organization can demonstrate that control.

What these have in common is that they do not just require correct access. They require provable correct access, on demand, going back in time. That is the difference between an access control system and a governance program. A directory can tell you who has access today. IGA can tell you who had access last quarter, who approved it, when it was last reviewed, and that no one held a toxic combination of permissions, which is exactly what an audit asks for. The reporting is not paperwork bolted on; for regulated organizations it is the point.

IGA from a defender's perspective

Governance failures do not look like attacks, which is precisely why they matter to defenders. Every IGA weakness is a quiet condition an attacker turns into an opportunity, and each one shows up in the artifacts an investigation produces.

Orphaned accounts. Accounts of departed users that were never deprovisioned. They are dormant, so no one watches them, and they often still hold real access. An attacker who obtains the credentials gets working access that nobody is monitoring and nobody expects to be in use. The leaver step that IGA automates is the control that would have closed them.

Privilege creep. The accumulated access of every role a long-tenured employee ever held. Compromise that account and you inherit far more than the current job needs, which is how a single foothold becomes wide reach. Access certification is the control that trims it back; without certification, every old account is over-provisioned by default.

Unowned entitlements. Access that exists with no record of who requested it, who approved it, or why. When an investigation asks "should this account have been able to reach the payroll database?", an ungoverned environment cannot answer. A governed one returns the request, the approver, and the last review date. Over-provisioned and unowned access is also the standing condition that makes privilege escalation pay off, the more an account can already reach, the less an attacker has to escalate.

SoD violations. One identity holding a combination that enables fraud. This is the insider-risk and compromised-account failure mode that no single-permission review catches, because each permission alone looks legitimate.

The thread is that IGA produces exactly the evidence an investigation needs: who had access, why, who approved it, and when it was last confirmed. A mature IGA program is not only a preventive control. It is the source of the access provenance that turns "we are not sure how that account had that permission" into a documented answer. Good governance and good forensics are built from the same records.

Frequently Asked Questions

What is identity governance and administration (IGA)?

Identity governance and administration is the framework for managing digital identities and their access across the full lifecycle, and governing that access so it stays appropriate and provable. The administration side provisions and removes access; the governance side sets policy, reviews access through certification, enforces segregation of duties, and produces audit evidence. It answers whether an identity should have access, not just whether it can log in.

What is the difference between IGA and IAM?

IAM is the operational system that authenticates users and enforces access decisions at login time, making legitimate access work right now. IGA governs that access over time: it decides what access should exist, provisions and deprovisions it across the lifecycle, certifies that it is still justified, and proves it to auditors. IAM enforces access; IGA decides and validates what should be enforced. Organizations need both.

What is access certification in IGA?

Access certification, also called recertification or an access review, is a periodic process where managers or resource owners confirm that the access their users hold is still needed and revoke what is not. It is the primary control against privilege creep and stale access, because it forces a keep-or-revoke decision on every entitlement, on a schedule, with the result recorded for audit.

What is segregation of duties (SoD) in IGA?

Segregation of duties is a governance policy that prevents one identity from holding a combination of entitlements that together enable fraud or error, even when each permission alone is legitimate. A common example is one person able to both create a vendor and approve payments to it. IGA enforces SoD policy across systems and flags violations during access requests and certification reviews.

What is the identity lifecycle (joiner-mover-leaver)?

The identity lifecycle is the path every account follows: joiner (provisioned with baseline access for the role), mover (access adjusted when the person changes roles), and leaver (access fully revoked on departure). IGA manages all three stages, ideally driven by the HR system. The mover and leaver stages are the ones most often mishandled, producing privilege creep and orphaned accounts.

Why is IGA important for compliance?

Regulations such as SOX, HIPAA, and GDPR require organizations to control access to sensitive systems and data and to prove that control on demand. IGA produces that proof: reports of who has access to what, who approved it, when it was last reviewed, and which segregation-of-duties rules are violated. It turns access management into provable, auditable access management.

How does IGA relate to least privilege?

Least privilege says each identity should hold only the access its job requires, and nothing more. IGA is how that principle is maintained over time rather than just set once. Role management grants the minimum for a job function, access certification removes access that is no longer needed, and lifecycle deprovisioning revokes everything when a person leaves. Without governance, least privilege erodes as roles change and grants are never revisited.

The bottom line

Identity governance and administration manages digital identities across their lifecycle and governs their access so it stays appropriate, least-privilege, and provable. Its administration side provisions and removes access through joiner-mover-leaver; its governance side enforces policy, runs access certification, blocks segregation-of-duties violations, and produces the audit evidence regulations demand. The capability that defines IGA is the one ordinary access systems lack: it does not just grant access, it continuously asks whether that access is still justified and proves the answer.

For a defender, IGA is both a control and a record. Its failures, orphaned accounts, privilege creep, unowned entitlements, SoD violations, are quiet conditions that turn a stolen credential into broad, unmonitored reach. Its successes are the same artifacts an investigation lives on: who had access, why, who approved it, and when it was last confirmed. IGA is where access management stops being "we grant carefully" and becomes "we can prove who has what, and that it should be that way."