Identity Governance and Administration (IGA) Overview

Identity Governance and Administration (IGA) defines the policies, processes, and technologies organizations use to manage digital identities, control access entitlements, and demonstrate compliance with regulatory requirements across their user populations. This reference covers the structural mechanics of IGA as a discipline, the regulatory landscape shaping its adoption, classification distinctions between IGA and adjacent identity disciplines, and the operational tensions practitioners encounter in practice. The scope spans enterprise, cloud, and hybrid environments within the US regulatory context.

• Definition and scope
• Core mechanics or structure
• Causal relationships or drivers
• Classification boundaries
• Tradeoffs and tensions
• Common misconceptions
• Checklist or steps (non-advisory)
• Reference table or matrix

Definition and scope

IGA functions as the organizational layer that determines who holds access to which resources, under what conditions, and for how long — then produces auditable evidence of those determinations for regulators, auditors, and internal governance bodies. The discipline is distinct from raw authentication (confirming identity at login) and distinct from authorization enforcement (applying policies at the resource level). IGA operates above both: it defines the entitlement model, governs the processes that modify entitlements over time, and certifies that the access state matches policy.

The scope of an IGA program typically spans four domains: identity lifecycle management (provisioning, changes, and deprovisioning of accounts), access request and approval workflows, role and entitlement modeling, and access certification (periodic review campaigns). Identity lifecycle management is often treated as the operational core, while access certification provides the compliance-facing output.

At the regulatory level, IGA intersects directly with the Sarbanes-Oxley Act of 2002 (SOX), which mandates internal controls over financial reporting (15 U.S.C. § 7262), and with HIPAA's Access Control standard under 45 C.F.R. § 164.312(a)(1), which requires covered entities to implement technical policies limiting system access to authorized users (HHS 45 C.F.R. § 164.312). The NIST Cybersecurity Framework (CSF 2.0) addresses identity management under the Govern and Protect functions, with access management controls mapped in NIST SP 800-53 Rev. 5 under control families AC (Access Control) and IA (Identification and Authentication).

Core mechanics or structure

An IGA system operates through five interlocking components:

1. Identity Repository Integration. IGA platforms connect to authoritative identity sources — typically HR systems, directory services (Active Directory, LDAP), and cloud directories — to maintain a synchronized record of all identities in scope. Directory services and Active Directory form the foundational data layer for most enterprise IGA deployments.

2. Role and Entitlement Modeling. IGA programs define roles as logical groupings of entitlements that correspond to job functions. Role-based access control (RBAC) is the dominant structuring model; more complex environments layer attribute-based access control (ABAC) rules that incorporate contextual attributes such as department, location, or clearance level.

3. Provisioning and Deprovisioning Automation. Access grants and revocations are executed through automated connectors to target systems. Automated deprovisioning is operationally significant: the Verizon 2023 Data Breach Investigations Report identified credential abuse as a factor in 49% of breaches (Verizon DBIR 2023), and orphaned accounts — those belonging to departed employees — represent a persistent exposure vector that manual processes fail to address at scale.

4. Access Request and Approval Workflows. IGA platforms manage the structured request, review, and approval of access changes. Workflows enforce separation of duties (SoD) by flagging or blocking combinations of entitlements that, if held by the same user, would enable fraud or error without detection.

5. Access Certification Campaigns. Periodic review campaigns require designated reviewers — typically managers, system owners, or application owners — to certify whether each user's access remains appropriate. Certification results produce audit-ready records demonstrating that access was reviewed and acted upon.

Causal relationships or drivers

Three structural forces drive IGA adoption in US organizations:

Regulatory compliance pressure. SOX Section 404 internal control audits, HIPAA technical safeguard requirements, and PCI DSS Requirement 7 (restricting access to system components and cardholder data to only those individuals whose job requires it, per PCI DSS v4.0) all generate demand for auditable access records that manual processes cannot reliably produce. The Federal Information Security Modernization Act (FISMA), codified at 44 U.S.C. § 3551, requires federal agencies to implement identity and access management as part of their information security programs, making IGA a federal procurement consideration.

Workforce scale and velocity. Organizations with high employee turnover, large contractor populations, or aggressive M&A activity cannot manage access entitlements through ticket-based manual processes without accumulating risk. When joiners, movers, and leavers are processed manually, access accumulates faster than it is revoked — a phenomenon termed "entitlement creep" or "access sprawl."

Cloud and SaaS proliferation. Expansion into cloud environments multiplies the number of target systems requiring access governance. Cloud identity security environments introduce non-federated SaaS applications that sit outside traditional directory-based provisioning, creating governance gaps that IGA platforms address through application connectors and API-based provisioning standards such as SCIM (System for Cross-domain Identity Management), defined in RFC 7644.

Classification boundaries

IGA is frequently conflated with adjacent disciplines. The boundaries are structural:

IGA vs. IAM. Identity and access management (IAM) is the broader category encompassing authentication, authorization, and directory services. IGA is a governance-layer sub-discipline within IAM, focused on policy definition, entitlement review, and audit evidence — not on runtime enforcement of access decisions.

IGA vs. PAM. Privileged access management (PAM) governs high-risk, elevated-privilege accounts (administrators, service accounts, root credentials). IGA governs the general population of digital identities. The two disciplines overlap at the point of role modeling — IGA should model privileged roles and flag SoD conflicts — but PAM addresses vault-based credential management and session recording that fall outside IGA scope.

