IGA vs ISPM: Governance Workflows vs Posture Analytics

Identity governance and administration (IGA) and identity security posture management (ISPM) both claim to fix excessive and risky access, so buyers keep asking whether one replaces the other. They do not: IGA is a process engine that decides and records who should have access, while ISPM is a detection layer that continuously finds where real configuration and access already diverge from what is safe. This guide compares them as disciplines, not products: what each is built to stop, how each fails, how each handles non-human identities, how findings turn into remediation, where they overlap and which to fund first. It is written for identity leaders, IAM architects and security teams planning an identity roadmap. For each discipline on its own, see the IGA Buyer's Guide and the ISPM Guide.

Key takeaways

• IGA governs intent, ISPM measures reality. IGA runs requests, approvals, joiner-mover-leaver changes and access reviews against a policy; ISPM reads identity providers, clouds and SaaS to find the weaknesses that exist regardless of what was approved.
• The failure modes are opposite. IGA fails quietly when connectors miss systems or reviewers rubber-stamp; ISPM fails loudly with thousands of findings nobody owns.
• Non-human identities expose the gap. Service accounts, workload roles, OAuth apps, API keys and AI agents rarely have an HR record to drive IGA, and posture tooling usually discovers them first.
• Remediation paths differ. IGA removes access through approved, evidenced workflows; ISPM findings need routing to an owner, and the safest route for access findings is often back through IGA.
• Buying order depends on your driver. Audit and lifecycle pressure points to IGA first; a large cloud, SaaS or NHI estate with weak configuration hygiene points to ISPM first; most mature programmes run both and integrate them.

What each discipline is for

• IGA: the system of record for access decisions. It ingests authoritative sources (HR for employees, contractor registers), automates joiner, mover and leaver changes, provides access requests with approvals, runs periodic access reviews and certifications, manages roles and separation of duties (SoD) policies, and provisions or deprovisions through connectors and standards such as SCIM (RFC 7644). Its output is evidence: who approved what, when, and when it was removed. See IAM and IGA Basics.
• ISPM: continuous assessment of identity configuration and hygiene. It reads identity providers, directories, cloud IAM, SaaS tenants and NHI sources, compares them against baselines, and produces prioritised findings: administrators without phishing-resistant MFA, legacy authentication still allowed, dormant but enabled accounts, standing privileged assignments, unused permissions, over-consented applications, credentials past their age limit. Its output is a ranked list of risks and a posture trend.

The shortest way to put it: IGA answers "should this access exist, and who said so?"; ISPM answers "what is exposed right now, whatever anybody approved?". A user can be fully certified in IGA and still have no MFA on an admin role; a configuration can be perfect while an orphaned contractor account that IGA never knew about sits in a SaaS tenant.

Side-by-side comparison

Threat model and failure modes: IGA

IGA defends against privilege creep, toxic combinations, joiners given too much, movers keeping old access and leavers who still have accounts. These map to MITRE ATT&CK T1078 Valid Accounts: most identity attacks use access that already exists.

• Coverage gaps: IGA can only govern applications it is connected to. Applications onboarded "later" never are, and their accounts sit outside every review. See the Entitlement Catalogue and Application Onboarding Guide.
• Rubber-stamp reviews: managers approve hundreds of line items without context, so certification evidence exists but access does not shrink. See the Access Reviews Guide.
• Open-loop remediation: a revoke decision creates a ticket that nobody closes; the audit trail says removed, the target system disagrees.
• Configuration blindness: IGA records that an administrator holds a role, not that the role is permanently active, that MFA is not enforced on it or that legacy authentication bypasses conditional access.
• Controls: connector coverage targets by risk tier; review campaigns with usage and peer context; closed-loop verification that reads the target after revocation; SoD rules for high-risk combinations (NIST SP 800-53 AC-5); automated disablement of inactive accounts (AC-2(3)).

Threat model and failure modes: ISPM

ISPM defends against exploitable identity configuration: missing or weak MFA, legacy protocols, standing privilege, over-permissioned roles, unused credentials and risky application consent, the weaknesses that let valid-account abuse succeed (T1078.004 Cloud Accounts, T1098.001 Additional Cloud Credentials).

