Cloud application gateways make IGA connectivity a governance issue

At a glance

What this is: This is a vendor analysis arguing that cloud application gateways turn IGA connectivity into a core governance design choice.

Why it matters: It matters because IAM, IGA, PAM, and NHI programmes all fail faster when the systems they must govern cannot be reached securely and consistently.

👉 Read Omada Identity's analysis of the Cloud Application Gateway for IGA connectivity

Context

Identity governance only works when the platform can reach the systems it is meant to govern. In hybrid estates, that connectivity is often blocked by firewall approvals, VPN dependence, segmented networks, and legacy application constraints that slow onboarding and leave gaps in oversight.

For IAM and IGA teams, the issue is not simply technical plumbing. When governance coverage depends on network exceptions, unmanaged systems stay outside review, audit evidence becomes incomplete, and Zero Trust ambitions collide with the reality of rigid infrastructure.

Key questions

Q: How should security teams handle IGA when key applications sit behind rigid network controls?

A: Treat connectivity as a gating requirement for governance coverage. If a system cannot be reached securely, it cannot be reliably reviewed, certified, or monitored. Teams should inventory blocked targets, identify the network constraints causing the blockage, and redesign the integration path so governance can extend without recreating a broad perimeter.

Q: Why do VPN-based integrations weaken modern identity governance programmes?

A: VPNs often restore access by extending network trust rather than scoping access to the application. That makes integration easier in the short term, but it introduces broad pathways that conflict with least privilege and complicate audit evidence. The practical result is broader exposure and a weaker Zero Trust posture.

Q: What breaks when identity governance cannot reach legacy and core systems?

A: Access reviews, entitlement discovery, and compliance evidence all become partial. The programme may still operate for modern cloud apps, but the most sensitive systems remain outside its control. That gap creates unmanaged risk, delayed remediation, and audit findings that are harder to defend.

Q: Who is accountable when governance tooling cannot cover a critical application because of network constraints?

A: Accountability sits with the identity, infrastructure, and application owners together, because the failure is cross-domain. If the programme cannot connect to a system, the gap must be treated as a shared design and control issue, not a vendor limitation. That is what auditors and regulators will examine.

Technical breakdown

Why IGA connectivity breaks in hybrid environments

Identity governance platforms rely on trusted connections to applications, directories, and databases so they can read entitlements, run reviews, and enforce policy. In many hybrid environments, those connections are blocked by segmentation, restricted authentication paths, and change-control processes that were never designed for broad governance integration. The result is not a product failure so much as a control-plane mismatch: the governance system cannot operate where the network does not allow it to reach. That is especially common with core business systems and legacy platforms that still assume fixed LAN or VLAN access.

Practical implication: treat application reachability as a prerequisite for governance scope, not a late-stage integration task.

Outbound-only connectivity and Zero Trust alignment

Outbound-only HTTPS connectivity changes the trust model by avoiding inbound exposure and reducing the need for firewall exceptions. Architecturally, that matters because it shifts the integration pattern away from network-level access and toward application-scoped communication. In Zero Trust terms, the control surface is narrower: the gateway connects to specific systems from a constrained runtime location, rather than opening broad paths into the enterprise. That does not remove the need for strong authentication, key control, and logging, but it does reduce the network perimeter assumptions that make governance deployments brittle.

Practical implication: prefer connectivity patterns that preserve least privilege at the network layer as well as the identity layer.

Why cryptographic custody matters in governance integrations

If a governance connector reaches sensitive systems but the vendor controls the encryption keys or custody model, the enterprise still lacks full operational assurance. The article’s emphasis on customer-managed keys reflects a broader governance principle: control of access paths is incomplete without control of the cryptographic boundary. This is particularly relevant in regulated environments where auditors expect evidence that the enterprise owns both access and protection mechanisms. The architecture becomes materially stronger when the customer retains key ownership and can demonstrate where trust is anchored.

Practical implication: require enterprise-controlled key management for any governance integration that touches sensitive or regulated systems.

NHI Mgmt Group analysis

Connectivity is now a governance control, not an infrastructure detail. Identity governance programmes fail when they assume the platform can simply reach every target system through existing network paths. That assumption breaks in hybrid estates because segmentation, firewall approvals, and legacy access rules dictate what can be governed. The implication is that coverage, not feature depth, becomes the real determinant of IGA success.

