OneLake Security: the complete 2026 guide
One security model, defined once, enforced everywhere data is stored in OneLake — that’s the pitch. The reality has a few sharp edges: a default role that quietly grants everyone access, a Power BI connection mode that can bypass the whole system, and shortcut behavior that doesn’t always work the way teams expect on the first try.
OneLake security is a role-based access control model built directly into OneLake — Microsoft Fabric’s storage layer. You define a security role once, scoped to an item, folder, table, or down to specific rows and columns, and that single definition is enforced consistently across Spark, the SQL analytics endpoint, Power BI, and any authorized third-party engine that reads the same data. It reached general availability in May 2026 and is enabled by default on every newly created supported item, with existing items rolled forward automatically by end of May.
What actually changed when OneLake security hit GA
Before this model existed, securing data in Fabric meant configuring access separately for every way someone might reach it. A Spark notebook checked workspace roles. The SQL analytics endpoint ran its own GRANT and REVOKE permission system. Power BI inherited whatever the semantic model’s connection happened to allow. Three different security surfaces, three different places a misconfiguration could hide, and no single place to audit what a given user could actually see across the whole platform.
OneLake security collapses that into one definition. Per the official GA announcement, the model is “an innovative, fine-grained access control model built natively into data lake storage that’s designed to work across multiple engines” — data secured at the item, folder, table, or row/column level, with that security traveling with the data wherever it’s read from, including in apps like Excel when data is accessed outside Fabric entirely.
The rollout mechanics, specifically
- Every newly created supported item has OneLake security enabled automatically from the moment it’s created — no opt-in step required going forward
- Existing items were automatically upgraded over the weeks following the GA announcement, with the full rollout completed by end of May 2026
- This change does not alter existing access on its own — turning the feature on doesn’t immediately restrict anyone. It simply makes the role management interface available so you can start defining real restrictions
OneLake security applies to Lakehouses (full Read/ReadWrite), Mirrored Databases (Read), and Databricks Mirrored Unity Catalog items (Read). Fabric Warehouses are governed by their own SQL-native security model rather than OneLake security roles directly — a distinction that matters a great deal once shortcuts enter the picture, covered in Section 06.
The anatomy of a OneLake security role
Every role, regardless of how simple or complex, is built from exactly four components. Understanding these four pieces is the entire foundation for everything else in this guide — the DefaultReader problem, the RLS/CLS rules, and the shortcut behavior are all just consequences of how these four pieces interact.
Grant only
Only GRANT-type roles exist today. DENY-type roles are on Microsoft’s roadmap but not yet available — you cannot explicitly exclude a user from data; you can only choose not to grant them access in the first place.
Read or ReadWrite
Read covers viewing data and metadata. ReadWrite adds the ability to edit data through Spark notebooks, the OneLake file explorer, or OneLake APIs — not through the Lakehouse UI for Viewers, which isn’t supported.
Tables, folders, or schemas
What the role actually covers — anywhere from a single table to an entire item’s worth of data. Folder-level grants inherit down through every subfolder and file beneath them automatically.
Entra identities
Users, security groups, or non-user identities like service principals. Group membership changes take roughly an hour to propagate; changes to the role definition itself take about five minutes.
The model is deny-by-default. A user who isn’t a member of any role covering a given table sees nothing — not an error, not a blank placeholder, simply no indication the data exists at all in folder and table listings.
The DefaultReader trap — and why it exists on purpose
The moment OneLake security is enabled on an item, Fabric automatically creates a role called DefaultReader. This role grants Read access to every table in the item to any user who already holds the ReadAll permission on it — which, in practice, covers most Viewers in the workspace.
This isn’t a bug or an oversight. It’s a deliberate transition mechanism: enabling security on an item that twelve people already had full access to shouldn’t instantly lock eleven of them out with no warning. DefaultReader preserves the status quo on day one so teams can configure real restrictions on their own timeline rather than under emergency pressure.
If you carefully build a role that restricts the Customer table to three named analysts using row-level filters — but never touch DefaultReader — every other Viewer in the workspace still sees the entire unfiltered Customer table through DefaultReader’s standing grant. Your new restrictive role did nothing, because DefaultReader’s broader grant is still active for everyone it covers. Before treating any new security configuration as actually enforced, either delete DefaultReader entirely or restrict its scope down to genuinely non-sensitive folders.
Two ways to handle it
- Delete it outright — appropriate when you’re building a fully restricted environment from scratch and every user needs to be explicitly assigned to a role before seeing anything
- Scope it down — edit the role and change its coverage from “all data” to a specific subfolder containing only genuinely public, non-sensitive content, leaving sensitive tables to be covered exclusively by roles you define deliberately
Row-level and column-level security — and how overlapping roles actually resolve
Beyond table-level access, a role can carry constraints that filter which specific rows or hide which specific columns its members can see within an otherwise-accessible table. This is what lets a single Sales table serve a regional rep who should only see their own territory and a VP who should see every region, without maintaining two copies of the data.
The one structural rule that catches almost everyone
Row-level and column-level security must be defined together, inside the same role. You cannot split them across two separate roles and expect them to combine the way you’d intuitively expect — a role handling row filtering and a separate role handling column hiding will not compose cleanly on the same table.
How access resolves when a user belongs to more than one role
This is the part of OneLake security where practitioner write-ups genuinely disagree with each other, so it’s worth being precise about what Microsoft’s own access control documentation specifies. Per Microsoft Learn, when a user is a member of multiple roles covering the same data, table-level access combines using a union model for rows and an intersection model for columns:
- Rows — union (least restrictive wins): if Role A grants access to Table X filtered to “Region = Redmond” and Role B grants access to the same table filtered to “Region = New York,” a user in both roles sees rows from both regions — the broader combined set, not the narrower one
- Columns — intersection (most restrictive wins): if Role A allows Column1 and Role B allows Column2 on the same table, a user in both roles sees only the columns permitted by every role they belong to — in this case, neither column individually, only what overlaps
Rows getting more permissive when roles combine, while columns get more restrictive, is not symmetric — and it’s easy to design roles assuming both behave the same way. The practical implication: never assume a narrow row-level role will quietly restrict a user who’s also in a broader role. If User A is in both a “Region = Redmond only” role and a “see all rows” role on the same table, the union model means they see every region — the restrictive role provides no actual restriction once the permissive role is also assigned. Keep genuinely restrictive and genuinely permissive roles mutually exclusive on the same table and the same user.
SQL analytics endpoint access modes — a one-time, deliberate switch
The SQL analytics endpoint sits in front of every Lakehouse, giving T-SQL access to the same Delta tables Spark and Power BI read. It supports exactly two access modes, and the choice between them is not automatic or inferred from your OneLake security roles — it’s a manual, explicit setting per endpoint.
The endpoint passes the signed-in user’s own identity through to OneLake for every read. From that point forward, table access is governed entirely by OneLake security roles — and only by them.
- SQL
GRANTandREVOKEstatements on tables are ignored completely - RLS, CLS, and object-level security are all defined and managed inside OneLake, not in SQL
- OneLake security roles sync to the endpoint with an
OLS_prefix, visible under Database Roles - This is the mode that gives consistent governance across Power BI, notebooks, and SQL together
The endpoint connects to OneLake using the identity of the workspace or item owner, not the querying user. Security is governed exclusively by permissions defined inside the SQL database itself.
- Traditional
GRANT,REVOKE, custom SQL roles, and SQL-defined RLS all work normally - OneLake security roles have no effect on table access through this endpoint
- Dynamic Data Masking is supported in this mode, which user’s identity mode does not currently support
- This is the mode every endpoint starts in by default — switching is opt-in, not automatic
Defining a meticulous set of OneLake security roles, RLS filters, and CLS rules accomplishes nothing for anyone querying through a SQL analytics endpoint still running in delegated identity mode. That endpoint keeps enforcing whatever SQL permissions already existed — completely independent of the OneLake roles you just built. Per Microsoft Learn, switching to user’s identity mode requires navigating to the endpoint’s Security tab → View data access mode → selecting “Use OneLake security for tables” — a step that has to happen once, deliberately, per endpoint.
Shortcuts and security inheritance — mostly seamless, with one real exception
Shortcuts let one lakehouse reference data physically stored in another, without copying anything. The general rule is straightforward and works the way most people expect: when a shortcut points from one item to a table in another, the security roles defined on the source item are enforced, even though the user is browsing the data through a completely different lakehouse.
This is genuinely useful — a central data team can own and secure a customer table once, and five other teams can reference it through shortcuts in their own lakehouses without ever duplicating the data or losing control over who can actually read it. The original OneLake security roles on the source always apply, regardless of where the shortcut is consumed from.
The exception that catches teams off guard
Fabric Warehouses don’t use OneLake security roles natively — they use SQL-native security: GRANT/REVOKE, SQL-defined RLS, CLS, and object-level security, all enforced inside the Warehouse’s own SQL execution context (its TDS endpoint). Those SQL security rules have no equivalent representation in OneLake’s role system.
When Warehouse data is accessed through a OneLake shortcut from a Lakehouse elsewhere, the SQL-level security configured inside that Warehouse is not translated into OneLake security and does not apply. A user could be fully blocked from a sensitive column inside the Warehouse’s own SQL endpoint — and see the complete, unfiltered table the moment someone creates a shortcut to it from a Lakehouse. This is one of the least-documented gaps in the entire model, and it’s exactly the kind of thing that gets discovered during an audit rather than during design. If a Warehouse has meaningful SQL security configured, treat any shortcut someone might create to it as a deliberate security decision, not a convenience.
The Direct Lake gap — where most real-world incidents actually happen
This is consistently the single most reported real-world failure mode following a OneLake security rollout, and it deserves more attention than any other section in this guide.
A Power BI semantic model running in Direct Lake mode reads Delta tables straight from OneLake for speed. By default, that connection authenticates using the semantic model’s own service principal identity — not the identity of whoever is actually viewing the report. The practical consequence: OneLake security roles, RLS, and CLS are evaluated against an identity that always has full access, completely bypassing whatever restrictions you carefully defined for the human looking at the report.
A data team spends months building a properly governed lakehouse — curated tables, defined OneLake security roles, RLS filters on sensitive customer data. An analyst with completely legitimate Viewer access to the workspace builds a Power BI report using a Direct Lake semantic model in that same workspace, including a table that holds restricted data nobody had gotten around to tagging yet. She didn’t do anything wrong by the access she was given. But because the semantic model authenticates with its own identity rather than hers, the report renders the full restricted table to her — and to anyone she shares the report with — none of whom were ever granted OneLake access to that data directly.
Closing the gap
The fix is enabling per-user identity enforcement on the semantic model explicitly, so Direct Lake queries OneLake using the viewer’s own identity rather than the model’s service principal. This is not the default behavior, and it is not something that activates automatically just because you’ve defined OneLake security roles correctly elsewhere — it’s a separate, deliberate configuration on the semantic model itself, and skipping it leaves the single most common real-world bypass of this entire security model wide open.
What OneLake security doesn’t cover — and what fills the rest
No single access control layer covers every governance requirement an enterprise actually has. Knowing what’s explicitly out of scope is what keeps a rollout from being mistaken for a complete governance program.
For everything outside OneLake security’s own scope — sensitivity classification, data loss prevention, network-level restriction — Microsoft Purview, Defender for Cloud Apps, and Fabric’s network security controls (including Outbound Access Protection and Private Links) are the layers that close the remaining distance to a complete governance posture.
Setting up your first restrictive role, step by step
Questions, answered directly
Sources and further reading
Cited in this guide
Related on UIG Data Lab
Accuracy note
Role mechanics, access modes, and the GA rollout timeline are verified against Microsoft Learn’s OneLake Security Access Control Model and the official GA announcement as of June 2026. Some practitioner write-ups describe role conflict resolution differently than Microsoft’s own documentation specifies — this guide follows the official Microsoft Learn description of union-for-rows, intersection-for-columns behavior. DENY-type roles, Dynamic Data Masking in user’s identity mode, and Data Share integration remain on Microsoft’s roadmap and were not available at the time of writing. Verify current capability status on Microsoft Learn before production rollout decisions. UIG Data Lab is an independent publication and is not affiliated with or endorsed by Microsoft Corporation.