Microsoft Fabric puts data engineering, warehousing, real-time analytics and Power BI on one copy of data in OneLake, so a single workspace role can now mean read access to every table, file and shortcut behind a report. Most Fabric tenants grew out of Power BI tenants, and the controls people know from Power BI do not cover Spark notebooks, OneLake APIs, shortcuts to external storage or pipelines that can push data anywhere. This guide covers how identity and access work in Fabric, workspace and OneLake security roles, service principals and workspace identities, private links and outbound access protection, logging and a hardening baseline. It is for data platform owners, Fabric administrators and security engineers. Reporting-only controls (sharing, publish to web, export settings) are covered in the Power BI Security Guide; this page assumes those are in place and goes deeper on the data platform.
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
- Contributor is a data access role. In Fabric, Admin, Member and Contributor all get ReadAll on lakehouse and warehouse data through OneLake APIs and Spark; only Viewer is limited to T-SQL reads.
- OneLake security only works once DefaultReader is handled. New items ship with a DefaultReader role that includes every user with ReadAll, so custom data access roles change nothing until you delete it or remove users from it.
- Private links protect inbound, not outbound. Tenant or workspace private links stop public access to Fabric; workspace outbound access protection is the control that stops notebooks and pipelines sending data to unapproved destinations.
- Workspace identities and service principals are the non-human access layer. Scope "Service principals can call Fabric public APIs" to a security group and treat Fabric-managed workspace identities as service principals with real permissions.
- The audit log is not the whole story. Purview audit covers control-plane operations such as ShareArtifact and UpdatedAdminFeatureSwitch, but Microsoft states it is not a complete source for OneLake data-plane activity.
How identity and access work in Microsoft Fabric
Every request to Fabric is authenticated with Microsoft Entra ID, so Entra Conditional Access applies: IP restrictions, MFA, country or region and device filters. Authorisation then happens in layers, and most exposure comes from misunderstanding which layer grants what.
| Layer | What it controls | Key point |
|---|---|---|
| Tenant settings | Organisation-wide features: service principal API access, export, sharing, private links | Set by Fabric administrators in the admin portal under Tenant settings; many can be scoped to security groups |
| Capacity | Compute and region; F SKU required for several security features | Trusted workspace access and outbound access protection need F SKUs; plan them on F SKU capacity rather than trials |
| Workspace roles | Admin, Member, Contributor, Viewer for everything in the workspace | Contributor and above can read all lakehouse and warehouse data through OneLake and Spark |
| Item permissions | Sharing a single item without a workspace role, including Reshare, ReadAll and ReadData | Contributors and Viewers can reshare only with Reshare permission |
| OneLake security roles | Folder and table access, with row-level and column-level security, inside an item | Applies across Fabric engines; users in no role see no data in that item |
| Engine security | T-SQL RLS, CLS and object-level security on warehouses and SQL analytics endpoints; semantic model RLS | Restricts what queries return for the user's identity |
Workspace roles in practice
- Admin: the only role that can update or delete the workspace, add or remove people including other admins, create the workspace identity and connect the workspace to Git.
- Member: everything an admin can do with items and data, can add Members or lower roles and reshare items, but cannot delete the workspace or manage its identity or Git connection.
- Contributor: creates, edits, deletes and runs notebooks, Spark jobs, pipelines, lakehouses, warehouses and shortcuts, and reads data through OneLake APIs and Spark (ReadAll). This is effectively a data engineer role with full read.
- Viewer: views items and execution output and reads through the SQL analytics endpoint (ReadData) where engine security applies, but cannot use OneLake APIs, Spark or Lakehouse explorer.
Reading data through a shortcut also needs permission on the shortcut destination, and on-premises gateway use needs separate gateway permissions, so a workspace role is not always sufficient, but it is always where review should start.
OneLake security roles
OneLake security applies role-based access control to data in OneLake. A role grants Read (or ReadWrite, for lakehouses) on specific folders or tables, can add row-level and column-level security, and is enforced across all Fabric engines. Lakehouses, mirrored databases and mirrored catalogs support it. Three details decide whether it works:
- DefaultReader: most new items include a DefaultReader role whose membership is virtualised: every user with ReadAll is a member. Delete it, or remove ReadAll from users, before relying on custom roles. Microsoft warns that a user added to a data access role but left in DefaultReader keeps full access.
- SQL analytics endpoint mode: new endpoints start in Delegated identity mode. An Admin or Member must switch the endpoint to User's identity access mode (Security tab, Data access mode settings) for OneLake security to apply to T-SQL queries.
- Who can create roles: users with Write and Reshare on the item, generally workspace Admins and Members. Keep Contributor for people who are trusted to read everything anyway, and give analysts Viewer plus a OneLake security role.
Microsoft's documentation does not state that workspace Admin, Member or Contributor are exempt from OneLake security roles or bound by them in every engine; test the behaviour on your own items with an account in each role before you depend on it for segregation.
Admin roles and privileged access
Fabric has several administrative tiers. Each needs its own owner, review cycle and logging.
| Role | Scope | Controls to apply |
|---|---|---|
| Fabric administrator (Entra role) | All tenant settings, all workspaces through admin APIs, Fabric identities | Privileged Identity Management with approval and time limit; phishing-resistant MFA; small named group |
| Capacity administrator | Assign workspaces to a capacity, capacity settings | Restrict to platform team; review when capacities move regions |
| Domain administrator | Domain settings and delegated tenant settings for a domain | Review delegations recorded as UpdateWorkspaceTenantSettingDelegation |
| Workspace Admin | Membership, workspace identity, Git connection, deletion | Two named admins per production workspace, assigned by group, no personal accounts as sole admin |
| Entra Application Administrator | Can modify or delete the service principal behind a workspace identity | Microsoft advises least privilege for this role because changes can break or repurpose Fabric identities |
- Use groups, not people: assign workspace roles to Entra security groups that are governed by access reviews or access packages. See the Entra ID Entitlement Management and Access Packages Guide.
- Separate development and production: use deployment pipelines or Git integration so engineers hold Contributor in development workspaces and only a service identity writes to production.
- Conditional Access for Fabric: require compliant devices or trusted locations for Fabric administrators and for workspace Admins of sensitive workspaces. See the Conditional Access Guide.
Integrations, API tokens and service accounts
Service principals
Two developer tenant settings decide what service principals can do. "Service principals can call Fabric public APIs" is enabled for new customers and lets service principals call create, read, update and delete APIs protected by Fabric permissions; restrict it to a dedicated security group. "Service principals can create workspaces, connections, and deployment pipelines" is disabled for new customers; enable it only for the automation identity that needs it. Treat the client secrets and certificates of these app registrations like any other high-value credential: prefer certificates or federated credentials over secrets, store them in a vault and rotate them. See the Azure RBAC and Service Principals Guide and the Azure Entra Client Secrets Security Guide.
If you embed content for customers using service principal profiles ("Allow service principals to create and use profiles"), review profile creation as part of tenant isolation. Enable "Block ResourceKey Authentication" unless you depend on streaming or push datasets with resource keys, because those keys authenticate without an identity.
Workspace identities
A workspace identity is a service principal and app registration that Fabric creates and manages in Entra ID, so nobody handles its secret. A workspace Admin creates it; it gets no workspace role by default; and it can authenticate OneLake shortcuts, pipelines, semantic models and Dataflows Gen2 connections. Its main security use is trusted workspace access: shortcuts reading firewall-enabled Azure Data Lake Storage Gen2 accounts, which requires an F SKU. Points to control:
- Grant the identity only the storage and database permissions each workload needs, on named resources.
- Remember that any Admin, Member or Contributor can select it in a connection, so its permissions are effectively shared with everyone in those roles.
- The default tenant limit is 10,000 Fabric identities; set "Define maximum number of Fabric identities in a tenant" to a realistic ceiling.
- Deleting an identity is permanent and breaks dependent items; deleting a workspace does not delete its identity until permanent deletion. Include workspace identities in your non-human identity inventory. See the Azure Managed Identities Security Guide.
Gateways and connections
On-premises and virtual network data gateways hold stored credentials for source systems. Limit gateway administrators, review data source users, and watch for credential changes. With private links enabled, on-premises gateways fail to register and a virtual network data gateway is required.
Network isolation and data exfiltration controls
Fabric separates inbound and outbound network controls, and each needs its own decision.
| Control | Direction | What it does | Trade-offs |
|---|---|---|---|
| Tenant private link with "Block public Internet access" | Inbound | Supported items reachable only through private endpoints from your virtual networks | Publish to Web, PDF and PowerPoint export, email subscriptions, trial capacities and on-premises gateways stop working; confirm Purview Information Protection behaviour with Microsoft |
| Workspace private link | Inbound | Restricts specific workspaces while others stay public | Better fit when only a few workspaces hold sensitive data |
| Conditional Access | Inbound (identity) | Location, device and MFA conditions on sign-in | Does not restrict where data goes after sign-in |
| Workspace outbound access protection | Outbound | Blocks all outbound connections from the workspace by default; allow destinations through managed private endpoints and data connection rules | F SKU only; workspaces containing unsupported items cannot enable it; incompatible with OneLake diagnostics and external data sharing |
| Managed private endpoints | Outbound | Private connections from Spark and OneLake to Azure data sources | Each endpoint needs approval on the target resource |
| Trusted workspace access | Outbound to storage | Lets firewall-enabled ADLS Gen2 accept the workspace identity | F SKU; not available cross-tenant |
| Purview DLP and sensitivity labels | Data | Labels follow data into exports such as PBIX, Excel, PowerPoint and PDF; DLP policies detect sensitive data | Confirm Information Protection behaviour with Private Link against Microsoft's current documentation |
Choosing an approach: a regulated organisation with a few crown-jewel workspaces will usually get more from workspace private links plus outbound access protection on those workspaces than from tenant-wide public access blocking, which breaks Power BI features for everyone. Small tenants without F SKUs rely on Conditional Access, tight workspace roles, sensitivity labels and tenant export settings. Map the exfiltration paths you are closing to MITRE ATT&CK Exfiltration Over Web Service (T1567), Transfer Data to Cloud Account (T1537) and Data from Cloud Storage (T1530). The wider pattern is covered in the Data Exfiltration Guide.
Logging and detection
Fabric activity is recorded in the Microsoft Purview audit log. Searching it requires the Audit Logs role in Exchange Online, and Microsoft publishes an operation list for every event. Fabric administrators can also query networking policy with the admin API "Workspaces - List Networking Communication Policies". For OneLake data-plane activity, Microsoft says the audit log is not complete and points to OneLake diagnostics.
| Operation | Why it matters |
|---|---|
| UpdatedAdminFeatureSwitch | Tenant setting changed, such as service principal access or export settings |
| UpdateWorkspaceAccess, AddWorkspaceRoleViaAdminApi | Workspace membership changes, including an admin granting themselves access through the admin API |
| ShareArtifact | An item shared outside workspace roles |
| ExportArtifact, ExportReport, DownloadReport | Data leaving Fabric as files |
| PublishToWebReport | Content made public on the internet |
| CreateShortcut | New path to or from external storage |
| UpdateArtifactRoles | OneLake security roles changed |
| CreateWorkspaceIdentityViaApi, DeleteWorkspaceIdentityViaApi | Non-human identity lifecycle |
| UpdateDatasourceCredentials, ChangeGatewayAdministrators | Stored source credentials or gateway control changed |
Forward these events to your SIEM and alert on tenant setting changes, Publish to Web, admin API role grants and bulk exports by a single identity. Correlate Fabric admin activity with Entra sign-in logs for the service principals named in "Service principals can call Fabric public APIs".
Metrics:
- Percentage of production workspaces assigned to groups only, with two or more named Admins.
- Number of users holding Contributor or above on workspaces labelled Confidential or higher.
- Percentage of lakehouses with OneLake security in use and DefaultReader removed.
- Percentage of sensitive workspaces with outbound access protection enabled.
- Service principals and workspace identities with no owner or no activity in 90 days.
- Time from an UpdatedAdminFeatureSwitch event to review by the platform owner.
Hardening baseline
- Inventory first: list workspaces, capacities and their SKUs, workspace role assignments, service principals in Fabric security groups, workspace identities, gateways and shortcuts.
- Tenant settings: scope service principal settings to security groups, enable Block ResourceKey Authentication, cap Fabric identities, and apply the reporting settings from the Power BI Security Guide.
- Workspace roles: move analysts from Contributor to Viewer plus OneLake security roles; assign roles to groups; review quarterly.
- OneLake security: define roles per lakehouse, remove DefaultReader where restriction is intended, and switch SQL analytics endpoints to User's identity access mode. Test with an account in each role.
- Network: pilot workspace private links and outbound access protection on one sensitive workspace; list the Power BI features that will stop working; agree the allow list of destinations; then extend.
- Data protection: apply sensitivity labels and Purview DLP to Fabric; use workspace customer managed keys from Azure Key Vault where policy requires it.
- Monitoring: stream audit events to the SIEM, enable OneLake diagnostics on sensitive items, and build the alerts above.
- Rollback: record tenant setting values before change; outbound access protection and private link settings can be turned off per workspace if a critical pipeline breaks, so pilot during a change window with the data owner present.
Common misconfigurations
- Contributor for every analyst: granted so people can "build things", it gives ReadAll through Spark and OneLake APIs to every table in the workspace.
- Custom OneLake roles with DefaultReader left in place: the roles look correct but every ReadAll user still sees everything.
- SQL endpoint still in delegated mode: OneLake security defined, but T-SQL users query through the item owner's identity.
- Service principal API access enabled for the whole organisation: any app registration in the tenant can call Fabric APIs within its permissions.
- Private link treated as a data loss control: inbound is locked down, but notebooks can still send data to any internet endpoint because outbound access protection is not enabled.
- Workspace identity with broad storage roles: granted contributor on a whole storage account, then usable by every Contributor through connections.
Framework mapping
| Control area | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 |
|---|---|---|
| Workspace roles, OneLake security roles, RLS and CLS | AC-3, AC-6 | PR.AA-05 |
| Private links and outbound access protection | SC-7, AC-4 | PR.IR-01 |
| Customer managed keys, encryption at rest | SC-28 | PR.DS-01 |
| Service principal and workspace identity credentials | IA-5, AC-2 | PR.AA-01 |
| Audit and detection | AU-6, SI-4 | PR.PS-04, DE.CM-03 |
Relevant ATT&CK techniques for detection design: Cloud Accounts (T1078.004), Additional Cloud Credentials (T1098.001) for new secrets on Fabric service principals, Data from Cloud Storage (T1530) and Exfiltration Over Web Service (T1567).
Practitioner checklist
- Restrict "Service principals can call Fabric public APIs" and the workspace creation setting to named security groups.
- Replace Contributor with Viewer plus OneLake security roles for users who only need to read.
- Remove or empty DefaultReader on every item that uses OneLake security roles, and switch SQL analytics endpoints to User's identity access mode.
- Put Fabric administrator behind Privileged Identity Management and phishing-resistant MFA.
- Enable workspace outbound access protection on workspaces holding confidential data, with an agreed destination allow list.
- Decide between tenant and workspace private links based on which Power BI features you can lose.
- Inventory workspace identities and service principals with owners, permissions and last activity.
- Alert on UpdatedAdminFeatureSwitch, PublishToWebReport, AddWorkspaceRoleViaAdminApi and bulk ExportArtifact events.
- Apply sensitivity labels and Purview DLP to Fabric items and review label coverage monthly.
Standards and references
- Microsoft Learn: Security in Microsoft Fabric
- Microsoft Learn: Roles in workspaces in Microsoft Fabric
- Microsoft Learn: Get started with OneLake security
- Microsoft Learn: Workspace outbound access protection
- Microsoft Learn: Private links for Fabric
- Microsoft Learn: Workspace identity
- Microsoft Learn: Fabric operation list
- NIST: SP 800-53 Rev. 5
Related NHI Mgmt Group resources: Power BI Security Guide · Azure RBAC and Service Principals Guide · Data Loss Prevention (DLP) Guide · Data Lake Security Guide