The idea behind Fabric OneLake Security (which GA’d on April 2026) is to centralize data access controls at the data layer, rather than configuring security separately for every Fabric experience. You define security once, close to the data in OneLake, using roles that can control access at the folder, table/object, row, and column levels through object-level security (also called Table-level and folder-level security), row-level security (RLS), and column-level security (CLS). Those rules are then enforced by supported Fabric engines and access paths, such as Lakehouse, Spark notebooks, the SQL analytics endpoint in user identity mode, and Power BI Direct Lake semantic models. Downstream experiences that go through those governed paths, such as Power BI reports or Excel connected through the semantic model, inherit the same secured view of the data.

However, OneLake security is not the native security model for every data location in Fabric. Some data stores use SQL security, some use KQL/Kusto RBAC, some use Power BI semantic model security, and shortcut-based data may require both source-system authorization and OneLake security. A simplified way to think about it is:

Data location / access pattern	Fabric features or tools that may access it	Primary security model	Notes
Lakehouse tables	Lakehouse experience, Spark notebooks, Spark jobs, Data Science notebooks/experiments, SQL analytics endpoint, Power BI Direct Lake semantic models, Power BI reports, Analyze in Excel, GraphQL when backed by Lakehouse/SQL endpoint	OneLake security	Supports table/object-level security, RLS, and CLS when accessed through supported engines.
Lakehouse files and folders	Spark notebooks, Spark jobs, Data Science, Data Pipelines, Copy Activity, OneLake REST APIs, OneLake DFS endpoint, Fabric SDKs, Azure Storage Explorer	OneLake security	Folder/file-level security applies. RLS/CLS are table/query concepts, not raw file filtering concepts.
Lakehouse data through Spark	Spark notebooks, Spark jobs, batch jobs, Data Science workloads	OneLake security	Spark can read Delta tables and files over OneLake. Writes require the appropriate OneLake ReadWrite, item, or workspace permissions.
Lakehouse data through SQL analytics endpoint	SQL analytics endpoint, SSMS or SQL tools connecting to the endpoint, GraphQL when using the Lakehouse SQL endpoint	OneLake security in user identity mode; SQL security in delegated identity mode	In user identity mode, table access, RLS, CLS, and OLS are defined in OneLake. In delegated identity mode, SQL permissions and SQL RLS/CLS/DDM are used instead.
Power BI Direct Lake semantic models over OneLake	Direct Lake semantic models, Power BI reports, Excel Analyze in Excel, Excel connected PivotTables, XMLA-based tools	OneLake security plus Power BI semantic model permissions/security	Users see the secured view exposed through the semantic model. Excel inherits this path when it connects through the semantic model.
Power BI Import semantic models	Power BI reports, Analyze in Excel, XMLA tools	Power BI semantic model security	Not OneLake security at query time because the data is imported into the semantic model. Use Power BI permissions, RLS, and OLS.
Warehouse native tables	Warehouse experience, T-SQL endpoint, Power BI, GraphQL when backed by Warehouse	SQL security	Uses Fabric item/workspace permissions plus SQL permissions such as GRANT, REVOKE, DENY, OLS, RLS, CLS, and DDM.
Warehouse data accessed through OneLake shortcuts or direct OneLake paths	Lakehouse shortcuts pointing to Warehouse data, OneLake API-style access	Do not assume Warehouse SQL security carries over	Warehouse SQL RLS/CLS/OLS is enforced in the Warehouse SQL execution context and is not automatically translated into OneLake security policies. Secure the shortcut/OneLake path separately.
Warehouse external Lakehouse references	Warehouse queries over external Lakehouse references	Depends on access mode and reference path	This is not Warehouse-managed table storage. Treat the referenced Lakehouse data as governed by its Lakehouse/OneLake security path, while Warehouse SQL permissions may still govern SQL objects such as views.
SQL database in Fabric native operational tables	SQL database query editor, SQL clients, applications, GraphQL when backed by SQL database	Fabric item/workspace permissions plus SQL security	Uses SQL access controls for granular security, including database roles, SQL permissions, and RLS.
SQL database in Fabric analytical copy in OneLake	SQL analytics endpoint, Spark/notebooks, Power BI, Fabric analytics experiences	Fabric item permissions plus the SQL analytics / OneLake analytical access path	SQL database data is replicated into OneLake for analytics, but native operational SQL security and analytical access should be considered separately.
Mirrored databases in Fabric	SQL analytics endpoint, Lakehouse/OneLake access paths, Power BI Direct Lake, GraphQL when using mirrored DB via SQL endpoint	OneLake security in Fabric for the mirrored analytical data	Source-system security is not automatically the same as Fabric analytical security. Define Fabric-side access explicitly.
Azure Databricks mirrored catalog in Fabric	Fabric Lakehouse/OneLake access paths, Power BI Direct Lake, Spark/SQL access paths	OneLake security in Fabric for the mirrored catalog data	Source-side Databricks permissions control what is mirrored or available from Databricks; Fabric-side access is governed separately.
KQL/Eventhouse native tables	Eventhouse, KQL database, Real-Time Analytics, KQL queries, Real-Time dashboards	KQL/Kusto RBAC	Native KQL tables are governed by KQL/Kusto roles such as admins, users, viewers, ingestors, and monitors.
KQL/Eventhouse data made available in OneLake	Power BI Direct Lake, Warehouse, Lakehouse, notebooks, SQL endpoint, shortcuts	KQL security for native KQL access; OneLake/security behavior depends on access path	OneLake availability exposes a Delta representation for other Fabric engines. Treat this separately from native KQL RBAC.
KQL external Lakehouse references	KQL database external table references to Lakehouse data	KQL RBAC plus underlying OneLake/shortcut/source permissions	This is not native KQL storage. The external reference points to data governed by the referenced Lakehouse or shortcut path.
Eventstream writing to Lakehouse	Eventstream, Real-Time Intelligence streaming into Lakehouse	Destination Lakehouse / OneLake security after data is written	Eventstream persists data into Lakehouse tables/files. Once landed, access is governed by the destination Lakehouse security model.
Data Pipelines and Copy Activity using Lakehouse source or destination	Fabric Data Factory pipelines, Copy Activity	Source security plus destination security	If reading from or writing to Lakehouse, OneLake permissions apply to the Lakehouse path. If the source or destination is external, that system’s authorization also applies. Do not treat Copy Activity as an RLS/CLS query-filtering engine unless it reads through a supported governed query endpoint.
Internal OneLake shortcuts	Lakehouse shortcuts, KQL shortcuts, Spark, SQL analytics endpoint, Real-Time Intelligence, Analysis Services / Direct Lake, OneLake APIs	OneLake security on shortcut path and target path	The most restrictive permission between the shortcut location and target location applies.
External shortcuts to ADLS, Azure Blob, Amazon S3, S3-compatible storage, Google Cloud Storage, Dataverse, OneDrive, SharePoint, Iceberg, or gateway-backed storage	Lakehouse shortcuts, Spark, SQL, Power BI Direct Lake, OneLake APIs, Storage Explorer	Source/connection authorization plus OneLake security on the shortcut path	External shortcuts use source credentials or delegated authorization, and OneLake security controls what users can see through the shortcut path.
Snowflake data surfaced in Fabric	Mirroring, GraphQL-supported SQL paths, or other supported Fabric access patterns	Usually mirrored-database/Fabric analytical security, not generic filesystem shortcut security	I would not list Snowflake as a standard OneLake filesystem shortcut source unless referring to a specific supported connector/path. Treat Snowflake as source-system authorization plus the Fabric item/security model used to expose it.
OneLake REST APIs	REST clients, automation, custom applications	OneLake security	Programmatic access to OneLake files/tables through APIs. Storage-level access cannot filter RLS/CLS row/column subsets; access may be blocked when the user is not allowed to see the full secured table.
OneLake DFS endpoint / abfss://	ADLS Gen2-compatible tools, Spark paths, custom clients	OneLake security	Direct file/path access through the ADLS-compatible endpoint. Best for file/folder access, not bypassing table-level RLS/CLS.
Fabric SDKs / ADLS-compatible SDKs	Python, .NET, Java, automation tools	OneLake security	Uses OneLake-backed APIs. Same caveat as direct API/DFS access for RLS/CLS-secured tables.
Azure Storage Explorer using the OneLake endpoint	Azure Storage Explorer	OneLake security	Entra-authenticated browsing and file access through the OneLake endpoint. Folder/file permissions apply.
GraphQL API backed by Fabric data	Fabric API for GraphQL over Lakehouse, Warehouse, SQL database, mirrored database sources	GraphQL item permissions plus underlying source security	GraphQL is an API access layer, not a separate storage security model. The effective model depends on whether the source is Lakehouse/SQL endpoint, Warehouse, SQL database, or mirrored data.
Semantic model in Direct Lake mode	Power BI reports, Analyze in Excel, XMLA tools, connected PivotTables	OneLake security plus semantic model permissions/security	This is the BI-facing access path that lets downstream tools inherit the secured Direct Lake view.
Real-Time dashboards, Fabric maps, Power BI reports, and other visual experiences	Reports, dashboards, visual apps	Underlying source or semantic model security	These are consuming experiences, not separate data security models. Security depends on the data source, semantic model, or query endpoint behind the visual.
Dataflow Gen2 output data	Dataflow Gen2 writing to Lakehouse, Warehouse, SQL database, KQL database, or other destinations	Destination security model	Once the data lands, it is governed by the security model of the destination item.
Dataflow Gen2 staging data	Internal Dataflow staging	Managed internal staging	Not usually treated as a directly secured user-facing data location. Focus security design on the source and final destination.

