Identity Governance and Administration (IGA) Overview

Identity Governance and Administration (IGA) is the discipline within enterprise cybersecurity that controls who has access to which systems, under what conditions, and how that access is provisioned, reviewed, and revoked over time. IGA sits at the intersection of IT operations, regulatory compliance, and risk management, making it a foundational component for organizations subject to frameworks such as NIST SP 800-53, SOX, HIPAA, and FedRAMP. This page covers the structural mechanics, regulatory drivers, classification boundaries, and professional tensions that define IGA as a distinct service and technology sector.

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

Definition and scope

IGA encompasses the policies, processes, and technologies that manage digital identities and their associated entitlements across enterprise environments. An entitlement is a discrete permission — read access to a database, write access to a file share, an administrative role in a cloud platform — and an IGA program tracks the full lifecycle of those permissions from initial provisioning through modification to termination.

The scope of IGA extends beyond simple user account management. It covers human identities (employees, contractors, partners), non-human identities (service accounts, API keys, machine credentials), and the roles or groups through which permissions are aggregated. NIST Special Publication 800-53 Rev 5 addresses IGA-relevant controls under the Access Control (AC) and Identity and Authentication (IA) control families, establishing baseline requirements for federal agencies and the private-sector organizations that contract with them.

IGA as a professional discipline is distinct from, though related to, Identity and Access Management (IAM). IAM is the broader category; IGA is the governance layer within IAM that addresses accountability, auditability, and policy enforcement — not just technical authentication and provisioning mechanics.

The identity security providers at this provider network organize IGA service providers by functional specialization, including role management, access certification, and privileged access governance.

Core mechanics or structure

IGA programs operate through five interlocking functional components:

1. Identity lifecycle management. Processes that govern the creation, modification, and deletion of accounts as users join, change roles within, or leave an organization. The joiner-mover-leaver model is the standard operational framework, with provisioning workflows triggered by authoritative HR systems.

2. Role management. The design and maintenance of role definitions that bundle entitlements into meaningful business functions. Role-based access control (RBAC), as defined in NIST Special Publication 800-207 on Zero Trust Architecture, is the most widely implemented model, though attribute-based access control (ABAC) is increasingly applied in cloud-native environments.

3. Access certification (access reviews). Periodic campaigns in which data owners, managers, or system owners attest that access assigned to users under their purview remains appropriate and necessary. The Sarbanes-Oxley Act (15 U.S.C. § 7201 et seq.) and its implementing rules from the Public Company Accounting Oversight Board (PCAOB) effectively mandate access review processes for financial system controls at publicly traded companies.

4. Separation of duties (SoD) enforcement. Controls that prevent any single identity from holding combinations of entitlements that, together, enable fraud or unauthorized action. SoD conflict detection is a core compliance function in IGA platforms, particularly under SOX and COSO Internal Control – Integrated Framework requirements.

5. Privileged access governance. Oversight of accounts with elevated system rights, including domain administrators, database administrators, and cloud infrastructure roles. This component intersects with Privileged Access Management (PAM), though IGA governs the policy layer while PAM tools enforce session-level controls.

Causal relationships or drivers

Three primary forces drive IGA program investment and maturation:

Regulatory pressure. The Health Insurance Portability and Accountability Act (45 C.F.R. §§ 164.308, 164.312) requires covered entities to implement access controls and audit activity on electronic protected health information (ePHI). The FedRAMP Authorization Framework requires cloud service providers to demonstrate IGA controls before achieving Authorization to Operate (ATO). PCI DSS v4.0, published by the PCI Security Standards Council, mandates access control, least privilege, and periodic access reviews for cardholder data environments.

Audit and breach findings. Access control failures are a persistent root cause in major breach investigations. The Verizon Data Breach Investigations Report (DBIR) consistently identifies credential misuse and privilege abuse as top attack vectors, creating post-breach pressure to retroactively build IGA controls.

Workforce complexity. Extended enterprise models — where contractors, vendors, and partners require scoped system access — multiply the total identity population an organization must govern. A mid-sized enterprise managing 5,000 employees may govern an additional 3,000 to 8,000 non-employee identities, each requiring lifecycle and entitlement management.

The outlines the broader compliance and framework landscape within which IGA programs operate.

Classification boundaries

IGA intersects with adjacent disciplines, and misclassification produces both implementation gaps and vendor selection errors.

IGA vs. IAM. IAM is the umbrella term encompassing authentication (proving identity), authorization (enforcing access decisions), and administration (managing accounts). IGA is the governance and policy enforcement layer within IAM — it answers "should this person have this access?" rather than "can this person authenticate?"

IGA vs. PAM. Privileged Access Management addresses the technical controls around high-privilege accounts: vaulting, session recording, just-in-time access issuance. IGA governs which privileged roles exist, who is approved to hold them, and how often that approval is recertified. The two disciplines require integration but serve distinct control objectives.

