Fabric security that holds when someone actually tests it

Microsoft Fabric governance and security is the design and enforcement of who can see which data across your Fabric estate: OneLake security roles at table, folder, row and column level, the workspace and capacity topology around them, sensitivity labelling, lineage, and the audit trail that proves all of it. Defined properly, it is enforced consistently across every Fabric engine. Designed naively, it fails open, and nobody finds out until someone looks.

Fabric governance rarely breaks with an alarm. It drifts. Contributor access was handed out during the build and never taken back. A row-level rule was written to protect payroll, and it does protect payroll, from the six people who were never a risk. A workspace that started as a sandbox now holds the group consolidation. The model looks correct in a workshop, passes the demo, and is quietly wide open.

This is the govern layer of the Fabric platform, and it is the layer most often skipped, because it produces nothing anyone can see in a report. It is also the layer that decides whether your finance numbers can be put in front of a board, an auditor or a bank without a caveat attached.

The uncomfortable part is that the failure modes are documented. Microsoft publishes them. They are simply not the ones a first rollout expects, and every one of them fails towards exposure rather than towards lockout. That is where this page starts.

Because four documented OneLake security behaviours all fail open, not closed. Workspace Admins, Members and Contributors bypass row and column rules entirely. Two roles carrying a row rule and a column rule cannot be combined. Filtering only works on Delta. And the DefaultReader role keeps handing out full access until you explicitly remove people from it. None of them announce themselves.

OneLake security is a genuinely good model, and we recommend it. What we do not recommend is switching it on and assuming it did what you meant. Here are the four behaviours that catch a first rollout, all first-party, all in Microsoft's own guidance.

• Your admins are not covered by your own rules. Workspace Admin, Member and Contributor roles bypass OneLake row-level and column-level security entirely. Those rules constrain Viewers. So the people most likely to be over-permissioned, the ones handed Contributor during the build and never asked to hand it back, are precisely the people your row-level security does not touch.
• A row rule and a column rule cannot be combined across roles. If a user ends up in one role carrying row-level security and another carrying column-level security, their queries error. It forces a single-role design for the data in question, and most teams discover that after the roles have already sprawled, not before.
• Filtering is Delta-only. Row and column rules apply to Delta. Point a rule at a non-Delta object and it is not filtered, it is blocked. Users lose access to data you fully intended them to keep, which lands on your desk as a broken report rather than as a security finding.
• DefaultReader hands over everything. The DefaultReader role grants data access to anyone with ReadAll. Add a user to a tighter data-access role and forget to remove them from DefaultReader, and they keep full access to the lot. It is a silent, total bypass of the model you just built, and it is the first thing we check.

None of these are bugs. They are documented behaviours, and each one is manageable once you know about it. The problem is the order in which most teams find out. A model that looks correct on the whiteboard will pass every test the person who designed it thinks to run, and still expose the payroll table to half the finance function.

OneLake security is role-based. You grant at table or folder level, then add row-level and column-level rules on top, and the rules are defined once on the data and enforced consistently across every Fabric engine and authorised third-party engines. Write the rule once and it holds whether the user arrives through SQL, through Spark, or through a report.

That single sentence is the reason to do this properly rather than bolt permissions onto each tool in turn. In most estates, security is redefined at every layer, once in the warehouse, once in the semantic model, once in the report, and the three definitions have quietly disagreed with each other within a quarter. OneLake security collapses that into one definition, on the data itself.

So the design work is about roles, not switches. Which roles exist. Which single role a given user sits in for a given dataset. Which grants sit at folder level and which at table level. Where a row-level rule is genuinely needed, and where it is a workaround for a workspace boundary that should have been drawn differently in the first place.

Yes, and it is the most under-used one. The workspace decides who is an Admin, Member, Contributor or Viewer, and since only Viewers are constrained by row and column rules, your workspace map is where your security model is really decided. The capacity boundary then decides which workloads can starve which, and which budget carries the cost.

Draw the workspace map badly and no amount of row-level security saves you. A single workspace holding the sandbox, the group consolidation and the HR extract, with a generous Contributor list, is not a governance model. It is a list of people who can see everything, dressed up as one.

The design that works is unglamorous. Separate the domains that need separate access. Keep the sensitive domain in its own workspace, with an admin list short enough that you could name every person on it from memory. Split development, test and production so that a well-meaning engineer is not a Contributor in production purely because they needed to be one in development.

Capacity does the same job on the money. A capacity boundary contains a runaway workload so that one bad query cannot throttle the estate, and it ties consumption to a domain, so the cost lands on the budget that caused it. That is the same boundary your Finance Director cares about, drawn for the same reason.

With sensitivity labelling and lineage. Labels classify the data and travel with it as it moves through the estate; lineage maps a reported figure back to the asset it came from. Between them they answer the only two questions an auditor actually asks: who could see this, and where did this number come from?

Governance that cannot be evidenced is not governance, it is an intention. The two artefacts that turn an intention into evidence are the label and the lineage trail.

