Azure Bastion Shareable Links: Secure VM Access?

Azure Bastion shareable links let you grant someone temporary, browser-based access to a specific virtual machine without giving them an Azure account or exposing the VM to the public internet. You create a link in the Azure portal, send it to the user, and they connect through Bastion using just their browser and the VM’s credentials. This article explains how shareable links work, how to configure them, their security implications, and common pitfalls to avoid.

What Are Azure Bastion Shareable Links?

Azure Bastion is a fully managed service that provides secure RDP and SSH connectivity to virtual machines directly in the Azure portal, over SSL. Normally, a user must have an Azure account with the appropriate RBAC permissions (e.g., Reader on the Bastion and Virtual Machine Administrator Login or Virtual Machine User Login) to connect. Shareable links change that model: they allow a user who does not have any Azure permissions to connect to a specific VM for a limited time, using only a URL and the VM’s local credentials.

The link is tied to the Bastion resource, the target VM, and a time window you define (from 30 minutes up to 8 hours). The user opens the link in a supported browser (Edge, Chrome, or Safari), enters the VM’s username and password (or SSH key if configured), and gets an RDP or SSH session inside the browser. The link is not a public URL—it is a signed URL that expires, and it can be revoked at any time by deleting the link in the portal.

How Shareable Links Work

Behind the scenes, Azure creates a signed token that encodes the Bastion resource ID, the target VM ID, and the expiration time. When the user opens the link, Azure validates the token, checks that the VM is running, and then proxies the connection through the Bastion service. The actual network path is:

• User’s browser → Azure Bastion (over HTTPS) → Target VM (via private IP, no public IP needed)

Because the connection is brokered by Bastion, the VM does not need a public IP address, and no inbound ports (RDP 3389 or SSH 22) need to be open on the NSG. The user never touches the VM’s network directly—only the Bastion service does.

Key technical points:

• The link is only valid for the duration you set (30 min to 8 hours). After expiry, the link returns an error.
• The link is tied to the VM, not the user. Anyone with the link and the VM’s credentials can connect.
• The link can be revoked manually before expiry by deleting it from the Bastion’s “Shareable links” page.
• The user does not need an Azure account or any RBAC role.
• The VM must be running and reachable by the Bastion (i.e., the Bastion must have network access to the VM’s private IP).

How to Create a Shareable Link

Creating a shareable link is done entirely in the Azure portal. You need the Network Contributor role on the Bastion resource (or a custom role with Microsoft.Network/bastionHosts/createShareableLinks/action). Steps:

1. Go to your Bastion resource in the Azure portal.
2. Under Settings, select Shareable links.
3. Click + Create.
4. Select the VM you want to share. Only VMs that are in the same virtual network as the Bastion (or a peered network with appropriate routing) will appear.
5. Set the Link validity (in hours or minutes, between 0.5 and 8 hours).
6. Click Create. The portal generates a URL and shows it in a list.
7. Copy the URL and send it to the user via a secure channel (email, chat, etc.).

You can create multiple links for the same VM with different expiry times. You can also delete a link at any time to revoke access immediately.

Security Considerations and Misconceptions

A common misconception is that a shareable link is a “backdoor” that bypasses all security. That is not true. The link still requires the VM’s local credentials (username/password or SSH key). The link only grants network-level access to the VM’s RDP/SSH port through Bastion—it does not grant any Azure RBAC permissions. The user cannot see the VM in the portal, cannot delete it, and cannot access other VMs in the same network.

However, there are real security risks:

• Credential exposure: If the VM uses weak passwords, anyone with the link can try to brute-force them. Bastion does not add extra login throttling beyond what the OS provides.
• Link leakage: If the link is forwarded to someone else, they can use it. There is no way to restrict by email or IP address.
• Lack of audit: The link itself does not log who used it. You can see that a connection was made via Bastion, but not which user authenticated (unless you enable bastion diagnostics and OS-level logs).
• No MFA integration: Shareable links do not support Azure AD authentication or multi-factor authentication. The only authentication is the VM’s local account.

