An access pattern where traffic is brokered or redirected through cloud infrastructure before reaching a target resource. It can simplify remote access, but it also introduces dependency on the brokered path for latency, availability, and control evidence.
Expanded Definition
Cloud-routed access describes an access path where authentication, policy enforcement, inspection, or session brokering occurs through cloud services before a user, workload, or autonomous system reaches the protected resource. It is not simply remote access delivered over the internet. The defining feature is that the cloud layer becomes part of the control plane and often part of the data path, creating a managed intermediary for routing, logging, and policy decisions.
In security operations, this pattern is often used to reduce direct exposure of internal systems, centralise access policy, and improve visibility across distributed environments. However, definitions vary across vendors and architectures: some products use the term to mean cloud-based remote access brokering, while others include proxy-based inspection, identity-aware access, or software-defined perimeters. For a security team, the important distinction is whether the cloud path is optional transport or a required trust and enforcement layer. NIST guidance on control implementation, especially NIST SP 800-53 Rev 5 Security and Privacy Controls, is useful when assessing logging, access enforcement, and boundary protection expectations.
The most common misapplication is treating cloud-routed access as if it were merely a connectivity convenience, which occurs when organisations ignore the security and availability dependency created by the brokered path.
Examples and Use Cases
Implementing cloud-routed access rigorously often introduces dependency on provider availability and path performance, requiring organisations to weigh simpler administration against added routing and trust complexity.
- Remote administrators connect to an internal management console through a cloud access broker that enforces MFA, device posture, and session recording before forwarding the session.
- An engineering team reaches private repositories and build systems through a cloud proxy rather than exposing VPN ingress directly to the corporate network.
- Contractors access a sensitive application via identity-aware cloud routing that limits which application paths are visible after authentication.
- Non-human identities, such as CI/CD agents or API clients, use cloud-mediated access to retrieve secrets or reach internal APIs, which connects this pattern to OWASP Non-Human Identity Top 10 concerns around governance, rotation, and over-privilege.
- An incident response team temporarily shifts privileged access through cloud routing to preserve audit trails while isolating direct network paths during containment.
Why It Matters for Security Teams
Cloud-routed access changes where trust is established, how access is observed, and which systems must stay available for users to work. If the routing layer fails, access can fail with it, even when the target resource is healthy. If the broker is weakly governed, it can become a high-value control bypass point. Security teams therefore need to treat routing policy, identity assurance, logging, and session controls as part of one access architecture rather than separate tools.
This matters especially in environments that blend human access, privileged administration, and NHI traffic. A cloud-routed model can improve evidence collection by making every connection inspectable, but only if logs are complete and policy decisions are durable enough to support investigation and compliance review. It also raises questions about failover, jurisdiction, and who can alter routing rules. Those questions become sharper when cloud routing is used for privileged sessions or for agentic systems that need continuous access to tools and APIs.
Organisations typically encounter the operational and governance burden only after an outage, a failed audit, or a suspicious access event, at which point cloud-routed access becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-53 Rev 5 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-1 | Cloud-routed access depends on controlled identities and authenticated access decisions. |
| NIST SP 800-53 Rev 5 | AC-4 | Boundary and flow control are central when cloud infrastructure brokers access to a target. |
| OWASP Non-Human Identity Top 10 | Cloud-routed access often mediates NHI traffic, especially for agents and service identities. | |
| NIST AI RMF | Agentic systems using cloud-routed access need governance over tool access and accountability. |
Govern NHI access through the broker with least privilege, rotation, and traceable ownership.
Related resources from NHI Mgmt Group
- What breaks when healthcare access is routed through centralized VPN or cloud-brokered paths?
- Who is accountable when a cloud-routed access broker fails or is compromised?
- How should teams govern Oracle ERP Cloud access beyond native controls?
- When does cloud service access become a command-and-control risk?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on July 11, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