Network-bound integration creates governance blind spots. When application onboarding depends on VPNs or static routing, the programme inherits the pace and fragility of old perimeter models. That slows recertification, delays access review coverage, and leaves sensitive systems outside control for longer than boards and auditors will accept. Practitioners should treat this as a scope problem, not a tuning problem.

Zero Trust and identity governance align only when connectivity is scoped at the right layer. Broad network access undermines the same least-privilege principles IGA is supposed to enforce at the entitlement layer. A gateway model that connects outbound to specific applications is closer to the governance intent than a model that recreates the old perimeter in another form. The practical conclusion is clear: network design now shapes governance credibility.

Cloud application gateways expose a broader identity management lesson for hybrid enterprises. Identity programmes cannot be measured only by policy quality or review frequency. They must also be judged by whether the control plane can consistently reach the systems where privilege actually lives. That is where governance either becomes real or remains aspirational.

Connectivity is becoming a formal design criterion across IAM, IGA, and PAM. The same integration constraints that delay governance rollout also affect privileged access workflows, third-party access reviews, and workload onboarding. The implication is that programme owners need one view of connectivity risk across human, machine, and administrative identity paths, not separate fixes by team.

From our research:

• Only 13% of organisations feel extremely prepared for the reality of agentic AI despite the majority racing toward autonomous adoption, according to The 2026 Infrastructure Identity Survey.
• From our research: 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to The 2026 Infrastructure Identity Survey.
• For a broader governance lens, see the Ultimate Guide to NHIs for lifecycle, visibility, and control patterns that help close the gap between access intent and operational reality.

What this signals

Connectivity debt is becoming identity debt. As hybrid estates expand, the cost of delaying application connectivity shows up as incomplete governance coverage, not just slower projects. Teams that still rely on perimeter-style integration will find that IGA scope lags business change, especially where cloud, core banking, and regulated workloads coexist.

The next wave of governance programmes will be judged on whether they can extend control without widening trust boundaries. That means practitioners should review every integration path through a Zero Trust lens and be ready to justify why any target system remains outside governance coverage.

A practical marker of maturity is whether the programme can govern systems that were not designed for modern identity tooling in the first place. If the answer depends on static network exceptions, the governance model is still being shaped by infrastructure constraints rather than identity requirements.

For practitioners

• Map governance scope to reachable systems first Inventory which applications, databases, and core platforms cannot be governed today because of segmentation, firewall policy, or authentication constraints. Use that map to sequence onboarding and to separate true coverage gaps from process backlog.
• Prefer outbound-only integration patterns Select governance connectivity models that initiate outbound HTTPS connections and avoid inbound firewall openings where possible. That keeps the trust boundary narrower and reduces the operational drag created by network change approvals.
• Require enterprise-controlled cryptographic custody Verify that any gateway or connector supports customer-managed encryption keys and a clear custody model. In regulated environments, the ability to demonstrate control of the keys is part of the evidence that governance is truly under enterprise ownership.
• Align IGA rollout with Zero Trust architecture reviews Review whether the integration path creates broad network reach or application-scoped access. If the path looks like a stretched perimeter, rework it before expanding governance to additional systems, and align the design with NIST SP 800-207 Zero Trust Architecture.

Key takeaways

• Connectivity is a governance dependency, because identity controls cannot work on systems they cannot reach.
• Network-bound integration slows coverage, weakens auditability, and creates blind spots in hybrid estates.
• Outbound-only connectivity, customer-controlled keys, and Zero Trust alignment are the levers that make IGA scale credibly.

Key terms

• Identity governance connectivity: The practical ability of an IGA platform to reach the systems it is supposed to govern. In hybrid environments this includes network pathing, authentication constraints, and integration design. If the platform cannot connect securely, the governance control is incomplete even when the policy model is sound.
• Outbound-only connectivity: A connection model where the gateway initiates traffic outward rather than accepting inbound access from the network. It narrows the trust boundary, reduces firewall complexity, and better aligns with least privilege because the enterprise does not need to open broad inbound paths to support governance.
• Cryptographic custody: Who controls the encryption keys and related protection boundaries for sensitive integrations. In identity governance, custody matters because access to the data path is only part of the control story. If the enterprise does not own the keys, it may not fully own the trust model.

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 governance in your organisation, it is worth exploring.

This post draws on content published by Omada Identity: Securing and Scaling Identity Governance with the Cloud Application Gateway. Read the original.