Cloud application gateways make IGA connectivity a governance issue

At a glance

What this is: This is an analysis of how cloud application gateways change IGA connectivity from a network problem into a governance control issue, with the key finding that rigid connectivity models delay oversight and expand audit exposure.

Why it matters: It matters because IAM and IGA teams cannot govern what they cannot reach, so connectivity design now directly affects coverage, auditability, and the practical scope of identity governance programmes.

Context

Identity governance depends on reaching the applications and systems that hold access, entitlement, and audit evidence. In hybrid estates, that often means core business applications, legacy databases, and operational systems that sit behind strict network segmentation, firewall approvals, and VPN dependencies.

The article argues that connectivity is no longer just an infrastructure issue. When governance tooling cannot connect cleanly to the systems it is meant to oversee, unmanaged systems remain outside review, compliance evidence becomes incomplete, and Zero Trust goals stay theoretical rather than operational.

Key questions

Q: What breaks when IGA platforms cannot connect to core applications?

A: Governance breaks at the point of coverage. If the platform cannot reach the application, access reviews, entitlement collection, and lifecycle actions stay incomplete, which leaves systems outside oversight and weakens audit evidence. In practice, the control failure is not the policy model but the inability to operationalise it across the full estate.

Q: Why do VPN-based connectivity patterns create governance risk for IGA?

A: VPNs restore reach by extending network trust, not by narrowing it. That broadens the attack surface, makes connectivity harder to scale across hybrid estates, and can conflict with Zero Trust objectives because governance traffic inherits network-level privilege instead of application-scoped access.

Q: How should security teams evaluate whether gateway-based connectivity is working?

A: They should test whether the gateway can bring critical systems under governance without firewall exceptions, manual routing changes, or standing network access. If coverage still depends on recurring network approvals, the gateway has not removed the real operational bottleneck.

Q: What governance decision should teams make before adopting a cloud application gateway?

A: Teams should decide whether connectivity will be measured as an architecture choice or as a governance control. If the answer is both, the design must preserve least-privilege access, customer-controlled keys, and auditable reach to every in-scope application.

Technical breakdown

Why rigid network paths break identity governance coverage

Identity governance platforms need application-level reach to certify access, pull entitlement data, and trigger lifecycle actions. When that reach depends on static VPN tunnels or lengthy firewall approvals, the control plane becomes hostage to network change management. The result is not simply slower rollout. It is partial coverage, where some systems remain outside governance because integration is too hard to complete in a timely way. That makes identity governance behave like a perimeter project instead of an enterprise control layer.

Practical implication: map every governed system to its actual connectivity path before rollout, not after.

Why outbound-only gateways fit Zero Trust better than network tunnels

A cloud application gateway that initiates outbound-only HTTPS connections changes the trust model. Instead of extending a network perimeter inward through a tunnel, the gateway scopes access to the application and identity context needed for governance tasks. That is closer to Zero Trust because access is not granted broadly to a subnet or LAN segment. The distinction matters for IGA because governance should reach the target system without inheriting the privileges and blast radius of a network-level path.

Practical implication: prefer application-scoped connectivity patterns that avoid broad network exposure for governance traffic.

How customer-controlled keys affect governance assurance

The article places encryption-key ownership inside the enterprise control boundary, using vaults such as HashiCorp or Azure Key Vault as examples. That matters because auditability is not just about whether a gateway works, but whether the organisation retains cryptographic control over the data path and evidence flow. If the vendor owns the trust anchor, governance assurance weakens. If the customer owns the keys, the connectivity layer is easier to defend in audit and board scrutiny.

Practical implication: verify that the connectivity layer preserves enterprise key ownership and does not create external custody risk.

NHI Mgmt Group analysis

Connectivity is now part of the governance control surface: identity governance fails when the systems in scope cannot be connected on time, under control, and with defensible evidence. That is why network approval cycles, tunnel dependencies, and exception-driven access paths should be treated as governance blockers, not just infrastructure friction. The practitioner lesson is to define connectivity as a formal IGA prerequisite, not a downstream implementation task.

