Microsoft Fabric OneLake Security Is Finally GA — Here’s What You Need To Know

It started with the best of intentions.

Our Microsoft Fabric data analytics team had spent months building a beautifully governed lakehouse in OneLake. Tables were curated. Data contracts were defined. The lakehouse was humming along, serving clean, trusted datasets to the entire organisation. It was a thing of beauty.

Then someone built a Power BI report.

Now, before you roll your eyes — I’m not blaming the analyst. She did exactly what we’d trained everyone to do: find the data you need, build a report, publish it. The problem wasn’t her. The problem was that her report, innocently built with her Read access, happened to include a lakehouse table that held restricted sensitive data.

She didn’t know it was sensitive. The data hadn’t been tagged yet. And because she had Viewer access to the workspace, and the semantic model was using Direct Lake mode in the same workspace, the permissions path looked like this:

Power BI Report → Semantic Model → Direct Lake → Lakehouse (same workspace)

She shared the report. Management loved it. It got published to a broader audience.

And suddenly, users who should never have seen sensitive data… could.

No one had done anything malicious. The security model just had a gap — and data leaked through it.

The Problem: Microsoft Fabric Security Was Fractured

We had all the right pieces, but they didn’t connect. Your data lives in OneLake, but how you secure it depends on how someone tries to access it:

• Through a Spark notebook? Workspace roles apply.
• Through the SQL analytics endpoint? That’s a whole separate permission model with GRANT/REVOKE.
• Through a shortcut? Depends on whether you’re using passthrough or delegated auth — and good luck tracing the chain.
• Through Power BI Direct Lake? The semantic model uses an SPN identity for data access, completely bypassing the user’s own permissions.

The result? Well-meaning teams spend months building governed data, then a single Power BI report — built with perfectly legitimate access — becomes the backdoor that exposes sensitive information.

It’s not a people problem. It’s a security model problem.

The Breakthrough: OneLake Security Is Now GA

As of May 2026, Microsoft Fabric OneLake security has hit General Availability, and it fundamentally changes the game.

Here’s why that matters: with OneLake security, that same Power BI scenario plays out completely differently now.

With OneLake security roles enabled, query access is validated against the underlying OneLake/Lakehouse security layer using the end user’s identity. When a Viewer opens the report, OneLake verifies whether that user has permission to read the sensitive table, folder, or files being queried.

If they don’t — the data doesn’t render. Period. The Viewer sees the report structure but no restricted data, even though the semantic model is in Direct Lake mode in the same workspace.

That’s the killer feature. OneLake security is the single data plane security model for all data stored in OneLake. Define your security roles once, and they’re enforced consistently across every Fabric engine — Spark notebooks, SQL analytics endpoints, Power BI, you name it.

No more duplicating permissions. No more “it works in Spark but not in SQL.” No more analysts accidentally exposing data because the security model assumed everyone behind a report had the same access.

How It Works

OneLake security uses a role-based access control (RBAC) model. Each role has four components:

1. Type — Currently only GRANT (DENY is on the roadmap)
2. Permission — Read or ReadWrite
3. Scope — The tables, folders, or schemas you’re securing
4. Members — Entra ID users, groups, or service principals

It’s deny-by-default, which means if you haven’t explicitly granted access, the user sees nothing.

Supported Items

The Hierarchy

OneLake is a hierarchical data lake, like ADLS Gen2. Security flows down:

Workspace → Item → Folders (Tables/, Files/) → Files

Permissions at a parent level cascade to children. Grant read access to a folder, and everything inside it — including subfolders — is accessible.

Verifying Role Membership

When a user reports seeing different data in Spark vs the SQL analytics endpoint, you can check their OneLake security role membership directly against the endpoint:

SELECT
    r.name AS RoleName,
    m.name AS MemberName,
    m.type_desc AS MemberType
FROM sys.database_role_members drm
JOIN sys.database_principals r
    ON drm.role_principal_id = r.principal_id
