Zero trust governance gaps leave apps and identities exposed

At a glance

What this is: This is an analysis of why Zero Trust governance fails when enforcement, visibility, and automation do not extend across all identities and applications.

Why it matters: It matters because IAM teams cannot treat Zero Trust as a policy statement if disconnected apps, manual workflows, and partial coverage still allow access paths to remain unchecked.

By the numbers:

• 52% of organizations experienced a cybersecurity incident caused by the inability to secure disconnected applications.
• 47% of organizations reported failing to meet regulatory requirements because of disconnected applications that weren’t properly secured and governed.
• 49% of respondents said the single most important step they would take to reduce identity risk is extending automation across more applications and workflows.

👉 Read Cerby's analysis of Zero Trust governance gaps in disconnected applications

Context

Zero Trust is a governance model for deciding which identities, human and non-human, should be allowed to access which resources under which conditions. The problem is that many organisations still treat it as a set of controls at the edge rather than a continuously enforced access model across the full application estate.

That gap is especially visible where apps sit outside IAM and IGA coverage, where manual approval chains slow down deprovisioning, and where compliance evidence is assembled after the fact instead of being produced by the control plane itself. In that environment, Zero Trust becomes partial by design rather than resilient by default.

For identity teams, the important question is not whether policy exists. It is whether policy can be enforced consistently across every application, access path, and lifecycle event that matters to the protect surface.

Key questions

Q: How should security teams govern disconnected applications in a Zero Trust programme?

A: Security teams should inventory disconnected applications, assign explicit business owners, and wrap them with compensating controls where federation or provisioning is not available. The key is to treat each app as a governed exception with measurable access and revocation processes, rather than assuming standard IAM coverage exists. Continuous review matters more than policy declarations.

Q: Why do disconnected applications weaken Zero Trust governance?

A: Disconnected applications weaken Zero Trust because they sit outside the identity control plane, so access can be granted, maintained, or removed inconsistently. That creates blind spots in enforcement, visibility, and evidence generation. When those blind spots involve sensitive workflows or contractor access, the result is a governance failure, not just an integration issue.

Q: How do you know if Zero Trust governance is actually working?

A: Zero Trust governance is working when access decisions are enforceable across the full application estate, revocation happens quickly, and audit evidence is generated by the control process rather than assembled later. If exceptions, manual approvals, and disconnected apps dominate the workflow, the programme is still aspirational.

Q: Who is accountable when access remains active in a disconnected application?

A: Accountability sits with the application owner and the identity governance team together, because both the control gap and the exception management process determine whether access persists. If the organisation cannot revoke access in time or prove who approved it, the governance model has failed regardless of whether a policy exists.

Technical breakdown

Zero Trust governance gap: why policy and enforcement diverge

Zero Trust governance only works when policy, visibility, and enforcement move together. In practice, organisations often define access rules for a subset of apps and identities, then assume the same rules apply everywhere. That assumption fails when disconnected applications, shadow workflows, or legacy systems sit outside the identity control plane. The result is not a policy problem on paper, but a control problem in execution: the organisation can describe who should have access, yet cannot reliably prove or enforce it at runtime. Practical implication: map every app and identity path that sits outside centralized enforcement before treating Zero Trust as operational.

Practical implication: extend governance coverage to every app and access path before relying on Zero Trust language in audits or architecture reviews.

Disconnected applications and the identity control blind spot

Disconnected applications are a structural blind spot because they often lack modern federation, provisioning, or lifecycle hooks. Many cannot integrate cleanly with SAML, SCIM, or OIDC, and some only expose controls through manual or proprietary workflows. That means access decisions, password changes, and revocations may happen outside standard IAM tooling, even though the app still handles sensitive data and critical business processes. This creates a governance gap where the identity team thinks control exists, but the application behaves as an exception. Practical implication: inventory every app that cannot participate in standard identity automation and classify it as a governance exception, not an edge case.

Practical implication: classify disconnected apps as governance exceptions and force compensating controls before granting business ownership.

Automation is the scaling mechanism for identity governance

Manual governance cannot keep pace with modern access churn. Spreadsheets, tickets, and email workflows create latency that attackers can exploit and that auditors will later surface as evidence gaps. Automation changes the operating model by making access reviews, revocations, password rotation, MFA enrollment, and audit trails machine-speed processes instead of human-paced tasks. In Zero Trust terms, automation is not a convenience layer. It is the mechanism that keeps least privilege current across changing systems and identities. Practical implication: prioritise automation in the workflows that create the highest risk when they lag, especially revocation and review.

Practical implication: automate the highest-risk lifecycle steps first, especially revocation, review, and evidence collection.

Threat narrative

Attacker objective: The attacker seeks access through unmanaged application paths that bypass the organisation’s intended Zero Trust controls and remain difficult to detect or revoke.

1. Entry occurs when attackers target applications or contractor access paths that sit outside consistent IAM enforcement, creating room for access to persist unnoticed.
2. Escalation follows when privileged access is retained in disconnected systems, allowing attackers or compromised users to move through resources that were never fully governed.
3. Impact lands as data exposure, compliance failure, or operational disruption because the organisation cannot prove, enforce, or revoke access in time.

Breaches seen in the wild

• ASP.NET machine keys RCE attack — 3,000+ exposed ASP.NET machine keys enabled remote code execution.
• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.

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

