Record Azure Bastion sessions only with a governed evidence lifecycle

Bottom line: Azure Bastion session recording can capture graphical RDP and SSH sessions and store recordings in an Azure Blob container. Microsoft documents that enabling recording on a Bastion host records all sessions through that host. The recording is sensitive administrative evidence and needs a defined purpose, notice, access model, retention, and incident process before enablement.

Source fact: what Microsoft documents

Microsoft’s Bastion session-recording guide says the feature requires the Premium SKU and records graphical sessions made through the recording-enabled bastion host. After a session closes or disconnects, the recording is stored in a configured Blob container and can be viewed from the Azure portal.

The page lists operational constraints. Session recording is not available through the native client, cannot currently be used concurrently with the documented Entra ID portal RDP scenario, supports one storage account and container at a time, and records all sessions when enabled. The storage container must not have blob versioning or immutable storage policies according to the source. Microsoft labels managed-identity storage authentication as the recommended Preview path and also documents SAS URL configuration; the page specifies the storage roles required for writing and viewing.

What the source does not establish

A recording does not capture activity outside the graphical session, prove the operator’s intent, prevent misuse, or replace command, guest, Azure Activity, and application logs. It does not guarantee a recording is complete if storage, identity, Bastion, browser, or session connectivity fails. Because the documented storage design excludes immutability and versioning for the recording container, separate controls are needed for protected preservation when evidence must be retained.

Applicability questions

• What security, support, legal, or quality purpose justifies recording, and what notice or consent is required?
• Which Bastion hosts, VMs, RDP and SSH sessions, native clients, and Entra sign-in modes are in scope?
• Who can write, list, view, copy, delete, or administer the storage container?
• What retention and deletion schedule applies, and how is a relevant recording placed under incident hold?
• What happens if storage access, managed identity, SAS, or the container fails during a privileged session?

DSE recommendation: controlled next steps

The following steps are DSE recommendations based on the cited source.

1. Obtain security, privacy, HR, legal, and operations approval for purpose, scope, notice, access, retention, and use.
2. Use a dedicated recording container and managed identity where supported. Restrict storage contributor, reader, and administrator roles separately.
3. Enable on a pilot Bastion host and test RDP, SSH, disconnect, storage interruption, container change, playback, export, deletion, and incident preservation.
4. Alert on recording configuration changes, storage failures, identity changes, and unauthorized reads or deletes.
5. Pair recordings with sign-in, Bastion, VM, command, and application logs; document known blind spots.

Verification and evidence

• Preserve Bastion SKU and configuration, container URI, identity, role assignments, retention standard, notice, and approval.
• Record test session start and end, object creation, playback, authorized access, and denied access.
• Demonstrate an incident-preservation process that does not violate the feature’s current storage constraints.
• Reconcile privileged session records with expected recordings and investigate gaps.

Official references

• Configure Bastion session recording — Microsoft