Third-party support for OneLake security

[aonelakeuser]

If you haven’t already, check out Arun Ulag’s hero blog “FabCon and SQLCon 2026: Unifying databases and Fabric on a single, complete platform” for a complete look at all of our FabCon and SQLCon announcements across both Fabric and our database offerings. 

---

As outlined in our technical whitepaper, 'The future of data security is interoperability', permissions that move with data is the future of data security. As modern data lakes are built on open-source technology like Delta and Iceberg, customers expect to use the analytics engines and services that best fit their needs—without copying data or redefining security. This creates a clear requirement: security must be defined once and enforced consistently everywhere data is consumed.

OneLake security now provides API support for third-party enforcement through an authorized engine model. This release extends the same principles used across Microsoft Fabric to external engines and services. OneLake security is now closer to its vision of defined once, enforced everywhere, even beyond first-party workloads.

Authorized engines

OneLake security is designed around a centralized policy definition with controlled, distributed enforcement. Security policies such as table permissions, row-level security (RLS), and column-level security (CLS) are authored and stored once in OneLake. Enforcement, however, happens at query time inside the engine that is reading the data.

To enable this safely and efficiently, OneLake uses an authorized engine approach:

• An authorized engine is granted scoped access to OneLake data and security definitions through OneLake APIs.
• When an engine receives a query, it fetches the relevant data and security definitions from OneLake and enforces those security rules during query execution, ensuring users see only the data they’re permitted to access.
• OneLake remains the source of truth for access control, while engines retain full control over query optimization and execution. Users control which data an engine can access by configuring OneLake security policies.

This model is already used by engines within Microsoft Fabric and is now available for third-party engines. The same security guarantees apply to users querying through an authorized third-party engine see only the data OneLake allows them to see, including limited rows and/or columns.

Implementation guidance

We’ve launched an implementation guide to go with the new APIs. The guide walks through the APIs used by OneLake to communicate metadata and security information and explains how to build an integration. Secondly, we provide a user-facing guide to set up an authorized engine in Microsoft Fabric.

The OneLake security APIs are designed to be engine-agnostic and be easily understandable. We achieve this by pre-computing the effective access that a user has across all their OneLake security roles. Engines are then given a ready-to-apply definition of security.

We will continue to evolve our API support for OneLake security in the future, including by adding support for using bitmaps to do RLS filtering.

Next steps

With authorized engine support:

• Data vendors can integrate with OneLake security directly to ensure consistent enforcement of security when reading data from OneLake.
• Fabric administrators can maintain a single source of truth for RLS, CLS, and role-based permissions.
• Business users have the freedom to use any query engine they want when reading data from OneLake.

If you’re building or operating a query engine that reads data from OneLake, now is the time to explore the OneLake security APIs and begin planning your integration. For architectural details and design rationale, we encourage you to read the OneLake security whitepaper.