How should teams measure IGA maturity when many applications are not integrated?

Why This Matters for Security Teams

IGA maturity is often overstated when teams count licences, connectors, or workflow templates instead of actual governance coverage. If most applications still require manual provisioning, ticket handoffs, or spreadsheet reconciliation, the programme cannot reliably answer who has access, why they have it, or how quickly it can be removed. That gap matters most in audits, incident response, and joiner-mover-leaver execution.

This is especially visible in non-human identity estates, where access sprawl and weak lifecycle controls create a larger blast radius than many human identity programmes. NHIMG’s Ultimate Guide to NHIs notes that only 5.7% of organisations have full visibility into their service accounts, which is a strong signal that maturity should be measured by governable coverage, not product ownership. NIST’s NIST Cybersecurity Framework 2.0 also reinforces that governance must be operational, not just documented.

In practice, many security teams discover their IGA programme is weakest in the exact applications that matter most, after an access review, audit request, or compromise has already exposed the manual workarounds.

How It Works in Practice

The most useful maturity model starts with application coverage tiers. Security teams should classify the estate by governability, then measure the percentage of applications that can support the full identity control loop: read state, change entitlements, and reconcile results. That approach is more useful than counting integrations because it reflects whether the programme can actually enforce policy end to end.

A practical model usually includes three layers:

• Tier 1: fully integrated applications, where identity state can be queried and updated through APIs or native connectors.

• Tier 2: partially integrated applications, where access can be requested or reported on, but provisioning or deprovisioning still needs manual work.

• Tier 3: non-integrated applications, where the team relies on tickets, spreadsheets, email approvals, or local admin action.

Teams should then track measurable control outcomes: percentage of critical apps governed end to end, average time to revoke access, percentage of entitlements reconciled after each certification cycle, and the share of exceptions carried outside policy. This is where current guidance aligns with NIST identity and access principles in NIST Cybersecurity Framework 2.0: outcomes matter more than control inventory.

For non-human identities, the same logic applies to service accounts, API keys, and workload identities. The 2024 Non-Human Identity Security Report from Aembit found that 88.5% of organisations say their non-human IAM practices lag behind or merely match human IAM efforts, which helps explain why mature-looking IGA programmes often fail when they reach less-integrated systems.

These controls tend to break down in legacy estates with thick-client administration, home-grown apps, or outsourced platforms where no reliable API, event feed, or entitlement model exists.

Common Variations and Edge Cases

Tighter integration targets often increase implementation cost and operational drag, so organisations have to balance coverage against the effort needed to modernise each application.

There is no universal standard for how many applications must be integrated before a programme is “mature.” Current guidance suggests judging by risk-weighted coverage instead: critical systems first, then broad estate coverage, then exception reduction. A small number of high-risk applications left unmanaged can matter more than dozens of low-risk apps with partial automation.

Manual handling is sometimes acceptable for low-risk, low-frequency applications, but that exception should be explicit, time-bound, and reviewed. The real edge case is when an organisation uses manual processes as the default operating model while still reporting success because the IGA platform is technically deployed. That creates false confidence, especially where offboarding, privileged entitlements, or non-human access are involved.

Teams should also separate “connected” from “governed.” A directory sync or access request form does not prove maturity if the system cannot revoke access cleanly, verify entitlement drift, or reconcile outcomes after change. NHIMG’s Schneider Electric credentials breach is a reminder that identity failures often become visible only after access control gaps are exploited, not during routine reporting.

For that reason, the best maturity score is the share of the application estate that can be governed continuously, with exceptions shrinking over time rather than being normalised as an integration strategy.

Related resources from NHI Mgmt Group

• How should security teams prioritise NHI remediation in cloud environments?
• How should security teams govern non-human identities at scale?
• How should security teams govern non-human identities for compliance?
• How should security teams govern non-human identities in Salesforce?