NHI Mgmt Group analysis

Zero Trust fails where enforcement stops and policy becomes aspirational. A Zero Trust programme is only as strong as the systems it can actually govern at runtime. Once disconnected applications, legacy workflows, or manual exceptions sit outside that control plane, the organisation has policy language without operational enforcement. The implication is that teams must measure Zero Trust by coverage and enforceability, not by documentation.

Disconnected applications are the most common place where governance becomes fictional. Applications that cannot participate in standard identity workflows create a parallel access universe with different rules, different evidence, and different failure modes. This is not an application hygiene problem alone, it is an identity governance problem because the organisation loses visibility into who can do what. Practitioners should treat every exception as a control boundary, not a temporary nuisance.

Automation is the only way to keep least privilege current at enterprise scale. Human-paced access reviews and revocations cannot match the speed at which applications, users, and threats change. When governance depends on manual action, the delay itself becomes the vulnerability. The practitioner conclusion is simple: if access cannot be updated at machine speed, Zero Trust will always lag behind reality.

Compliance should be a byproduct of continuous control, not the purpose of governance. The article is right to frame compliance as downstream of enforceable policy, because audit evidence without live control only proves that paperwork exists. The field should stop accepting disconnected applications as an audit exception and start treating them as a governance failure mode. Identity leaders need continuous evidence tied to actual enforcement, not retrospective justification.

Identity, application, and lifecycle governance must be evaluated as one system. A protect-surface model only works when access, revocation, and evidence generation are aligned across every identity type in the environment. That includes human users, service accounts, and any workflow that can outlive the review cycle. The practitioner takeaway is to govern the system of record and the system of access together, or neither will be trustworthy.

From our research:

• 52% of organizations experienced a cybersecurity incident caused by the inability to secure disconnected applications, according to The 2024 ESG Report: Managing Non-Human Identities.
• From our research: 85% of organizations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• For a broader NHI governance baseline, see Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs, which helps teams align visibility, enforcement, and lifecycle control across disconnected systems.

What this signals

Disconnected app risk is now an identity governance issue, not a niche integration problem. When 52% of organisations report incidents tied to applications they cannot secure properly, the operational lesson is that coverage gaps create real breach exposure. Teams should expect Zero Trust programmes to be judged by how many apps sit outside standard controls, not by how polished the policy language looks.

Audit evidence must be generated by the control itself. Manual evidence collection may satisfy a checklist, but it does not reduce the time an access exception remains active. The practical test for IAM, IGA, and PAM teams is whether revocation, review, and rotation actions leave a machine-generated trail that can be verified without reconstruction.

Identity programmes should separate managed access from tolerated exceptions. The more a platform depends on spreadsheets, tickets, and emails, the more likely it is that revocation will lag behind change. Teams that want to mature Zero Trust should map exception-driven apps into a formal control backlog and close them in order of data exposure and business criticality.

For practitioners

• Map disconnected applications first Inventory every application that cannot support standard identity automation, then classify it by business criticality, data sensitivity, and manual control dependency. Treat each one as a Zero Trust exception that needs explicit ownership and compensating controls, not as an acceptable leftover.
• Enforce revocation outside business hours Remove access deprovisioning from manual working-hour processes where possible and make revocation event-driven for high-risk access paths. The goal is to prevent delayed removal of access in systems that continue to operate after the help desk closes.
• Automate evidence generation with control execution Tie access review, password rotation, MFA enrollment, and lifecycle actions to systems that produce audit-ready evidence as they run. That reduces the gap between what the organisation claims to govern and what it can actually prove.
• Define the protect surface by exception closure Build your protect-surface inventory around the apps, identities, and workflows that sit outside standard federation or provisioning. Close each exception with a named owner, a review cadence, and a control path that can be tested.
• Measure Zero Trust by coverage, not policy count Use coverage metrics such as governed application percentage, revocation latency, and exception volume to judge whether Zero Trust is real in practice. Policy documents alone do not tell you whether access is actually being controlled.

Key takeaways

• Zero Trust breaks down when policy cannot be enforced across disconnected applications and unmanaged access paths.
• Disconnected apps and manual workflows create measurable governance gaps, including incident exposure and compliance failure.
• Automation, continuous visibility, and evidence generation are the controls that turn Zero Trust from theory into operating practice.

Key terms

• Zero Trust governance gap: The gap between an organisation’s stated Zero Trust policy and what it can actually enforce across users, applications, and resources. It appears when identity controls, visibility, or lifecycle actions do not reach part of the environment, leaving access decisions partially governed or entirely manual.
• Disconnected application: An application that does not integrate cleanly with standard identity tooling such as federation, provisioning, or automated lifecycle workflows. These systems often become exceptions in IAM and IGA programmes, creating blind spots for access, evidence, and revocation even when they hold sensitive data.
• Protect surface: The subset of data, applications, assets, and services that require the strongest security and governance controls in a Zero Trust model. It is the practical boundary for continuous verification, access review, and enforcement, and it should be defined by business criticality and exposure.
• Control-plane enforcement: The ability of an identity or security programme to apply policy at runtime rather than merely documenting policy. In practice, it means access can be granted, denied, reviewed, and revoked in a way that is measurable, auditable, and consistent across the environment.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Cerby: Zero Trust governance gaps and disconnected applications. Read the original.