Back to Blog

Microsoft Fabric Security and Governance Checklist - 2026 Buyer Edition

May 14, 2026•10 min read•Michael Ridland

If you are about to sign for Microsoft Fabric, or already paying for it and wondering whether your setup is actually safe, this is the checklist I wish someone had handed me three years ago. It is written for the person on the buying side of the table, not the consultant trying to win the work.

Fabric is genuinely good. It is also a product where the defaults are not what most Australian organisations need. The combination of OneLake, workspaces, semantic models, real-time intelligence and Copilot means there are a lot of moving parts that touch sensitive data. Each part has its own permissions model, and they do not always agree with each other.

This is the checklist we walk through with every new client engagement at Team 400. Most of the items take an afternoon to configure. A few take weeks because they require conversations with people who do not currently know what Fabric is. Either way, you want them done before the platform goes anywhere near production data.

The Tenant Settings That Catch People Out

Before workspaces, before sensitivity labels, before any of the fancy stuff, you have to get tenant settings right. These are the toggles your Fabric admin controls from the admin portal, and they apply across every workspace in your tenant.

The defaults are usually too permissive. Here is what to lock down first.

External Sharing

Out of the box, Fabric lets users invite guest accounts and share content with people outside your tenant. For most Australian businesses I work with, this should be either disabled or restricted to specific security groups. We have seen organisations where a single analyst shared a workspace with a personal Gmail account "just to test something" and forgot about it. Six months later the workspace had grown to include payroll data.

Check: Admin portal, Tenant settings, "Allow Azure Active Directory guest users to access Fabric." Restrict to a named group of people who actually need it.

Service Principal Access

Service principals are how automation tools authenticate to Fabric. They are also how attackers move sideways once they have compromised a developer account. Restrict service principal use to a specific security group, and make it a deliberate ticket-driven process to add a service principal to that group.

Publish to Web

Publish to web makes a report viewable by anyone with the link, with no authentication. There is essentially no legitimate use case for this in a corporate Fabric tenant. Disable it at the tenant level. If someone needs to share a chart with the public, they can screenshot it and put it on the company website.

Export and Sharing Permissions

Several settings control whether users can export data to Excel, CSV, PowerPoint, or PDF. The right answer depends on your data classification, but for any tenant holding regulated data (financial services, healthcare, government), these should be controlled per workspace based on sensitivity, not allowed tenant-wide.

Workspace Design - The Part Everyone Gets Wrong

Workspaces are where Fabric items live. They are also the primary unit of access control. Get workspace design wrong and you will spend the next two years untangling it.

One Workspace Per Project, Per Environment

The single biggest mistake I see is teams using one giant workspace for everything. Development items mixed with production items, finance datasets sitting next to marketing datasets, semantic models that nobody can find. When you add a new analyst, you give them access to all of it.

The right pattern is at least three workspaces per project: dev, test, and production. For larger organisations, separate workspaces by business domain as well. Yes, this means more workspaces to manage. Yes, it is worth it.

Workspace Roles Are Not Granular Enough

Fabric workspaces have four roles: Admin, Member, Contributor, Viewer. These are coarse. A Contributor can publish content, modify items, and schedule refreshes. There is no built-in role for "can build reports but cannot modify the semantic model."

For larger teams, this means you need to design around the limitation. Either separate the semantic model into its own workspace where only the data team has Contributor rights, or accept that everyone in your reporting workspace can technically break things and rely on source control and review processes.

Use Security Groups, Not Individual Users

Every workspace role assignment should go to an Azure AD security group, never to individual user accounts. When Jane leaves the company, you remove her from the group and her access disappears from every workspace at once. When you assign individual users, you are guaranteed to forget at least one workspace when someone leaves.

OneLake and the Permissions Puzzle

OneLake is the data layer underneath all of Fabric. It is fundamentally a managed Azure Data Lake Storage Gen2 instance with some clever metadata on top. The permissions model has improved a lot since the early Fabric days, but it is still where most security incidents happen.

Item-Level Permissions

Each lakehouse, warehouse, KQL database and semantic model can have its own permissions on top of the workspace permissions. You can grant someone read access to a specific table in a lakehouse without giving them workspace access. This is useful, but it creates an audit nightmare if you do not document it.

Rule we apply: item-level permissions are exceptions, not the default. If you find yourself adding individual users to specific tables, you probably have the wrong workspace structure.

OneLake Security (Preview)

OneLake Security, which entered general availability earlier this year, lets you apply row-level and column-level security at the OneLake level rather than per-engine. This is a big deal because it means the same security rules apply whether someone queries via Power BI, SQL endpoint, or a notebook.

If you are on Fabric and not yet using OneLake Security for your sensitive tables, this is item one on your to-do list. The previous approach of defining row-level security in the semantic model only protected Power BI users. A determined analyst with notebook access could bypass it entirely.

Shortcuts and What They Inherit

Shortcuts let you reference data in another lakehouse or storage account without copying it. The catch is that shortcut access uses the credentials of the shortcut creator by default, not the credentials of the person reading the data. This is sometimes what you want and sometimes a serious problem.