• Finding overload: a first scan of a large tenant returns thousands of findings; without prioritisation by privilege and exposure, teams fix easy low-risk items and leave the dangerous ones.
• No owner, no fix: ISPM can tell you a service principal holds a secret older than policy allows; it cannot tell you who is accountable for it unless an inventory with owners exists.
• Read-only remediation: findings are exported to spreadsheets or tickets that bypass approval and evidence, so fixes are undocumented or are reverted at the next change.
• Baseline drift: tools score against vendor recommendations that change; teams chase the score, not risk. Microsoft's own documentation states its Identity Secure Score "doesn't express an absolute measure of how likely you're to get breached".
• Controls: a published baseline such as CISA's SCuBA baseline for Microsoft Entra ID (for example MS.AAD.1.1v1 "Legacy authentication SHALL be blocked" and MS.AAD.7.4v1 "Permanent active role assignments SHALL NOT be allowed for highly privileged roles"); risk-based prioritisation; owner assignment; exceptions with expiry; continuous monitoring as in NIST SP 800-53 CA-7.

Non-human identity coverage

The comparison changes most for non-human identities. IGA's lifecycle model starts from a person in HR; service accounts, workload roles, OAuth applications, API keys and AI agents have no joiner date, no manager and no leaver event. Many IGA deployments therefore either exclude them or represent them as "owned" objects reviewed once a year. ISPM tools, which read cloud and IdP data directly, usually find these identities and their credential problems first.

Cloud platforms now expose native posture signals that either discipline can consume. Platforms are listed alphabetically.

• AWS: IAM Access Analyzer produces external access, internal access and unused access findings; the unused types are "Unused roles", "Unused IAM user access keys and passwords" and "Unused permissions", measured over a configurable usage window.
• Google Cloud: the IAM recommender compares granted with used permissions over an observation period of up to 90 days and suggests removing or replacing roles, including for service agents holding basic roles. Availability: basic-role recommendations are free; non-basic role recommendations and lateral movement insights need Security Command Center Premium or Enterprise.
• Microsoft: Identity Secure Score recalculates every 24 hours against Microsoft's identity recommendations, such as requiring MFA for administrative roles and blocking legacy authentication. Availability: the score is available to free and paid customers; some recommendations need a paid licence.

Whichever leads, NHIs need an owned inventory before either tool can act. See the PAM vs IGA vs NHI Management comparison and How to assign owners to orphaned service accounts.

Remediation paths

How a problem is fixed matters as much as finding it. The two disciplines remediate differently, and choosing the wrong path creates either delay or undocumented change.

The pattern: findings about who has what should flow into IGA for decision and evidence; findings about how the platform is configured go to platform owners through change management; credential findings go to secrets and NHI owners. ISPM should open the work and later verify it closed; IGA should record access decisions.

Overlap and integration

The categories are converging. IGA suites add usage analytics and risk scoring; ISPM products add review-style workflows; IdPs add both. Overlap is real in three places: dormant and orphaned account detection, privileged access visibility and access risk scoring. Integration patterns that work:

• ISPM feeds IGA reviews: attach usage and risk context (last sign-in, unused permissions, missing MFA) to review line items so reviewers revoke with evidence. See Access Reviews vs Continuous Access Monitoring.
• Event-driven micro-certifications: a high-severity ISPM finding (for example a new owner-level grant to a service principal) triggers an immediate IGA certification for its owner instead of waiting for the quarterly campaign.
• IGA feeds ISPM context: owner, business justification and approval status reduce false positives and route findings correctly.
• Shared inventory: one reconciled identity inventory, human and non-human, used by both. See NHI Inventory Reconciliation.
• Detection hand-off: posture is preventive; active abuse belongs to ITDR. See ISPM vs ITDR.

Buying order and decision criteria

• Choose IGA first when: audit findings cite access reviews, leaver timeliness or SoD; you have many on-premises or custom applications needing provisioning; regulated processes require approval evidence; HR-driven lifecycle is manual.
• Choose ISPM first when: most access lives in one or two IdPs, cloud platforms and SaaS; you have weak MFA or privileged access hygiene; NHI counts dwarf human counts; you need a fast measurable risk reduction before a longer IGA project.
• Use native features first when: you are small, mostly on one cloud IdP and a few SaaS applications. Built-in access reviews, secure scores and cloud recommenders cover much of both disciplines; buy specialist tools when coverage, scale or evidence needs exceed them.
• Large organisations: usually need both. Run ISPM to find and size the problem, and IGA to make fixes durable and auditable. Avoid two separate inventories and two sets of owners.
• Questions that settle it: Which risk drove this budget, failed audit or exposure? What share of access is in connected applications? Do NHIs have owners? Who will act on findings each week?

For evaluation detail see the IVIP and ISPM Buyer's Guide and the IGA RFP Template.

Worked scenario: one finding, two disciplines

