Who is accountable for securing disconnected applications under Zero Trust?

Why This Matters for Security Teams

Disconnected applications are a common weak point in zero trust programs because they sit outside the cleanest identity, policy, and telemetry paths. When an app cannot easily integrate with central access control, teams often fall back to manual exceptions, broad network trust, or long-lived credentials. That creates exactly the kind of hidden privilege Zero Trust is meant to remove. NHI Management Group notes that 97% of NHIs carry excessive privileges, and only 5.7% of organisations have full visibility into their service accounts, which makes disconnected apps especially risky when accountability is unclear. Ultimate Guide to NHIs — Standards and NIST SP 800-207 Zero Trust Architecture both reinforce the principle that trust must be continuously evaluated, not assumed at the network boundary. The practical question is not whether the app is legacy, third-party, or difficult to integrate. The real issue is who owns the control gap when the application cannot participate in modern policy enforcement. In practice, many security teams encounter the failure only after an audit exception, secret leak, or access dispute has already exposed the gap.

How It Works in Practice

Accountability for disconnected applications works best as shared ownership with clear decision rights. Identity teams usually define the access model, security architecture sets the Zero Trust pattern, and the application owner implements what is technically possible inside the system or vendor platform. Governance then verifies exceptions, compensating controls, and review cadence. That division matters because disconnected apps rarely fail in just one place. They can lack SSO, ignore modern token standards, store static secrets, or require local admin accounts that bypass central policy. A workable control pattern usually includes:

• Mapping each disconnected app to a named business and technical owner.
• Replacing persistent shared secrets with short-lived credentials where the platform allows it.
• Using compensating controls such as PAM, network segmentation, and scoped service accounts when direct federation is not possible.
• Documenting exception expiry dates, review triggers, and revocation steps.
• Capturing telemetry so the app is still visible to monitoring and incident response.

This is where workload identity guidance becomes useful. NHIMG’s Guide to SPIFFE and SPIRE shows how cryptographic workload identity can reduce dependence on static app secrets, even when the app stack is uneven. For control design, NIST SP 800-53 Rev 5 Security and Privacy Controls helps anchor the review and logging obligations. These controls tend to break down when ownership is split across a SaaS vendor, a retiring internal team, and a central security function with no authority to force remediation.

Common Variations and Edge Cases

Tighter control over disconnected applications often increases operational overhead, requiring organisations to balance Zero Trust consistency against business continuity. The biggest edge case is a mission-critical legacy app that cannot support federation, token exchange, or modern logging. In those environments, current guidance suggests compensating controls are better than pretending the app is fully compliant. That means explicit exception handling, strict network restrictions, short-lived local accounts where possible, and a documented sunset plan. Another common variation is third-party hosted software. Here, accountability is often shared but not symmetrical. The app owner remains responsible for business risk acceptance, while the vendor may control only some technical settings. Best practice is evolving, but the expectation is still that the internal owner can prove the app is classified, reviewed, and constrained. For high-risk systems, a control owner should be able to answer three questions quickly: who can access it, how that access is issued, and how fast it can be revoked. Disconnected apps also complicate audits because evidence is fragmented across directories, tickets, vaults, and network rules. The organisations that manage this well treat exceptions as time-bound risk decisions, not permanent architecture. If that discipline is missing, the “temporary” workaround becomes the de facto trust model.

Related resources from NHI Mgmt Group

• Who should be accountable for closing access-trust gaps across BYOD, shadow IT, and unmanaged applications?
• Who is accountable for securing access when IAM alone does not verify device trust?
• Who is accountable for making zero trust work across federal or enterprise environments?
• Who is accountable for access recertification and deprovisioning when organisations adopt zero trust?