What breaks when regulated cloud access still relies on VPNs and bastions?

Why VPNs and bastions break cloud access evidence

VPNs and bastions are often treated as a control boundary, but in regulated cloud environments they usually become a visibility boundary instead. Once access is funneled through a shared tunnel or jump host, the security story shifts from “who got what access, to which resource, and under what approval” to “someone connected and we reconstructed the rest later.”

That gap matters because cloud regulation and audit expectations are increasingly evidence-led. If the control does not generate clean identity, session, and privilege records at the moment access is granted, the organisation has to stitch together logs from the network edge, the jump host, the cloud control plane, and the target service after the fact.

This is why the problem is not only technical. A bastion may prove that a connection occurred, but not always which effective permissions were exercised inside the cloud environment. A VPN may prove a user entered the network, but not whether the session was bounded to a specific role, account, workload, or environment with sufficient precision for compliance review.

Why privilege and attribution become harder to defend

Regulated cloud access needs attribution that survives scrutiny. When many people traverse the same ingress point, the organisation loses the clean chain between approved identity, approved purpose, and actual action taken. That makes it harder to answer basic questions such as whether the operator used the right role, whether elevation was temporary, and whether the session was constrained to the intended scope.

This is where Cloud PAM and CIEM Guide becomes useful: cloud privilege should be judged on effective permissions and just-in-time elevation, not on the presence of a tunnel or hop host. If the access path obscures what was actually activated, the reviewer is left inferring privilege from logs instead of evidencing it directly.

Legacy remote access also tends to flatten differences that regulators care about. A contractor, an administrator, and an emergency responder may all land on the same bastion, even though each should have distinct approval, session scope, and audit treatment. That is a governance failure as much as an access design failure.

What better regulated cloud access looks like

The stronger pattern is to make access decisions visible at issuance and enforce them at the control point closest to the cloud resource. In practice, that means pairing identity-aware access, short-lived privilege, session recording, and environment scoping so the evidence trail is produced as a by-product of access rather than reconstructed later.

Remote Access Identity Guide is relevant because it frames remote access as an identity problem, not just a network-routing problem. For regulated environments, that distinction matters: if access can be tied to user, device posture, MFA, and destination scope at entry, the audit narrative becomes far easier to defend.

The practical objective is not to eliminate every remote entry point immediately. It is to retire access paths that hide effective privilege, merge distinct user populations, or force compliance teams to infer control operation from indirect network evidence. Where a VPN or bastion remains, it should be treated as a constrained exception with explicit session logging, role binding, and tight blast-radius limits.

What breaks when you keep the old pattern

The first thing that breaks is evidence quality. The second is accountability. The third is the ability to prove that access was proportionate to the request, because the organisation can no longer show the exact privilege state that existed during the session.

That is why NIST SP 800-207 Zero Trust Architecture is a strong fit here: it pushes verification, least privilege, and resource-level decisioning closer to the transaction instead of trusting the network path. For regulated cloud access, that shift is the difference between a control that merely permits entry and a control that can actually be evidenced.

VPNs and bastions also become problematic when they are shared across tenants, environments, or business functions. In that case, one compromise or one poor exception can create a wider trust boundary than the cloud model was designed to tolerate. The longer the organisation relies on these choke points, the more likely it is to accumulate invisible exceptions that are expensive to unwind later.

Practitioner Guidance

What to verify: Confirm whether every regulated cloud session can be tied to a named identity, an approved role, a bounded destination, and a time-limited privilege state without manual log stitching. If the answer depends on human reconstruction, the control is too weak for audit-grade evidence.

Decision rule: If the VPN or bastion is the only place where access can be approved, logged, and attributed, treat that as a migration signal rather than a stable target state. Keep it only when it adds a measurable control layer, not when it is merely the path of least operational resistance.

What practitioners underestimate: The hardest part is usually not connectivity, it is proving that the access was necessary, correctly scoped, and revocable at the moment it occurred. Once those facts are implicit, the organisation has already lost the strongest compliance evidence.

Practitioner takeaway: Regulated cloud access should generate its own proof. If your access path cannot show identity, privilege, and session scope without after-the-fact correlation, it is functioning as a convenience layer, not a defensible control.

Related resources from NHI Mgmt Group

• What breaks when privileged access still depends on VPNs and bastion hosts in hybrid cloud?
• What breaks when cloud access reviews are still run like on-premise recertifications?
• What breaks when cross-cloud access still depends on long-lived secrets?
• What breaks when a BYOC model still relies on standing vendor access?