JOIN sys.database_principals m
    ON drm.member_principal_id = m.principal_id
WHERE r.name = 'YourRoleName';

Source: Microsoft Learn: Troubleshoot OneLake security for SQL analytics endpoints

In user identity mode, OneLake security roles propagate to the SQL endpoint with an OLS_ prefix — they’ll show up in Object Explorer under Security → Roles → Database Roles. If you don’t see them, your security sync may be stuck or the endpoint is still in delegated mode.

The Two Modes of SQL Analytics Endpoint

This is where it gets interesting. The SQL analytics endpoint can run in one of two modes:

👤 User Identity Mode (New Hotness)

The SQL endpoint passes the signed-in user’s identity to OneLake for permission checks. OneLake security roles are fully enforced — including RLS and CLS. This is the mode you want for consistent governance.

To enable it, navigate to your SQL analytics endpoint → Security tab → View data access mode → select Use OneLake security for tables (User’s identity access mode).

-- Once enabled, SQL GRANT/REVOKE on tables is ignored.
-- All table-level security comes from OneLake roles.
-- Security roles sync automatically (up to 5 min latency).

🔄 Delegated Identity Mode (The Old Way)

The SQL endpoint uses the item owner’s identity to access OneLake. Security is managed entirely through traditional SQL GRANT/REVOKE, RLS, and Dynamic Data Masking. OneLake security roles are not enforced here.

Choose this mode if you have legacy T-SQL tooling that needs full SQL-native security compatibility.

Important: Switching modes temporarily makes SQL analytics endpoints unavailable across the entire workspace. Do it during maintenance windows.

Row and Column Level Security in Microsoft Fabric

OneLake security supports both RLS and CLS — and yes, they work across all engines:

In the OneLake security UI, you define RLS as SQL predicates just like you would in a traditional SQL Server security policy. Under the hood, it’s the same T-SQL pattern:

-- Create a security predicate function
CREATE FUNCTION Security.fn_securitypredicate(@UserName AS varchar(50))
    RETURNS TABLE
WITH SCHEMABINDING
AS
    RETURN SELECT 1 AS result
WHERE @UserName = USER_NAME()
   OR USER_NAME() = '[email protected]';
GO

-- Bind it to your table with a security policy
CREATE SECURITY POLICY SalesFilter
ADD FILTER PREDICATE Security.fn_securitypredicate(SalesPersonID)
ON Sales.SalesOrderHeader
WITH (STATE = ON);
GO

Source: Microsoft Learn: Implement row-level security

In the OneLake security UI, you skip the boilerplate — just give it the WHERE clause. The predicate function and policy are generated for you.

For external engines (third-party query engines integrating with OneLake security via the authorized engine model), the effective access comes back as JSON:

{
  "identityETag": "3fc4dc476ded773e...",
  "value": [
    {
      "path": "Tables/dbo/Customers",
      "access": ["Read"],
      "rows": "SELECT * FROM [dbo].[Customers] WHERE [customerId] = '123'",
      "columns": [
        {"name": "address", "columnEffect": "Permit", "columnAction": ["Read"]},
        {"name": "city", "columnEffect": "Permit", "columnAction": ["Read"]}
      ],
      "effect": "Permit"
    }
  ]
}

Source: Microsoft Learn: OneLake security integrations

This means external engines don’t need to re-implement the auth model — they just fetch the user’s effective permissions and enforce them.

How Multiple Roles Combine

Here’s a subtle but important detail. If a user is in multiple security roles, OneLake combines permissions using a UNION (least-restrictive) model for objects, but an INTERSECTION model for columns.

So if Role1 gives access to TableA with RLS filtering to “Redmond” and Role2 gives access to TableA with RLS filtering to “New York”, the user sees both rows. But if Role1 allows Column1 and Role2 allows Column2, the user only sees columns granted by all roles.

The formal formula (yes, there’s a formula):

