Identity governance has been "modernized" multiple times-on-prem directories, legacy IGA, cloud IAM, zero trust, SaaS management. Yet the core problems haven't moved much: over-privileged access, weak offboarding, zombie accounts, and blind spots around non-human identities.

This article traces how identity governance evolved, why fundamental issues persist despite new technologies, and what has to change if we want identity programs people actually trust.

Key findings at a glance

  • Identity-driven attacks dominate, but governance still lags. More than three-quarters of breaches are now identity-based, yet only about 50% of organizations rate their IAM/IGA tools as effective, and just 44% feel highly confident they can prevent identity-driven incidents. (guidepointsecurity.com)
  • Stolen credentials remain the #1 way attackers get in. Compromised credentials are the most common initial attack vector, responsible for roughly 16-22% of breaches and costing about $4.8-4.9M per incident, with an average 292 days to identify and contain. (riskandinsurance.com)
  • Non-human identities have quietly taken over. In modern cloud environments, machine identities outnumber humans by 20-45:1, and nearly 1 in 5 organizations has already experienced a non-human identity (NHI)-related security incident. (techprescient.com)
  • Confidence in NHI governance is even worse. Only about 1.5 out of 10 organizations feel highly confident in their NHI security, 88.5% say their NHI IAM is behind or only on par with human IAM, and only 19.6% express strong confidence in their non-human practices. (aembit.io)
  • Manual work is still the default. Most IAM/IGA programs remain heavily manual-access requests, offboarding, and service-account governance live in tickets and spreadsheets-despite two decades of "automation" promises. (guidepointsecurity.com)
  • Legacy design assumptions never went away. Identity governance systems were born as compliance engines for on-prem apps and static roles; many "modern" tools kept that DNA, just with cloud connectors and a shinier UI. (paloaltonetworks.com.au)

How identity governance grew up-but never outgrew its roots

1. From audit checkbox to access nerve center

When identity governance and administration (IGA) emerged more than 20 years ago, the primary driver wasn't zero trust or adaptive access. It was regulation.

Laws like Sarbanes-Oxley (SOX) and Gramm-Leach-Bliley (GLBA) forced organizations to prove who had access to what, and when that access was certified. Vendors responded with the first generation of IGA platforms: heavy, on-prem systems wired into directories and a handful of core business apps.

Early IGA was built to:

  • Aggregate entitlements from systems like Active Directory, SAP, Oracle and mainframes.
  • Run periodic access reviews for auditors.
  • Implement role-based access control (RBAC) at scale.

These platforms were essentially compliance-reporting engines for a world where IT owned every system, apps were mostly on-prem, and change was slow. They relied on painstaking role engineering, scheduled certifications, and batch provisioning jobs. (paloaltonetworks.com.au)

Identity management (authentication, SSO, MFA) lived next door, but separate. Governance was a specialized compliance function, not the day-to-day fabric of access.

2. The compliance-first DNA that erodes trust

That origin story matters, because it shaped how many people still experience identity governance:

  • Slow, project-heavy deployments. Legacy IGA roll-outs often took 6-12 months, with consultants and dedicated admins. Many mid-market companies simply never finished the implementation.
  • Rigid, brittle roles. RBAC models designed for static org charts cracked under reorgs, M&A, and agile product teams. Maintaining roles became its own full-time job.
  • Review fatigue. Quarterly or annual access reviews turned into rubber-stamping rituals. Managers approved whatever was in front of them because the process was too painful to engage with meaningfully.

Meanwhile, attackers shifted to targeting identities directly. IBM's data shows that abusing valid accounts is now one of the most common ways to break into enterprise networks, accounting for around 30% of cyberattacks. (ibm.com)

So you get a paradox:

Organizations invest in identity governance to satisfy auditors, but still suffer identity-driven incidents. Over time, stakeholders learn to see IGA as a checkbox, not a control they truly trust.

The tooling changed-cloud UIs, more integrations, nicer dashboards-but the mental model stayed: batch imports, periodic reviews, human-driven workflows. Same problems, new skins.

Why trust in identity governance is still low in 2026

3. The maturity gap: "We bought tools, but nothing really changed"

