How should teams govern access in disconnected systems that do not integrate with IAM?

Why This Matters for Security Teams

Disconnected systems are not a governance edge case. They are where accountability gaps, orphaned accounts, and stale access tend to accumulate because the usual joiner-mover-leaver flow does not reach them. If a platform cannot integrate with IAM, it still creates an identity surface that must be owned, reviewed, and retired. Current guidance from the NIST Cybersecurity Framework 2.0 and the OWASP Non-Human Identity Top 10 both point to the same operational reality: visibility and lifecycle control matter more than whether a system is fully integrated.

For NHI Management Group, the problem is not only human admin accounts. Service accounts, API keys, local operator roles, and embedded secrets often persist in disconnected tools long after ownership has changed. The Ultimate Guide to NHIs notes that only 5.7% of organisations have full visibility into their service accounts, which is exactly the kind of gap disconnected systems create and preserve. In practice, many security teams encounter stale access only after an audit finding, an incident, or a failed offboarding has already exposed the problem.

How It Works in Practice

The practical answer is to build a parallel control plane for systems that cannot speak to the main IAM stack. That starts with inventory, then ownership, then periodic review. Teams should extract account lists from exports, local reports, admin consoles, and log sources, then reconcile them against authoritative HR, contractor, or asset records. The goal is not perfect federation. The goal is defensible control over who can still act in the system and why.

For disconnected platforms, governance usually works best when it is explicit and repetitive:

• Identify the system owner and the backup owner, even if the platform has no native integration.
• Maintain a local account register with purpose, privilege level, creation date, and expiry or review date.
• Map every privileged account to a person, team, or approved service function.
• Use manual or scripted recertification on a fixed cadence, with evidence retained for audit.
• Disable or revoke access on termination, contract end, or role change using a documented runbook.

This approach aligns with the lifecycle and audit guidance in the Lifecycle Processes for Managing NHIs and the broader control expectations reflected in the Regulatory and Audit Perspectives. When the platform stores secrets locally, teams should also treat rotation and offboarding as separate tasks, not one-time cleanup. Where integration is impossible, compensating controls such as bastion access, approval gates, and immutable logging become the evidence trail. These controls tend to break down in legacy systems with shared admin credentials, no export capability, and no reliable audit logs because ownership cannot be proven after the fact.

Common Variations and Edge Cases

Tighter governance for disconnected systems often increases manual effort, so organisations have to balance coverage against operational friction. That tradeoff is real, especially in OT, lab, mainframe, or vendor-managed environments where change windows are narrow and native identity controls are weak. Best practice is evolving here, and there is no universal standard for every platform, but the expectation remains the same: access must be attributable and reviewable.

Some systems allow only shared logins, local files, or hard-coded credentials. In those cases, the safest pattern is to reduce blast radius rather than pretend the risk is gone. Use separate accounts where possible, tie approvals to named owners, enforce password or secret rotation, and limit administrative access to short windows. If a platform is vendor-operated, contract language should require access reporting, offboarding support, and notification for account changes. The 52 NHI Breaches Analysis reinforces how often hidden credentials and poor lifecycle control become the real failure mode.

The best programs treat disconnected systems as temporary exceptions with permanent controls, not as exempt assets. That mindset is consistent with the Top 10 NHI Issues, where visibility, rotation, and offboarding are recurring weaknesses. The hardest cases are shared-access environments where no single owner exists, because governance fails as soon as accountability becomes collective instead of assigned.

Related resources from NHI Mgmt Group

• How should security teams govern AI systems used in classified or disconnected environments?
• How should security teams govern non-human identities that have persistent access?
• How should security teams govern API keys used for generative AI access?
• How should security teams govern disconnected apps that do not integrate with IAM?