A mid-sized company runs IGA for 60 connected applications and quarterly reviews. It pilots posture assessment across its IdP, two cloud accounts and its main SaaS tenants.

1. Day one findings: 14 administrators without phishing-resistant MFA, legacy authentication allowed for a mail protocol, 230 enabled accounts with no sign-in for 90 days, 41 cloud roles with unused administrative permissions, and 19 OAuth applications with tenant-wide consent and no recorded owner.
2. Routing: MFA and legacy authentication go to the IdP team as configuration changes against the baseline. The 230 dormant accounts are matched with IGA: 180 belong to connected applications and are disabled through IGA leaver correction; 50 sit in a SaaS tool IGA never onboarded, so the app is onboarded and the accounts handled as a one-off owner review. Cloud roles go to engineering owners as infrastructure-as-code changes. The OAuth applications go to an NHI ownership drive before any revoke.
3. Durability: the next quarterly review campaign now includes last-used data from the posture tool; reviewers revoke noticeably more stale line items with less effort, and the posture tool verifies each revocation.
4. Lesson: neither discipline alone would have closed this set. IGA did not see configuration or the unonboarded app; ISPM had no authority or evidence trail to remove access.

Implementation and rollback

1. Agree the baseline: pick a published baseline for each platform and the IGA policy set (review cadence, SoD rules, leaver SLA).
2. Build the shared inventory: reconcile human and non-human identities with owners before switching on automated actions.
3. Run posture in read-only mode: measure for two to four weeks; tune severity; agree routing rules per finding type.
4. Integrate with IGA: feed usage context into the next review campaign; enable event-driven certifications for a small set of high-severity findings.
5. Automate carefully: auto-remediation only for low-impact, reversible actions (for example disabling, not deleting, a dormant account with no owner response after a notice period).
6. Rollback: disable rather than delete; keep entitlement snapshots before bulk revocations so IGA can re-provision; keep configuration exports before tenant setting changes.

Detection and measurement

• Leaver closure time: median hours from HR termination to access removed in all systems, including those found by posture scans.
• Coverage ratio: share of identities and applications found by posture assessment that are also governed in IGA (target rising towards 100 percent for tier one apps).
• Critical finding age: median days critical posture findings stay open; target under the agreed SLA.
• Review effectiveness: revocation rate in campaigns with usage context compared with campaigns without it.
• NHI ownership: share of service accounts, workload roles and OAuth apps with a named, current owner.
• Recurrence: share of closed findings that reappear within 90 days, a signal that fixes bypassed IGA or code.

For board-level reporting see IGA KPIs and KRIs to Report to the Board.

Common failure patterns

• Buying ISPM to avoid IGA: findings pile up because there is no workflow, owner model or evidence trail to remove access.
• Treating IGA certification as security assurance: clean review results hide MFA gaps, standing admin roles and over-consented apps that IGA does not model.
• Two inventories, two owner lists: IGA and posture tools disagree on who owns an identity, and findings bounce between teams.
• Fixing in the console: posture findings corrected by hand in a cloud console are reverted by the next infrastructure deployment.
• Leaving NHIs out of scope: both programmes report success while service accounts and agent credentials drive the real exposure. See the Service Account Breaches Lessons Guide.

Framework mapping

Practitioner checklist

• Write down which problem drives the budget: audit evidence, lifecycle, or configuration exposure.
• Measure connected-application coverage in IGA and compare it with what posture scans discover.
• Build one reconciled identity inventory with owners for human and non-human identities.
• Adopt a published baseline per platform and score posture against it, not against a vendor score alone.
• Define routing rules: access findings to IGA, configuration findings to platform change, credential findings to NHI owners.
• Feed last-used and risk context into access review campaigns.
• Trigger event-driven certifications for high-severity findings such as new privileged grants.
• Verify every remediation by re-reading the target system and track recurrence within 90 days.

Standards and references

• NIST: SP 800-53 Rev. 5 Security and Privacy Controls for Information Systems and Organizations
• NIST: Cybersecurity Framework 2.0
• CIS: Critical Security Controls Version 8.1
• CISA: SCuBA M365 Secure Configuration Baseline for Microsoft Entra ID
• OWASP: Non-Human Identities Top 10 (2025)
• AWS: IAM Access Analyzer findings
• Google Cloud: Role recommendations overview
• Microsoft: What is the Identity Secure Score?

Related NHI Mgmt Group resources: ISPM Guide · IGA Buyer's Guide · PAM vs IGA vs NHI Management · ISPM vs ITDR · Access Reviews vs Continuous Access Monitoring