Labelling is the classification layer. It says what this data is, how sensitive it is and how it should be handled downstream, and it keeps saying so as the data moves. It is a classification and handling control. It is not a substitute for a role, and any supplier who tells you a label on its own will keep the wrong people out of a table is selling you comfort.

Lineage settles the argument you have had a hundred times. A number in the board pack looks wrong. Without lineage, that becomes a fortnight of email. With lineage, it becomes a trace back to source and a root cause. For a Finance Director this is the entire point: a figure you can defend, with a chain of custody you can show.

Both are supported and both are legitimate, and the choice has real governance consequences. Link to Fabric keeps your Dynamics data inside the Dataverse governance boundary, so you inherit those controls rather than rebuild them. Azure Synapse Link puts the data in your own storage account, under your own controls, where you choose the tables and you own the access model end to end.

This is not a plumbing decision that governance inherits. It is a governance decision that the plumbing follows.

• Link to Fabric. No copy, no ETL, and the data stays inside the Dataverse governance boundary. The governance argument is straightforward: you inherit an access model you already run rather than building a second one. The trade is control. Every non-system table with Track changes enabled is selected automatically, you cannot cherry-pick, and it consumes additional Dataverse storage.
• Azure Synapse Link for Dataverse. Continuous export into your own storage account. Your storage, your pipelines, your access model, and your admins choose which tables move. The trade is that the governance is now yours to design, run and evidence, all the way down. Entirely doable. It is simply work, and it should be a decision rather than an accident.

Both paths are supported. Microsoft has been explicit that it intends to keep enabling data export well into the future, so anyone telling you one of them is about to disappear is guessing. The pipe that has genuinely gone is Export to Data Lake, which has been retired. If you are still sitting on it, that is the real reason to move, rather than an invented deadline.

A tested security model and the evidence to prove it: a map of what your Fabric estate exposes today, a single-role OneLake design that does not trip the documented failure modes, a workspace and capacity topology that matches the domains you need to govern, a cleared DefaultReader, sensitivity and lineage, and an evidence pack you can hand to a board or an auditor.

The engagement runs in steps, grounded in your estate rather than a template.

1. Map what is actually exposed today

   Roles, workspace memberships, who holds Admin, Member and Contributor, and what each of them can genuinely see. This is usually the first surprise, and it is usually the thing that gets the work funded.

2. Design the OneLake security model

   Table and folder grants, then row and column rules, as a single-role design that does not trip the row-plus-column combination, and that names which parts of the estate OneLake security covers and which it does not.

3. Fix the topology

   Workspace and capacity boundaries that match the domains you need to govern, with an admin list short enough to defend, and development separated from production so nobody holds Contributor in the wrong place.

4. Clear DefaultReader, and evidence it

   Remove the standing full-access path, then prove it is gone rather than assert it. The proof is the deliverable, not the assurance.

5. Sensitivity, lineage and the audit trail

   Labelling and lineage, so you can answer who could see this and where the number came from without a fortnight of email.

6. Test it like an attacker, not like the author

   We test the model against the documented bypasses rather than the happy path, and hand you the results, including the ones we do not like.

What lands is a designed, tested model and the evidence pack that goes with it, right-sized to an SME rather than a governance regime you will never staff. The scope is transparent and the cost is shown before you commit.

Two people, and they need different things from the same engagement. The IT Director owns the security model and the risk. The Finance Director owns the audit exposure and signs the cheque. A Fabric governance decision that only one of them believes does not get funded, so this page is written for both.

• IT Director and Head of Data. You get the security model, the bypass surface named and closed, the workspace and capacity topology that carries it, and a test result rather than an assurance. You also get an honest scope: which items OneLake security covers today, and which parts of your estate need a different control.
• CFO and Finance Director. You get audit exposure you can describe and defend, numbers with a traceable chain of custody, and a workspace and capacity boundary that is also a cost boundary, so consumption lands on the budget that caused it. And you are told what it costs before you commit, not after.

Both, and that is the point. Governance is the cross-cutting layer, not a rung on the ladder: it is designed alongside the readiness assessment, built into the migration or the implementation rather than bolted on afterwards, and then run day to day by the managed platform.

1. Diagnose.

   Start with the Fabric readiness assessment if you do not yet know where you stand.

2. Migrate or build.

   Governance is designed into the migration to Microsoft Fabric and the Fabric implementation, not retrofitted after go-live when the roles have already sprawled.

3. Govern.

   This page. The security model, the topology and the audit trail, designed and tested rather than assumed.

4. Run.

   The managed Fabric platform runs the boundary day to day, holds the cost line, and keeps the model honest as people and workloads change.

For the Dynamics 365 programme specifically, see Microsoft Fabric for Dynamics 365. Fabric is the platform. The reconciled model layer that sits on it is the data warehouse pillar, where our pre-built reconciled foundation Reveal may also be the right answer, and the reporting layer on top of that is Power BI. This page governs the platform underneath both.