TL;DR: Disconnected and legacy applications often hold the most sensitive access while lacking APIs, standard provisioning paths, and modern governance hooks, according to READI. That leaves offboarding, certification, and least-privilege enforcement weakest exactly where the risk is highest, so identity programmes need coverage beyond modern SaaS and clean integrations.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on READI's blog post: Legacy and disconnected applications concentrate sensitive access while remaining outside normal identity governance coverage.
Why it matters: IAM, IGA, and PAM teams cannot rely on API-first governance when the highest-risk systems are the ones with no modern integration path.
Context
Identity governance breaks down when an application cannot be connected through standard interfaces. In that situation, provisioning, certification, and offboarding depend on manual workarounds rather than enforceable controls, so risk accumulates where the programme has the least visibility.
Disconnected systems are not just inconvenient to integrate. They are often older clinical platforms, mainframe interfaces, custom internal tools, and inherited acquisition systems, which means they frequently sit at the centre of privileged access without ever entering the governance baseline.
Key questions
Q: How should teams govern machine and third-party access to APIs?
A: Teams should treat API callers as privileged machine identities and apply least-privilege access, short-lived credentials where possible, and explicit lifecycle ownership. That reduces the chance that a token, service account, or integration can move beyond the narrow workflow it was meant to support.
Q: Why do disconnected applications create identity governance risk?
A: They create risk because the organisation cannot reliably see, certify, or revoke access through the same control plane used for integrated systems. That produces blind spots in entitlement visibility, audit evidence, and offboarding, especially as the application count grows.
Q: What is the difference between API integration and screen-level automation?
A: API integration connects systems through documented interfaces, so data and actions move as structured requests and responses. Screen-level automation drives the user interface like a person would, clicking buttons and reading fields on a web or desktop app. APIs are usually more stable and auditable, while screen automation is more brittle and can break when layouts, labels or workflows change.
A: Treat disconnected applications as first-class governance targets, not exceptions. Use a control layer that can discover access, trigger joiner mover leaver actions, and keep entitlements aligned with policy even when the application lacks modern APIs. The goal is consistent provisioning, deprovisioning, and review coverage across the full application estate.
Technical breakdown
Why API-first governance leaves legacy systems exposed
Identity governance platforms work best when a system can expose structured identities, entitlements, and lifecycle hooks through standard interfaces. That model breaks when an application has no API, no SCIM endpoint, or no predictable provisioning surface. In practice, the governance platform can only govern what it can address programmatically, so disconnected systems fall back to side channels such as spreadsheets, tickets, and email approvals. Those workarounds create an audit trail, but not an enforceable control plane. See the Entitlement Catalogue and Application Onboarding Guide.
Practical implication: Map every high-risk application to its actual integration surface, not to the governance pattern you wish it had.
Why manual access management fails at scale
Manual governance sounds flexible, but it becomes a control failure once the application estate is large enough. CSV exports, quarterly recertification, and inbox-based approvals do not give teams continuous knowledge of who still has access, what changed, or whether ownership remains current. The deeper problem is that manual processes scale by exception handling, while identity governance needs repeatable state management. Once a disconnected application is managed by hand, the programme loses consistency across joiner, mover, and leaver events. See the IGA Buyer's Guide.
Practical implication: Treat spreadsheet-based administration as a temporary exception process, not as a governance model.
How connector automation extends governance to the screen layer
When an application has no API, the remaining interface is often the user interface itself. Screen-level automation uses computer vision and scripted actions to interact with an application the way a person would, without requiring application changes or custom code for each system. That approach is technically distinct from API integration because it governs the existing interface, not a newly exposed one. It is especially relevant where Win32 desktop tools, web front ends, and terminal systems all coexist in the same environment.
Practical implication: Assess whether screen-level automation can bridge the gap for systems that will never expose modern interfaces.
NHI Mgmt Group analysis
Disconnected applications create identity governance debt, not just integration debt. The governance gap is not simply that older systems are harder to connect. It is that the hardest systems to connect are often the ones with the most sensitive access and the least scrutiny. That turns integration backlog into a control-risk backlog, especially when inherited systems never entered the original governance design.
Manual certification over disconnected systems gives auditors artefacts, not assurance. Quarterly approvals and exported account lists can look orderly while leaving orphaned access untouched. The problem is not that the process lacks paperwork. The problem is that the process cannot continuously reconcile actual access state in the system itself. Practitioners should treat this as a governance integrity issue, not an administrative inconvenience.
Screen-level control is a practical concept for the long tail of legacy access. When an application will not expose a programmable interface, governance has to meet the interface that exists. That shifts the question from API availability to whether the identity programme can reliably observe and act on the live application surface. For teams carrying acquisition baggage or terminal-era systems, that is the decisive design constraint.
The risk cluster defines the governance priority. Legacy clinical tools, mainframe-connected systems, and inherited applications are not edge cases to defer until the end of the programme. They are the places where privilege has tended to accumulate because normal controls never reached them. Teams should re-rank onboarding by access sensitivity and governance blind spot, not by technical convenience.
Top 10 NHI issues is relevant here because disconnected systems expose the same structural weakness as unmanaged NHIs: access exists outside the lifecycle process that is supposed to govern it. In both cases, the programme looks complete on paper while the highest-risk identities remain partially or fully outside control. The practical conclusion is that coverage gaps are themselves a first-class governance finding.
What this signals
Governance coverage will increasingly be judged by what remains outside the automation layer. Modern identity programmes already do a decent job where systems expose clean interfaces. The harder test is whether they can still maintain control when the application only offers terminal screens, desktop windows, or brittle legacy workflows.
Disconnected application management is becoming a lifecycle problem, not just an onboarding problem. Once a system remains outside the governance stack for too long, ownership drifts, offboarding weakens, and audit evidence degrades. Teams should expect the most difficult systems to become the most expensive governance gaps unless they are tackled explicitly.
Control visibility will matter more than connector count. A programme that can point to many integrations but cannot close the blind spots in legacy estates is still exposed. Identity leaders should measure how much of the high-risk application portfolio is actually under enforceable governance, not how much of the environment is connected in theory.
For practitioners
- Prioritise the highest-risk disconnected systems first Rank legacy applications by access sensitivity, regulatory exposure, and current ownership clarity before assigning integration work. Put the systems with privileged access and no modern interface at the top of the queue. See the Entitlement Catalogue and Application Onboarding Guide.
- Replace spreadsheet governance with bounded exception handling Use manual approvals only as a temporary bridge while you define ownership, attestation, and revocation steps that can be repeated consistently. Do not let ad hoc administration become the steady state.
- Test screen-level automation against one terminal or desktop system Run a controlled proof of concept on one representative legacy application to validate whether the existing interface can support governed actions without custom connector development.
- Rebuild offboarding for systems outside the IGA stack Inventory where leaver actions still depend on emails, ticket queues, or local administrators, then assign named owners and revocation steps for those systems before the next certification cycle.
Key takeaways
- Disconnected applications are dangerous because they often hold sensitive access while remaining outside normal identity governance workflows.
- The main evidence is structural rather than numerical: the highest-risk systems are frequently the ones with no API, no modern interface, and no clean onboarding path.
- The practical answer is to govern the real interface, then prioritise offboarding and certification where manual workarounds still dominate.
Related NHI Mgmt Group resources: NHI Lifecycle Management Guide · Top 10 NHI Issues · IGA Buyer's Guide · IAM and IGA Basics
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 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 — Vulnerable Third-Party NHI | Disconnected inherited applications behave like unmanaged trust surfaces with weak lifecycle control. |
| NHI-10 — Human Use of NHI | Manual spreadsheet governance relies on humans to operate access control outside automated identity flows. | |
| Recommendation — Classify legacy disconnected systems as unmanaged trust surfaces and bring them into lifecycle control. Eliminate human-operated access handling where governance can be expressed as repeatable lifecycle control. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The core issue is ungoverned access permissions in systems the programme cannot currently reach. |
| Recommendation — Map disconnected applications to PR.AA-05 and close entitlement blind spots with enforceable controls. | ||
| CIS Controls v8 | CIS-5 — Account Management | Disconnected apps often fail at account lifecycle management, especially offboarding and recertification. |
| Recommendation — Apply account-management controls to legacy systems and verify leaver revocation by system, not by spreadsheet. | ||
Key terms
- Disconnected Application: An application that is not integrated with the organisation's central identity and access stack. Access is often managed through shared passwords, manual approval, or local admins, which makes revocation, evidence, and ownership harder to enforce consistently across the application lifecycle.
- Screen-Level Automation: Screen-level automation is software that operates an application by interacting with its visible interface, such as buttons, forms and menus. It is used when no usable API exists, or when a task must mimic user actions in the UI. Because it depends on the screen layout, it is typically more fragile than API-based integration.
- Identity Governance: Identity governance is the set of controls that defines who approves access, who owns it, how it is reviewed, and when it is removed. In practice, it turns identity management from a deployment task into a durable control system that can withstand audits, organisational change, and operational growth.
- 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, machine identity security, and identity lifecycle management 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 5, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org