Identity-based cloud access removes the VPN rewrite tax

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Twingate's blog post: Cloud-native access control fails when identity decisions stop at IAM and the network layer still depends on VPNs, jump boxes, and static IP allowlists.

Why it matters: This matters because multi-cloud teams need access policy that follows identity, device posture, and resource scope across cloud boundaries without turning network topology into the control plane.

Context

Cloud-native access control fails when identity and network policy live in separate control planes. IAM can answer who a user is and what a workload may do, but it does not by itself govern how a private resource is reached over the network path. That gap is why teams end up stitching together VPNs, bastions, and IP allowlists that are hard to govern consistently.

In multi-cloud environments, the real problem is not lack of authentication. It is the mismatch between identity policy and legacy connectivity patterns that were designed before per-resource trust decisions became practical. Identity and access management basics only becomes operationally complete when the access path itself is governed, not just the API call or login event.

Key questions

Q: How does Zero Trust Network Access work for backup sharing?

A: Zero Trust Network Access for backup sharing creates an app-specific, identity-aware access path instead of exposing the backup network directly. It verifies the requesting user or workload, applies policy before connection, and usually allows only the backup service, port, and source identity approved for that session.

Q: Why do VPNs create overbroad access in multi-cloud environments?

A: VPNs often create overbroad access because they place a user or device inside a network boundary rather than granting application-level permissions. In multi-cloud setups, that network path can span many subnets, accounts and services, so access expands beyond what the user needs and becomes harder to align with policy drift and least privilege.

Q: How should teams offboard users from cloud access paths?

A: Teams should offboard users by removing cloud entitlements at the identity provider, revoking federated sessions, disabling privileged roles, and closing any time-bound grants tied to cloud consoles, APIs or bastion paths. They should also remove group membership, rotate shared secrets if used, and confirm that delegated access cannot be reactivated without reapproval.

Technical breakdown

Why cloud IAM stops short of private resource access

Cloud IAM governs permissions for cloud APIs, service principals, and workload-to-workload actions, but it does not natively decide whether a person on a specific device should reach a private database or admin interface. That decision sits in the connectivity layer, where traditional routing, firewalls, VPNs, and bastions still dominate. When identity policy stops at the cloud control plane, operators end up duplicating access logic across network controls that cannot evaluate identity context in real time. See the IAM and IGA Basics.

Practical implication: Treat private-resource reachability as a separate authorization problem and align it with identity-aware policy enforcement.

How zero trust network access changes the enforcement point

Zero Trust Network Access shifts access from topology-based exposure to identity-based authorization. Instead of placing a user on a network and filtering later, the system evaluates the user, device, and requested resource before establishing a resource-specific session. The important architectural change is that access is outbound-only from the private side, which removes the need for inbound exposure while preserving per-resource policy decisions. See the ZTNA Guide.

Practical implication: Use identity-driven resource policies to eliminate broad network access and reduce lateral movement opportunities.

Why DNS-based resource definition matters in multi-cloud

Defining access by DNS name rather than by subnet or static IP makes policy portable across AWS, GCP, and Azure. It decouples authorization from address space, so the same resource identity can remain stable even when infrastructure changes behind it. This also reduces the operational burden of updating security groups every time a service, environment, or connector placement changes. See the Multi-Cloud Identity Guide.

Practical implication: Model private services as named resources and govern access at that resource boundary instead of at the network range boundary.

Threat narrative

Attacker objective: The objective is to use a valid access path to reach more internal resources than the user or device should have been able to touch.

1. Entry occurs through the weakest available path when organizations expose private resources through VPNs, bastions, or static allowlists instead of identity-aware per-resource policy.
2. Credential or session abuse then grants the user broad network reach that is larger than the specific resource they actually need.
3. Escalation follows when that network reach can be reused for lateral movement across adjacent services that were never meant to share trust.
4. Impact is unauthorized discovery, overbroad access, and harder offboarding because the network path remains a standing control surface after identity changes.

Breaches seen in the wild

• Coupang Signing Key Breach: Unrevoked signing key credentials expose 33.7 million records after employee offboarding failure at Coupang.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Cloud-native access control fails when identity never reaches the resource boundary. Twingate's core point is not about replacing IAM, but about closing the gap between identity assertions and private-resource reachability. If the network layer still decides access through IP ranges, VPN membership, or bastion reach, identity governance remains incomplete. The practical conclusion is that resource authorization must be evaluated where the resource is actually consumed.

