Identity governance’s last mile: what disconnected apps change

At a glance

What this is: This is an analysis of how disconnected applications create the last-mile gap in identity governance, with the key finding that legacy systems can leave 70 to 80 percent of an enterprise footprint outside normal recertification and provisioning paths.

Why it matters: It matters because IAM, IGA, and PAM teams cannot claim governance coverage if they cannot certify, provision, or offboard access in the applications where business risk actually accumulates.

By the numbers:

• A bank can burn through three to five million dollars and still only cover 20 to 30 percent of its application footprint when disconnected apps require custom connector builds.

👉 Read Opnova's analysis of identity governance for disconnected applications

Context

Identity governance fails when an application cannot be reached for recertification, provisioning, or deprovisioning. That is the central problem in disconnected application estates, where legacy systems still sit outside modern APIs, SCIM, and standard governance workflows. For IAM and IGA teams, the gap is not theoretical. It is the place where control coverage stops and audit findings begin.

In that environment, the question is not whether identity governance exists, but whether it extends to the systems where business access is actually used. The long tail of AS/400, green-screen, and flat-file workflows forces teams into manual workarounds that do not scale. That makes lifecycle governance inconsistent across the estate, especially where human access reviews and entitlement certification are still tied to quarterly control cycles.

Key questions

Q: How should IAM teams govern applications that cannot expose modern APIs?

A: Treat those systems as explicit governance exceptions, not informal edge cases. Put a control owner around each disconnected application, define how entitlement evidence is captured, and require a verifiable process for recertification, provisioning, and offboarding. If the workflow cannot be evidenced, the control does not exist in practice.

Q: Why do disconnected apps create so many audit problems?

A: Because auditors need proof that access was granted, reviewed, and revoked consistently, not just a statement that policy exists. Disconnected apps often force teams to assemble evidence after the fact from emails, screenshots, and export files. That is slow, fragile, and difficult to defend when controls are reviewed at scale.

Q: What are the signs that identity governance is not working in practice?

A: Common warning signs are repeated access workarounds, ignored approval workflows, super admins holding too much power, and teams bypassing the process because it is too slow or hard to use. If access reviews are always behind, permissions stay stale, and IT has to chase owners for answers, governance is operating more as paperwork than control.

Q: Should organisations automate legacy access workflows before modernising the platform?

A: Yes, if the automation is reviewable and tied to a control owner. The practical decision is not platform replacement versus automation, but whether the organisation can reduce manual work without losing evidence, accountability, or exception handling across disconnected systems.

Technical breakdown

Why disconnected applications break IGA coverage

Disconnected applications are systems that do not expose the interfaces identity governance platforms expect. Instead of modern APIs or SCIM, they may rely on flat files, CSV exports, green-screen terminals, or proprietary admin consoles. That means the IGA layer cannot directly read entitlements, trigger provisioning actions, or validate state changes in a standardized way. The result is a control gap, not merely an integration inconvenience. The governance system can see the policy, but it cannot execute the workflow in the target application.

Practical implication: inventory non-integrated systems separately and treat them as governance exceptions until they are brought under a controllable workflow.

How imitation learning changes connector delivery

Imitation learning records how a human actually performs an administrative task and converts that behaviour into a repeatable workflow. In Opnova’s description, the system learns from screen interactions, not just browser events, so it can work across terminals and legacy interfaces. The technical point is that the workflow is derived from observed execution, then replayed along a recorded happy path, with inference only used when the state deviates. That reduces the dependence on hand-built integrations while preserving a reviewable procedure.

Practical implication: require human-reviewable workflow logic for any learned automation before allowing it to handle governance-sensitive actions.

Why human review still matters in legacy access workflows

Even when automation handles the repetitive steps, legacy identity workflows still need human judgment for exceptions, priority, and context. A recertification or provisioning task can fail because the target system behaves differently from one run to the next, or because the access decision requires business context that is not encoded in the workflow. This is where governance and execution separate: automation can repeat the steps, but it cannot own the accountability for access correctness. That distinction matters in audit, where evidence of control operation must be credible.

Practical implication: define exception-handling ownership before automating legacy identity workflows so human intervention is explicit, not ad hoc.

Threat narrative

Attacker objective: The practical objective is not exploitation in the traditional sense, but to exploit governance blind spots where access cannot be certified, provisioned, or revoked reliably.

1. Entry begins with a disconnected legacy application that cannot be governed through standard identity tooling, forcing manual workflows or custom connector development.
2. Escalation occurs when access decisions, recertifications, and provisioning actions accumulate in spreadsheets, tickets, and service desk queues outside the normal control plane.
3. Impact follows as audit failures, slow onboarding, and unreviewed access persist across the long tail of applications, increasing operational risk and control drift.

