Microsoft Fabric Security, Explained: OneLake Security, Identity Modes & Engine Enforcement

Thumb
09 Sep 2026

Microsoft Fabric Security, Explained: OneLake Security, Identity Modes & Engine Enforcement

Learn how Microsoft Fabric enforces security across every engine — from workspace roles and OneLake Security to identity modes and engine-level enforcement.

A plain-English guide to how Microsoft Fabric security really works: control plane vs data plane, workspace role bypass rules, User vs Delegated identity modes, and the engine enforcement matrix.

Microsoft Fabric puts every engine — SQL, Spark, Power BI, Lakehouse, Eventhouse — on top of one shared data layer, OneLake. That’s powerful, but it raises an obvious question: if everything reads from the same place, how do you make sure the right people see the right data? This is a practical, plain-English walkthrough of how Fabric security actually works, from workspace roles down to OneLake Security itself.

Control Plane vs Data Plane

Fabric security operates on two separate planes, and mixing them up is the single most common source of confusion.

Control Plane Workspace Roles Admin . Member . Contributor . Viewer Governs who can open/manage the workspace Admin/Member/Contributor bypass OneLake Security Data Plane OneLake Security Row / Column / Object-level rules Enforced by every engine, at the data itself Only Viewers are governed by these rules

The key takeaway: OneLake Security is the only security that matters for data access. Workspace roles control who can manage a workspace — but Admins, Members, and Contributors bypass OneLake Security entirely. Only the Viewer role is actually governed by row/column/object-level rules.

↑ back to top

Workspace Roles & Bypass Rules

RoleManages WorkspaceBypasses OneLake Security
AdminYesYes
MemberYesYes
ContributorYes (limited)Yes
ViewerNoNo — governed by OneLake Security rules
Common mistake: assuming a restrictive OneLake Security rule protects data from every user in the workspace. It doesn’t — anyone with Admin, Member, or Contributor access sees everything regardless of the rule.
↑ back to top

Identity Modes: User’s Identity vs Delegated Identity

This is the most consequential configuration decision in a Fabric security setup, and it’s not easily reversible once downstream permissions are built around it.

User’s IdentityDelegated (Fixed) Identity
Who the engine seesThe actual signed-in user (Entra ID token passthrough)A single fixed service identity for every query
Cross-engine consistencyConsistent — same identity everywhereInconsistent — one identity masks individual users
Recommended forNew implementationsLegacy patterns migrating gradually
RiskLowSwitching later has destructive side effects on existing SQL permissions
Recommendation: use User’s Identity for any new Fabric implementation. It keeps enforcement consistent across every engine and avoids a costly identity-mode migration later.
↑ back to top

Engine Enforcement Matrix

OneLake Security is enforced consistently, but rollout status varies slightly by engine:

EngineOneLake Security Enforcement
Lakehouse (SQL analytics endpoint)GA
SparkGA
Power BI / Semantic ModelsGA
Lakehouse UI (Explorer)GA
Eventhouse (KQL)Preview
External enginesPreview
↑ back to top

Best Practices

  • Default to User’s Identity for new Fabric workspaces — don’t set Delegated Identity out of habit from legacy patterns.
  • Remember Viewer is the only role actually governed by OneLake Security — design your workspace role assignments accordingly, not just your data rules.
  • Document identity-mode decisions before granting broad SQL permissions; changing modes later can break existing access.
  • Treat Eventhouse and external-engine access as preview-stage — validate enforcement behavior before relying on it for sensitive data.
Want a security review of your own Fabric workspace? Book an architecture advisory session with Translyticx Consulting.

Sources: Microsoft Fabric security fundamentals, OneLake Security (preview) — Microsoft Learn.

Leave a comments