Azure Bastion Adds Managed Identity Support for Session Recording, Cutting the SAS Token Maintenance Burden

Azure Bastion's Premium SKU has carried graphical session recording for a while now, capturing every RDP and SSH session end to end and storing it as a browser-playable video. The feature does real work for security teams: it produces an audit trail of administrative activity, preserves forensic evidence for incident response, and gives visibility into who touched what across privileged access paths. The weak point was never the recording itself. It was how Bastion authenticated to the storage account holding those recordings.

With the recently announced Public Preview of Managed Identity support for graphical session recording, Microsoft has addressed that weak point directly. Bastion can now write recordings to a designated storage account using a Microsoft Entra ID managed identity instead of a Shared Access Signature URL. If you advise organizations on cloud security posture, this is one of those updates where the operational difference outweighs the headline.

What changed

Previously, enabling session recording meant choosing exactly one authentication method to your storage account: a SAS URL. You generated a time-limited token scoped to a blob container, pasted it into the Bastion session recording blade, and Bastion used that URL to upload recordings for every session. It worked, but it carried the structural problems that come with any long-lived shared secret.

Managed Identity is now a second, fully supported option. Bastion's system-assigned or user-assigned identity authenticates to storage through Entra ID tokens, and Azure handles issuance, refresh, and lifecycle automatically. Role-based access control governs what that identity can do, scoped through a single role assignment rather than a manually minted token.

The prerequisites for the feature itself remain unchanged. You still need the Premium SKU, since Developer, Basic, and Standard tiers do not support session recording. You still need a General Purpose v2 storage account in the same region as Bastion. And users who need to play back recordings still require Blob Data Reader on the storage account. What changed is only how Bastion writes the data.

Provider comparison: SAS URL versus Managed Identity

It helps to look at both options side by side, because the comparison is really a comparison of two credential models that show up across every cloud platform, not just Azure.

SAS URL is the bearer-token model. A Shared Access Signature is a URI granting restricted, time-limited access to storage. For session recording you generate one scoped to your container with Read, Create, Write, and List permissions, set a start and expiry date, and hand the resulting Blob service SAS URL to Bastion. Anyone holding that URL has the access it encodes, for as long as it remains valid.

The practical costs of the SAS approach accumulate at scale:

• Expiry overhead. SAS tokens expire on a fixed schedule. When one lapses, Bastion can no longer write recordings, and the failure is silent. Your audit trail stops until someone notices and mints a replacement. For a compliance control, a gap nobody sees is the worst kind.
• Exposure risk. A SAS URL accidentally logged, pasted into a ticket, or shared in chat grants write access to your storage account to whoever finds it.
• No Entra identity. SAS tokens provide preauthorized access that bypasses Entra RBAC entirely. That means no Conditional Access enforcement, no identity-based restrictions, none of the controls your security team relies on elsewhere.
• Manual rotation. Unlike secrets in Key Vault with automated rotation, SAS tokens need a person or a custom pipeline to regenerate them and update the Bastion configuration on a recurring cadence.

Managed Identity is the workload-identity model. Bastion's managed identity, registered with Entra ID, authenticates with platform-issued tokens that carry no secret you ever see or store. Access is granted through a single RBAC assignment: the Storage Blob Data Contributor role on the storage account. Azure rotates and refreshes the underlying tokens for you.

The benefits map almost one to one against the SAS drawbacks. There are no credentials to leak or rotate. There is no silent-failure mode from token expiry, because the recording pipeline keeps authenticating without intervention. The identity is visible in Entra access reviews and governable through standard permission controls. And because uploads happen under a real, auditable identity rather than an anonymous token, the control aligns far better with compliance frameworks that expect attributable access.

Setting it up

The configuration path for Managed Identity is short. Start in your storage account, expand Settings, and open Resource sharing (CORS) to create a Blob service policy with the values Bastion's playback requires. Then move to the Bastion resource, open Identity, and toggle the system-assigned identity to On. Azure generates an object (principal) ID, the unique identifier registered with Entra ID for that identity.

In the Bastion session recording configuration, select either System Assigned or User Assigned Managed Identity, choose the container for recordings, and confirm the Blob Container URI is correct before applying. The final step is the RBAC grant. Under the identity's Azure role assignments, add a new assignment scoped to your subscription and target storage account, and assign the Storage Blob Data Contributor role. Save it, and Bastion will use that identity to upload recordings from then on. Completed recordings appear under the Session recordings blade, playable in the browser.

Compared with the SAS flow, where the equivalent step is generating a token you will have to come back and regenerate later, this is a one-time setup. That asymmetry is the whole point.

Business impact

For anyone running privileged access at enterprise scale, the migration consideration is straightforward and the direction is clear. Session recording is frequently tied to a regulatory or contractual obligation, which means a silent recording gap is not just an operations annoyance, it is a potential compliance finding. The SAS model puts that obligation at the mercy of a calendar reminder and a manual token refresh. Managed Identity removes the human dependency entirely.

There is also a security-posture argument that matters beyond Bastion. Moving storage authentication onto Entra ID brings session recording under the same identity governance you already apply to everything else: access reviews, RBAC scoping, and audit logging of which identity did what. SAS tokens sit outside all of that by design. Every long-lived shared secret you can retire is one fewer credential to inventory, rotate, and worry about leaking.

The migration itself is low-friction. Because both options write to the same storage container structure, teams already using SAS can stand up the managed identity, grant the role, switch the Bastion configuration, and let the old token expire without disrupting playback of existing recordings. For new Premium deployments, there is little reason to choose SAS at all unless an external constraint forces it.

The feature is in Public Preview, so the usual caveat applies: validate it in non-production first and keep preview status in mind for workloads under strict change control. But the trajectory is unambiguous. Azure is steering Bastion session recording toward the same credential-free, identity-governed model it has been pushing across the rest of its storage and compute services, and for production environments that is the configuration worth standardizing on. For the full walkthrough, Microsoft's Record Bastion sessions documentation covers both authentication paths in detail.