Recent surveys paint a consistent picture: most teams don't fully trust their own identity stack.

  • In a 2025 Ponemon/GuidePoint study of 625 IT professionals, only 50% said their IAM investments are effective, and just 44% reported high confidence in their ability to prevent identity-based incidents. (guidepointsecurity.com)
  • Ping Identity found that 97% of organizations struggle with identity verification, and nearly half (49%) consider their fraud-prevention strategies somewhat or entirely ineffective. (securitymagazine.com)

Under the hood, the same blocker keeps showing up: manual or semi-manual processes are still the backbone of many identity programs. (guidepointsecurity.com)

That manual backbone leaks into every part of identity governance:

  • Access requests routed through generic IT queues rather than policy-driven workflows.
  • Offboarding checklists executed inconsistently across HR, IT, and app owners.
  • Service accounts tracked in spreadsheets, if they're tracked at all.

When people see "automated" IGA still dumping work back into tickets and email, they stop believing the narrative. The trust gap is rational.

4. What low trust looks like on the ground

If you sit with a lean IT team at a 200-500 person company, low trust in identity governance isn't abstract. It shows up as:

  • Workarounds and shadow access. Teams bypass formal access requests because they're slow and opaque, relying on direct admin grants, shared accounts, or "temporary" permissions that never get removed.
  • Inconsistent enforcement of least privilege. Everyone agrees least privilege and adaptive security are good ideas. But when policies are enforced by humans in tickets rather than identity automation and orchestration, over-privileged access wins by default.
  • Limited adoption of advanced features. Many organizations own tools that could handle policy-based access control, adaptive access, or fine-grained SaaS governance-but don't enable those features because they're too hard to configure or maintain.

The outcome: a sprawling mix of identity tools (SSO, PAM, IGA, secrets managers, SaaS admin consoles) with no single pane of glass, no consistent access control policy enforcement, and little shared confidence.

Same fundamental problems, new skins: SaaS, sprawl and non-human identities

5. SaaS exploded, governance didn't keep up

Legacy IGA assumed a world where central IT controlled most systems. That world is gone.

Modern organizations routinely run 100+ SaaS apps, plus multiple cloud providers, data platforms, OT systems, and custom microservices. Business units buy tools directly; app owners manage their own entitlements. (paloaltonetworks.com.au)

Research from IBM shows that 40-47% of breaches now involve data spread across multiple environments, and about 35% involve shadow data-unmanaged, overlooked stores outside official governance. (riskandinsurance.com)

That same pattern exists for identities:

  • Some accounts live in Okta or Azure AD.
  • Others exist only inside SaaS tools.
  • Others are buried in CI/CD pipelines, production access scripts, OT gateways, or cloud IAM roles.

Most "modern" IGA and SaaS governance tools still focus on the ~20% of apps that expose SCIM or mature APIs, leaving the other 80%-where day-to-day work happens-largely manual.

Iden's own research and product strategy start from this coverage problem: most IGA tools handle SCIM-enabled apps, roughly 20% of the stack, while the rest remain a manual drain of tickets and spreadsheets.

So despite new logos and cloud-native UIs, the old pains remain:

  • Incomplete account provisioning and deprovisioning.
  • Orphaned and zombie accounts across long-tail SaaS.
  • Fragmented audit trails and weak audit readiness.

6. Non-human identities turned human problems into machine-scale ones

If SaaS blew up the app surface, non-human identities blew up the identity count.

Machine identities-service accounts, API keys, bots, workloads, IoT devices-now outnumber humans by 20-45:1 in typical cloud environments. (techprescient.com) Many organizations still:

  • Can't inventory all their service accounts; one study found 68% of organizations can't accurately list them. (techprescient.com)
  • Rely on static, long-lived credentials (API keys, SSH keys, embedded secrets) that are rarely rotated. (jumpcloud.com)
  • Give non-human identities broad or permanent access "to avoid breaking automation," leading to severe privilege creep.

Survey data reflects how shaky the situation feels:

  • Nearly 1 in 5 organizations has already suffered an incident tied to NHIs. (astrix.security)
  • Only 1.5 out of 10 organizations are highly confident in their ability to secure NHIs, vs. about 1 in 4 for human identities. (astrix.security)
  • 88.5% say their NHI practices lag behind or only match their user IAM, and just 19.6% express strong confidence in NHI controls. (aembit.io)

