Microsoft Fabric Security Best Practices for Manufacturers: Plant-Level Access Without Killing Adoption

It is that plant-level margin, standard cost build-ups, supplier price files and payroll extracts now sit on the same platform as the OEE board everybody wants running on a screen next to the line. Those two populations want opposite things. The shop floor wants a dashboard that opens in three seconds on a shared terminal with no login friction. Finance wants margin data that a plant manager physically cannot reach.

Both defaults fail. Lock it down hard and adoption dies — people go back to the Excel extract, the least secure artefact in the estate and the one nobody audits. Leave it open and you have a governance incident waiting for an auditor to find. Fabric gives you enough control to solve this. What it does not give you is a single switch.

Securing Microsoft Fabric means designing five independent control layers — Entra ID identity and Conditional Access, workspace roles, item permissions, OneLake data access roles, and engine-level controls such as SQL granular permissions and semantic model row-level security — plus Microsoft Purview classification over the top.

The constraint everything hangs off: workspaces are the primary security boundary. Get the topology wrong and every finer-grained control becomes a patch over a structural problem. By the time you have 300 items across nine workspaces, restructuring is a project, not a change.

Assign workspace roles to Microsoft Entra ID security groups, not to individual users. The reason is joiner-mover-leaver arithmetic, not elegance. Grant per person and within eighteen months you have a planner who moved from Plant B to Plant D two years ago and still reads Plant B cost, with no owner able to say why.

Build the taxonomy around how the business splits, not the tool: by plant, by function (finance, production, quality, maintenance, supply chain), and by seniority tier where a genuine data distinction exists — FAB-Plant-Jeddah-Production, FAB-Finance-GroupMargin, FAB-Contractor-EPC-ProjectX. Because the highest permission across groups wins, one over-broad group silently defeats every narrow one beneath it. Audit for that, not for individual grants.

Workspaces are the primary security boundary; domains are not. Domains look like a security construct in the admin portal and are not one — domain assignment gives items a metadata attribute for discovery in the OneLake catalog, but item visibility still depends on workspace roles. What domains give you is federated governance: domain admins can override delegated tenant settings including the default sensitivity label.

The topology that works in industrial estates separates by data sensitivity first, lifecycle second:

That fourth workspace is the one manufacturers most often skip and the one that pays for itself: separate the restricted items and the broad-access controls never have to be clever.

The layers are independent. Each stops somewhere specific — and workspace Admin, Member and Contributor roles override most finer-grained restrictions beneath them.

The most common error is the third column of the semantic model row. A team builds dynamic RLS by plant, assigns everyone Viewer, considers it solved — then discovers the plant analysts were also given Contributor so they could publish their own reports, which means RLS never applied to them.

Implement row-level security once at the lowest layer every consumption path shares, then verify each path independently. The pattern that holds up is a plant-security bridge table: one row per user principal name per plant code, sourced from HR or the ERP org structure rather than maintained by hand, with a dynamic RLS expression matching USERPRINCIPALNAME() against it. Sourcing it from the system of record is the part that survives contact with reality.

Three behaviours to test rather than assume. Direct Lake mode changes the answer — where the SQL analytics endpoint enforces RLS, Direct Lake on SQL falls back to DirectQuery, while Direct Lake on OneLake succeeds and SQL-based RLS is not applied. Fixed identity versus single sign-on changes who is authorised. And service principals cannot be added to RLS roles, while Entra security groups containing B2B guests may not resolve — the documented workaround is adding external users directly by email.

Object-level security has a side effect worth naming: for a user without permission the secured column behaves as if it does not exist, and any visual referencing it breaks with a "Column cannot be found" error. Hiding StandardCost with OLS breaks the cost report for plant users rather than blanking a number.

In Microsoft Fabric you can only share items with B2B guest users by sharing the workspace. Explicit sharing of particular items with guests is not supported, except for reports, dashboards, semantic models and apps. That matters in an EPC (Engineering, Procurement & Construction) or contract manufacturing estate, where third parties — line integrators, maintenance contractors, co-packers, freight partners, the parent's audit team — can outnumber internal headcount.

The workable pattern is a dedicated external-facing workspace per counterparty, holding only Power BI reports and their semantic models, fed from the internal Gold layer. Guests get Viewer there and nothing else.

In a manufacturing Fabric estate the OT/IT boundary should be unidirectional. Process data flows out of the plant network to Fabric through a broker or historian using OPC-UA or MQTT; nothing in the analytics estate writes back to SCADA, PLCs or the MES control path. The controls that matter sit below Fabric: a demilitarised zone between plant and enterprise networks, an OPC-UA or MQTT broker as the only egress, read-only access into the historian, and no inbound route to the control system.

Three categories should not cross without a documented reason: PLC and controller credentials or configuration, anything on the safety-instrumented path, and live setpoint control. Aggregated process data, alarm and event history, batch genealogy and downtime coding all cross safely. The identity consequence catches people: shop-floor terminals usually run shared logins, and a shared account defeats per-user row-level security completely — every rule evaluates against one identity.

This is the section most security guidance skips, and it is where these programmes fail. Five tensions are real, not solvable by configuration alone:

• Shared terminals versus per-user security — irreconcilable in principle; resolve by putting only non-restricted operational data on shared screens
• Self-service versus the Contributor bypass — plant analysts who build their own reports need Contributor, and Contributor bypasses RLS and OLS entirely; give them a separate build workspace with no restricted data
• Least privilege versus request queues — every access request that takes four days teaches someone to email an Excel file instead
• Private link versus everything people like — blocking public internet access costs you on-premises gateways, Copilot, PDF and PowerPoint export, and email subscriptions
• Restricted workspaces versus one version of the truth — splitting margin out risks two cost models drifting apart; source both from the same Silver layer

Workspace roles beat almost everything below them — Admin, Member and Contributor read data through T-SQL, OneLake APIs and Spark, and bypass RLS and OLS. OneLake security is GRANT-only, so you cannot carve an exception out of a broad grant — you restructure the grant instead. Distribution lists silently fail at the SQL analytics endpoint: a distribution list added to a OneLake security role cannot be resolved there, so its members appear not to hold the role.

Direct Lake on OneLake does not apply SQL-based RLS, so a model built on warehouse RLS has a hole the moment someone builds a Direct Lake on OneLake model over the same tables. Labels classify; on their own they do not restrict. And none of this addresses the Excel layer — once data leaves Fabric into a workbook on someone's laptop, every control here stops applying except label-based encryption on supported export paths.

Answer these five this week, before you touch a permission screen:

• How many people hold Contributor or above on a workspace containing standard cost, margin or payroll data — and can you name each one and why?
• Is every workspace role assigned to a security group, or are there named-user grants? Count them.
• Which identity refreshes your ERP data, what else can it reach, and who can trigger it?
• If a plant manager opened the SQL analytics endpoint directly, rather than the Power BI report, what would they see?
• Can any pipeline in your Fabric estate write into an MES, SCADA or historian system?

If question one returns a number above fifteen, or question five returns yes, those are your first two work packages regardless of what else is on the roadmap. We build governed Microsoft Fabric estates for manufacturers, FMCG, packaging, logistics and EPC businesses — workspace topology, Entra ID group design and Purview classification as one exercise, not three.