Every enterprise data platform faces the same fundamental challenge: how do you give people access to the data they need without exposing data they shouldn’t see? Traditionally, this meant a patchwork of security configurations, like having one set of rules for your SQL warehouse, another for your Spark jobs, and yet another for your BI reports. You’d define the same policy three times, and inevitably something would fall out of sync.

Microsoft Fabric’s OneLake security solves this with a single, unified security layer that sits directly on the data, not on the compute engine on top of it. Define your rules once, and they’re enforced consistently whether a user queries via Spark, SQL Analytics Endpoint, Power BI DirectLake, or any authorized third-party engine.

In this post, we’ll walk through the full setup from creating sample data to configuring table-level, row-level, column-level, and file folder security with code you can run yourself.

Current Status: OneLake Security is in public preview as of the time of writing. It supports Fabric Lakehouses and mirrored databases.

Architecture Overview

Before getting into setup, it helps to understand the two security planes in Microsoft Fabric:

OneLake Security operates on the data plane. It defines granular access policies that travel with the data itself.

The Permission Hierarchy

Critical point: OneLake Security only affects viewers and users who access data through item-level read/read all permissions. Workspace Admins, Members, and Contributors always have full read+write access and bypass OneLake security entirely. This is by design; they need to manage the data.

Enable OneLake Security

We’ll use four Delta tables in our Lakehouse SecurityDemoLH, each designed to showcase a different security capability:

Plus four file folders:

Open SecurityDemoLH -> Click Manage OneLake security in the top toolbar -> Read and accept the confirmation dialog -> Click Continue.

Fabric immediately creates a DefaultReader role. This role grants full read access to all tables and files for any user with ReadAll permission on the item. It ensures no one loses access immediately after enabling security.

In addition to the step above, you will also need to switch the data access mode from SQL Security to OneLake Security  from the SQL Analytics Endpoint: In your workspace, open the SQL analytics endpoint for SecurityDemoLH, Click the Security tab in the ribbon -> View data access mode -> Data Access Mode (Preview) -> switch to Use OneLake security for tables

The DefaultReader role must be modified before your security configuration takes effect. Otherwise all ReadAll users still see everything.

Option A: Delete DefaultReader (for a full demo with restricted access): 1. In the OneLake Security panel, select the DefaultReader role checkbox 2. Click Delete → Confirm

Option B: Restrict DefaultReader to Public folder only: 1. Click on DefaultReader → Edit 2. Change scope from “All data” to “Selected data” 3. Check only Files/Public 4. Save

Object-Level Security (Table & Folder Access)

OLS controls which tables and folders a user’s role can see. Users in a role without a specific table/folder listed simply cannot discover or query that object.

Security Roles We’ll Create

Choose the Objects

After you click "Create Role", a SalesAnalyst who opens the Lakehouse Explorer or runs SHOW TABLES will only see Sales and Products. The Customers and EmployeeSalary tables are completely invisible to them.

Key behavior (Folder traversal): When you grant access to a subfolder (e.g., Files/Financials), the user can navigate to it but cannot see sibling folders (Files/Marketing). Access checks happen at read time, not at listing time.

Row-Level Security (RLS)

RLS restricts which rows within a table are visible to a user. You define the filter using a familiar SQL WHERE clause predicate.

RLS Syntax:

SELECT * FROM {schema}.{table} WHERE {condition}

Supported operators: =, <>, >, >=, <, <=, IN, NOT, AND, OR, IS NULL

Max length: 1,000 characters per rule

We have now successfully created RLS on the sales role, which restricts sales role users to only see the records where country is 'USA'

Column-Level Security (CLS)

CLS hides specific columns from users. It uses a deny-list approach. You start with all columns visible, then remove the ones you want to hide.

How Enforcement Works by Engine

Choose the column to hide and then click Remove and Save. Here I have just hidden the Amount column in the Sales Tables from the users who are part of the Sales Role.

Shortcuts and Security

OneLake Security integrates with Fabric shortcuts in two scenarios:

Internal Shortcuts (OneLake → OneLake)

When a shortcut points from one Fabric item to another OneLake item, the security from the target item applies. The user must have permissions at the target lakehouse.

External Shortcuts (ADLS Gen2, S3, Dataverse)

External shortcuts use a double gate model:

1. The user must have the Fabric Read permission on the shortcut item

2. The external storage credential must also authorize the user’s access

Both must pass for a read to succeed.

Listing behavior: Shortcuts always appear in folder/table listings. Access is checked only when a user actually attempts to read data through the shortcut.

Best Practices

Use Entra ID security groups for role membership rather than individual users. Group membership changes take ~1 hour to propagate; role definition changes take ~5 minutes.

Delete or restrict DefaultReader immediately after enabling OneLake Security; otherwise all your other roles have no effect.

Keep RLS predicates simple: integer and string equality checks (=) perform best. Complex expressions with functions can impact query latency.

RLS + CLS must be in the same role; never split them across roles.

OneLake Security brings enterprise-grade, fine-grained access control to Microsoft Fabric, and it’s designed around a simple principle: define once, enforce everywhere. The same security policy applies whether your users query through Spark notebooks, the SQL Analytics Endpoint, Power BI DirectLake reports, or authorized third-party engines without any engine-specific re-configuration.