How should organisations govern legacy applications that cannot connect directly to identity platforms?

Why This Matters for Security Teams

Legacy applications often fail governance not because they are low value, but because they sit outside modern identity plumbing. If they cannot call an identity platform directly, access reviews, joiner mover leaver actions, and entitlement changes can drift into spreadsheets and ticket queues. That creates blind spots for privileged access, over-retained accounts, and delayed offboarding, which are recurring themes in the Ultimate Guide to NHIs.

This matters most where disconnected systems still host sensitive data, operational workflows, or service accounts that can be used by automation. NIST’s Cybersecurity Framework 2.0 expects identity governance to be part of broader asset and access management, even when technology is uneven across the estate. NHIMG research also shows that only 5.7% of organisations have full visibility into their service accounts, which is exactly the kind of gap legacy platforms create.

In practice, many security teams discover the problem only after a stale account, orphaned privilege, or audit exception has already exposed the weakness.

How It Works in Practice

The practical answer is to place a governance control layer between the identity program and the legacy application. That layer should discover accounts and entitlements, translate policy into application-specific actions, and keep records of who approved access, when it was created, and when it was removed. Current guidance suggests treating this as lifecycle orchestration, not just access administration.

For connected applications, the identity platform can enforce policy in real time. For disconnected systems, the control layer may need to use file-based feeds, database connectors, RPA, batch jobs, or privileged service accounts to execute changes. The key is that the legacy app remains governed by the same joiner mover leaver workflow, even if the technical path is indirect. NIST SP 800-53 Rev. 5 supports this model through access enforcement, account management, and auditability requirements.

A sound operating model usually includes:

• Periodic discovery of all local accounts, shared accounts, and application roles.
• Policy-driven provisioning and deprovisioning with human approval where needed.
• Recertification of entitlements against business ownership and role need.
• Compensating controls for applications that cannot support direct API integration.
• Logging that ties each action back to an identity, request, and control decision.

Where the application can support a bridge, use it to reduce manual handling. Where it cannot, document the compensating process and test it like any other security control. The lifecycle discipline described in Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs is especially relevant here because the challenge is not just creation, but continuous alignment. These controls tend to break down when legacy owners are unclear and entitlement data lives only inside the application database.

Common Variations and Edge Cases

Tighter governance of legacy systems often increases operational overhead, requiring organisations to balance control strength against application fragility and support constraints. There is no universal standard for this yet, so best practice is evolving around risk tiering rather than a single integration pattern.

Some environments can support only indirect governance. Mainframe applications, packaged ERP systems, and vendor-managed tools may permit exports, scheduled imports, or service account wrappers but not modern API calls. In those cases, a compensating control approach is acceptable if it is documented, tested, and reviewed on a defined cadence. That is the same logic reflected in the Ultimate Guide to NHIs — Regulatory and Audit Perspectives.

The edge case to watch is shared administrator access. If multiple operators use the same account, governance must shift from individual entitlement tracking to session control, approval traceability, and strong logging. Another common exception is vendor-hosted legacy software where the customer cannot change the local identity model. In those cases, governance should focus on contract terms, review evidence, and limiting what the service account can reach. NHIMG’s Top 10 NHI Issues research shows why this matters: weak visibility and weak rotation remain persistent failure points across the estate.

Legacy governance succeeds when teams accept that indirect control is still control, provided the process is measured, repeatable, and owned.

Related resources from NHI Mgmt Group

• How should organisations govern AI applications that connect directly to models?
• How should healthcare organisations govern access to patient data across applications and privileged workflows?
• Why do large organisations struggle to onboard business applications into identity security workflows?
• How should organisations approach identity governance when business applications, cloud infrastructure, and data access are all converging?