Microsoft Fabric is a SaaS platform, so a lot of security is handled for you — encryption, patching, the underlying infrastructure. What's left to you is the part that actually causes incidents: who can reach the platform, who can open an item, and what data they can see once they're in. Get the model right and Fabric is genuinely enterprise-grade. Get one layer wrong and the others won't save you.

Fabric security spans four layers, plus a cross-cutting protection layer. The rule that matters: design all four together — a gap in any one undermines the rest.

The four layers at a glance

LayerControlsMechanisms
NetworkCan traffic reach the tenant?Private Links, managed VNet / private endpoints, Conditional Access
IdentityWho is the caller?Entra ID, service principals, workspace identity, MFA
Workspace / itemCan they open the item?Workspace roles, item sharing, permissions
DataWhich rows / columns / tables?OneLake security roles: RLS, CLS, OLS
ProtectionIs data protected & governed?Encryption (TLS, CMK), sensitivity labels, DLP, Purview

1. Identity & access — the entry point

Every authentication flows through Microsoft Entra ID, so this is where access begins and where most least-privilege work pays off.

  • Entra ID + MFA — enforce multi-factor authentication and least privilege on every account that reaches Fabric.
  • Service principals / workspace identity — for pipelines, jobs and CI/CD, use a workspace identity (a managed service principal) or an SPN rather than a person's account. Credentials never get embedded, and access survives staff changes.
  • Conditional Access — apply Entra policies on device, location and risk to gate who can reach the tenant at all.

2. Workspace & item permissions — the boundary with a trap

A workspace is the primary collaboration and security boundary. Roles grant broad access; items inherit workspace permissions and can add their own. The catch is in what the higher roles can do:

  • Admin / Member / Contributor — can read and write all data in the workspace's items, and crucially they bypass OneLake data-access (RLS/CLS/OLS) roles entirely.
  • Viewer — read access, and it is the role to which OneLake security roles actually apply.
  • Item sharing — share a single Lakehouse, Warehouse or report without granting workspace-wide access — useful for least-privilege external sharing.

"Granular row and column rules only constrain Viewers. Put a user you want restricted into Admin, Member or Contributor and your RLS quietly does nothing."

This is the most common misconfiguration we see: data-level rules carefully defined, then undermined because the people they were meant to restrict hold a workspace role that bypasses them.

3. Data-level security — OneLake security, RLS, CLS, OLS

OneLake security lets you define fine-grained access once, in the OneLake experience, and it is then honoured across engines that respect it — notably the SQL analytics endpoint and Direct Lake. Three controls work together:

  • Row-Level Security (RLS) — restricts which rows a role can see (e.g. a regional manager sees only their region).
  • Column-Level Security (CLS) — hides specific columns such as salary or PII from a role.
  • Object-Level Security (OLS) — controls which tables or folders a role can even discover; objects not listed are invisible and unqueryable.

The advantage of defining these as OneLake security roles is reach: any tool that respects OneLake security applies them — not just Power BI. That single property is what makes the next decision the most important one on this page.

4. The decision that turns a bug into a breach: where to enforce RLS

If you take one thing from this article, take this. Row-level security can live in two very different places, and they are not equivalent:

  • Semantic-model RLS — enforced by Power BI only. Direct Spark or notebook access to the Lakehouse bypasses it entirely.
  • OneLake security / Lakehouse–Warehouse RLS — enforced at the data layer, so any respecting tool honours it. This is the safe default whenever consumers use more than Power BI.
  • Direct Lake integration — Direct Lake can integrate OneLake security so the model honours the underlying data-layer rules rather than duplicating them.

Never assume semantic-model RLS protects direct Lakehouse access. It does not. If a single analyst can point a notebook or SSMS at the Lakehouse, model-only RLS is decorative — enforce at the data layer.

5. Network security

Necessary, but never sufficient on its own:

  • Private Links — restrict tenant access to an Azure VNet and block public access, so only that network can reach notebooks, Lakehouses, warehouses and databases.
  • Managed virtual network — Fabric-managed isolation for Spark workloads; compute clusters run in a dedicated network.
  • Managed private endpoints — let workspace admins reach data sources behind a firewall or with no public access.

