What happens when IGA does not cover both on-premises and cloud applications?

When IGA stops at the data centre, access controls become fragmented and teams end up building custom workarounds for cloud and third-party applications. That creates inconsistent policy enforcement, more manual effort, and blind spots in review and revocation. A unified approach is needed so governance follows the user and the application, regardless of hosting model.

How Coverage Gaps Turn IGA into Two Different Control Models

When identity governance only covers on-premises applications, you no longer have one control plane. You have one set of governed applications and another set of cloud or third-party systems that still need access reviews, provisioning, deprovisioning, and owner accountability, but are now handled outside the core process. That split usually creates drift in policy, evidence, and exception handling.

The practical problem is not just that some applications are missing from scope. It is that the organisation starts making different decisions for different hosting models, even when the business risk is the same. Governance becomes a patchwork of directories, scripts, tickets, and manual review steps instead of a consistent lifecycle for access.

That is why a unified governance model matters, especially where cloud services expose privileged access paths or secrets outside the traditional data centre boundary. The same account review discipline that works for internal systems should extend to cloud entitlements and application access, or the review process stops reflecting actual exposure. For a broader identity perspective, the Ultimate Guide to NHIs and the NHI Lifecycle Management Guide show how lifecycle, visibility, and revocation discipline break down when governance is incomplete.

Where the Operational Breaks Show Up First

The first symptom is usually inconsistent joiner, mover, leaver handling. Cloud and third-party applications often end up with separate onboarding paths, separate approval chains, and separate offboarding triggers, which means access removal is slower and less reliable than it is for on-premises systems.

Another common break is evidence quality. If review data is exported from one system but cloud entitlements are checked elsewhere, audit trails stop lining up with actual access. Teams then spend time reconciling spreadsheets and screenshots rather than validating whether access is still appropriate.

At scale, fragmented coverage also hides ownership problems. If no one can state which system is authoritative for a given application, role, or entitlement, recertification becomes ceremonial. The control may still exist on paper, but it no longer answers the question that matters: who can do what, and where is that authority enforced?

A useful way to think about the issue is that cloud governance does not fail because the cloud is inherently ungovernable. It fails when the control model assumes application hosting location is the boundary of responsibility. Resources such as The 2026 Infrastructure Identity Survey and Ultimate Guide to NHIs, Key Challenges and Risks highlight the same pattern: over-privilege, limited visibility, and weak lifecycle control become more damaging when identities are spread across multiple control planes.

Risk and Threat Considerations

Fragmented IGA coverage creates a straightforward security exposure: access can remain valid after it should have been removed, and privilege can be reviewed in one system while the real entitlement lives in another. That increases the likelihood of unauthorized access, delayed revocation, and control failure during incidents or staff changes.

Failure mechanism: the organisation relies on partial inventory and partial workflows, so cloud and third-party entitlements fall outside the authoritative governance loop. Reviewers approve what they can see, while unreviewed access persists elsewhere.

Impact: attackers and insiders gain more room to abuse stale access, excessive privilege, or forgotten application accounts, and auditors are left with incomplete evidence that the access model is being enforced consistently.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

CIS Controls v8 and NIST CSF 2.0 set the technical controls, while ISO/IEC 42001:2023 define the regulatory obligations.

Framework	Control / Reference	Relevance
CIS Controls v8	6 — Access Control Management	Controls account governance across all applications and platforms.
	5 — Account Management	Identity lifecycle breaks when cloud apps sit outside provisioning and offboarding coverage.
Recommendation — Extend account governance to cloud and third-party applications with consistent review and revocation. Apply centralized account lifecycle controls so cloud access is provisioned and removed consistently.
NIST CSF 2.0	PR.AA — Identity Management, Authentication, and Access Control	Unified access control across hosting models is an identity governance issue.
	GV.RM — Risk Management Strategy	Coverage gaps create governance and residual risk that must be managed explicitly.
Recommendation — Map every application to a single access control model and verify enforcement across environments. Treat uncovered cloud applications as residual governance risk and track remediation to closure.
ISO/IEC 42001:2023	A.5 — Policies for AI Systems	Not selected
Recommendation — Not selected

Practitioner Guidance

What to prioritise: define one authoritative access governance scope that includes on-premises, cloud, and third-party applications, then test whether every entitlement can be discovered, reviewed, and revoked through that scope. If an application can create access but cannot be governed, treat it as a control gap rather than an integration detail.

What to verify: check that deprovisioning, recertification, and exception handling produce the same outcome regardless of hosting model. The most important test is not whether the identity platform connects to the application, but whether access removal and review completion are actually observable end to end.

Common mistake: treating cloud apps as a later phase of the same programme while continuing to rely on local scripts or one-off admin actions. That usually preserves the appearance of governance while leaving the riskiest entitlements outside the process.

Practitioner takeaway: if governance does not follow the application wherever it runs, IGA becomes a reporting layer over fragmented access control instead of a real control mechanism.