What control gaps can appear in customer-operated cloud IGA?

How the cloud shared-responsibility split creates control gaps

Customer-operated cloud IGA often fails at the seam between software ownership and environment ownership. The vendor may own the product, but the customer, partner, or managed service provider owns the Azure tenant, adjacent integrations, and parts of the operating model. That split can leave no single team clearly accountable for patching cadence, change approval, support escalation, or evidence retention, even when each team assumes someone else is covering it.

That ambiguity matters because IGA is not just software administration. It depends on who can change connectors, who validates configuration drift, who approves emergency fixes, and who can produce proof that controls were operating during the audit period. If those duties are not mapped to the real operating model, the control may look present in design but fail in execution.

In practice, the strongest control gap is often not technical access, but unclear ownership of operational decisions. A platform can have the right roles and workflows while still lacking a dependable answer to basic questions such as who patches the tenant-hosted components, who tests connector changes, and who signs off on exceptions after an outage or vendor update.

Where patching, change control, and support usually break down

Patch responsibility is the first place this model gets weak. If the software is vendor supplied but tenant hosted, the customer may assume the vendor will harden or update the environment, while the vendor assumes the customer will apply tenant-side changes. That gap can delay remediation, leave incompatible versions in place, or create a support deadlock when an issue spans both product and platform.

Change control is the second common failure point. IGA platforms often rely on connectors, workflow rules, approval logic, and environment-specific settings, so even small changes can affect access decisions or synchronization. Without a tested process for requesting, approving, deploying, and rolling back changes, teams can introduce outages or silently degrade governance logic.

Support and evidence collection fail for the same reason. When incidents, audit questions, or control exceptions arise, the team that operates the tenant may hold logs and configuration evidence, while the team that owns the software may hold product knowledge. If those handoffs are not defined, investigations slow down and auditors get partial answers instead of a complete control story. The IGA Buyer’s Guide is useful here because it forces buyers to test connectors, operating assumptions, and vendor responsibilities before deployment.

What good operating models do before go-live

A workable customer-operated model treats ownership as evidence, not assumption. The team should document who owns the application, who owns the cloud tenant, who operates integrations, and who is accountable for each control outcome. That includes patching, backup, monitoring, incident response, access reviews, and the retention of operational evidence.

Governance should also be tested, not just written. A practical control test is whether the organization can answer, from a live incident or audit sample, who approved the change, who deployed it, who validated it, and who retained the supporting records. The IAM and IGA Basics guide helps anchor this distinction between access administration and governance ownership, which is exactly where customer-operated cloud programs tend to drift.

For customer-operated deployments, the most important design choice is to separate product support from tenant operations. That means defining service-level expectations, escalation paths, evidence responsibilities, and rollback authority before the first production connector or workflow goes live. Without that separation, control ownership becomes situational and weakens as soon as the first exception occurs.

Risk and Threat Considerations

When ownership is unclear, control failure tends to hide until an audit, incident, or tenant change exposes it. The result can be unmanaged exposure in connectors, delayed patching, missing logs, or an inability to prove that access governance actually operated during the review period.

Failure mechanism: responsibility gaps let each party assume the other side is covering patching, tenant hardening, support, or evidence retention, so broken controls persist without a clear escalation owner.

Impact: the organization can lose control assurance, fail an audit request, and extend the blast radius of a misconfiguration or delayed remediation across identity workflows and connected cloud services.

Practitioner Guidance

What to verify: require a named owner for the application, the cloud tenant, the connectors, and the evidence pack. If any of those four are shared, make the handoff explicit in the operating procedure and test it with a real scenario.

Decision rule: if a control depends on both vendor software knowledge and customer tenant access, treat it as a joint-operating control and confirm who can execute the change when the other party is unavailable.

What good looks like: your team can show a current RACI, a tested escalation path, patch and change records, and audit evidence without reconstructing ownership after the fact.

Practitioner takeaway: customer-operated cloud IGA fails most often when responsibility is implied rather than operationalised, so the control objective is to make ownership provable before production use begins.

Related resources from NHI Mgmt Group

• Who is accountable when IAM control gaps appear in cloud or on-premises models?
• How should security teams prioritise NHI remediation in cloud environments?
• How should security teams govern non-human identities in cloud environments?
• Who is accountable when segmentation gaps appear during a cloud or hypervisor migration?