A hardened jump host can reduce the exposure of Azure Local administration, but it is not automatically Microsoft Azure Bastion. “Bastion” describes an architectural pattern; Azure Bastion is a specific Azure service with documented deployment and connectivity requirements.
For Azure Local, start with the access outcome: administrators need a controlled path to the Azure control plane, Azure Local hosts, Windows Admin Center, guest consoles, RDP or SSH endpoints, and supporting network or identity systems. The design should keep management endpoints private, minimize standing privilege, restrict lateral movement, and create evidence of who performed each action.
TL;DR
- Do not expose RDP, SSH, WinRM, Windows Admin Center, or host-management interfaces directly to the internet.
- Distinguish Azure portal and Azure RBAC access from Azure Local host access and guest operating-system access.
- Call a self-managed server a hardened administrative jump host or gateway—not Azure Bastion—unless the design is actually using the Azure Bastion service in a supported architecture.
- Use a dedicated management segment, deny-by-default rules, narrow destination ports, separate administrative accounts, strong authentication, and secure administrative devices.
- Apply Conditional Access to supported Microsoft Entra applications and Azure management actions; a firewall or NSG cannot identify “Entra-authenticated packets.”
- Collect Azure activity, identity, endpoint, host, gateway, and network evidence in a time-synchronized monitoring system.
Define the three access paths
1. Azure management-plane access
Azure Local resources and Azure Local VMs enabled by Arc can be managed through supported Azure interfaces. Microsoft Entra ID authenticates the user, and Azure RBAC authorizes resource actions at the applicable scope.
This path covers supported portal, CLI, PowerShell, ARM/Bicep, and API operations. It does not automatically grant an interactive guest session or local administrator rights inside a VM.
2. Platform and fabric administration
Azure Local hosts, cluster functions, Windows Admin Center, PowerShell, networking, and storage operations have platform-specific access paths. Some actions are available in Azure; others use local tools. Microsoft’s supported-operations guidance warns that mixing local and Azure control-plane changes can create synchronization problems for certain Azure Local VM properties.
Document which interface is authoritative for every operation.
3. Guest and application administration
RDP, SSH, VM console, database administration, and application consoles authenticate through the guest or application’s supported identity system. That might be AD DS, local identity, SSH certificates or keys, a privileged-access product, or a documented Microsoft Entra integration.
Do not assume that an Azure RBAC role equals guest administrator access.
Choose the access pattern
Use the narrowest supported path that meets operational and recovery requirements.
| Pattern | Appropriate use | Key controls |
|---|---|---|
| Azure portal and supported Arc/Azure Local operations | Routine resource lifecycle and governance | Entra authentication, Conditional Access where applicable, Azure RBAC, PIM, activity logs |
| Windows Admin Center in Azure for Arc-enabled Windows Server | Browser-based management of supported Arc-enabled Windows Servers without a VPN, public IP, or inbound RDP | Supported OS and Arc configuration, Entra/RBAC controls, extension health, logging |
| Windows Admin Center gateway on a private management network | Local or private administration of hosts and VMs | Private connectivity, gateway hardening, certificate management, role separation, restricted source devices |
| Hardened jump host | Tools or protocols that require a controlled interactive admin station near the managed systems | No public management ports, tiered accounts, PAW controls, application allowlisting, session evidence |
| Direct private administration | Emergency or narrowly scoped operations from an approved secure workstation | Private route, explicit firewall rules, time-bound authorization, detailed logging |
Windows Server Management enabled by Azure Arc documents Windows Admin Center in Azure for supported Arc-enabled Windows Servers as a remote-management option without requiring a VPN, public IP address, or other inbound connectivity. Validate the target OS, Arc state, licensing, region, and operation before adopting it as the primary path.
Reference architecture
Administrative device zone
Use a managed, hardened workstation for privileged work. It should have strong device identity, current security controls, restricted software, protected credentials, and no routine email or web use for high-impact administration.
Identity and privilege plane
Start with a documented hybrid identity for Azure Local so source authority, synchronization, authentication, authorization, and privileged access have explicit owners.
- Separate daily-use and administrative identities.
- Assign Azure roles to controlled groups at the narrowest practical scope.
- Use Privileged Identity Management when available to make access eligible, time-bound, approved, and auditable.
- Use phishing-resistant authentication for privileged Entra access.
- Maintain tested emergency access that does not depend on the same failing component it must recover.
- Keep AD DS, Azure, host, network, and workload privilege tiers explicit.
Access gateway zone
If a jump host or Windows Admin Center gateway is required, place it in a dedicated management segment. It should not host normal workloads, browse the internet freely, receive email, or share credentials with managed systems.
Harden the operating system, restrict installed tools, use a supported endpoint-security platform, rotate secrets, patch through a controlled process, and capture administrative events. Avoid persistent credentials, shared local accounts, and plaintext passwords in templates or scripts.
Managed-system zones
Separate Azure Local hosts, management appliances, guest workloads, backup infrastructure, identity systems, and security tooling where risk warrants it. Permit only required flows from approved gateways or devices.
Network policy: identity is not a packet attribute
An NSG, host firewall, or physical firewall evaluates network properties and the capabilities of that enforcement point. It does not normally know that a random RDP packet came from an “Entra-authenticated user.”
The broader Zero Trust architecture with Entra and SDN guide connects this network boundary to device, identity, workload, and monitoring controls.
Build policy in two linked layers:
- Identity policy controls who may activate a role or sign in to a supported resource.
- Network policy controls which managed device or gateway may reach which private endpoint and port.
A conceptual rule matrix follows:
| Source | Destination | Service | Default |
|---|---|---|---|
| Approved admin-device network | Access gateway | HTTPS or approved remote-management protocol | Allow only from managed sources |
| Access gateway | Azure Local management endpoints | Exact documented management ports | Allow narrowly |
| Access gateway | Guest administration network | RDP/SSH/WinRM only where required | Time-bound or policy-controlled |
| Guest workload networks | Management networks | Any | Deny |
| Internet | RDP/SSH/WinRM/WAC/host management | Any management service | Deny |
| Management systems | Logging, identity, DNS, NTP, update and security services | Documented service ports | Allow and monitor |
Resolve the exact ports from current product documentation and the deployed features. Do not copy a universal port list into production without packet-flow validation.
Do not publish insecure infrastructure examples
The prior article used native Azure VM and virtual-network resources as if they deployed directly to Azure Local and embedded a plaintext administrator password. Replace those examples with principles and links to the current Azure Local workflow.
Azure Local VM management uses Azure Arc resource bridge, custom locations, and Azure Local-specific VM resources. The supported portal, CLI, PowerShell, ARM/Bicep, and Terraform methods vary with the Azure Local release.
Any production automation should:
- use the current Azure Local resource provider and API version;
- reference secrets through an approved secret-management path;
- avoid passwords in source control, command history, deployment output, and templates;
- use least-privilege deployment identities;
- validate supported network, image, disk, and VM operations for the deployed version;
- create logs sufficient to reconstruct the change.
Authentication and Conditional Access boundaries
Conditional Access can require controls when an identity accesses a supported Microsoft Entra resource. Apply it to Azure portal access, privileged activation, Windows Admin Center in Azure where supported, and other documented Entra-integrated applications.
See Conditional Access architecture and limitations for the supported identity boundary and the private network controls that must complement it.
For local RDP or SSH, separately define guest authentication, source-device requirements, credential protection, network access, session control, and logging. Windows Server does not acquire a universal interactive Entra sign-in capability merely because it runs on Azure Local or is connected to Azure Arc.
Logging and evidence
Collect enough evidence to follow one administrative session across layers:
For one regulated-workload application of these controls, see the healthcare identity and security example.
- Microsoft Entra sign-in and Conditional Access results;
- PIM activation and Azure role changes;
- Azure Activity Log and relevant resource diagnostics;
- Windows Admin Center or gateway authentication and action logs;
- host and cluster administrative events;
- guest Windows security or Linux authentication logs;
- endpoint detection and response telemetry;
- firewall, network-controller, and flow telemetry supported by the deployed platform;
- privileged-access session records where used;
- DNS, NTP, certificate, and agent-health evidence.
Use Azure Monitor Agent for supported guest OS data collection rather than the retired Log Analytics agent. Configure data collection rules, retention, access, and cost controls deliberately. Microsoft Defender features may use different agents or agentless capabilities; validate each feature rather than assuming one agent supplies every security signal.
Failure and recovery tests
Test these scenarios before production approval:
- The Azure control plane or WAN is unavailable.
- Microsoft Entra authentication is unavailable or a Conditional Access policy blocks administrators.
- AD DS or DNS is impaired.
- The Windows Admin Center gateway or jump host is unavailable.
- A privileged workstation is lost or compromised.
- Certificates expire or secrets are rotated.
- Logging is unavailable or delayed.
- The management segment is isolated by an incorrect rule.
For each scenario, document the safe local path, emergency authority, required credentials, audit trail, and steps for returning to normal controls. An emergency path that is never tested is not a recovery control.
Implementation sequence
- Inventory every administrative endpoint, protocol, identity provider, role, and operator.
- Classify actions by Azure control plane, Azure Local fabric, guest, network, storage, backup, and identity system.
- Remove public exposure and build private routes from approved administrative devices or gateways.
- Create dedicated accounts and narrow group-based roles.
- Harden the administrative device and gateway images.
- Implement deny-by-default segmentation and document every exception.
- Configure supported telemetry and time synchronization.
- Test normal, elevated, emergency, and disconnected operations.
- Review access and evidence regularly; expire unused rules and privileges.
Final architecture principle
Secure remote administration is a chain, not a server. The chain begins with a trusted administrator and device, passes through identity and authorization controls, traverses a private and narrowly filtered network path, reaches the correct management plane, and leaves evidence at every step.
If any link is vague—especially the distinction between Azure access, host access, and guest access—the design is not ready for production.