Effective Access = (R1_ols ∩ R1_cls ∩ R1_rls) ∪ (R2_ols ∩ R2_cls ∩ R2_rls)

For shortcuts, there’s an additional layer of inferred roles that propagate permissions from the source. It’s elegant, but you need to understand the algebra if you’re doing anything complex.

Default Roles — The “Oops” Trap

Every new lakehouse comes with default roles baked in:

• DefaultReader — Gives Read access to all tables to anyone with ReadAll permission.
• DefaultReadWriter — Gives ReadWrite access to anyone with Write permission.

This means by default, anyone who can see your lakehouse can read all its data. That’s fine for development, but in production, delete the DefaultReader role or your data is wide open.

Microsoft’s own docs say it plainly:

“When you add a user to a data access role, make sure that you remove them from the DefaultReader role. Otherwise, they maintain full access to the data.”

Learned that one the hard way, I’m sure. 😅

Microsoft Fabric Shortcuts Security

Shortcuts are one of Fabric’s superpowers, and OneLake security handles them cleanly:

• Passthrough shortcuts (SSO): The calling user’s identity flows through to the target. The user must have OneLake security permissions on the target data.
• Delegated shortcuts: Uses a fixed credential. OneLake security is evaluated at the shortcut level, then the delegated credential.

Gotcha: Power BI semantic models using Direct Lake over SQL and T-SQL engines in delegated mode don’t pass the user’s identity through shortcuts. Use Direct Lake over OneLake mode or user identity mode to fix this.

Also: when listing directories, all internal shortcuts are shown regardless of access. It’s only when you try to open a shortcut that OneLake checks permissions. This is by design — it enables discoverability — but it means a user might see a shortcut name without being able to open it.

Limitations You Should Know

OneLake security is GA-capable, but it’s not unlimited:

• 250 roles per Fabric item (can request 1000)
• 500 members per role
• 500 permissions per role
• ~5 minutes for role definition changes to propagate
• ~1 hour for group membership changes to propagate

Also:

• Distribution lists don’t resolve in SQL analytics endpoints — users appear as non-members. Use security groups instead.
• B2B guest users need specific Entra External ID settings configured.
• Spark notebooks need runtime 1.3+ (Fabric 3.5+).
• Data preview for RLS/CLS secured tables isn’t supported for non-schema lakehouses. Use schema-enabled lakehouses.

Lessons Learned

After spending way too many late nights untangling permission issues, here’s what I’d tell my past self:

1. Plan your hierarchy before you build. OneLake security permissions inherit down the folder tree. Structure your data so that broad access can be granted at high levels and sensitive data lives in restricted subfolders.

2. Use security groups, not individual users. Managing 500 individual user assignments is a nightmare. Groups scale. Distributions lists don’t work in SQL endpoint.

3. Remove DefaultReader in production. Do it on day one. Give yourself an explicit “break glass” role for admins and nothing more.

4. User identity mode or bust. If you’re building new, use user identity mode on your SQL analytics endpoints. Delegated mode is for backward compatibility only.

5. Shortcuts need special attention. Understand the difference between passthrough and delegated auth. Shortcuts look like magic until they leak data because the wrong identity was used.

6. The 5-minute rule is real. Role changes take ~5 minutes to sync. Group changes take ~1 hour. Don’t make security changes in an incident and expect instant results.

The Bottom Line

OneLake security GA is a massive step forward for Fabric governance. It gives you a single data plane security model that works across every query engine, with support for RLS, CLS, and shortcuts.

Is it perfect? No. The latency on group changes is painful. Distribution list support would be nice. And 250 roles per item might feel tight in complex environments.

But it’s one model instead of three. And after years of wrestling with fractured permissions across workspace roles, item sharing, and SQL GRANTs, I’ll take “good enough and unified” over “perfect and impossible to manage.”

Are you using OneLake security in production? Hit any gotchas I missed? Drop a comment below — I’d love to hear how you’re approaching Fabric governance.