Azure Bastion: Secure RDP and SSH Without Public IPs

Virtual machines with RDP or SSH open to the internet are among the most scanned and brute-forced assets in any cloud estate, and Azure Bastion exists so that administrators can reach those machines without a public IP on the VM at all. Bastion is a managed service deployed into your virtual network that brokers RDP and SSH sessions over TLS on port 443, then connects to the target VM over its private IP. Removing the exposed port is only half the job: who can reach Bastion, which identities can open sessions, how shareable links and native clients are governed, and whether sessions are logged and recorded decide whether Bastion is a control or just a different door. This guide covers the identity model, privileged roles, integrations, logging, a hardening baseline and the misconfigurations that recur. It is written for Azure platform engineers, cloud security architects and identity teams; for the wider choice between VPN, ZTNA and bastion patterns, see the Secure Remote Access Beyond VPN Guide.

This is an independent guide from NHI Mgmt Group, based on Microsoft's public documentation as of November 2026. It is not sponsored or reviewed by Microsoft. Product features change, so confirm settings against Microsoft's current documentation.

Key takeaways

• The SKU decides the security features you have. Session recording and private-only deployment need Premium; native client, shareable links, IP-based connection, custom ports and disabling copy and paste need Standard or higher; Developer is a shared, one-VM-at-a-time service Microsoft says is not suitable for production.
• Connecting needs only Reader roles. Microsoft documents Reader on the VM, its NIC, the Bastion resource and (for peering) the target virtual network, so the real gate is who holds those reads plus credentials for the guest OS. Scope them tightly and grant them just in time.
• Bastion does not remove the need for strong guest authentication. Users still sign in to the VM with a local account, an SSH key, Kerberos or Microsoft Entra ID; weak local passwords remain weak behind Bastion.
• Shareable links bypass the Azure portal sign-in. Anyone holding the link reaches the VM sign-in page, so treat link creation as a privileged action, set expiry dates and review the list.
• Logs are off until you route them. Enable the BastionAuditLogs diagnostic category, NSG flow logs and Activity Log export, and alert on configuration changes to the Bastion resource and its subnet NSG.

How identity and access work in Azure Bastion

Bastion sits between two separate authentication steps, and most design errors come from treating them as one. First, the user authenticates to Azure (portal or Azure CLI) with Microsoft Entra ID and needs Azure RBAC reads on the right resources. Second, the user authenticates to the guest operating system on the VM. Bastion carries the session; it does not replace either step.

Entra ID support varies by path. As documented at the time of writing, Entra ID sign-in works with the native client for RDP and SSH and in the portal for SSH; portal-based Entra ID for RDP is in preview and cannot be used at the same time as session recording. Entra guest (B2B) users can be granted Bastion access but cannot sign in to VMs with Entra authentication. Microsoft also notes that Kerberos is configured in the portal only, cross-realm authentication is not supported, and Bastion recognises only the first domain controller if more are added. Its own verification procedure is to set Network security: Restrict NTLM: Incoming NTLM traffic to Deny all domain accounts on the target, because enabling Kerberos alone does not stop fallback to NTLM.

Choosing a SKU and deployment model

Bastion comes in four SKUs: Developer, Basic, Standard and Premium. Upgrades take about ten minutes and downgrades are not supported (you delete and redeploy), so choose with the security features in mind.

• Small estates and labs: Developer is free but supports one VM at a time and no peering; Microsoft warns it is not for production. Use it to remove public IPs from test VMs, not as a production control.
• Production with audit duties: Microsoft's own SKU guidance describes the cost difference between Standard and Premium as marginal and recommends Premium for production. If an auditor or regulator expects privileged session evidence, Premium is the only tier with recording.
• Hybrid networks on ExpressRoute: private-only Premium removes the public IP entirely. Clients reach Bastion's private IP over ExpressRoute private peering or VPN, which requires IP-based connection, and Microsoft recommends the native client for end-to-end private connectivity.
• Hub and spoke: one Bastion in a hub or shared services network can serve directly peered spokes in the same tenant. Cross-tenant peering is not supported, and Bastion cannot be deployed inside a Virtual WAN hub (deploy it in a spoke and use IP-based connection).