Identity-based connectivity is a governance model, not just a transport change. The important shift is that authorization becomes per-resource and context-aware, so device posture, group membership, and session state can matter at the point of access. That changes offboarding, contractor access, and cross-cloud operations because the policy now follows the identity rather than the subnet. The right lens is operational governance of access paths, not simply network modernization.

Standing network access is the wrong primitive for multi-cloud security. VPNs, jump boxes, and static allowlists all assume access should be granted to a network first and constrained later. That assumption breaks down when one cloud workload, one database, or one admin console needs tightly scoped reach without exposing the rest of the environment. Access request and approval workflow design becomes more effective when it issues resource-specific access instead of broad network membership.

Cloud-native access control needs to be measured by blast-radius reduction, not by topology preservation. The real benefit is not fewer firewall edits. It is that subnets can return to being routing and segmentation constructs instead of access-control mechanisms. For identity teams, this is where cloud IAM, device trust, and resource authorization finally converge into a governable model.

Multi-cloud identity sprawl becomes an access-path problem as much as an account problem. When one policy model spans AWS, GCP, and Azure, the control objective shifts from synchronising every network rule to maintaining a single identity source of truth for resource reach. That is why practitioners should treat cloud-native access control as part of identity governance, not as an adjacent networking convenience.

Read next: ZTNA Guide

What this signals

Identity-based access will increasingly replace network membership as the control unit. As more teams move to multi-cloud, the practical problem is not just who can log in, but which private resources a given identity can reach without widening the blast radius. The governance challenge shifts from firewall administration to policy design, session scope, and offboarding discipline.

Resource-level policy is the cleaner boundary for cloud operations. When access decisions are tied to named services, device posture, and IdP group state, platform teams can stop using subnets as an access-control workaround. That makes it easier to separate routing, segmentation, and trust decisions instead of forcing one network design to carry all three.

For practitioners

• Define private resources as identity-governed targets Replace subnet-level thinking with named resources, then attach access policy to each resource so reachability follows identity and not network address.
• Remove broad network exposure from private services Eliminate inbound firewall rules, bastion dependence, and static IP allowlists where a per-resource access model can enforce the same requirement more cleanly.
• Tie offboarding to access-path revocation Make group removal, policy sync, and session expiry part of the same offboarding workflow so users lose resource reach as soon as their role ends.
• Validate cross-cloud access with real identity context Test AWS, GCP, and Azure access using the same user, device posture, and group membership conditions so the policy behaves consistently across environments.
• Monitor the connector and policy control plane separately Track resource authorization logs, connector health, and identity sync failures as distinct signals because access can fail in different places than the traffic path.

Key takeaways

• Cloud-native access fails when identity policy and network reachability are governed separately, because the resource path remains outside IAM's visibility.
• The operational cost of VPNs, jump boxes, and static allowlists is policy sprawl across clouds, not just extra infrastructure.
• A resource-level identity model changes offboarding, auditability, and lateral movement risk by moving enforcement to the point of access.

Related NHI Mgmt Group resources: Access Request and Approval Workflow Design Guide · IAM and IGA Basics · ZTNA Guide · Multi-Cloud Identity Guide

Key terms

• Zero-Trust Network Access: Zero-Trust Network Access is a way to give users secure access to specific applications without placing them on the internal network. Access is granted only after identity, device posture, and policy checks, then limited to the requested resource. ZTNA reduces lateral movement by replacing broad network trust with per-session authorization.
• Static IP Allowlist: A static IP allowlist is a list of fixed IP addresses that are permitted to reach a system or service. It works by comparing the source address of each request against a maintained list, often at a firewall, load balancer or application gateway, so access depends on network origin rather than user identity.
• Private Resource: A private resource is an internal service or data endpoint that is not exposed directly to the public internet. It is usually reachable only through private networking, such as a VPN, peering link, private endpoint or internal load balancer, which limits exposure to trusted network paths.
• Bastion Host: A bastion host is an intermediary system used to reach protected internal resources. It centralises entry but also concentrates trust and availability risk, which means the design only works well when logging, offboarding, and recovery are tightly controlled.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management. It helps security and IAM practitioners connect identity policy to the access paths their programmes actually govern.