Why this matters

The big shift here is that security moves closer to where the data lives. In the old world, it was common to secure the warehouse one way, the semantic model another way, the notebook experience another way, and then hope everyone remembered to duplicate the same rules in the next thing someone built. That may work when you have a small number of reports and users, but it becomes painful as the environment grows. And when AI enters the picture, with more engines, copilots, agents, notebooks, and APIs touching the same data, “remember to configure it everywhere” is not exactly a strategy.

This is why OneLake security is such an important concept in Fabric. It is Microsoft trying to make the data layer itself a more consistent security boundary, so that the same table or folder can be governed once and then safely used through multiple Fabric experiences. That does not mean every security problem magically disappears (unfortunately, the “make security easy” button is still not in the product), but it does reduce the number of places where teams have to repeat the same rules.

Think of OneLake security as the baseline guardrail

The cleanest way to think about OneLake security is as a baseline guardrail for data stored in OneLake. If a user should not see a table, a folder, certain rows, or certain columns, you want that rule defined as close to the data as possible. Then, when that user accesses the data through a supported path, the same baseline applies.

But the word “baseline” is important. OneLake security does not replace every other Fabric security model, and it does not mean you can stop thinking about workspace roles, item permissions, SQL permissions, KQL roles, or semantic model security. Those layers still matter because Fabric has many different data experiences, and not all of them are native OneLake storage. A Warehouse table is governed differently than a Lakehouse table, and a Power BI Import model is different because the data has been imported rather than queried from OneLake at runtime.

