They stall when the application has weak APIs, inconsistent entitlement models, or no reliable identity source to reconcile users, roles and access. Schema mapping, entitlement design, and connector build effort become the bottleneck, especially for legacy or custom apps. Manual fulfilment then persists, so joiner-mover-leaver workflows, access reviews and automated provisioning cannot close the control gap.
Why integration effort becomes the bottleneck
Identity governance only scales as far as the application can expose a trustworthy access model. In harder-to-integrate systems, the work is rarely just “connect the app”; it is reconciling the application’s users, roles, groups, entitlements and account states into a form the governance platform can understand and action consistently. That is why the delay usually appears as mapping work, not policy work.
Legacy and custom applications often fail on the same few points: no stable API, no clean entitlement catalogue, inconsistent role semantics, and no authoritative source for account ownership or lifecycle state. If the integration team cannot determine what an access item means, who owns it, or how it should be provisioned and revoked, automated governance turns into a manual interpretation exercise. That creates queue time, rework and exception handling, which are the real stall factors.
For that reason, the operational problem is often upstream of the governance workflow itself. The program can have good joiner-mover-leaver design, but if the application cannot surface reliable attributes or accept automated changes, the workflow stops at the connector boundary. The result is a partial control that still looks mature on paper but leaves fulfilment, reviews and revocation dependent on people.
What weak entitlement design does to access reviews and provisioning
Applications with inconsistent entitlement models force identity teams to choose between bad options. They can map roles too broadly and risk overprovisioning, map them too narrowly and create noisy exception traffic, or leave access as free-text or ticket-based requests that do not reconcile cleanly. Each choice makes certification less trustworthy because reviewers are not evaluating a stable entitlement structure.
That is why entitlement design matters as much as connector engineering. A workable governance design needs a stable identity source, clear entitlement ownership, and enough structure to distinguish role membership from direct grants, inherited access, temporary access and administrative access. When the application does not support those distinctions, access reviews become an exercise in interpretation rather than assurance.
Manual fulfilment also persists because the system cannot always prove state. If the governance platform cannot confirm that a user was provisioned, moved, or removed as intended, it cannot safely close the loop. That weakens recertification, makes orphaned access more likely, and leaves auditors with evidence gaps even when the business believes controls exist.
In practice, the hardest applications are often the ones with the most business-specific logic. Their access model is tightly coupled to local processes, so the governance program must either adapt to that complexity or accept a reduced control set for that application. The difference between those outcomes is usually the amount of remedial design work the business is willing to fund.
Why legacy applications keep identity governance fragmented
Legacy platforms tend to stall governance for structural reasons, not because teams are careless. They may expose only partial identity data, lack consistent object identifiers, or require bespoke provisioning steps that cannot be repeated safely at scale. When that happens, the governance program cannot rely on standard correlation, so it falls back to spreadsheets, service desk routing or one-off scripts.
That fragmentation has a second-order effect: the organisation starts treating each difficult application as a special case. Over time, the exceptions become the operating model, and the program loses coverage exactly where the risk is highest. A strong identity program should bring applications under identity governance by making onboarding, entitlement definition and account correlation deliberate work, not an afterthought.
Programs also stall when data quality is weak at the source. If the identity record cannot reliably identify the owner, the manager, the worker status or the application account linkage, then automated provisioning and access review decisions become fragile. That is why a good identity data model is not a reporting concern only, it is a control precondition.
For legacy estates, a practical distinction matters: some systems can be governed directly, while others need compensating controls until they are modernised. The more opaque the application, the more you should expect control friction, longer remediation cycles and a greater reliance on manual evidence.
Risk and Threat Considerations
When hard-to-integrate applications sit outside the normal governance pattern, the organisation accumulates silent access risk. Manual fulfilment, delayed revocation and inconsistent entitlement mapping make it easier for excess access to persist after role changes, departures or project completion, and they make it harder to prove that access was removed on time.
Failure mechanism: The application cannot reliably expose or enforce the entitlement model that identity governance expects, so provisioning, certification and deprovisioning degrade into manual exceptions, stale access and weak correlation.
Impact: Joiner-mover-leaver controls lose completeness, access reviews become less defensible, and the business inherits a larger window for unauthorized or unnecessary access to remain active.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-5 — Account Management | Governance stalls when app accounts and access paths cannot be managed consistently. |
| Recommendation — Standardize account lifecycle handling and remove manual exceptions from application access management. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Hard integrations often fail where identity material and lifecycle handling are unclear. |
| AC-2 — Account Management | The issue is reliable provisioning, revocation, and account state reconciliation across apps. | |
| Recommendation — Enforce managed credential lifecycle controls for application access paths. Maintain authoritative account inventories and automate provisioning and deprovisioning where possible. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication, and Access Control | The question is about whether access can be governed consistently across difficult applications. |
| Recommendation — Map each application to a governed access model with clear identity and entitlement ownership. | ||
| ISO/IEC 27001:2022 | A.5.16 — Identity management | Identity governance depends on accurate identity records and accountable access administration. |
| Recommendation — Define authoritative identity ownership and lifecycle controls for each integrated application. | ||
Practitioner Guidance
What to verify: Before onboarding a difficult application, confirm whether it has a stable authoritative source for identities, a repeatable entitlement model, and a deterministic way to provision and revoke access. If any one of those is missing, treat the integration as a control-design problem rather than a connector task.
Decision rule: If the application cannot support reliable automated reconciliation, do not force a fully automated model on day one. Use a constrained control pattern, define the minimum governable access set, and document the manual steps that remain until the application is remediated or retired.
What practitioners underestimate: The longest delay is often not technical coding but entitlement normalisation, ownership assignment and exception agreement. Those decisions determine whether the connector can support repeatable governance, or merely move the manual work into a different queue.
Practitioner takeaway: Identity governance stalls when the application cannot be reduced to a trustworthy access model, so the real success measure is not connector completion, it is whether the app can be governed, reviewed and revoked consistently without manual interpretation.
Related resources from NHI Mgmt Group
- How should security teams reduce the backlog of applications without native connectors in identity governance programs?
- How should security teams implement reconciliation in identity governance programs with connected applications and manual admin changes?
- Why do identity governance programs matter when organisations run SAP and cloud applications together?
- Why do applications outside the identity perimeter create more governance risk for IAM programs?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org