For any shortcut that touches data with stricter access controls than the destination workspace, switch to identity passthrough. The configuration is in the shortcut settings under "Connection." Test it with a non-admin account before you assume it works.

Sensitivity Labels - The Bit That Connects Fabric to the Rest of Microsoft

Sensitivity labels are how you tell Fabric which data is sensitive. They come from Microsoft Purview, apply across the Microsoft 365 estate, and flow through to Fabric items. They are also where governance moves from "Fabric problem" to "whole-of-organisation problem."

Define Labels Before You Roll Out Fabric

If your organisation already uses sensitivity labels in Microsoft 365 (Confidential, Highly Confidential, etc.), Fabric should adopt the same labels. If you have not defined labels yet, do that first. Trying to retrofit labels onto thousands of existing Fabric items is painful.

For Australian organisations subject to the Privacy Act, OAIC notifiable data breach requirements, or sector-specific regulations like APRA CPS 234, labels are how you operationalise the policy. "Customer financial data is highly confidential" is a policy statement. A sensitivity label that automatically encrypts the file and blocks external sharing is the implementation.

Mandatory Labelling for New Items

Configure Fabric to require a sensitivity label before any item can be saved. This forces every analyst and developer to think about classification at the point of creation, not as a cleanup task six months later.

Label Inheritance and Downstream Items

When you label a source dataset, Fabric should propagate the label to downstream items - reports, dashboards, paginated reports. This works, but you have to enable it explicitly. Check the tenant setting "Apply sensitivity labels from data sources to their data in Fabric."

Audit Logs and Monitoring

You cannot prove your security controls work unless you can see what happened. Fabric audit logs go to the Microsoft 365 unified audit log by default, which is fine but not enough for most organisations.

Stream Audit Logs to Sentinel or Your SIEM

For any production Fabric environment holding regulated data, audit logs should flow into a SIEM where someone is actually looking at them. Microsoft Sentinel is the obvious choice if you are already in the Microsoft estate. Splunk, Datadog and others work too.

The events you care about most: workspace permission changes, sensitivity label changes, data exports, sharing actions, and admin portal modifications. Set up alerts on these specifically, not generic "anomaly detection."

Capacity Metrics and Cost Anomalies

Cost is a security issue too. A compromised account can run up significant capacity charges by spinning up notebooks or running expensive queries. Set capacity alerts in Azure Cost Management for spend that exceeds a daily threshold. This catches both attacks and the much more common "junior developer left a notebook running over the weekend" scenarios.

Questions to Ask Your Fabric Consultant Before Signing

If you are evaluating Fabric consultants, here are the questions that separate the people who know what they are doing from the people who completed a Microsoft Learn module last week.

  1. How do you handle workspace separation between dev, test and production?
  2. What is your approach to OneLake Security versus semantic model row-level security?
  3. How do you configure sensitivity label inheritance from source systems?
  4. What audit log retention period do you recommend for our industry, and where do those logs go?
  5. How do you manage service principal credentials for automated pipelines?
  6. Walk me through how you would revoke access for a departing employee with workspace permissions across twelve workspaces.

If the answers are vague or contain a lot of "we would look at that during discovery," that is your signal. The consultant should have opinions on every one of these from prior engagements.

The Fabric Security Checklist - One Page Version

If you want to use this as a checklist with your team, here are the actions in order:

  • Restrict external sharing to a named security group
  • Restrict service principal access to a specific group
  • Disable publish to web tenant-wide
  • Review and tighten export permissions per sensitivity tier
  • Create separate dev, test and production workspaces for each project
  • Assign workspace roles via security groups only, never individuals
  • Document the policy for item-level permissions and limit their use
  • Enable OneLake Security for tables holding sensitive data
  • Audit all shortcuts for credential mode
  • Define sensitivity labels in Purview before broader rollout
  • Make labelling mandatory for new Fabric items
  • Enable label inheritance from data sources
  • Stream Fabric audit logs to your SIEM
  • Set capacity cost alerts in Azure Cost Management
  • Document the offboarding process for users with Fabric access

This is the minimum. There is more, particularly if you are in financial services or healthcare with specific compliance requirements, but if you have these fifteen items in place you are ahead of most Australian organisations running Fabric today.

Where Team 400 Fits

We work with Australian organisations on Fabric implementations from initial assessment through to production operations. Security and governance is not a separate workstream we tack on at the end - it is the first thing we design, because retrofitting it costs three times as much.

If you have an existing Fabric tenant and want a third-party review of where the gaps are, our Microsoft Fabric consultants run security assessments that map your current state against this checklist and produce a prioritised remediation plan. We have also done full implementations from greenfield, often as part of a wider business intelligence rebuild where Fabric replaces an older Synapse or Databricks footprint.

For organisations using Fabric as the foundation for AI workloads, our Microsoft AI consultants team works closely with the Fabric team to make sure security boundaries hold when Copilot, Azure OpenAI and custom agents start touching the same data.

If you want to talk through your specific situation, get in touch. We are based in Sydney and the Sunshine Coast, and work with clients across Australia.