Securing OneLake: Every Access Path, Every Control

Start with the access you want

Pick one data product and audience: report consumers, analysts, engineers or a service identity. Write down the purpose, sensitivity, permitted rows and columns, and whether they need to build, copy, share or export.

Then choose a starting pattern below. These are design options to assess with your data owner. More than one can apply to the same product; review every route that audience can reach.

Report consumption

Use when: people need a governed report or shared semantic model.

Set up: consumer access to the model, with RLS/OLS where required. Choose SSO or a scoped fixed/refresh identity; confirm source access for that identity. Keep model edit access separate.

Also decide: Build, XMLA, export and direct source access. A report restriction does not establish those boundaries.

Direct Lake identities · Model RLS

Governed SQL access

Use when: analysts or applications need an approved SQL interface.

Set up: required item and SQL grants. Choose OneLake enforcement through a supported user-identity endpoint, or SQL-native rules on the selected SQL surface.

Also decide: raw files, Spark and shortcuts. If the boundary depends on SQL rules, verify that alternate paths cannot expose more data.

SQL modes and enforcement

Multi-engine analysis

Use when: analysts need several supported engines over shared tables.

Set up: scoped OneLake grants, the required engine configuration and deliberate source-workspace roles. Check the support status of each selected route.

Also decide: raw-file access, extra grants and copies. Record how each engine enforces the same intended boundary.

Supported engines · OneLake grants

Ingestion and engineering

Use when: a team or job must load, transform or move data.

Set up: a named technical owner, an explicit execution identity and the source and destination grants required by the connector. Assess production write and administration rights separately.

Also decide: who can use or change the connection, where copies may land, and who maintains destination controls and credentials.

Copy configuration · Dataflow connections

Scope: this guide supports data-access governance. Data quality, retention, lifecycle, discovery, network controls and operations need accompanying decisions in your wider Fabric governance approach. The map models reads; it does not establish write or administration privileges.

Explore the access paths

These are technical outcomes, not governance approvals. Broad access may be intentional; a rule may still allow too much. “Other identity” does not guarantee a successful read. Record the business decision and test evidence separately; counts are not a security score.

Reviewed 1 November 2026. OneLake security is generally available. Microsoft’s engine-support table now lists Eventhouse RLS/CLS filtering as generally available; this does not establish how native Eventhouse data is secured through OneLake availability. The Files column models raw storage access, not the preview Table Read API. The endpoint-mode selector models lakehouse and mirrored-database SQL analytics endpoints, not native Warehouse or operational SQL database queries. Shortcut cells identify a rule to check; the consuming engine must also support enforcement.

Make and own the decision

For each audience and reachable path, record the intended boundary, the owner and the evidence. A policy decision needs a corresponding Fabric configuration.

Decision	What to record
Pending	A grant, configuration, test or approval is still missing. Name the next action and owner.
Allowed	The business purpose, permitted data and actions, approver, configured controls and evidence that the intended boundary holds.
Disallowed	The reason and the control that prevents this audience using the path, with a denied-access test.
Approved exception	The reason, scope, accountable approver, compensating controls, evidence and expiry date.

My suggested ownership split: the data owner agrees purpose and permitted use; the technical owner maintains and tests the controls; the platform team manages shared guardrails and monitoring. Assign named people or teams and an exception approver for your organisation. Microsoft ownership guidance.

Select a map cell to download a decision-record template with its scenario and sources. Add the real item IDs, audience, grants, identities and evidence in your team’s governance register. The template starts as Pending and Untested.

Prove the boundary

Allowed access: use the actual intended identity to verify the permitted rows, columns and actions.
Restricted access: test data outside that scope and every alternate route the audience can reach, including files, shortcuts, copy and export. Record expected and observed outcomes.
Access removal: remove the intended grant or membership, allow for documented propagation, use a fresh session and confirm the expected loss of access.
Change and review: record test date, evidence location and reviewer. Repeat after relevant role, model, connection, endpoint or policy changes, and on the agreed review schedule. Verify that required audit events are actually captured.

Example: a regional sales analyst

Requirement: view sales for one region in an approved report. The data owner decides whether Build, export and direct querying are needed.

Proposed design: a consumer role on a shared model, model RLS for that region, and a scoped fixed identity or Import refresh identity. Source access is assessed separately. Building a report in another workspace does not require editing the shared model.

