Finance wants the monthly exports, sales wants the reports, operations wants last year's archives. The files are in Azure Blob Storage, and these people only need to open and download them, never change them. This guide explains how to give business users read-only access to Azure Blob Storage, which roles to assign, and the mistakes that quietly give them much more.
Short answer: Assign the Storage Blob Data Reader role to a Microsoft Entra group, scoped to the container. If users will browse in the Azure portal, also assign Reader on the storage account; if they use Azure Storage Explorer, they can attach the container with Microsoft Entra ID and skip it. Never use roles that can list the account keys, such as Reader and Data Access or Storage Account Contributor: a key gives full read and write access.
The roles involved in read-only access
Azure separates the management plane (the storage account as a resource) from the data plane (the blobs). Read-only access to files needs a data role, as described in Authorize access to blobs using Microsoft Entra ID.
| Role | Plane | What it allows | Use it for read-only users? |
|---|---|---|---|
| Storage Blob Data Reader | Data | List and read blobs | Yes, at container scope |
| Reader | Management | See the storage account in the portal | Only to browse in the portal |
| Storage Blob Data Contributor | Data | Read, write, delete blobs | No |
| Reader and Data Access | Management | Read the account and list its keys | No |
| Storage Account Contributor | Management | Manage the account, list its keys | No |
The last two rows are the classic trap. According to Authorize access to blob data in the Azure portal, a role with the listkeys action lets the portal use the account key, and the key opens every container in the account for reading and writing.
Step by step: read-only access with Storage Blob Data Reader
- Create a security group in Microsoft Entra ID for the audience, for example Finance – Reports readers. Groups make onboarding and leavers a membership change, not a new role assignment.
- In the Azure portal, open the storage account, then Containers, and select the container.
- Open Access control (IAM) > Add role assignment, choose Storage Blob Data Reader, and assign it to the group. Keeping the container scope means the group sees nothing else in the account.
- If the users will work in the Azure portal, assign Reader to the same group on the storage account. The portal needs it to navigate to the containers, as stated in Assign an Azure role for blob data access.
- Wait up to 10 minutes for the assignments to take effect, then ask a user to test.
- In the storage account Configuration, enable Default to Microsoft Entra authorization in the Azure portal, so the portal uses the user's identity rather than trying the account key.
How business users open the files
Azure portal. With Storage Blob Data Reader and Reader, users go to the storage account, then Containers, and download files. The authentication method shown above the blob list must be Microsoft Entra user account.
Azure Storage Explorer. Users who only have the data role can still work: in Connect to Azure Storage, they choose Blob container, then Sign in using Microsoft Entra ID, and paste the container URL. Microsoft recommends this option when a user has data access but no management access; see Get started with Storage Explorer.
A read-only SAS URL. For a one-off need, a SAS with Read and List permissions and a short expiry works without any role. It is anonymous, though: whoever has the link can read, and Azure cannot tell you which person used it. Keep SAS for systems and short exchanges, and read how to revoke a SAS token before you send one.
Read-only access to part of a container
The smallest scope of a standard role assignment is the container. To narrow it further:
- Role assignment conditions (Azure ABAC) add a check to Storage Blob Data Reader, based on attributes of the user, the request or the blob, such as blob index tags. They are powerful but need a consistent taxonomy; see Authorize access using role assignment conditions.
- ACLs apply to directories and files on accounts with hierarchical namespace (Data Lake Storage).
- One container per audience is usually the simplest and easiest to review.
Mistakes to avoid
- Assigning Reader alone and expecting users to read blobs: they will see the account but no data.
- Assigning roles at subscription or resource group scope for convenience: the user can read every storage account below it.
- Giving Contributor or Storage Account Contributor to "make it work": it includes the keys.
- Assigning roles to individuals instead of groups: access reviews and departures become manual work.
- Forgetting the storage firewall: if the account only accepts selected networks, users outside them are refused whatever their role.
When the native Azure approach is the right choice
Storage Blob Data Reader on a group is the right answer when the users are comfortable with the Azure portal or Storage Explorer, belong to your Microsoft Entra tenant, and need long-term access governed by your IT team. It is free, auditable in Azure Monitor resource logs, and fits your existing Azure RBAC reviews.
It is less comfortable when the audience is large and non-technical, when access must end on a given date, or when the people are partners outside your tenant. Our guide on sharing a container with an external partner covers that case.
Blob Web Explorer: read-only access without Azure roles
Blob Web Explorer, governed access and collaboration for Azure Blob Storage, gives business teams access to files without assigning them any Azure role:
- Read-only shares: the container owner shares by email with Read access and an optional validity period; access stops on the end date and can be disabled at any time.
- Reader role from Microsoft Entra ID with Enterprise: users sign in with their work account and you assign Administrator, Contributor or Reader from your tenant.
- A familiar web explorer: preview PDF, images and text, download several files as a ZIP, search by file name and path across containers.
- Activity attributed to each person, with CSV export, for access reviews.
- No copy: files stay in your containers, and recipients never receive a SAS URL or key.
See the security page for the access model and the pricing page for plans.
Bottom line
To give business users read-only access to Azure Blob Storage, assign Storage Blob Data Reader to a group at container scope, add Reader on the account only if they use the portal, and keep every role that can list keys away from them. When the audience is non-technical or access must end on a date, a sharing layer is simpler than more role assignments.
Start free with Blob Web Explorer and share a container read-only with your first team.
Frequently asked questions
Which Azure role gives read-only access to blob data?
Storage Blob Data Reader. It lets a user list containers and blobs and read their content, without writing or deleting. Assign it at the container scope rather than on the whole storage account or subscription to follow least privilege.
Why can't a user with Storage Blob Data Reader see the container in the Azure portal?
The Azure portal also requires a management role, the Reader role at the storage account level or above, to navigate to the containers. Reader alone does not give access to data. Without it, the user can still open the container in Azure Storage Explorer by attaching it with Microsoft Entra ID.
Is the Reader role enough to read blobs?
No. Reader is a management-plane role; it shows the storage account resources but does not authorize reading blob data. A data role such as Storage Blob Data Reader is required. Avoid Reader and Data Access, which can list the account keys and therefore gives full access to the data.
How long does it take for a role assignment on blob data to work?
Microsoft documents that assigning or removing a role can take up to 10 minutes to take effect, and longer when the assignment is made at the management group scope.
Can I give read-only access to a single folder of a container?
Not with a plain role assignment, whose smallest scope is the container. You can add a role assignment condition (Azure ABAC) based on blob attributes, or use ACLs on accounts with hierarchical namespace. The simplest option is often to put the files for each audience in their own container.