Traditional IAM and IGA frameworks assumed individuals with HR records, managers, and predictable joiner-mover-leaver events. Non-human identities don't fit that mold:

  • Containers spin up and down in seconds.
  • Service accounts persist long after the apps they served are retired.
  • Ownership is murky-does DevOps, security, data engineering, or a vendor "own" that key?

Without identity orchestration and automation that treats non-human identities as first-class citizens, everything that was hard for human accounts-least privilege, offboarding, continuous policy enforcement-becomes nearly impossible at machine scale.

Breach data: governance promises vs. real-world outcomes

7. Credentials and over-privilege are still winning attackers the game

Identity governance programs promise to:

  • Enforce least privilege access.
  • Prevent orphaned accounts.
  • Provide clean audit trails for every access decision.

But breach data shows that basic access hygiene is still failing at scale:

  • IBM's 2024 Cost of a Data Breach report found that stolen or compromised credentials are the most common initial attack vector, responsible for about 16% of breaches globally, with average costs near $4.81-4.88 million and detection/containment taking roughly 292 days-the longest of any vector. (riskandinsurance.com)
  • Other analyses put credential-driven breaches closer to 20-22% of incidents, and note that identity-based threats in general account for more than three-quarters of breaches. (deepstrike.io)
  • One technical study estimates that over 10 million secrets are exposed in public code repositories annually, while governance gaps leave many of those credentials valid and over-privileged for years. (techprescient.com)

These aren't exotic zero-days. They are failures of mundane identity governance fundamentals:

  • Incomplete or slow offboarding.
  • Weak or unenforced access control policies.
  • Lack of continuous monitoring for privilege creep and toxic combinations.
  • Minimal governance of non-human identities and production access paths.

8. Zero trust and least privilege are slogans without continuous automation

Most organizations say they are "on a zero trust journey" and that they "enforce least privilege." Many deploy adaptive access controls at the SSO/IdP layer.

But if the underlying entitlements across SaaS, cloud, OT, and internal systems are inaccurate or stale, adaptive access can only do so much. You're adaptively granting access to bad baseline permissions.

To move from slogans to reality, identity governance has to become:

  • Continuous, not periodic. Access should be evaluated and corrected continuously based on real usage and risk-not once a quarter in spreadsheet-driven reviews.
  • End-to-end automated. Account provisioning, access requests, approvals, and offboarding must run as identity automation workflows across all systems, not just a handful of SCIM-compliant apps.
  • Coverage-complete. Governance must span human and non-human identities, SaaS and cloud IAM, OT security, and production access environments.

Until then, we'll keep seeing the same incidents blamed on "human error" and "misconfigurations" that better identity governance was supposed to catch years ago.

Where identity governance has to go next

9. Redefine the scope: govern all identities, not just employees

The future of identity governance starts with a simple, uncomfortable admission:

You don't have an identity governance program if it ignores non-human identities.

Practical next steps:

  1. Inventory all identities. Build and maintain a live catalog of users, contractors, service accounts, API keys, bots, workloads, and third-party integrations across cloud, SaaS, and on-prem.
  2. Assign clear ownership. Every identity-human or machine-needs a responsible owner, lifecycle policy, and least-privilege baseline.
  3. Unify views in a single pane of glass. Consolidate entitlements, roles, and usage across SSO/IdP (e.g. Okta), cloud IAM, and SaaS into one console that supports real decisions, not just pretty charts.

This is exactly the gap Iden is built to close: providing a unified view and control plane that covers human, AI agents, and service accounts in one system, with connectors spanning SailPoint, Okta, Oracle, Microsoft, mainframes, and modern stacks.

10. Replace slow projects with fast, universal automation

Second, we have to stop pretending that yet another 12-month role-engineering project will fix identity governance.

Instead:

  • Automate the joiner-mover-leaver lifecycle across every app in your stack-SaaS, cloud, and legacy-so account provisioning and offboarding are policy-driven, not ticket-driven.
  • Orchestrate identity data from HR, ITSM, and directories into a single policy engine that can drive access control consistently.
  • Use connectors that work beyond SCIM and REST APIs, so the long-tail of tools your people actually use is governed, not ignored.

Iden's universal connector platform is designed to do exactly this: automate user and service-account access for any app-SCIM, API, or none-often going live in hours, not months, and delivering fine-grained control deeper than standard SCIM group mappings.