IGA vs. CIAM. Customer Identity and Access Management (CIAM) governs external user identities — consumers, patients, citizens. IGA governs internal workforce and extended enterprise identities. The regulatory frameworks differ: CIAM intersects with consumer privacy law (CCPA, COPPA), while IGA intersects with enterprise security and financial controls frameworks.

IGA vs. Provider Network Services. LDAP-based provider network services (Microsoft Active Provider Network, LDAP) store identity attributes and group memberships. IGA platforms sit above provider network services, using them as enforcement points while governing the policy logic, workflow approvals, and certification processes that determine what the provider network should contain.

Tradeoffs and tensions

Least privilege vs. operational friction. The security principle of least privilege — granting only the minimum access required — conflicts with the operational reality that under-provisioned users escalate tickets, request exceptions, or accumulate access informally. Organizations that enforce strict least privilege without adequate request-and-approval workflows typically see informal access proliferation, which defeats the control objective.

Automated provisioning vs. audit confidence. Fully automated provisioning improves speed and reduces manual error but requires high confidence in the authoritative HR data feed. When HR systems contain errors — wrong department, wrong job title, delayed termination records — automated provisioning propagates those errors directly into access assignments. Manual review checkpoints slow provisioning but create an audit trail.

Role explosion vs. role sprawl. Granular RBAC designs that accurately reflect business function can generate hundreds or thousands of discrete roles, making the role catalog itself unmanageable. Consolidating roles reduces catalog complexity but introduces coarse-grained permissions that violate least privilege. NIST SP 800-53 control AC-6 (Least Privilege) and AC-16 (Security and Privacy Attributes) address this tension at the control level but do not prescribe specific role architectures.

Certification fatigue vs. certification quality. Access certification campaigns that generate thousands of review items per reviewer produce rubber-stamp approvals — automated review processes approves all items without meaningful scrutiny. High-volume, low-context certifications provide audit evidence without substantive access validation, which regulators such as the Office of Inspector General (OIG) in healthcare have flagged as a compliance weakness.

Common misconceptions

Misconception: IGA is a technology product, not a program. IGA platforms (software tools that automate provisioning, certification, and role management) are components of an IGA program, not the program itself. Organizations that deploy IGA software without governing the processes, data quality, and ownership model around it routinely fail audits and accumulate orphaned accounts and toxic access combinations.

Misconception: Access certifications satisfy the least-privilege requirement. Periodic certification confirms that access was reviewed at a point in time. It does not continuously enforce least privilege. Between certification cycles, access creep — the accumulation of entitlements beyond job function — is undetected. Continuous access monitoring, not certification alone, addresses ongoing least-privilege enforcement.

Misconception: IGA is only relevant to large enterprises. Federal compliance requirements apply based on data type and sector, not organization size. A 200-person healthcare organization handling ePHI is subject to the same HIPAA Security Rule access control requirements as a 200,000-employee health system.

Misconception: Disabling terminated employee accounts is sufficient offboarding. Disabling an account prevents active authentication but does not revoke permissions, remove the account from shared groups, or address service account credentials tied to that individual. Complete identity offboarding requires full deprovisioning across all connected systems, not merely account disablement in a primary provider network.

Misconception: Non-human identities are out of scope for IGA. Service accounts, API tokens, and machine identities now outnumber human identities in most enterprise environments. NIST SP 800-53 control IA-2 explicitly addresses identification for non-person entities, and regulatory frameworks including FedRAMP require that non-human identity lifecycle be governed under the same policy framework as human identities.

Checklist or steps

The following sequence represents the standard IGA program buildout phases as documented in NIST SP 800-53 Rev 5 control family requirements and common audit frameworks:

Phase 1 — Identity inventory
- Document all identity types in scope: employees, contractors, service accounts, API credentials
- Identify authoritative sources for each identity type (HR system, ticketing system, provider network)
- Establish identity population count across all connected systems

Phase 2 — Entitlement discovery
- Map all entitlements (roles, permissions, group memberships) across in-scope systems
- Identify orphaned accounts (no active owner or HR record)
- Identify shared accounts and assess their governance status

Phase 3 — Role model design
- Define role taxonomy based on business function, not technical groupings
- Document role owners and approval authorities for each role
- Identify SoD conflicts within the initial role catalog

Phase 4 — Provisioning workflow design
- Define joiner, mover, and leaver workflows with authoritative trigger sources
- Establish approval chains for privileged role assignments
- Define emergency access (break-glass) procedures with audit logging requirements

Phase 5 — Access certification design
- Determine certification frequency by system risk tier (quarterly for high-risk, annually for low-risk is a common baseline)
- Assign data owners and reviewer accountabilities per system
- Define remediation SLAs for access revocation following certification decisions

Phase 6 — Monitoring and reporting
- Implement continuous monitoring for high-risk entitlement combinations
- Define IGA metrics for reporting to governance bodies (access review completion rates, SoD violation counts, orphaned account counts)
- Align reporting cadence with audit and compliance obligations

Reference table or matrix

The how to use this identity security resource page describes how IGA-related providers are organized within this network, including which service categories and framework references appear in the professional providers index.