IGA vs. ITDR. Identity threat detection and response (ITDR) is a detection and response discipline focused on identifying active attacks against identity infrastructure. IGA is a preventive governance discipline focused on ensuring access policy is correct before an attack occurs. IGA data (access history, entitlement records) can feed ITDR analytics, but the functions are operationally distinct.

IGA vs. Directory Services. Directory services (Active Directory, LDAP, cloud directories) are identity stores — they hold account data. IGA platforms govern the policies applied to that data and orchestrate changes across directories and downstream systems.

Tradeoffs and tensions

Automation vs. oversight accuracy. Automated provisioning reduces access sprawl and deprovisioning lag, but rule-based automation applies role assignments without contextual judgment. Role mining algorithms that derive roles from existing access patterns can encode historical over-provisioning into the role model, institutionalizing the problem IGA is meant to solve.

Certification thoroughness vs. reviewer fatigue. Access certification campaigns generate value only if reviewers examine access records meaningfully. Large campaigns that surface thousands of entitlements for a single reviewer typically result in rubber-stamp approvals — a documented failure mode in SOX audits where certification records exist but access was not genuinely reviewed. Reducing campaign scope increases meaningful review but risks leaving ungoverned access outside the campaign boundary.

Centralized governance vs. application team autonomy. IGA programs typically impose standardized provisioning workflows and role structures on application teams that prefer to manage their own access locally. The tension between central governance and application-team autonomy produces shadow access paths — manual group memberships, shared accounts, or out-of-band access grants — that sit outside IGA visibility. Insider threat and identity risk increases proportionally to the volume of unmanaged access paths.

SoD enforcement vs. operational flexibility. Strict separation-of-duties enforcement can block legitimate business operations — for example, an employee temporarily needing access that conflicts with their primary role during an incident or organizational restructuring. Compensating controls (time-limited access grants, additional approvals) address the operational need but add administrative overhead.

Common misconceptions

Misconception: IGA and IAM are synonymous. IGA is a governance sub-discipline within the broader IAM category. IAM encompasses authentication protocols, directory services, federation, and runtime authorization enforcement — domains that IGA does not address. Treating IGA as equivalent to IAM leads to governance gaps in authentication and federation controls.

Misconception: Completing a certification campaign satisfies access governance requirements. Certification campaigns produce audit evidence, but they do not govern the access granted between campaigns. Entitlements that accumulate between certification cycles remain ungoverned until the next review period. Continuous access monitoring or risk-based certification triggers are required to govern the interim state.

Misconception: Role-based access control eliminates entitlement sprawl. Role proliferation — the accumulation of hundreds or thousands of fine-grained roles that mirror existing access patterns rather than job functions — is a documented failure mode of RBAC implementations. NIST SP 800-207 notes that flat role models do not scale to complex, dynamic environments without additional policy layering.

Misconception: IGA platforms automatically discover all access. IGA platforms govern access through connectors to integrated target systems. Applications that have not been integrated — including legacy systems, unmanaged SaaS tools, and locally managed databases — remain outside IGA visibility. Discovery coverage is bounded by integration scope, not by the IGA platform's theoretical capability.

Checklist or steps (non-advisory)

The following sequence describes the operational phases of an IGA program implementation as documented in NIST SP 800-53 Rev. 5 control family AC and related identity management guidance:

1. Inventory identity sources — Enumerate all authoritative identity sources (HR system, directory services, cloud directories) and document their data models, update frequencies, and owner contacts.
2. Define the identity lifecycle model — Document the joiner, mover, and leaver (JML) process, including trigger events, required approvals, and expected provisioning/deprovisioning timelines for each system.
3. Catalog target systems and integration priority — List all systems containing access entitlements, classify by risk level and user population size, and sequence connector development by priority.
4. Conduct role mining and role design — Analyze existing access patterns to identify candidate roles; validate role definitions against documented job functions rather than historical access grants.
5. Define SoD conflict matrix — Document entitlement combinations that constitute SoD violations, establish detective and preventive controls for each conflict type.
6. Configure provisioning workflows — Build access request, approval, and fulfillment workflows; establish escalation paths and SLA targets for each workflow type.
7. Execute initial access certification campaign — Run a baseline certification across all in-scope systems to establish a known-good access state; document reviewer actions and revocations.
8. Establish recurring certification schedule — Define certification frequency by system risk tier (quarterly for high-risk, semi-annual for standard); document campaign scope, reviewer assignment logic, and remediation timelines.
9. Implement access analytics and anomaly detection — Connect IGA entitlement data to identity risk scoring and analytics tooling to surface outlier access patterns between certification cycles.
10. Integrate with audit and compliance reporting — Map IGA certification records, provisioning logs, and SoD violation reports to applicable regulatory control requirements (SOX, HIPAA, PCI DSS, FISMA).

Reference table or matrix

IGA Functional Component Comparison Matrix

IGA vs. Adjacent Disciplines: Boundary Reference

References

• NIST SP 800-53 Rev. 5 — Security and Privacy Controls for Information Systems and Organizations
• NIST Cybersecurity Framework 2.0
• NIST SP 800-207 — Zero Trust Architecture
• NIST SP 800-63-3 — Digital Identity Guidelines
• HHS 45 C.F.R. § 164.312 — HIPAA Security Rule Technical Safeguards
• 15 U.S.C. § 7262 — Sarbanes-Oxley Act Section 404
• [44 U.S.C. § 3551 — Federal Information Security Modernization Act (FISMA)](https://uscode.house.gov/view.xhtml?req=granuleid:USC-prelim-title44-section3551&