Network prerequisites are strict. Dedicated SKUs need a subnet named exactly AzureBastionSubnet, /26 or larger for deployments since 2 November 2021, containing nothing else; a Standard SKU static public IP unless private-only; and no user-defined routes on that subnet. Advertising a default route (0.0.0.0/0) over ExpressRoute or VPN into the Bastion virtual network breaks the service, and private DNS zones named exactly management.azure.com, blob.core.windows.net, core.windows.net, vaultcore.windows.net, vault.azure.net or azure.com must not be linked to it. For private-only access, use the Premium SKU private-only deployment and confirm current Private Link options with Microsoft.

Admin roles and privileged access

Separate the people who run Bastion from the people who use it, and treat both as privileged.

• Bastion operators: deploying to the subnet needs Microsoft.Network/virtualNetworks/write, Microsoft.Network/virtualNetworks/subnets/join/action and rights on Microsoft.Network/publicIPAddresses. Whoever can change the Bastion resource can switch on shareable links, native client tunnelling or IP-based connection, or turn off recording by changing the storage target. Limit write on Microsoft.Network/bastionHosts to a small platform group and make it eligible, not active, through PIM. See the Privileged Identity Management (PIM) Guide.
• NSG owners: whoever can edit the NSG on AzureBastionSubnet or on target subnets can widen who reaches port 443 or open RDP and SSH from other sources. Hold NSG write to the same standard as Bastion write.
• Session users: Microsoft's guidance is to use PIM for just-in-time, time-bound Reader assignments on the VM, NIC, Bastion and peered virtual network. Pair this with guest OS rights: Remote Desktop Users rather than local Administrators where the task allows.
• Shareable link creators: creating and deleting links are separate actions (createShareableLinks/action, deleteShareableLinks/action, deleteShareableLinksByToken/action); viewing needs getShareableLinks/action. Grant creation only to named administrators.
• Recording reviewers: viewing recordings needs Storage Blob Data Reader on the recording storage. Recordings show everything typed and displayed in sessions, so restrict this role to the audit or security team and log access to the container.
• Administrator devices: Microsoft recommends privileged access workstations for production Bastion management. See the Privileged Access Workstations Guide.

Require MFA and compliant devices for Azure management sign-ins through Conditional Access, since Bastion inherits whatever assurance the Entra sign-in provides. See the Conditional Access Guide and the Azure Mandatory MFA guide.

Integrations, API tokens and service accounts

Bastion has few machine identities of its own, but the features around it introduce credentials that are easy to forget.

Logging and detection

Bastion produces four useful evidence streams, and none of the session-level ones is retained by default.

Add NSG flow logs on the Bastion and target subnets: the most valuable signal is RDP (3389) or SSH (22) reaching target VMs from any source other than the AzureBastionSubnet range, which means a path around Bastion exists. Microsoft also lists Defender for Cloud for failed-authentication patterns and Entra sign-in logs for risky sign-ins by Bastion users. Relevant ATT&CK techniques to tune detections against are T1133 External Remote Services, T1021.001 Remote Desktop Protocol, T1021.004 SSH, T1110 Brute Force and T1078.004 Cloud Accounts. For routing and retention, see the Azure Monitor, Activity Log and Diagnostic Settings Guide and the Microsoft Sentinel Guide.

Metrics that show the control is working:

• Number of VMs with a public IP and port 3389 or 22 reachable from the internet (target: zero outside documented exceptions).
• Percentage of RDP and SSH flows to production subnets that originate from AzureBastionSubnet.
• Percentage of Bastion session users holding access through PIM eligible assignments rather than standing roles.
• Active shareable links without an expiry date, and links older than 30 days.
• Percentage of production Bastion hosts with BastionAuditLogs routed to the SIEM, and with session recording enabled where required.

Hardening baseline