Breaches seen in the wild

• Coupang Signing Key Breach — Unrevoked signing key credentials expose 33.7 million records after employee offboarding failure at Coupang.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Disconnected applications create a governance ceiling, not just an integration backlog. Identity programmes are often measured by policy coverage, but disconnected estates prove that policy is not the same as enforceable control. When recertification, provisioning, and offboarding cannot reach the application, the programme has hit its operational ceiling. That is why the last mile matters more than the platform message, and why auditors eventually find the gap first.

Last-mile identity work is where lifecycle governance becomes real. Joiner-mover-leaver processes only matter if they can be executed in the systems that hold business access. A quarterly review that cannot touch a green-screen application is not a lifecycle control, it is a reporting ritual. The governance failure is not lack of intent, but lack of execution reach across the estate.

Automation that replays human work is a governance control only when the replay is reviewable. Learned workflows can reduce connector cost, but they do not remove the need for accountability, approval boundaries, and exception handling. The important question is whether the learned process can be independently evidenced and governed, not whether it is faster than a systems integrator build. Practitioners should treat replayable automation as a control extension, not a substitute for governance design.

Identity governance for disconnected systems is becoming a resilience issue. When access operations depend on manual queues or bespoke connector projects, the organisation inherits both speed risk and audit risk. That combination is especially visible in regulated sectors where onboarding delays, missed recertification, and unmanaged exceptions compound each other. The practical conclusion is that disconnected application coverage now belongs in resilience planning, not only in IAM backlog management.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• From our research: Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, according to The State of Non-Human Identity Security.
• Disconnects between access policy and actual application control are a recurring governance problem, which is why Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs remains the practical reference for coverage, offboarding, and recertification.

What this signals

Disconnection will remain the hidden IAM risk until teams measure control reach, not just policy coverage. The practical signal is whether every entitlement can be recertified and revoked in the systems that actually hold business access. When a team cannot do that, the programme has a visibility problem, a lifecycle problem, and an audit problem at the same time. The right response is to treat disconnected applications as a distinct governance class rather than a temporary inconvenience, and to align that work with the NIST Cybersecurity Framework 2.0 and NIST SP 800-53 Rev 5 Security and Privacy Controls.

Last-mile governance is becoming an operating model issue. The organisations that manage it well will define explicit evidence paths for legacy systems, while the ones that do not will keep absorbing manual work into the service desk. That creates a slow-moving identity debt that eventually shows up as compliance drag, onboarding delays, and control exceptions. The named concept here is identity reachability gap: the distance between governance intent and the applications where access decisions actually happen, and it is now a programme design problem, not a tooling footnote.

For practitioners

• Map disconnected applications by governance criticality Classify legacy systems by whether they block recertification, provisioning, offboarding, or all three. Prioritise the applications that create audit exposure or slow down access changes in regulated workflows.
• Separate learned workflow automation from control ownership Require a named control owner for every replayed workflow so exception handling, approval logic, and evidence retention remain explicit.
• Build a recertification path for non-API systems Create evidence-backed review and approval processes for systems that only expose flat files, terminals, or custom admin screens, and document how those reviews are validated.
• Measure ticket volume as a governance signal Track manual ticket backlogs, connector build time, and failed recertification rates together, because those figures show where identity governance is not reaching the business.

Key takeaways

• Disconnected applications break the link between identity policy and enforceable control, which is why they remain a persistent audit risk.
• Manual ticket volume, six-month connector builds, and partial application coverage are clear signs that the identity programme is not reaching the full estate.
• Teams should treat legacy application coverage as a lifecycle and governance priority, not just an integration backlog.

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.
• Last-Mile Integration Challenge: The final gap between identity policy and executable control in the target system. In practice, the challenge appears when the IGA platform can define the rule but cannot perform or evidence the action in a legacy application.
• Imitation Learning: A machine-learning approach that learns a workflow by observing how a human performs it. In governance use cases, the value is repeatability, but the control question is whether the learned path is reviewable, auditable, and bounded by explicit approval rules.
• Control Reach: The extent to which a governance programme can actually execute and verify access decisions across the systems it claims to cover. Control reach is stronger than policy coverage because it measures operational enforcement, not just documented intent.

What's in the full analysis

Opnova's full analysis covers the operational detail this post intentionally leaves for the source:

• The computer-use and imitation-learning workflow used to turn manual admin actions into repeatable procedures.
• The service desk and identity engineering workflow that reduces connector delivery from months to hours.
• The bank case study behind the 15,000-ticket reduction and the access process changes that made it possible.
• The practical framing for disconnected applications that security leaders can use in audit and budget conversations.

👉 Opnova's full post covers the connector approach, bank case study, and governance impact in more operational detail.

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 or identity governance programme, it is worth exploring.