For lean IT teams, the payoff is concrete: customers report 80% fewer manual access tickets, 120 hours saved per quarter on access reviews, and up to 30% reduction in SaaS spend through automated license reclamation and avoided "SCIM tax" upgrades.

11. Make governance continuous, risk-aware, and audit-ready by default

Finally, identity governance must become a continuous control, not a quarterly event.

That means:

  • Continuous access reviews. Replace once-a-year campaigns with ongoing, risk-based recertification triggered by changes in role, behavior, or sensitivity of data.
  • Adaptive security grounded in real entitlements. Use behavioral and device signals to adapt access on top of accurate, least-privilege entitlements.
  • Immutable audit trails. Every grant, change, and revocation-human and non-human-should generate a tamper-resistant audit record to simplify SOC 2, ISO 27001, and other identity compliance regimes.

Iden bakes this into its modern governance platform ("Evolve"), combining end-to-end lifecycle automation, continuous governance, automated access reviews, and immutable audit logs-while still complementing existing SSO/IDP and IGA systems rather than forcing a rip-and-replace.

The outcome is not just better reports. It's an identity governance system that:

  • Actually enforces least privilege.
  • Makes offboarding and license cleanup automatic.
  • Treats non-human identities as first-class citizens.
  • Gives auditors and security leaders evidence they can trust.

Frequently asked questions

What's the difference between identity governance and identity management?

Identity management (IAM) focuses on enforcement: authentication, single sign-on, MFA, session management, and coarse-grained access decisions at login.

Identity governance (IGA) focuses on oversight and risk: who should have access to what, whether that access is appropriate over time, and how you prove it to auditors. It includes lifecycle automation (provisioning and offboarding), access reviews, policy enforcement, and audit trails across all identities and systems. (idsalliance.org)

You can have a strong SSO solution and still have weak governance if entitlements are wrong, offboarding is slow, or non-human identities are unmanaged.

Why do so many identity governance projects fail or stall?

Common failure patterns include:

  • Compliance-only scoping. Projects optimized for passing audits, not for day-to-day operator experience and security outcomes.
  • Role-engineering rabbit holes. Months spent perfecting RBAC models that instantly break with org changes.
  • Limited coverage. Focusing on a few SCIM-compliant apps while leaving most SaaS and non-human identities manual.
  • Over-reliance on consultants. Systems that only specialists can operate, leaving lean internal teams stuck once the project ends.

Successful programs flip the script: start with coverage and automation (especially offboarding and high-risk entitlements), expand iteratively, and choose platforms that a small IT team can run without a dedicated IGA admin.

How should we govern non-human identities differently from human ones?

At a minimum, you should:

  1. Discover and inventory all NHIs. Service accounts, bots, API keys, certificates, OAuth apps, workload identities-across clouds, SaaS, and on-prem. (paloaltonetworks.com)
  2. Assign owners and purpose. Each NHI needs a business owner, documented purpose, and defined least-privilege scope.
  3. Automate credential lifecycle. Use secrets managers and automated rotation, not hard-coded or manually rotated secrets.
  4. Integrate NHIs into IGA. Treat them as first-class identities in your identity governance platform so they appear in access reviews, policy enforcement, and audit trails.

Without that, NHIs remain a massive blind spot-one that attackers are already exploiting.

What does a "single pane of glass" for identity governance really look like?

"Single pane of glass" is only useful if it drives action, not just visibility.

In practice, it means a console where you can:

  • See every identity-human and non-human-and all entitlements across SaaS, cloud, on-prem, OT, and production access tools.
  • Trigger or approve access requests, modify policies, and run access reviews from one place.
  • Generate audit-ready reports with full, immutable audit trails without stitching together exports from half a dozen systems.

Iden's platform is designed to be that operational hub while integrating with your existing SSO/IdP (such as Okta) and, if you have them, legacy IGA platforms like SailPoint or Saviynt.

Identity governance has had 20 years of rebranding, but the fundamentals haven't changed: you either have continuous, automated, complete control over who and what can access your systems-or you don't.

The future isn't another UI over the same manual workflows. It's complete coverage, continuous governance, and automation that finally makes least privilege and trustworthy offboarding real across every identity in your stack.