Pair private endpoints with identity and data-layer controls. Locking the network alone leaves over-permissioned users completely unaddressed.

6. Encryption & data protection

  • In transit — always encrypted with TLS 1.2+ (negotiating TLS 1.3 where possible) between Microsoft services.
  • At rest — encrypted by default; add customer-managed keys (CMK) for keys you own and control.
  • Masking — apply column masking for sensitive fields where consumers need the row but not the raw value.

7. Governance & compliance

  • Sensitivity labels — Microsoft Information Protection labels classify items and flow with the data, including into exports.
  • Data Loss Prevention (DLP) — policies detect and restrict sensitive data movement.
  • Purview integration — catalog, lineage, classification and audit across the estate — important for regulated domains such as fintech.
  • Auditing — track access and activity via the audit log for compliance evidence.

The Fabric security checklist

A condensed version of the above — the things worth confirming on every Fabric environment before it carries real data:

  • Enforce MFA + Conditional Access; use service principals / workspace identity for all automation.
  • Keep restricted users out of Admin/Member/Contributor — those roles bypass data-level security.
  • Define RLS/CLS/OLS at the data layer (OneLake security), not only in the semantic model.
  • Use Private Links / managed private endpoints to remove public exposure where required.
  • Enable CMK where key ownership is mandated; apply sensitivity labels + DLP.
  • Register the tenant in Purview for lineage, classification and audit.

Frequently asked questions

What are the layers of security in Microsoft Fabric?
Fabric security is layered across four areas: network (can traffic reach the tenant — Private Links, managed VNet, Conditional Access), identity (who the caller is — Entra ID, service principals, MFA), workspace and item permissions (can they open the item — workspace roles, item sharing), and data-level security (which rows, columns and tables they see — OneLake security with RLS, CLS and OLS) — plus a protection layer of encryption, sensitivity labels and Purview. A gap in any one layer undermines the others, so they must be designed together.
Do Fabric workspace roles bypass row-level security?
Yes. Admin, Member and Contributor roles can read and write all data in the workspace's items and bypass OneLake data-access roles (RLS/CLS/OLS) entirely. Those granular rules only constrain Viewers and users with item-level Read. If you want a user restricted by row- or column-level security, do not place them in Admin, Member or Contributor and expect the rules to hold.
Where should you enforce row-level security in Microsoft Fabric?
At the data layer (OneLake security or Lakehouse/Warehouse RLS) whenever consumers can reach the data through more than Power BI. Semantic-model RLS is enforced by Power BI only and is bypassed entirely by direct Spark or notebook access. Direct Lake can integrate OneLake security so the model honours the data-layer rules rather than duplicating them. Never assume semantic-model RLS protects direct Lakehouse access — it does not.
What is OneLake security (RLS, CLS, OLS) in Fabric?
OneLake security defines fine-grained access once, in the OneLake experience, and it is honoured across engines that respect it — notably the SQL analytics endpoint and Direct Lake. RLS restricts which rows a role sees; CLS hides specific columns such as salary or PII; OLS controls which tables or folders a role can even discover. Defining them as OneLake security roles means any respecting tool applies them, not just Power BI.
How is data encrypted in Microsoft Fabric?
Data is always encrypted in transit with TLS 1.2 or higher (negotiating TLS 1.3 where possible) between Microsoft services, and encrypted at rest by default. For keys you own and control, add customer-managed keys (CMK). Column masking can also be applied to sensitive fields where consumers need the row but not the raw value.

Worried your Fabric or Power BI access model has a gap like the RLS one above? It's exactly the kind of thing our migration and audit work is built to catch. Book a scoping call.

Security in Fabric isn't about finding one master switch — it's about making sure the four layers agree with each other. The most expensive mistakes are the quiet ones: a network locked down while an over-permissioned role reads everything, or row-level security that protects the report but not the lake beneath it. For the architectural choices that sit alongside these, see our guide to the Fabric decisions that are hard to undo.