Fabric Security: Control Plane vs Data Plane

Overview

Microsoft Fabric security is built on two distinct layers that are often confused but serve very different purposes:

• Control plane access determines what you can do in Fabric, such as creating items, managing workspaces, and sharing content.
• Data plane access determines what data you can actually see or interact with inside OneLake.

For much of Fabric’s early life, workspace roles were used as the primary security boundary. That works for collaboration, but it becomes problematic as platforms scale and data products need stronger governance.

This is where OneLake security comes in. It introduces native, fine-grained security directly at the storage layer, allowing organizations to separate operational permissions from data access. At FabCon, Microsoft announced that OneLake security is going GA in April 2026, signaling that this model is ready to become the standard for enterprise Fabric deployments.

Control Plane Access: Workspace Roles

Workspace roles are Fabric’s control plane permissions. They define who can manage and operate inside a workspace.

The key thing to understand is this:

If you are an Admin, Member, or Contributor on a workspace, you can see and access the data stored in OneLake for that workspace.

By default:

• Admins, Members, and Contributors have implicit read and write access to OneLake data.
• These roles are intended for builders and operators, not fine-grained data consumers.
• OneLake security roles primarily affect Viewers or users with only read-level item permissions.

This means workspace roles are not just portal access. Granting control plane access almost always implies broad data visibility within the workspace, which is why overusing Contributor access quickly becomes a governance issue.

Data Plane Access: OneLake Security

OneLake security represents Fabric’s data plane. It governs access to the data itself, independent of who can manage Fabric resources.

With OneLake security, you can:

• Grant access to specific tables or folders
• Apply row-level security (RLS) to filter data per user
• Apply column-level security (CLS) to hide sensitive fields
• Use a deny-by-default model where users only see data explicitly granted to them

Security is defined once in OneLake and enforced consistently across supported Fabric engines, reducing duplication and eliminating mismatched access behavior between SQL, Spark, and other experiences.

Why the Separation Matters

The real breakthrough is the separation of responsibilities:

• Control plane answers: Who can build and operate in this workspace?
• Data plane answers: Who should actually see this data?

Without OneLake security, these concerns are tightly coupled. With it, platform teams can grant broad operational access while data owners retain precise control over who sees what.

This model is critical for governed self-service, regulated environments, and AI-driven analytics, where data access must be consistent no matter how or where data is queried.

Why GA in April 2026 Is a Big Deal

Security features in preview are rarely trusted as the foundation of an enterprise platform. By announcing OneLake security GA in April 2026 at FabCon, Microsoft is signaling that:

• OneLake security is no longer optional or experimental
• Fine-grained data access is expected to be the default pattern
• Workspace roles should stop being used as a proxy for data access

This marks a shift in Fabric from being secured primarily by workspace membership to being secured by data product policy.

Final Thoughts

If you take only one thing away, it should be this: Granting Admin, Member, or Contributor access means granting access to the data in that workspace’s OneLake storage.

OneLake security exists to fix that coupling.

As Fabric matures, the winning architecture will treat workspace roles as operational permissions and OneLake security as the authoritative data access layer. With GA arriving in April 2026, now is the right time to design Fabric environments with that future in mind.