# Identity Governance and Administration (IGA)
Identity Governance and Administration is the discipline of managing the complete lifecycle of digital identities and their access rights across an organization's technology environment. IGA covers identity creation (provisioning a new employee's accounts and access on day one), access changes (modifying access when an employee changes roles), access certification (periodically reviewing whether existing access is still appropriate), and identity termination (deprovisioning all access when an employee leaves).
IGA operates at the governance layer above the operational controls of MFA, PAM, and SSO. MFA verifies that the person authenticating is who they claim to be. PAM controls elevated access to critical systems. SSO provides seamless access to authorized applications. IGA determines which access each identity should have, whether that access is still appropriate, and whether excess access has accumulated over time.
The problem IGA solves is access accumulation. In most organizations, access is granted readily (the new hire needs access to the ERP system by Monday) but rarely reviewed or revoked (the employee who transferred from finance to marketing six months ago still has access to the financial reporting system). Over time, every user accumulates access beyond what their current role requires. This accumulated excess access is the attack surface that credential theft exploits: a compromised account with eight years of accumulated access provides far more lateral movement options than an account with only the access required for its current role.
IGA manages four phases of the identity lifecycle:
Joiner (onboarding). When a new employee, contractor, or partner is created in the HR system (or equivalent source of truth), IGA automatically provisions their digital identity: creates accounts in Active Directory, Entra ID, and relevant applications; assigns role-based access based on their department, job title, and location; and provisions access to the tools and data their role requires.
Automated provisioning reduces two risks: delay (the new hire waiting days for account creation, unable to work) and over-provisioning (the IT team copying access from a peer who has accumulated excess permissions, transferring that excess to the new hire). Role-based provisioning grants a defined, auditable set of access based on the role, not based on what a peer happens to have.
Mover (role change). When an employee changes roles, departments, or locations, IGA adjusts their access: provisions new access required for the new role and revokes access that was specific to the previous role. This is where most organizations fail. The employee receives their new access (because they cannot work without it) but retains their old access (because nobody initiates the revocation). Each role change without access adjustment adds to the accumulation problem.
IGA platforms automate the mover process by comparing the employee's current access against the role-based access model for their new position. Access that is in the new role model but not in the current access is provisioned. Access that is in the current access but not in the new role model is flagged for revocation (or automatically revoked, depending on the organization's policy).
Access certification (periodic review). Even with automated joiner and mover processes, access drift occurs: temporary access that was never revoked, emergency access that became permanent, exceptions that were granted and forgotten. Access certification is the periodic review where managers and application owners verify that each user's access to their systems is still appropriate.
Access certification campaigns are typically conducted quarterly or semi-annually. The IGA platform presents each reviewer with a list of users who have access to their systems and asks: "Is this access still needed? Approve or revoke." Reviewers who do not respond within the defined window trigger escalation. Access that is not certified is automatically revoked (a policy that motivates reviewer participation).
The operational challenge: certification fatigue. A manager reviewing 200 access entries clicks "approve" on everything to complete the review quickly. CDA recommends micro-certifications (reviewing a subset of access monthly rather than all access quarterly), risk-based prioritization (high-risk access reviewed more frequently than low-risk), and anomaly highlighting (the IGA platform flags access that is unusual for the user's role, drawing the reviewer's attention to the entries most likely to need revocation).
Leaver (offboarding). When an employee or contractor terminates, IGA revokes all access: disables accounts in Active Directory and Entra ID, revokes application access, removes group memberships, and recovers company devices. Offboarding must be timely: an employee who was terminated on Friday but whose accounts remain active until IT processes the ticket on Tuesday has four days of unauthorized access.
Automated offboarding triggers from the HR system (termination event) and executes within minutes, not days. The IGA platform disables all accounts, revokes all access, and generates a deprovisioning report for audit evidence. CDA's recommended SLA: account disablement within 1 hour of termination notification for voluntary departures, and within 15 minutes for involuntary terminations (where the terminated employee may be motivated to cause harm).
RBAC is the access model that IGA enforces. Instead of granting access to individual users (Alice gets access to the ERP, Bob gets access to the ERP and the CRM, Carol gets access to all three), RBAC defines roles (Finance Analyst, Sales Representative, IT Administrator) and assigns access to roles. Users are assigned to roles, and they receive the access associated with those roles.
RBAC provides several benefits: consistency (every Finance Analyst has the same access), auditability (the auditor can review the role definitions rather than inspecting every individual user's access), scalability (adding a new employee is assigning them to a role, not configuring individual application access), and least privilege enforcement (roles are designed with minimum necessary access, preventing over-provisioning).
Role engineering (designing the roles and their associated access) is the foundational IGA activity. Roles must be granular enough to enforce least privilege (a single "Employee" role with access to everything is not RBAC) but not so granular that every user has a unique role (role explosion defeats the purpose). The balance is typically 30 to 100 roles for a mid-market organization, covering the major job functions and access patterns.
Entitlements are the specific permissions that compose a role: read access to the financial reporting database, write access to the marketing content management system, admin access to the IT ticketing platform. Entitlement management tracks these granular permissions across every application and ensures they are assigned through defined roles, not through ad hoc individual grants.
Entitlement discovery is the first step: what permissions exist in each application, who has them, and how were they granted? Most organizations cannot answer this question for their SaaS applications because each SaaS platform manages its own permissions independently. IGA platforms with SaaS integration (SailPoint, Saviynt, ConductorOne, Okta Identity Governance) provide cross-application visibility into entitlements.
The principle of least privilege (every user should have only the minimum access required for their current role) is mandated by every compliance framework and recommended by every security standard. In practice, least privilege erodes continuously through access accumulation. IGA is the operational mechanism that enforces least privilege over time by managing the lifecycle events (joiner, mover, leaver) and periodic reviews (certification) that keep access aligned with current roles.
Without IGA, least privilege is an aspiration written in the access control policy. With IGA, least privilege is an operational state maintained through automated lifecycle management and periodic certification.
Accumulated excess access is the tool that insider threats exploit. An employee in the marketing department who retains access to financial systems from a previous role can access financial data that their current role does not require. Whether the access is exploited deliberately (insider data theft) or accidentally (inadvertent data exposure), the risk exists because the access exists. IGA reduces insider threat exposure by ensuring that access matches the current role, not the accumulated history of every role the user has ever held.
Access governance is mandated by every major compliance framework. SOC 2 CC6.2 requires periodic access reviews. ISO 27001 A.5.18 requires access rights management including periodic review. PCI DSS Requirement 7 requires restriction of access to cardholder data by business need-to-know. HIPAA requires role-based access control for systems containing PHI. NIST 800-53 AC-2 requires account management including periodic review.
Auditors specifically request evidence of access certification: when was the last review conducted, who participated, what access was revoked, and how were non-responses handled? An organization without access certification evidence will receive findings in every serious audit.
The SEC cybersecurity disclosure rules and GDPR data protection requirements both implicitly require governance over who has access to what data. An organization that cannot answer "who has access to our customer data?" cannot demonstrate the data governance that regulators require. IGA provides the answer: the role model defines who should have access, the IGA platform tracks who actually has access, and the certification process verifies the two are aligned.
IGA sits in the IAT (Identity Access and Trust) domain of the Planetary Defense Model. IAT is civilization: who is in the environment, what can they access, and how is trust established. IGA governs the lifecycle of those identities and the appropriateness of their access over time.
CDA's Zero Possession Architecture (ZPA) methodology applies to IGA through the possession principle: "Possess nothing." Users should not possess access they do not currently need. Access accumulated from previous roles, temporary exceptions that became permanent, and emergency access that was never revoked are all forms of excess possession that ZPA eliminates through IGA lifecycle management.
The civilizational analogy: Roman citizenship carried specific rights and obligations. When a citizen's status changed (promoted to senatorial rank, assigned to a provincial governorship, discharged from the legions), their rights and obligations changed accordingly. A governor who retained his provincial authority after returning to Rome was a political threat. IGA ensures that digital citizens' access changes when their role changes, preventing the accumulation of authority that creates risk.
Four TOP missions connect to IGA:
CDA approaches IGA with one emphasis: automated deprovisioning SLAs. The leaver process is the highest-risk IGA event because a terminated employee with active access has both motive (they were just fired) and means (their accounts are still active). CDA's recommended SLA (1 hour for voluntary, 15 minutes for involuntary) is aggressive by industry standards (many organizations take days). The SLA is achievable through HR-to-IGA automation (the termination event in the HR system triggers the deprovisioning workflow without manual IT intervention). Any organization under CDA engagement implements this automation as a priority IAT control.
Word count: 1,948