How should organisations secure remote access to high-performance workloads in Azure without relying on broad VPN access?

Why This Matters for Security Teams

Broad VPN access is a poor fit for high-performance workloads because it gives users a network path instead of a narrowly scoped entitlement. For Azure-based HPC environments, that usually means a single login can expose far more than the desktop, job scheduler, or dataset the user actually needs. Current guidance suggests treating access as a workload and resource authorization problem, not a perimeter problem, as reflected in the OWASP Non-Human Identity Top 10 and NHIMG’s Ultimate Guide to NHIs.

This matters because HPC users often need temporary access to sensitive compute nodes, storage, and supporting services, while administrators must preserve performance and limit lateral movement. NHIMG research shows that 97% of NHIs carry excessive privileges, which is exactly the pattern broad remote access tends to amplify. In practice, many security teams discover the real exposure only after a workload, secret, or storage path has already been overexposed rather than through intentional access design.

How It Works in Practice

The safer model is to authenticate the user strongly, then authorize access at the resource level so the session can reach only the approved desktop, workstation, or workload. In Azure, that typically means combining identity-aware access, just-in-time elevation, and narrowly scoped policy checks instead of dropping users into a broad internal network. The goal is to verify who the user is, what they are allowed to open, and which actions are permitted in that session.

For workloads that depend on automation or delegated access, workload identity becomes the key primitive. Rather than relying on long-lived secrets, teams should prefer short-lived tokens, ephemeral credentials, and policy evaluation at request time. The SPIFFE workload identity specification is useful here because it shifts trust from static network location to cryptographic identity, which aligns with modern NHI governance. For broader control design, the NIST SP 800-53 Rev. 5 Security and Privacy Controls supports least privilege, session control, and continuous enforcement.

• Use strong user authentication plus conditional access before any remote session starts.
• Grant access per desktop, node, job queue, or storage target, not to the whole subnet.
• Issue short-lived credentials for the task and revoke them automatically when the task ends.
• Prefer workload identity and token exchange over shared secrets or static service account keys.
• Log session start, resource access, and privilege changes so administrators can reconstruct the path later.

NHIMG’s Guide to SPIFFE and SPIRE is especially relevant when the remote user or agent needs cryptographic proof of identity across multiple services. These controls tend to break down when legacy HPC tools require shared accounts or fixed credentials because the platform cannot distinguish one task from another.

Common Variations and Edge Cases

Tighter remote access often increases operational overhead, requiring organisations to balance performance, supportability, and isolation. That tradeoff becomes sharper in HPC because some schedulers, license managers, and storage systems were never designed for per-request authorization, and best practice is evolving rather than fully standardized. The practical answer is usually a phased model that starts with the most sensitive workloads and gradually removes broad network reach.

One common edge case is vendor or research collaboration, where external users need temporary access to specific compute resources. Another is headless automation, where agents or job runners need access without a human session. In both cases, static group membership and standing VPN access usually outlive the task and create unnecessary exposure. NHIMG’s Ultimate Guide to NHIs — Key Challenges and Risks and the 52 NHI Breaches Analysis both reinforce how quickly overprivileged identities become incident pathways.

Where a full zero-trust design is not yet possible, current guidance suggests narrowing the blast radius first: remove shared admin paths, shorten credential lifetimes, and constrain access to named workloads rather than broad subnets. That approach preserves the performance users need while reducing the chance that one remote session can reach everything else in the environment.

Related resources from NHI Mgmt Group

• How should organisations control access to GPU-intensive and hybrid cloud workloads without relying on traditional VPN sprawl?
• How should security teams secure database access without relying on VPN trust?
• How should security teams govern remote access without recreating broad VPN trust?
• How should organisations move away from VPN-first remote access without weakening security?