TLDR Microsoft Fabric data warehouse security works across four distinct layers covering identity, network, workspace roles, and SQL-level permissions. Each layer protects something different, and they interact with each other in ways that aren’t always obvious. Most teams configure the first layer and stop, leaving significant exposure at the SQL and network levels. This guide covers all four layers, how to sequence them, and where real implementations typically go wrong.
Introduction Security breaches rarely happen because someone skipped a step they knew about. They happen because the person responsible for data warehouse security didn’t know a step existed. This guide covers security specifically for the Microsoft Fabric data warehouse item, not OneLake file-layer or Lakehouse security.
Microsoft Fabric data warehousing ships with a multi-layer permission model covering identity authentication, network boundaries, workspace roles, and SQL-level data controls. A workspace-level setting can override a tenant policy. A DENY statement in SQL can block a user who workspace roles said should have full read access. Getting one layer right doesn’t automatically protect the others.
In this blog, we’ll cover how each security layer works, what can go wrong, and how to set them up in the right order.
Key Takeaways Microsoft Fabric warehouse security uses four stacked layers that must be configured together, not independently Workspace-level private link settings override tenant-level settings, and this priority rule is widely misunderstood Removing a user from a workspace role does not remove their SQL login. This is a gap most teams discover after the fact Row-level security and dynamic data masking both have known bypass techniques that require deliberate mitigation Customer-managed key encryption exists for regulated industries that need direct control over their encryption keys How Microsoft Fabric Structures Warehouse Security Microsoft Fabric doesn’t have a single security setting. It has four stacked layers, and each one handles a different kind of threat. Miss one and the others don’t compensate for it.
The four layers, from outermost to innermost:
Entra ID determines who you are before you get anywhere near the warehouse Network isolation determines whether your connection is accepted at all, regardless of identity Workspace roles determine what you can do across every item inside a workspace SQL permissions determine what data you can actually see inside the warehouse itself
The layers also interact with each other. Worth knowing before you start configuring:
A workspace Viewer role gives T-SQL read access, but not access to OneLake files via Spark or APIs A SQL DENY statement overrides ReadData permissions set at the workspace level Workspace-level private link settings take precedence over tenant-level settings Getting one layer right does not automatically protect the others
Security Layer What It Controls Where It’s Configured Entra ID Authentication and identity Microsoft Entra admin center Network Which connections are allowed Fabric admin portal, Azure Portal Workspace Roles Access to all items within a workspace Fabric workspace settings SQL Permissions Data access inside the warehouse T-SQL statements in the warehouse
Identity and Access with Microsoft Entra ID Every connection to a Microsoft Fabric data warehouse runs through Microsoft Entra ID. There’s no alternative authentication method. Entra ID handles single sign-on via Microsoft 365 credentials and issues OAuth 2.0 tokens to authorize actions inside Fabric. For most organizations, the default setup works. But it’s not enough on its own.
What Conditional Access Does Conditional Access is a policy engine inside Entra ID that enforces rules based on the full context of a login, not just the password. It evaluates conditions and applies controls automatically before a user reaches Fabric.
It checks the following conditions.
Require MFA for users outside the corporate network Block login from non-compliant devices Restrict access to Intune-managed devices for specific groups Limit session duration or require re-authentication One licensing note worth flagging is that Conditional Access requires a Microsoft Entra ID P1 license or Microsoft 365 Business Premium. It doesn’t come with the base Entra tier.
Service Principals and Managed Identities Not every connection to a Fabric warehouse comes from a human. Pipelines, scheduled jobs, and automated processes need to authenticate too.
Fabric handles this through two options.
Workspace managed identity lets the workspace authenticate against external sources like Azure Data Lake Storage (ADLS) without embedding user credentials anywhere Managed identity is particularly useful when connecting to firewall-restricted or fully private ADLS storage, since it works across public, restricted, and fully blocked storage configurations.
Network Security and Private Links Entra ID confirms who someone is. Network security is a separate question entirely. It determines whether that connection should be accepted at all, regardless of who’s asking. By default, Microsoft Fabric accepts connections from the public internet. Locking that down requires either tenant-level or workspace-level private link configuration.
Inbound vs Outbound Security Network security in Fabric works in two directions, and both need to be addressed independently.
Inbound controls which networks can reach Fabric at all. Restricting inbound access blocks unauthorized external connections before they touch any workspace or item Outbound controls where Fabric can send data. This matters for preventing pipelines and ingestion commands from connecting to unapproved external endpoints A warehouse that’s locked down inbound can still be exposed outbound. Both directions need explicit configuration.
Tenant-Level vs Workspace-Level Private Links Fabric allows private link configuration at two levels, and they interact through a clear priority rule.
Tenant-level applies to the entire organization
Workspace-level applies to individual workspaces and can override tenant settings
Tenant Public Access Workspace Public Access Private Link In Effect Allowed Blocked Workspace-level private link Blocked Allowed Tenant-level private link Blocked Blocked Workspace-level private link
How to Set Up a Workspace-Level Private Link This requires a Fabric workspace admin and an Azure admin working together. Run the steps in this order:
Create a Private Link Service resource in Azure via ARM template, specifying resource type Microsoft.Fabric/privateLinkServicesForFabric, the tenant ID, and the workspace ID Create a virtual network and a VM with no public IP inside Azure Create a private endpoint within the VNet pointing to the Fabric private link service Verify the workspace is reachable from inside the VNet Deny public access to the workspace under Inbound Networking in Fabric workspace settings The workspace ID is in the browser URL when the workspace is open. The tenant ID appears in the Fabric “About” dialog under the tenant URL parameter.
Outbound Access Protection Outbound access protection prevents the warehouse from connecting to unapproved external data sources. When enabled, it blocks the following commands from reaching any endpoint not explicitly allowed:
This is a workspace-level setting under Outbound Networking. It applies to warehouses and SQL analytics endpoints. Worth noting before enabling in production is that turning it on blocks creation of certain item types that rely on external connectivity, so plan ahead.
Workspace Roles and Item Permissions Once identity and network are configured, the next layer controls what different users can actually do inside a workspace. Fabric has two mechanisms for this. Workspace roles cover the core team, and item-level permissions cover everyone else. Getting this distinction right is where most access control errors happen in practice.
The Four Workspace Roles Fabric workspaces have four built-in roles. Each gives a different level of access across every item inside the workspace.
Role What They Can Do Admin Full control. Manage workspace, add/remove any user, create and modify items Member Add lower-permission users, share items, create and modify warehouse items Contributor Create and modify warehouse items, but cannot manage membership Viewer Read-only via T-SQL. Cannot access OneLake files or Spark
The ReadData vs ReadAll gap is worth calling out specifically:
ReadData provides T-SQL read access via the SQL analytics endpoint. Viewer and above get this ReadAll covers access to underlying OneLake files via Spark and OneLake APIs. Contributor and above only
Viewer role gives ReadData but not ReadAll. For teams with sensitive files stored in OneLake alongside the warehouse, this difference matters more than it might seem.
Capability Admin Member Contributor Viewer Update or delete the workspace Yes No No No Add or remove users Yes Yes (lower roles only) No No Create or modify warehouse items Yes Yes Yes No Read via T-SQL (ReadData) Yes Yes Yes Yes Read via OneLake / Spark (ReadAll) Yes Yes Yes No
When to Use Item Sharing Instead of Workspace Roles Workspace roles are built for the active development team. People building, maintaining, and owning the solution. Anyone beyond that group should get item-level sharing, not workspace membership.
Use item sharing for:
SQL analysts running queries against the warehouse Report developers building Power BI models Business users who need read access to specific tables
When sharing a warehouse at the item level, the available permissions are:
Permission What It Gives Connect Basic connection access, required for everything else ReadData Read all data via SQL ReadAll Read all OneLake data via Spark and APIs, plus subscribe to OneLake events Monitor View query history and execution details Audit Access query audit logs (preview as of 2026) Reshare Ability to share granted permissions with others
The default when sharing is Connect only. Additional permissions must be explicitly checked and granted.
SQL-Level Data Controls Workspace roles and item permissions set the boundaries. SQL-level permissions work inside those boundaries, controlling exactly which tables, columns, and rows a specific user can touch. This is where most of the compliance-relevant security work actually happens. Fabric warehouse supports four controls, each solving a different problem.
1. Object-Level Security Object-level security controls whether a user can access a specific database object at all. It applies to tables, views, and stored procedures, and runs through standard T-SQL GRANT and DENY statements.
The rule that catches most teams off guard:
A user with Connect and ReadData item permissions can connect and read data by default But if they’ve been explicitly denied SELECT on a specific table, that denial takes precedence DENY always overrides ReadData, even for workspace Viewers Don’t assume item permissions fully define what a user can see. SQL-level DENY goes deeper.
2. Column-Level Security Column-level security lets you expose a table while hiding specific columns from specific users. A support analyst might need customer names and phone numbers, but not birth dates or credit card numbers. No duplicate tables, no separate views needed.
Implementation uses column-specific GRANT and DENY statements:
Grant specific columns only: GRANT SELECT ON Customer(Name, Phone) TO [[email protected] When a user without full access runs SELECT *, they see only the columns they’ve been granted. Denied columns either return an error or are absent from results, depending on how the denial is structured.
3. Row-Level Security Row-level security (RLS) lets different users see different rows of the same table. A sales rep querying the Orders table sees only their own orders. A manager running the same query sees their entire region. Same query, different results based on who’s asking.
RLS requires three components built in sequence:
Schema: a dedicated schema to hold the security objects Function: an inline table-valued function that defines which rows a given user should see Security policy: binds the function to the target table and activates it
A few things to know before deploying RLS:
Filter predicates apply to SELECT, DELETE, and UPDATE operations Each table needs its own RLS policy defined separately Users querying a table with no policy see unfiltered data
4. Dynamic Data Masking Dynamic data masking (DDM) takes a different approach to the other three. Instead of blocking access to a row or column, it shows scrambled or partial values to users without UNMASK permission, while users with appropriate permissions see the real data. The underlying data in the database is never changed.
Fabric warehouse supports four masking functions:
Function What It Shows default() 0 for numbers, 1900-01-01 for dates, XXXX for strings partial(prefix, padding, suffix) First and last N characters with masking in between random(min, max) A random number within a defined range instead of the real value email() First character of the email followed by [email protected]
DDM is configured at table creation or added to existing columns via ALTER TABLE. Viewer role users without UNMASK permission see masked values automatically.
SQL Control What It Restricts Best Used For Object-Level Security Access to entire tables or views Blocking access to sensitive tables entirely Column-Level Security Access to specific columns Hiding PII fields like SSN, salary, card numbers Row-Level Security Access to specific rows Multi-tenant data, regional data separation Dynamic Data Masking Full values in columns Partial visibility, like showing only the last 4 digits of a card number GRANT / DENY / REVOKE All of the above Fine-grained permission management via T-SQL
Security Risks Most Teams Overlook Getting the configuration right is one thing. Understanding where it fails even when configured correctly is another. These four risks don’t show up in most Fabric security checklists, but they come up in real deployments.
1. The RLS Side-Channel Problem Row-level security can leak data even when the policy is correctly implemented. A user who knows RLS is active can use error-based inference to discover hidden values.
Consider this query:
If it returns a divide-by-zero error, the attacker knows Jane’s salary is exactly 100,000. The filter predicate evaluated her row before the error was thrown, which confirms the value exists and what it is.
How to mitigate it:
Avoid storing sensitive numeric values in tables protected only by RLS Combine RLS with column-level security so the vulnerable column is inaccessible by permission, not just filtered by policy Microsoft’s own documentation acknowledges this risk.
2. The Dynamic Data Masking WHERE Clause Bypass DDM hides column values in query output. It does not prevent filtering on those columns.
A user who can’t see the salary column can still run:
The results tell them exactly who earns 100,000, even though the salary value never appears in the output.
How to mitigate it:
Don’t use DDM as a standalone control for truly sensitive data Layer it with column-level security that blocks read access entirely for unprivileged users
3. SQL Logins Persist After Workspace Removal Removing a user from a workspace role or revoking item sharing does not delete their SQL login from the warehouse. The login persists until it’s explicitly dropped via T-SQL.
What this means in practice:
A removed user who still knows the warehouse connection string may retain SQL access The fix is running a DROP USER statement inside the warehouse after removing workspace access This step is not automatic and is not prompted anywhere in the Fabric UI
4. The ReadAll Gap Most Teams Miss Viewer role grants ReadData, meaning T-SQL read access via the SQL analytics endpoint. It does not grant ReadAll, which covers OneLake file access via APIs and Spark notebooks. Contributor and above get both.
Why this matters:
In environments where users also have access to Spark notebooks or OneLake file browsers, a Contributor role exposes more than SQL data ReadAll gives access to the underlying Parquet files in OneLake, not just the tables visible through the warehouse endpoint Map this distinction carefully before assigning roles in mixed-access environments
Data Fabric vs Data Mesh: What You Need to Know About Modern Data Management Compare the centralized Data Fabric vs the decentralized Data Mesh architecture for modern data management.
Learn More
Encryption and Compliance Controls Data at rest in Microsoft Fabric is encrypted by default using Microsoft-managed keys. This covers all data stored in OneLake and requires no configuration. For most organizations, that’s sufficient. For regulated industries like financial services , healthcare, and government where key custody is a compliance requirement, Fabric goes further.
How Customer-Managed Keys Work Customer-managed keys (CMK) give organizations direct control over the encryption keys that protect their data. When CMK is enabled for a Fabric workspace, it encrypts both OneLake data and warehouse metadata using the customer’s own key stored in Azure Key Vault.
What CMK covers: Warehouse metadata including table definitions, stored procedures, and schema information Key creation, rotation, and access policy control stays with the customer
What CMK does not cover: Ephemeral backend compute caches that process queries These caches are short-lived, cleared automatically after each session, and use Microsoft-managed keys only No data persists in them beyond the session lifetime, so the trade-off is architectural, not a security gap
Microsoft documents this boundary explicitly. The reason is performance. Applying CMK to transient compute caches would create latency that doesn’t fit how they work architecturally.
Audit Logs Audit logs track what’s happening inside the warehouse after access is granted. They’re stored in OneLake and can be queried using T-SQL.
What audit logs track:
Schema and permission changes
What teams need to know before enabling:
Audit logging is off by default It requires the Audit item permission to be granted to the user or service principal setting it up Specific actions to log must be selected manually, including SELECT, INSERT, and EXECUTE For any organization with compliance or records management requirements, this should be enabled during initial setup, not after an incident
Microsoft Purview Integration Microsoft Purview sits on top of Fabric’s native security controls and adds enterprise-scale governance. The integration gives security and compliance teams visibility and enforcement across the data estate without rebuilding what Fabric already handles.
What Purview adds:
Sensitivity labels applied to warehouse items, now accessible through Fabric public APIs for programmatic classification at scale Data loss prevention (DLP) policies that restrict access to warehouses containing flagged sensitive data classifications Insider risk management signals from Fabric workloads, feeding the same detection capabilities already in use across Microsoft 365
How to Sequence a Fabric Warehouse Security Implementation Configuring the four layers in the wrong order creates gaps that are harder to close after the fact. Each step below builds on the one before it. Skipping ahead or reversing the order is where most security debt in Fabric implementations gets introduced.
Step 1. Configure Entra ID and Conditional Access first. Before anyone gets workspace access, define who is allowed to authenticate to Fabric and under what conditions. This is the policy that governs every subsequent access decision.
What to set up at this stage:
User and group authentication via Microsoft Entra ID Conditional Access policies covering location, device compliance, and sign-in risk MFA requirements for users accessing from outside the corporate network
Step 2. Set network boundaries before assigning workspace roles. If the warehouse should only be accessible from within a specific VNet or corporate network, establish private links and deny public access before adding anyone to the workspace.
Why order matters here:
Adding workspace members before locking the network means those users had public internet access during the open window Network controls should be verified and tested before any team member is onboarded into the workspace
Step 3. Assign workspace roles only to the active development team. Admin, Member, and Contributor roles give broad access to every item in the workspace. Keep this group small.
Who belongs here:
Data engineers actively building pipelines Warehouse developers writing and testing SQL Admins managing the workspace itself Everyone else gets handled in the next step.
Microsoft Fabric Raises the Bar Again: The Undisputed #1 Analytics Platform Learn why Microsoft Fabric is the #1 analytics platform with AI-powered insights and unified data.
Learn More
Step 4. Use item sharing and SQL permissions for everyone else. Analysts, report developers, QA testers, and business users should get Connect-level item access first, then specific SQL grants on the exact objects they need. Nothing more.
What this prevents:
Accidental ReadAll exposure from over-assigning Contributor Broad table access for users who only need two or three objects Permission sprawl that becomes difficult to audit over time
Step 5. Layer RLS, CLS, and DDM based on data sensitivity. Not every table needs all three controls. Match the control to the sensitivity level of the data.
How to decide:
Sensitive PII columns (salary, SSN, card numbers) warrant column-level security Multi-tenant or role-segmented data needs RLS Fields that need partial visibility, like the last four digits of a payment card, are good candidates for dynamic data masking Use Table 8 as a reference for which control fits which scenario
Step 6. Enable audit logging and Purview policies last. These controls observe and enforce on top of the base configuration. They work better once the access model is stable and the roles and permissions are locked in.
What to enable at this stage:
Audit item permission and action-level logging (SELECT, INSERT, EXECUTE) Purview sensitivity labels on warehouse items DLP policies for warehouses containing classified data
Case Study: Building a Governed Microsoft Fabric Environment for SSMH
Southern States Material Handling (SSMH), a Toyota equipment distributor operating across multiple locations, needed to build a Microsoft Fabric environment that could serve both engineering teams and business users without exposing sensitive operational data across the organization.
Problem The challenge was separating development-level access from downstream user access while maintaining a governed, auditable structure across the entire analytics estate.
Solution Kanerika designed the workspace architecture, configured access controls, and deployed the governance layer alongside the broader analytics and reporting buildout.
Engineering access was separated from business user access through workspace roles and item-level sharing, with KANGuard and KANGovern deployed on top of Fabric’s native model to enforce ongoing policy and data classification.
Results
85% increase in operational visibility across locations 100% scalability achieved with ongoing support post-deployment Access boundaries between development and business user tiers defined and enforced from day one Governance layer built on Microsoft Purview, enabling classification and DLP enforcement across the Fabric environment
In the words of Delano Gordon, CIO of SSMH: “Kanerika’s flexibility in aligning Microsoft Fabric with our business needs ensures that we are building a system that will drive even better results across our operations.”
How Kanerika Implements Fabric Security for Enterprise Clients Kanerika is a Microsoft Fabric Featured Partner and Microsoft Solutions Partner for Data and AI with Analytics Specialization. The firm is ISO 27001 and ISO 27701 certified, SOC II Type II compliant, CMMI Level 3 appraised, and named Forbes America’s Best Startup Employers 2025. These are audited credentials across delivery capability, security posture , and operational maturity.
For warehouse security specifically, Kanerika uses three governance tools built on Microsoft Purview. KANGuard enforces policy-based access rules on top of Fabric’s native permissions. KANGovern manages data classification, ownership, and enforcement across the data estate. KANComply maps Fabric security controls to regulatory frameworks, including GDPR and SOC II, so compliance reporting reflects actual configurations rather than manual documentation.
Conclusion Microsoft Fabric data warehouse security is a four-layer problem, and all four layers need deliberate attention. Entra ID handles identity. Network configuration handles access at the connection level. Workspace roles handle coarse-grain team access. SQL-level controls handle what data specific users can actually see inside the warehouse. Each layer has its own configuration points, its own failure modes, and its own interaction effects with the others. The teams that get this right plan the sequence before they start, understand the priority rules between layers, and treat the gotchas like RLS side-channel risks, DDM bypass, SQL login persistence, as known problems to account for rather than theoretical edge cases to ignore later.
Transform Your Data Analytics with Microsoft Fabric! Partner with Kanerika for Expert Fabric implementation Services
Book a Meeting
FAQ’s What is the difference between workspace roles and item permissions in Microsoft Fabric? Workspace roles (Admin, Member, Contributor, Viewer) apply to every item inside a workspace and are designed for teams collaborating on the same set of data assets. Item permissions are granted directly to specific warehouses or other Fabric items and give access to individual users or groups without workspace membership. For anyone outside the core development team, item-level sharing with specific SQL permissions is the more appropriate path.
How does row-level security work in a Fabric data warehouse? Row-level security in Fabric warehouse is implemented in three steps. First, a separate schema is created to hold the security objects. Second, an inline table-valued function defines a filter predicate, which is the logic that determines which rows a given user can see based on their identity. Third, a security policy binds that function to the target table and activates it. Filter predicates apply automatically to SELECT, DELETE, and UPDATE operations on the protected table.
Can dynamic data masking be bypassed in Microsoft Fabric? Yes, under specific conditions. Dynamic data masking hides column values in query results for users without UNMASK permission, but those columns are still searchable in WHERE clauses. A user can narrow down the real value of a masked field by filtering within progressively tighter ranges. For sensitive data, DDM should be combined with column-level security that blocks read access entirely, rather than used as a standalone control.
What is the difference between ReadData and ReadAll in Fabric? ReadData gives a user the ability to query warehouse data through the SQL analytics endpoint using T-SQL. ReadAll gives access to the underlying data files in OneLake through APIs and Spark. Workspace Viewer role includes ReadData but not ReadAll. Contributor role and above include both. This distinction matters in environments where users also have access to notebooks, OneLake file browsers, or external Spark environments.
How do I set up a private link for a Microsoft Fabric workspace? Setting up a workspace-level private link requires an Azure admin and a Fabric workspace admin working together. The process involves deploying a Private Link Service resource in Azure via ARM template using the workspace ID and tenant ID, creating a VNet with a VM that has no public IP, creating a private endpoint in the VNet pointing to the Fabric private link service, verifying connectivity from within the VNet, and then denying public access to the workspace in Fabric’s inbound networking settings.