For these reasons, shareable links are best for short-term, break-glass access (e.g., a contractor needs to fix something for an hour) rather than routine access. For routine access, use Bastion’s native Azure AD integration or just-in-time access via Microsoft Defender for Cloud.

Common Issues and Troubleshooting

If a user reports they cannot connect, check these common issues:

• Link expired: The link is only valid for the set duration. If it expired, create a new one.
• VM is stopped: The VM must be running. Bastion cannot start a stopped VM.
• Network connectivity: The Bastion must be able to reach the VM’s private IP. Check that the VM’s NSG allows inbound RDP/SSH from the Bastion’s subnet (usually the AzureBastionSubnet). Also, if the VM is in a peered network, ensure that peering is set up correctly and that the Bastion’s subnet has route to the VM’s subnet.
• Browser issues: Shareable links require a supported browser (Edge, Chrome, or Safari). Internet Explorer is not supported. Also, the browser must allow pop-ups and WebSocket connections.
• Credentials: The user must have a valid local account on the VM. If the VM is domain-joined, they may need to use the domain\username format. Also, if the account is locked out or the password is expired, the connection fails.

If the link was deleted, it will show as “Invalid” in the user’s browser. You can always regenerate a new link.

Costs and Limits

Azure Bastion has a pricing model based on the number of Bastion instances (scaling units) and outbound data transfer. Shareable links themselves do not incur an extra charge beyond the Bastion’s base cost. However, each active session uses one of the Bastion’s concurrent session slots. The default limit is 25 concurrent sessions per Bastion instance, but you can scale out by adding more instances (each adds 25 more slots). If you expect many users to connect simultaneously, ensure you have enough instances.

There is also a limit on the number of shareable links you can create per Bastion resource (currently 500). If you need more, you must delete old links or use a different approach.

Alternatives to Shareable Links

Shareable links are not the only way to grant temporary access. Consider these alternatives based on your needs:

• Native Bastion with Azure AD authentication: If your VMs are Azure AD-joined, you can use Azure AD credentials to log in. This supports MFA and conditional access, and you can assign specific users via RBAC. This is more secure but requires the VM to be Azure AD-joined and the user to have an Azure AD account.
• Just-in-Time (JIT) VM access: Microsoft Defender for Cloud’s JIT feature opens the NSG port (RDP/SSH) for a limited time for a specific user, but the user still needs an Azure account and RBAC permission to connect via Bastion or directly.
• Azure Virtual Desktop (AVD): For full remote desktop experience with identity management, AVD is a more feature-rich (but more expensive) solution.
• VPN or ExpressRoute: For long-term or high-frequency access, a site-to-site VPN or ExpressRoute gives users direct network access, but then you must manage firewalls and user access.
• Third-party PAM tools: Tools like CyberArk or HashiCorp Vault can broker access with session recording and approval workflows, but they add complexity and cost.

Choose the solution based on the user’s identity, the sensitivity of the VM, and how often access is needed.

Frequently Asked Questions

Can I create a shareable link for a VM that has no public IP? Yes, that is the primary use case. The VM only needs a private IP that the Bastion can reach. The user connects via Bastion, not directly to the VM.

Does the user need an Azure account to use a shareable link? No. The user only needs the link and the VM’s credentials. They do not need to sign in to Azure at all.

Can I set a custom expiration time? Yes, you can set any duration between 30 minutes and 8 hours. After that, the link becomes invalid.

Can I revoke a shareable link before it expires? Yes, you can delete the link from the Azure portal at any time. This immediately invalidates it.

Does the shareable link work for both RDP and SSH? Yes, the same link works for both protocols. The user selects the protocol in the Bastion login page, depending on what the VM supports.

Is the connection encrypted? Yes, the connection from the user’s browser to Bastion is over HTTPS (TLS). The connection from Bastion to the VM is over the Azure backbone using RDP or SSH, which are also encrypted.

Related

• Prevent Identity Theft on Internet: 12 Steps
• Humanoid Robot Buying Guide for Businesses
• SSH Session Manager vs Azure Bastion: Which Path?