TL;DR: Many organisations already own some governance capability inside Okta or Microsoft Entra, but Ploy's analysis shows the decisive issue is estate coverage: disconnected apps, manual removals, and review decisions that still need people to complete. The governance problem is not whether access can be reviewed, but whether review outcomes can actually be enforced across the full estate.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Ploy's blog post: IdP governance gaps persist when disconnected apps, manual remediation, and partial estate coverage leave review decisions unenforced.
Why it matters: IAM and IGA teams need to test what is actually covered by their current IdP licences before assuming governance is solved, especially where apps sit outside the connected estate.
Context
Identity providers answer who a user is and let them sign in. Identity governance answers what they should have, who approved it, when it ends, and how removal is proven across the estate.
The gap usually appears when access lives outside the connected core. NHI lifecycle management and governance reviews matter because disconnected apps, local accounts, and manual remediation turn policy into follow-up work instead of enforceable control.
That makes this a coverage problem rather than a tooling slogan problem. If the estate is fragmented, governance has to extend beyond directory-native controls to preserve evidence and closure.
Key questions
Q: How do identity governance and identity providers differ?
A: An identity provider handles authentication, sign-in, and basic account visibility. Identity governance decides whether access is appropriate, who approved it, when it expires, and whether removal or recertification actually happened. The two functions often sit in the same vendor stack, but they solve different problems and cannot be treated as interchangeable.
Q: How should security teams govern access in disconnected apps?
A: Security teams should treat disconnected apps as lifecycle exceptions and enforce a manual control model that records every joiner, mover, and leaver action. The goal is not perfect automation on day one, but provable control over who can grant access, who can remove it, and how quickly those changes are completed.
Q: What is the best way to verify review remediation?
A: The best way is to verify the reviewer’s decision against the underlying evidence, then test that the required remediation was actually completed. Use documented approval records, challenge-step evidence, and a follow-up control such as access re-certification, ticket closure checks, or policy enforcement to confirm the fix. Link the review decision to the remediated entitlement or account state.
Q: When should teams add a separate IGA layer?
A: Teams should add a separate IGA layer when identity governance needs centralised control across multiple directories, applications, and HR sources that the native platforms cannot reconcile on their own. It becomes useful for joiner-mover-leaver workflows, access certifications, segregation-of-duties checks, and entitlement lifecycle management across disparate systems.
Technical breakdown
Why IdP-native governance stops at the connector boundary
Identity governance features inside an IdP are only as complete as the applications and entitlements they can see. Connected apps can inherit request, approval, certification, and lifecycle logic, but local accounts, admin consoles, and shadowed SaaS tools often remain outside that path. In practice, the control works for what is federated and integrated, then degrades into imports, exports, and manual follow-up where coverage ends. That is why teams often believe governance exists while auditors still find gaps. The technical issue is not lack of intent, but incomplete object coverage across identity sources and target systems.
Practical implication: Map each governance workflow to the systems it can actually reach, then separate native enforcement from record-keeping for everything else.
Why review decisions do not equal remediation
Access reviews create decisions, not outcomes. A reviewer can mark access for removal, but the target system still has to support that action, the account still has to be reachable, and the removal still has to be verified after execution. Some environments apply changes automatically, while others require separate remediation because of group rules, synced groups, or disconnected applications. This split matters because an unexecuted review decision is evidence of process, not evidence of control. The technical model therefore has two steps: certify access and then enforce the result against the authoritative source or app owner path.
Practical implication: Treat every review outcome as incomplete until the removal is executed and independently confirmed.
How lifecycle automation breaks down in fragmented estates
Joiner, mover, leaver automation depends on a clean identity-to-entitlement mapping and a reliable source of truth for role change. Where apps are tied to group rules, spreadsheets, or local admin ownership, the lifecycle engine can record the change but not always push it everywhere. That creates a split estate: some entitlements update automatically, others linger until someone manually removes them. The architectural weakness is not the workflow itself, but the assumption that all access paths are equally governable through one integration model. Once that assumption fails, lifecycle becomes partially descriptive rather than fully controlling.
Practical implication: Separate automated lifecycle paths from manual ones so lingering entitlements cannot hide inside a supposedly complete process.
NHI Mgmt Group analysis
IdP-native governance is only as strong as estate coverage. Okta and Microsoft both sell governance capabilities, but Ploy's checklist shows the real question is how much of the estate sits outside the IdP. When disconnected apps, local accounts, and third-party tools dominate, the control plane turns into a partial view of access rather than a full governance system. Practitioners should judge governance by enforcement reach, not by whether a feature exists in a licence bundle.
Review approval is not control until remediation closes the loop. Both vendors document cases where review decisions cannot be applied automatically, which means certification can stop at paper accountability. That is a governance gap, not a cosmetic limitation, because the decision and the state change are no longer the same event. Teams should treat unenforced removals as the point where governance debt accumulates.
Disconnected apps are where governance assumptions break first. Ploy's self-assessment table points to the edge cases that matter most: apps outside the catalogue, local accounts, and access removed outside the tool. Those are the places where identity programmes discover that automation did not equal coverage. The practical implication is to design for exception handling as a first-class operating model, not as a leftover manual task.
Coverage checklist governance is a stronger model than vendor scoring. Ploy's approach is useful because it forces teams to evaluate what they can prove, not what they can buy. That matters across human IAM, NHI governance, and AI agent lifecycle work, where the central problem is often the same: access that cannot be reviewed, enforced, or evidenced across every system. The safer programme is the one that tests end-to-end closure before expanding scope.
Governance debt accumulates where manual ownership replaces system enforcement. The article shows that someone still has to own the work when policy decisions do not map cleanly to target systems. That creates a standing operational burden that scales with every disconnected app and every exception path. Teams should treat manual ownership as a measurable governance risk, not a temporary inconvenience.
From our research library:
- Nearly 60% of IT leaders cite restrictive cost and complexity as a weakness of legacy identity governance, according to the 2025 State of Identity Governance Report.
What this signals
Governance programmes that depend on a single identity plane need to be measured against the edge of the estate, not the middle. Where apps sit outside the IdP, certification and lifecycle processes become partial controls unless the manual path is designed and tracked explicitly.
The most durable operating model is the one that distinguishes native enforcement from recorded intent. That distinction matters when auditors ask for proof, because a workflow that logs a decision but cannot carry it through the target system is governance in name only.
Coverage debt: the hidden gap is not missing policy, but the accumulation of systems that never enter the automated control path. Teams should surface that debt early, because it expands quietly as disconnected apps, local accounts, and shadowed workflows multiply.
For practitioners
- Define estate coverage by application class List connected SaaS apps, disconnected SaaS apps, local admin consoles, and team-owned tools separately so you can see where governance is native and where it is manual.
- Test whether review decisions are actually enforced Run one access review on an app outside the normal integration path and verify that a remove decision produces an executed change plus evidence.
- Separate licence availability from configuration reality Check whether governance features are included in your current edition, switched on, and connected to the applications that matter before assuming coverage.
- Measure manual follow-up as a governance cost Track how many requests, reviews, and removals still require human intervention after policy decisions are made, then compare that burden across the estate.
Key takeaways
- The core issue is not whether Okta or Microsoft offer governance features, but whether those features cover the full estate that actually needs control.
- Disconnected apps and manual remediation are the main reasons governance programmes look complete on paper but fail to close access in practice.
- A useful evaluation asks whether requests, reviews, lifecycle changes, and evidence all survive outside the IdP-connected core.
Related NHI Mgmt Group resources: Access Reviews and Certification Guide · NHI Lifecycle Management Guide · IGA Buyer's Guide · Identity Provider and SSO Security Guide
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST CSF 2.0, CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Ploy's checklist is about whether access permissions and governance are actually covered across the estate. |
| Recommendation — Map request, review, and removal coverage to PR.AA-05 so entitlements are governed across connected and disconnected apps. | ||
| CIS Controls v8 | CIS-5 — Account Management | The guide centres on account lifecycle ownership, review, and removal across IdP and non-IdP systems. |
| Recommendation — Use CIS-5 to reconcile account creation, review, and removal coverage across apps that sit outside the IdP. | ||
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | The article focuses on lifecycle control, approvals, and deprovisioning across mixed application estates. |
| AC-6 — Least Privilege | The checklist is fundamentally about whether access remains appropriate over time and across review outcomes. | |
| Recommendation — Apply AC-2 to ensure account lifecycle events are approved, reviewed, and removed across every in-scope application. Use AC-6 to keep entitlements bounded to current job needs and remove excess access after role changes. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Improper Offboarding | The guide repeatedly focuses on leavers, old access, and removal that still happens outside the tool. |
| Recommendation — Apply NHI-01 to close offboarding gaps where disconnected systems keep stale access alive after lifecycle changes. | ||
Key terms
- Identity Provider: An identity provider is the system that authenticates a user or workload and issues the trust signal used by downstream applications. In federated environments, it becomes a high-value control point because compromise, misconfiguration, or over-trust at this layer can affect many services at once.
- Identity Governance and Administration (IGA): A framework of policies, processes, and technology to manage and govern digital identities and their access rights. Increasingly extended to cover non-human identities alongside human users.
- Access Review: A formal process for confirming whether access is still needed and justified. In IAM programs, the review becomes an evidence-bearing control when decisions are recorded, scoped correctly, and traceable to the right reviewer, application owner, or auditor.
- Lifecycle Management: Lifecycle management is the process of creating, reviewing, rotating, and retiring identities and their secrets in a controlled way. For NHIs, it is essential because stale credentials, orphaned accounts, and incomplete offboarding are common paths to long-lived exposure and unauthorised access.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on November 6, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org