1. Inventory exposure first. List VMs with public IPs and NSG rules allowing 3389 or 22 from Internet or any source. This is the list Bastion is meant to shrink. See the Exposed RDP Compromise guide for why it matters.
2. Pick the SKU and topology. Premium for production where recording or private-only access is required; a hub Bastion serving peered spokes for most estates; Developer only for test.
3. Build the subnet and NSG. /26 or larger AzureBastionSubnet. If you apply an NSG, Microsoft states you must create all required rules: inbound 443 from Internet (or a narrower set of your public egress IPs), 443 from GatewayManager, 443 from AzureLoadBalancer, 8080 and 5701 VirtualNetwork to VirtualNetwork; outbound 22 and 3389 to VirtualNetwork, 443 to AzureCloud, 8080 and 5701 VirtualNetwork to VirtualNetwork, and 80 to Internet. Omitting rules can block platform updates.
4. Lock target subnets. Allow inbound 3389 and 22 only from the AzureBastionSubnet address range, deny from everywhere else, and remove VM public IPs.
5. Pilot with one workload. Assign PIM-eligible Reader roles to a pilot group, enable BastionAuditLogs and recording, and confirm sessions, Kerberos or Entra sign-in and file transfer work as expected before removing public IPs for the next ring.
6. Restrict optional features. Enable native client, shareable links, IP-based connection and file transfer only where there is a named need. Disable copy and paste for web clients on sensitive workloads (Standard or higher).
7. Configure recording safely. Dedicated storage account and container, managed identity authentication, no immutable policy or blob versioning on the recordings (Microsoft lists both as unsupported), CORS limited to the Bastion's bst- DNS name, and access restricted to reviewers.
8. Govern with policy. Use Azure Policy to audit or deny public IPs on VM NICs and NSG rules exposing management ports, and to require diagnostic settings on Bastion hosts. See the Azure Policy and Management Groups Guide.
9. Plan rollback. Keep a documented break-glass path (for example, serial console or a temporary just-in-time NSG rule from a fixed admin IP, approved and logged) for when Bastion is unavailable during maintenance, which Microsoft notes disconnects existing sessions.

Common misconfigurations

• Bastion deployed, public IPs left in place: teams add Bastion but never remove the VM public IP or the Internet-sourced NSG rule, so the brute-force surface remains. Exposed RDP has been a repeated entry point for ransomware; see the Remote Desktop (RDP) Security Guide.
• Subscription-wide Reader as the access model: because connecting needs only Reader, a broad standing Reader assignment quietly lets every reader attempt sessions to every VM they hold guest credentials for.
• Shared local administrator passwords: the Bastion log names the Entra user but the VM logs only show "Administrator", and a password reused across VMs turns one compromised session into many.
• Shareable links with no expiry: links handed to contractors for a one-off task stay live, and the holder needs no Azure identity to reach the sign-in page.
• Incomplete NSG on AzureBastionSubnet: applying an NSG with only port 443 inbound breaks GatewayManager or data plane rules, and the "fix" under pressure is often an allow-all rule.
• Recording that silently fails or leaks: immutable storage or blob versioning on the container, an expired SAS URL, or recordings readable by a broad group. Remember that native client sessions are not recorded at all, so allowing native client on a Premium host creates an unrecorded path.

Framework mapping

In ISO/IEC 27001:2022 terms, the same controls support Annex A 8.2 (privileged access rights), 8.5 (secure authentication), 8.15 (logging) and 8.20 (networks security).

Practitioner checklist

• Every production VM reachable for administration only through Bastion, with no public IP and no Internet-sourced 3389 or 22 rule.
• Production Bastion on a SKU that supports the features your audit duties need (Premium for recording or private-only).
• AzureBastionSubnet /26 or larger with the full documented NSG rule set, and target subnets accepting 3389 and 22 only from that range.
• Session access granted through PIM-eligible Reader assignments scoped per workload, with Virtual Machine User Login preferred over Administrator Login.
• Guest sign-in via Entra ID or Kerberos with NTLM fallback blocked; no shared local administrator passwords.
• Shareable link creation limited to named admins, every link with an expiry, reviewed monthly.
• Native client and IP-based connection enabled only where needed and only from managed admin devices.
• BastionAuditLogs, Activity Log and NSG flow logs in the SIEM, with alerts on Bastion feature and NSG changes.
• Session recording on managed identity, dedicated container, access limited to reviewers.
• Documented and tested break-glass path for Bastion outages.

Standards and references

• Microsoft Learn: What is Azure Bastion?
• Microsoft Learn: Secure your Azure Bastion deployment
• Microsoft Learn: Configure NSG rules for Azure Bastion
• Microsoft Learn: Choose the right Azure Bastion SKU
• Microsoft Learn: Azure Bastion FAQ
• Microsoft Learn: Configure Bastion session recording
• Microsoft Learn: Create a shareable link for Bastion
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: Secure Remote Access Beyond VPN Guide · Azure Virtual Network Security Guide · Microsoft Azure Security Guide · Privileged Access Management Guide