Zero Trust is undermined when governance relies on network-level shortcuts: a VPN can restore access, but it does so by widening the trust boundary rather than narrowing it. That creates a mismatch between the governance model and the transport model, especially in hybrid estates where core systems, cloud services, and legacy applications coexist. The implication is that IGA programmes should not accept perimeter-style workarounds as the default route to coverage.

Cloud application gateway design exposes a new governance pattern: application-scoped reach without network-scoped privilege. That is a useful concept because it separates the need to govern an application from the need to open the environment around it. In practice, this shifts the decision from 'can we connect?' to 'can we connect without expanding trust?' and that is a stronger question for identity leaders to ask.

Identity governance maturity should be measured by reachable coverage, not by platform ambition: a programme that cannot bring critical systems under review has not failed because the policy model is weak, but because the operational path to those systems is broken. Boards and auditors will judge the programme on scope, evidence, and consistency, not on the elegance of the architecture deck. The practical conclusion is that connectivity design now belongs in governance architecture reviews.

From our research library:

• Nearly 60% of IT leaders cite restrictive cost and complexity as a weakness of legacy identity governance, according to the 2025 State of Identity Governance Report.

What this signals

Connectivity is a governance dependency, not a convenience: identity programmes that defer network design until late in the rollout often end up with partial coverage and weak evidence. The practical shift is to treat application reachability as part of the control design, especially when regulated systems sit behind segmented networks.

Application-scoped reach is the more durable pattern for hybrid estates: governance tooling should connect to the system it manages without borrowing broad network privilege. That distinction matters because the more a programme depends on tunnels and exceptions, the less credible its Zero Trust posture becomes.

For practitioners

• Define connectivity as a governance prerequisite List the applications, databases, and operational systems that must be reachable before access reviews, certifications, or provisioning workflows can operate at scale. Treat unmet connectivity as a scope gap in the identity programme, not as a later integration ticket.
• Replace network-centric access paths with application-scoped paths For governed systems, avoid relying on broad VPN or subnet-level access where an application-level gateway can preserve tighter scope. The goal is to let governance traffic reach the target system without extending the enterprise perimeter.
• Validate who owns the encryption keys Confirm that the connectivity layer preserves customer-controlled key ownership and that the enterprise can defend the trust boundary during audit. If the path relies on external custody, document the exception and the residual risk.
• Prioritise high-value systems blocked by network approvals Start with core banking, clinical, or other regulated applications that are most likely to sit behind rigid network controls. Bringing those systems into governance first creates the clearest evidence of whether the connectivity model works.
• Measure governance coverage by reachable systems Track the proportion of in-scope systems that can actually be certified, provisioned, and audited through the governance platform. Coverage that depends on manual workarounds should be recorded as incomplete governance, even if the platform is technically deployed.

Key takeaways

• Identity governance cannot deliver full oversight when connectivity to core systems depends on delayed network approvals and rigid VPN paths.
• The article frames outbound-only application gateways as a way to reduce exposure while preserving the reach that governance workflows need.
• Practitioners should measure IGA success by the systems they can actually certify and audit, not by whether the platform is technically installed.

Key terms

• Identity Governance: Identity governance is the set of controls that defines who approves access, who owns it, how it is reviewed, and when it is removed. In practice, it turns identity management from a deployment task into a durable control system that can withstand audits, organisational change, and operational growth.
• Application-scoped policy: A policy model that grants access to a specific service or function instead of to an entire network segment. It reduces over-broad access and makes revocation more precise, especially in environments where internal tools are operationally sensitive and widely distributed.
• 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.
• Customer-controlled encryption: Customer-controlled encryption means the organisation, not the provider, controls the encryption keys used to protect its data. In regulated identity environments, this reduces provider-side exposure and helps preserve control when the platform is hosted outside the customer’s direct infrastructure.

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.