Evidence: the analyst sees the permitted region, cannot retrieve another region through any reachable route, and loses access as intended when the consumer grant is removed. Validate source, model and export controls independently.

Decision: Pending until the configuration is tested and the named approver records the decision. An example is not evidence of your tenant’s behaviour.

Start with one data product, agree the pattern with its users, test it and reuse the documented approach where it fits. Microsoft’s governance guidance supports an iterative approach with clear responsibilities.

Configure the controls by path

Start with the identity that actually reads the data. Then check the permission model on that exact route.

Path	What I check
Spark	Use the supported lakehouse catalog for secured tables and enable the OneLake Spark Catalog as documented. Direct path reads of RLS/CLS-secured tables are blocked for nonprivileged users. Keep elevated source roles limited to people who need them. Spark enforcement
Files / API	Folder access, direct file reads and the Table Read API are different routes. Scope folder roles; inspect DefaultReader and every other grant. ReadAll grants data access through DefaultReader on supported items, so it does not guarantee unrestricted access after that role is narrowed or removed. Access model
SQL endpoint	Use user identity mode when OneLake should govern table reads. Delegated mode is a supported choice for SQL-native grants, RLS, CLS and Dynamic Data Masking; maintain those rules separately. A mode switch needs planning and can interrupt queries. Access modes and limitations
Warehouse	Distinguish SQL queries, the Spark SQL connector, Direct Lake on SQL and direct OneLake reads. Warehouse T-SQL security does not become a OneLake policy for shortcuts. Grant direct OneLake access deliberately. Warehouse shortcut warning
Reports	For per-user source authorization, use a supported SSO route such as Direct Lake on OneLake. Fixed identity and Import are valid designs when consumer restrictions are enforced in the semantic model. Test model RLS/OLS and source access separately. Build permission does not itself bypass model RLS. Direct Lake security · Model RLS
Copy / Dataflow	Check the connector, source query path, connection identity, its grants, and destination permissions. A SQL read can enforce rules for the connection identity; an unsupported direct-file route can be blocked. Item-creation policy is an additional governance control, not a substitute for data permissions. Copy activity · Dataflow connector setup
Shortcuts	Check passthrough versus delegated authentication and the consuming engine. External shortcuts use connection credentials, with OneLake security restricting access through the shortcut. Internal OneLake shortcuts can also be delegated. Shortcut security
Export	Check the exporting identity, model rules, export permissions and destination. Label protection follows supported Power BI export formats; ordinary CSV/TXT exports do not retain that protection. External data sharing is a separate operation. Export protection

A different identity can still be restricted. A blocked file read does not mean every query route is blocked. Trace the identity and enforcement layer before changing a rule.

What the map cannot infer

The map cannot see your actual grants, identities or settings. Select a “Check” cell to see what matters, then test with the intended reader. The Files column covers raw file reads; the preview Table Read API is a separate route that enforces RLS/CLS.

Documented limits to check

Eventhouse availability. Native KQL access, OneLake availability and Eventhouse reading OneLake-secured data are different routes. Microsoft says you cannot apply table RLS while OneLake availability is enabled. Review the availability workflow and its data impact before changing settings. Native KQL RLS applies even to database admins.

Elevated SQL readers. General OneLake documentation describes broad workspace access; the SQL endpoint limitations also describe RLS enforcement for elevated roles in user identity mode. Treat the SQL result as an engine-specific check, not a universal bypass. SQL synchronization and shortcut identity mapping also need to be valid.

Map assumptions. The labels are an interpretation of documented rules under the stated scenarios. Microsoft does not publish this exact cross-product matrix. The checks and sources explain what is documented and which configuration is still missing; they do not certify a tenant’s effective permissions.

Current support and planned work

OneLake security is generally available. Microsoft’s supported-engine table, updated 31 October 2026, lists Eventhouse RLS/CLS filtering as generally available. Current OneLake RLS does not support dynamic or multitable queries. The roadmap lists dynamic and multitable RLS as planned for public preview in Q1 2027; that is a plan, not an available capability or a guaranteed date.

Fabric Policies is in preview for item creation and selected workspace settings. Microsoft’s policy overview describes external-sharing rules, while its launch announcement labels external-sharing governance “Coming Soon.” Verify availability before relying on it.

Microsoft sources

Documentation rechecked 1 November 2026 · Preview and roadmap dates can change

Agree the access, name the owner, test the paths and keep the evidence current. Fabric keeps changing, so recheck the docs when your design changes.