The table above is useful because it helps avoid the most common trap: assuming that “Fabric security” means one thing everywhere. Sometimes the answer is OneLake security, sometimes it is SQL security, KQL/Kusto RBAC, Power BI semantic model security, or some combination of those layers.

How this works with Power BI and Direct Lake

Power BI is where many people will feel the impact first, because Direct Lake can read data directly from OneLake while still giving users the familiar report and semantic model experience. In that pattern, OneLake security can provide the source-level view of what the user is allowed to see, while the semantic model still controls the BI-facing experience, including model permissions and any additional semantic model security. If the report goes through the governed Direct Lake path, the user should inherit the secured view of the underlying data.

The nuance is that security layers can stack. If you use OneLake security for broad data-layer rules and semantic model RLS for report-specific rules, the user must satisfy the effective rules that apply in that path. The semantic model should not be treated as a way to grant back data that was denied at the source. I would use semantic model security when it is truly about the model or reporting experience, and use OneLake security when the rule should follow the data across engines.

How to apply OneLake security

At a high level, applying OneLake security starts with the Fabric item that stores the data, such as a Lakehouse, mirrored database, or mirrored catalog that supports OneLake security. From the item menu, you choose Manage OneLake security and create a new role. You give the role a name, choose the Grant role type, select the permission you want to grant, and decide whether the role applies to all data or only selected tables and folders. For selected data, you choose the specific tables or folders that members of the role should be able to access.

Once the table or folder is in the role, you can add more granular restrictions where they make sense. For folders and files, the rule is about the path: can this user read or write this part of the lake? For tables, you can go further and configure row-level security or column-level security. RLS uses a SQL-style predicate to limit which rows are returned, while CLS removes access to selected columns so users cannot see the data values in those columns.

The final step is assigning members to the role. You can add individual users, Microsoft Entra groups, or security principals, and in some cases use permission-based membership so users with certain Fabric item permissions are included automatically. Whenever possible, I would use groups instead of individual users. Individual assignments feel easy on day one, but they become a maintenance headache later when someone changes jobs, joins a new team, or leaves the company.

Where teams get tripped up

The biggest mistake I see with any centralized security model is assuming it applies everywhere just because the product branding is the same. OneLake security is powerful, but it is not a universal replacement for every Fabric security mechanism. If you are querying a Warehouse through its SQL endpoint, you need to think in SQL security terms. If you are using native Eventhouse tables, you need to think in KQL/Kusto RBAC terms. If you are using an imported Power BI semantic model, you need to think about Power BI model security because the query is not going back to OneLake at runtime.

Shortcuts deserve special attention because they often look simple, but the security story depends on what the shortcut points to and how authentication is handled. An internal shortcut can require permissions on both the shortcut path and the target path, while an external shortcut may require source-system authorization plus OneLake security on the shortcut path. That is why shortcuts should be documented as part of your security design, not just treated as convenient plumbing.

Final thought

My advice is to treat OneLake security as a major step toward simpler, more consistent data-layer governance in Fabric, but not as a reason to stop designing security carefully. Start with the data locations that have the highest reuse, the most sensitive data, or the greatest number of downstream experiences. Define the baseline rules in OneLake where supported, then layer on SQL, KQL, or semantic model security only where that is the correct security model for the access path. And because Fabric is evolving quickly, always verify the latest Microsoft documentation before rolling this into production, especially for supported engines, limitations, shortcuts, and Direct Lake behavior.

More info:

OneLake Security in Microsoft Fabric: Centralized Data Access Control for AI Readiness

Video Introduction to OneLake Security in Fabric (Row, Column & Object Level Security)