Understanding Microsoft Fabric: How to Secure Your Data with RLS, CLS, OneLake Security, and More
Microsoft Fabric gives you powerful tools to build pipelines, optimize warehouses, and load data incrementally. But none of that matters if the wrong people can access your data. Security is not something you bolt on at the end. It needs to be part of your architecture from day one.
In this article, we will cover the complete security model in Microsoft Fabric, from workspace roles and item-level permissions to row-level security (RLS), column-level security (CLS), dynamic data masking (DDM), and the new OneLake security roles. You will learn how to implement each layer, how they work together, and when to apply each one.
If you are preparing for the DP-700: Fabric Data Engineer Associate exam, security is heavily tested. Microsoft expects you to know how to secure data at every level and choose the right approach for a given scenario.
This article is part of the Understanding Microsoft Fabric series, a practical guide designed to help you master every key component of Fabric and prepare for the DP-700 certification.
If you have been following the series, we have already covered:
How the Fabric Security Model Works: Three Levels of Protection
Before diving into specific features, it is important to understand how Fabric evaluates security. When a user tries to access data, Fabric checks three levels sequentially. The user must pass all three to see the data.
Level 1: Microsoft Entra Authentication. Is the user able to authenticate to the Microsoft Entra tenant? This is the identity layer. Without a valid Entra ID (formerly Azure Active Directory) account, nothing else matters.
Level 2: Fabric Authorization. Can the user access Microsoft Fabric and the specific workspace or item? This is controlled by workspace roles, item-level permissions, and tenant settings.
Level 3: Data Security. Can the user perform the requested action on the specific table, column, or row? This is where row-level security, column-level security, dynamic data masking, and OneLake security roles come into play.
Think of it like entering a secured office building. Level 1 is your employee badge (are you who you say you are?). Level 2 is whether you have access to a specific floor (can you enter this workspace?). Level 3 is whether you can open a specific filing cabinet on that floor (can you see this particular data?).
DP-700 Exam Tip
The exam frequently presents scenarios where a user cannot see specific data and asks you to identify the cause. Always think in terms of these three levels: authentication, authorization, and data security.
Take Your DP-700 Prep to the Next Level
Reading articles is great for understanding concepts. But passing the exam requires practice. I created a comprehensive practice test course specifically for DP-700: Implementing Data Engineering Solutions Using Microsoft Fabric. Inside you will find:
300+ exam-style questions 5 full practice tests Case studies and scenario-based questions Detailed explanations, learn WHY each answer is correct All 3 exam domains covered
Whether you are just starting or doing final prep, these tests will show you exactly where you stand.
Limited offer: Use code EARLY_BIRD at checkout Get the practice exams on Udemy
1. Workspace Roles: Admin, Member, Contributor, and Viewer
Workspaces are the primary organizational unit in Fabric. They sit on top of OneLake and divide the data lake into separate containers that can be secured independently. Workspace roles are the first and broadest layer of access control.
There are four workspace roles, from most to least privileged:
Admin: Full control. Can manage workspace settings, add or remove members, configure private endpoints, managed identity, and Spark settings. Can view, modify, share, and manage all content.
Member: Can view, modify, and share all content. Can add Contributors and Viewers (but not other Members or Admins). Can share items and grant Reshare permission.
Contributor: Can view and modify all content in the workspace. This is the standard development role. Contributors can create and edit Fabric items like Lakehouses, Warehouses, Notebooks, Pipelines, and Dataflows.
Viewer: Can view all content but cannot modify anything. This is the read-only role for report consumers and analysts. Viewers are the primary audience for data security features like RLS and CLS, because their access can be further restricted at the data level.
Key points to remember:
Workspace roles apply to ALL items in the workspace. You cannot use workspace roles to restrict access to individual items. For that, you need item-level permissions.
Admins, Members, and Contributors bypass OneLake security roles and can read and write all data regardless of data access role configuration.
Only Viewers (and users with item-level Read permission) are subject to OneLake security, RLS, CLS, and dynamic data masking enforcement.
Assign roles to security groups rather than individuals. This simplifies management and makes auditing easier.
DP-700 Exam Tip
If a question asks how to give a user read-only access to a workspace while enforcing row-level security, the answer is the Viewer role. Admins, Members, and Contributors bypass RLS enforcement by default.
2. Item-Level Permissions: Sharing Individual Items
Sometimes workspace roles are too broad. You may want to share a single report, Lakehouse, or Warehouse with a user without giving them access to the entire workspace. That is where item-level permissions come in.
When you share a Fabric item, you choose which permissions to grant:
Read: The user can connect to the item and view its contents.
ReadAll: The user can access the full data in the item. For items with OneLake security enabled, ReadAll only grants access through the DefaultReader role.
Write: The user can modify the item content.
Reshare: The user can share the item with others.
Item permissions work independently of workspace roles. A user who has no workspace role at all can still access a specific item if it has been shared with them directly. In that case, they can only see the shared item, not other items in the workspace.
When workspace roles and item permissions overlap, the most permissive access wins. For example, if a user has the Viewer workspace role and also has Write item permission on a specific Warehouse, they can write to that Warehouse even though the Viewer role alone would not allow it.
DP-700 Exam Tip
Know the difference between workspace roles and item permissions. Workspace roles apply to all items in the workspace. Item permissions apply to individual items. A user with no workspace role can still access a shared item if they have been granted item-level permissions directly.
3. OneLake Security: Granular Role-Based Access Control (Preview)
OneLake security is the most granular security layer in Fabric. It enables you to define role-based access control at the table, folder, column, and row level directly in OneLake, and it enforces that security consistently across all Fabric compute engines, including Spark, SQL, and Power BI.
This is a major shift from the traditional approach where each engine had its own security configuration. With OneLake security, you define permissions once and they apply everywhere.
How OneLake Security Roles Work
OneLake security uses a deny-by-default model. All users start with no access to data unless explicitly granted by a role. Each role has four components:
Data: The tables or folders the role grants access to.
Permission: What the user can do. Read (view data and metadata) or ReadWrite (read, write, update, delete through Spark notebooks, OneLake APIs, or OneLake file explorer).
Members: The users or security groups assigned to the role.
Constraints: Optional row-level or column-level filters that restrict which data within the granted tables is visible.
Important: once you enable OneLake security on an item, it cannot be turned off. Make sure you are ready before enabling it.
The DefaultReader Role
When you first enable OneLake security on a Lakehouse, a DefaultReader role is automatically created. This role gives all users with ReadAll permission full read access to all data in the Lakehouse. This ensures existing users are not suddenly locked out.
To start restricting access, you have two options:
Edit the DefaultReader role to narrow its scope (for example, remove sensitive tables).
Delete the DefaultReader role entirely and create custom roles for each user group.
Who Is Affected?
OneLake security roles only apply to users with the Viewer workspace role or with Read item-level permission. Users with Admin, Member, or Contributor workspace roles bypass OneLake security entirely and can read and write all data.
This is a critical point for exam preparation. If a question asks how to enforce table-level access control, the users in question must be Viewers, not Contributors.
Multiple Roles Resolution
If a user belongs to multiple OneLake security roles, the most permissive role wins. For example, if one role grants full access to a table and another role applies RLS to restrict rows, the RLS will not be enforced because the broader access role takes precedence.
This means you need to keep restrictive and permissive roles mutually exclusive. Do not assign the same user to both a broad role and a narrow role on the same data.
Supported Items
As of early 2026, OneLake security is still in preview and supports the following Fabric items:
Lakehouse
Mirrored databases (added January 2026)
Warehouses use their own T-SQL security model (GRANT/DENY/REVOKE, RLS, CLS, DDM)
OneLake Security and Shortcuts
OneLake security works seamlessly with shortcuts. When a user accesses data through a shortcut, the security roles defined on the source item are enforced, even when the shortcut lives in a different Lakehouse. This means data owners can share data across teams using shortcuts without creating copies and without losing control over security. The original OneLake security roles always apply, regardless of where the shortcut is consumed.
New in January 2026
Granular REST APIs for OneLake security role management (Get, Create, Delete individual roles), enabling CI/CD integration.
Mirrored database support: You can now define OneLake data access roles on all mirrored item types, including table, row, and column-level security.
DP-700 Exam Tip
OneLake security is the recommended approach for consistent data protection across all engines. Remember that it only affects Viewers, not Admins/Members/Contributors. If multiple roles apply to the same user, the most permissive role wins.
4. SQL Granular Permissions: GRANT, DENY, REVOKE in the Warehouse
While OneLake security covers the Lakehouse, the Fabric Data Warehouse uses familiar T-SQL security constructs for granular access control. If you have experience with SQL Server or Azure Synapse, you will feel at home.
The Warehouse supports standard GRANT, DENY, and REVOKE statements on database objects:
-- Grant SELECT on a specific table to a user
GRANT SELECT ON dbo.FactSales TO [analyst@contoso.com];
-- Deny access to a sensitive table
DENY SELECT ON dbo.EmployeeSalary TO [analyst@contoso.com];
-- Revoke a previously granted permission
REVOKE SELECT ON dbo.FactSales FROM [analyst@contoso.com];Best practice: Use the Viewer workspace role for consumers who need read access to the Warehouse, then use T-SQL GRANT statements to give them access to specific objects. This way, they can only see the tables or views you explicitly allow.
For development teams, use Admin, Member, or Contributor workspace roles. These roles provide full access to all Warehouse objects without needing individual GRANT statements.
Only Microsoft Entra authentication is supported in Fabric Warehouse. SQL authentication (username/password) is not available.
DP-700 Exam Tip
If a question asks how to restrict a Warehouse user to specific tables, the answer is to assign them the Viewer workspace role (or share the Warehouse item directly) and then use T-SQL GRANT to give access to only the required tables.
5. How to Implement Row-Level Security (RLS) in Fabric
Row-level security restricts which rows a user can see in a table. It uses predicate-based filtering: you define a function that evaluates each row against the user’s identity, and only matching rows are returned.
How to Implement RLS in the Warehouse
Step 1: Create a security predicate function that returns 1 (allow) or 0 (deny) for each row based on the user:
CREATE FUNCTION security.fn_sales_predicate(@Region AS varchar(50))
RETURNS TABLE
WITH SCHEMABINDING
AS
RETURN
SELECT 1 AS result
WHERE @Region = USER_NAME()
OR USER_NAME() = 'manager@contoso.com';Step 2: Create a security policy that applies the predicate to a table:
CREATE SECURITY POLICY sales.SalesFilter
ADD FILTER PREDICATE security.fn_sales_predicate(Region)
ON sales.FactSales
WITH (STATE = ON);Now, when analyst_eu@contoso.com queries sales.FactSales, they only see rows where Region = ‘analyst_eu@contoso.com’. The manager sees all rows.
RLS in the Lakehouse
RLS can be applied at the SQL analytics endpoint of a Lakehouse using the same T-SQL syntax. However, with OneLake security (Preview), you can now also define row-level filters directly in OneLake security roles. This is the recommended approach for new implementations because it enforces RLS consistently across all engines, not just SQL.
Key Considerations
Filter predicates are applied silently. If all rows are filtered, the query returns an empty result set rather than an error. The user does not know rows exist that they cannot see.
Each table needs its own security policy. RLS does not cascade between tables.
RLS in the Warehouse is enforced only for users without Admin, Member, or Contributor workspace roles.
When RLS is active on a Warehouse table and accessed through Power BI Direct Lake, the semantic model falls back to DirectQuery mode.
DP-700 Exam Tip
RLS is a critical exam topic. Understand how to create filter predicates, apply security policies, and test them using EXECUTE AS. Also know that RLS is enforced for Viewers but not for Admins/Members/Contributors.
6. How to Implement Column-Level Security (CLS) in Fabric
Column-level security restricts which columns a user can see in a table. Unlike RLS (which filters rows), CLS hides entire columns from unauthorized users.
How to Implement CLS in the Warehouse
Use the standard T-SQL GRANT SELECT statement, specifying individual columns:
-- Grant access to all columns except Salary and SSN
GRANT SELECT ON dbo.Employees(EmployeeId, FirstName, LastName, Department) TO [analyst@contoso.com];Now, when analyst@contoso.com queries dbo.Employees, they can see EmployeeId, FirstName, LastName, and Department, but any query that references Salary or SSN will fail with a permissions error.
CLS in the Lakehouse
With OneLake security (Preview), you can define column-level security directly in OneLake data access roles. You specify which columns to exclude from a role when granting access to a table. This is enforced across Spark, SQL, and Power BI.
Key Considerations
CLS operates at the metadata level. A user without column access will get an error if they reference the restricted column, even indirectly.
In Power BI Direct Lake mode, CLS causes a fallback to DirectQuery. Some metadata queries may fail if they reference restricted columns, even when the visual does not explicitly show them.
CLS is complementary to RLS. Use them together for defense in depth: CLS hides sensitive columns, RLS filters sensitive rows.
Only Microsoft Entra authentication is supported for CLS enforcement.
DP-700 Exam Tip
If a question describes a scenario where certain users should not see salary or personal identification columns but need access to the rest of the table, the answer is CLS using GRANT SELECT on specific columns.
7. Dynamic Data Masking (DDM): Obfuscation vs. True Security
Dynamic data masking is different from CLS. Instead of completely hiding a column, it obfuscates the data so that unauthorized users see a masked version while authorized users see the full value. The actual data in the database is not changed.
Mask Types
There are four types of masks:
Default: Full masking. Strings show “XXXX”, numbers show 0, dates show 1900-01-01.
Email: Shows the first letter, then “XXX@XXXX.com” (for example, aXXX@XXXX.com).
Random: Replaces numeric values with a random number within a specified range.
Custom String: Shows a configurable number of characters from the start and end, with custom padding in the middle.
How to Implement DDM
-- Add a mask to an existing column
ALTER TABLE dbo.Customers
ALTER COLUMN Email ADD MASKED WITH (FUNCTION = 'email()');
ALTER TABLE dbo.Customers
ALTER COLUMN Phone ADD MASKED WITH (FUNCTION = 'partial(0, "XXX-XXX-", 4)');Users without Admin, Member, or Contributor workspace roles (and without UNMASK permission) see the masked values. Authorized users see the full data.
DDM vs. CLS: Which to Use?
Dynamic data masking is NOT a replacement for column-level security. Here is why:
DDM is cosmetic. The masked data is still present in the query result. A determined user could use brute-force queries, inference attacks, or joins to reconstruct the original values.
CLS is structural. The column is completely inaccessible. No query can reference it.
Use CLS when you need true security (the user must never see the data). Use DDM when you need a quick obfuscation layer for casual viewers (for example, masking phone numbers in a dashboard).
Microsoft recommends using DDM, RLS, and CLS together as complementary layers.
DP-700 Exam Tip
If a question asks for the most secure way to prevent users from seeing sensitive columns, the answer is CLS, not DDM. DDM is useful for obfuscation but should not be relied upon as a sole security mechanism.
8. SQL Analytics Endpoint: User Identity vs. Delegated Identity Mode
The SQL analytics endpoint for Lakehouses now supports two identity modes that determine how security is enforced. Understanding these modes is critical for choosing the right approach.
User Identity Mode
Security is enforced using OneLake security roles. The SQL analytics endpoint passes the signed-in user’s identity to OneLake, and read access is governed by the roles defined in OneLake. SQL GRANT/REVOKE on tables is not allowed in this mode. RLS and CLS are defined in the OneLake security role UI.
Use this mode when you want to define permissions once in OneLake and have them enforced across all engines consistently. This works best when workspace users are Viewers with read-only access.
Delegated Identity Mode
Security is governed exclusively by SQL permissions defined inside the database. The SQL analytics endpoint connects to OneLake using the identity of the workspace or item owner. This supports traditional T-SQL security: GRANT, REVOKE, custom roles, RLS, CLS, and DDM.
Use this mode when you need traditional SQL-style control, when your environment relies on existing DBA workflows, or when you need DDM (which is not available in OneLake security).
DP-700 Exam Tip
Know the difference between User Identity mode (OneLake roles control everything) and Delegated Identity mode (SQL permissions control everything). If the question asks about consistent cross-engine security, User Identity mode is the answer.
9. Sensitivity Labels, Microsoft Purview, and Encryption
Fabric integrates with Microsoft Purview (formerly Microsoft Information Protection) to provide data classification and sensitivity labeling. This adds a governance layer on top of the technical access controls.
How Sensitivity Labels Work
Sensitivity labels classify Fabric items (Lakehouses, Warehouses, reports, datasets) based on the sensitivity of the data they contain. Labels like “Confidential”, “Highly Confidential”, or “Public” can be applied manually or automatically.
When a label is applied:
The label travels with the data. If someone exports a Power BI report to Excel or PDF, the sensitivity label is preserved.
Encryption and access restrictions can be enforced based on the label.
The label appears in the OneLake Catalog, making it easy for users and auditors to see which items contain sensitive data.
The Govern Tab in OneLake Catalog
As of January 2026, the security and governance insights that were previously available in the Microsoft Purview Hub have been permanently moved to the Govern tab in the OneLake Catalog. The Purview Hub report has been removed. The Govern tab provides a unified command center for administrators, including sensitivity label coverage, endorsement status, and security health across your tenant. This is now the single place to monitor governance and compliance in Fabric.
Workspace Identity
Workspace Identity is a managed identity assigned to a Fabric workspace that allows items within the workspace (like Pipelines, Notebooks, Dataflows Gen2, and OneLake shortcuts) to access secured data sources without storing user credentials. This enables credential-free, service-principal-like authentication for production pipelines.
Workspace Identity integrates with trusted workspace access, meaning you can configure storage accounts or databases to trust only specific Fabric workspaces. This is essential for enterprise security because it eliminates the need to embed passwords or connection strings in your data workflows.
Audit and Activity Logs
All actions within Fabric, including data access, item sharing, workspace changes, and security modifications, are logged and can be monitored. You can access audit logs through Microsoft Purview and PowerShell.
For the Warehouse specifically, SQL audit logs (Preview) provide detailed tracking of T-SQL operations, including who ran which queries and when.
Customer-Managed Keys (CMK)
By default, all data in OneLake is encrypted at rest using Microsoft-managed keys. For organizations that need additional control, Fabric supports customer-managed keys (CMK) via Azure Key Vault (GA). This allows you to encrypt your data using your own keys.
As of early 2026, CMK support has been extended to Azure Key Vaults deployed behind a firewall and to SQL Databases in Fabric (Preview).
DP-700 Exam Tip
If a question asks how to ensure sensitivity classifications persist when data is exported from Fabric, the answer is sensitivity labels from Microsoft Purview. Labels travel with the data across exports and downloads.
10. Outbound Access Protection: Preventing Data Exfiltration
Outbound Access Protection (OAP) allows you to restrict outbound connections from Fabric to only approved external endpoints. This prevents data exfiltration by ensuring Spark jobs, SQL queries, or pipelines cannot send data to unauthorized locations.
As of early 2026:
OAP for Spark and SQL Analytics Endpoints is generally available.
OAP for Dataflows, Data Pipelines, and OneLake shortcuts is in preview.
A Tenant API for OAP is coming soon, allowing tenant admins to see which workspaces have OAP enabled.
This is an important enterprise security feature that limits the blast radius if a notebook or pipeline is compromised.
DP-700 Exam Tip
If a question describes a scenario where you need to prevent Spark notebooks from sending data to unauthorized external storage, the answer is Outbound Access Protection.
Common Security Mistakes to Avoid in Microsoft Fabric
Relying on workspace roles alone. Workspace roles are too broad for data security. All Contributors can see all data. Use OneLake security roles or SQL GRANT statements to restrict access at the data level.
Assuming CLS and RLS apply to Admins/Members/Contributors. They do not. These roles bypass all data security enforcement. Only Viewers and users with item-level Read permission are subject to RLS, CLS, and DDM.
Using DDM as a substitute for CLS. Dynamic data masking is cosmetic. A determined user can reconstruct masked data through inference or brute-force queries. Use CLS when true column-level security is required.
Assigning conflicting OneLake security roles. If a user belongs to a broad role and a restrictive role on the same data, the broad role wins. Keep roles mutually exclusive to avoid unintended access.
Forgetting the DefaultReader role. When you enable OneLake security on a Lakehouse, the DefaultReader role gives all existing users full read access. If you want to restrict access, you must edit or delete this role.
Enabling OneLake security without a plan. Once enabled on an item, OneLake security cannot be turned off. Plan your roles and membership carefully before enabling it, and test in a non-production workspace first.
Not using security groups. Assigning permissions to individual users is hard to maintain and audit. Always use Microsoft Entra security groups for workspace roles, item permissions, and OneLake data access roles.
DP-700 Exam Tip
The exam loves to test security gotchas: Admins bypassing RLS, DDM not being true security, DefaultReader granting broad access, and conflicting role resolution. Pay attention to who the user is (their workspace role) before evaluating which data security features apply.
What is Next
In the next article, we will explore Data Governance with Microsoft Purview, including data lineage tracking, data catalog, sensitivity classification, and how to build a governance framework across your Fabric environment.
Make sure to bookmark this series so you do not miss any upcoming articles.