Understanding Microsoft Fabric OneLake Security

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:

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)

The post Understanding Microsoft Fabric OneLake Security first appeared on James Serra's Blog.