Forum Discussion
RLS,CLS Security Design and Implementation
Hi Experts, we are about to implement RLS and CLS at three levels such as Onelake Security ,SQL Analytics Endpoint and Semantic Model. I need experts advice what are key considerations ,we need to bear in mind 2. What are the grey areas that might led to pitfall 3. How to ensure RLS and CLS design highly optimal. Your guidance would be highly appreciated. Thank you
Thank you oussamahaimoud .
Thanks for the response ,the table is a good reference for the pre-GA state of OneLake Security,
but it needs updating for May 2026. The picture has changed significantly.
OneLake Security reached GA in May 2026 and now supports both RLS and CLS natively across all Fabric engines. The corrected matrix looks like this:
LayerRLSCLSNotesOneLake (GA May 2026)✅✅Enforced across Spark, SQL Endpoint (User Identity mode), Direct Lake, Data AgentSQL Endpoint✅✅Supplementary-
required for L2 defence-in-depthSemantic Model✅ DAX✅ OLSReport consumer layer -Power BI only
The key enabler is SQL Analytics Endpoint in User Identity mode. Once you switch the endpoint from delegated to user identity mode (Security tab → Use OneLake security for tables), OneLake security roles,
including RLS predicates and CLS column policies, are fully enforced on all T-SQL queries. SQL GRANT/REVOKE on tables is then ignored; all table-level security flows from OneLake roles.
This is confirmed in the GA documentation and post-GA technical writeups (e.g. Joel Tan's May 2026 breakdown: https://joeltan.me/microsoft-fabric-onelake-security-ga/).
Two constraints from the GA release that are worth flagging for anyone implementing this:RLS predicate and CLS column policy must be combined in a single OneLake security role ,splitting them across two roles causes query errors. This is a gotcha that catches people out.
OneLake RLS applies to Viewer-role users only ,workspace Admin, Member, and Contributor roles bypass OneLake security entirely by platform design.
Your workspace role assignments need to be tight before L1 enforcement means anything.The "semantic model as primary enforcement" model was the correct design pattern before OneLake Security GA because the storage layer had no enforcement capability.
With GA, the recommended architecture flips: L1 OneLake is primary (enforces across all engines simultaneously), L2 SQL Endpoint is supplementary defence-in-depth, and L3 DAX/OLS covers the Power BI report consumer layer.
All three together give you true defence-in-depth , no single layer is optional. Appreciate your help.
3 Replies
Semantic model is your primary enforcement plane. SQL endpoint is your second line. OneLake is perimeter only. Here's a summary to remember :
Thank you oussamahaimoud .
Thanks for the response ,the table is a good reference for the pre-GA state of OneLake Security,
but it needs updating for May 2026. The picture has changed significantly.
OneLake Security reached GA in May 2026 and now supports both RLS and CLS natively across all Fabric engines. The corrected matrix looks like this:
LayerRLSCLSNotesOneLake (GA May 2026)✅✅Enforced across Spark, SQL Endpoint (User Identity mode), Direct Lake, Data AgentSQL Endpoint✅✅Supplementary-
required for L2 defence-in-depthSemantic Model✅ DAX✅ OLSReport consumer layer -Power BI only
The key enabler is SQL Analytics Endpoint in User Identity mode. Once you switch the endpoint from delegated to user identity mode (Security tab → Use OneLake security for tables), OneLake security roles,
including RLS predicates and CLS column policies, are fully enforced on all T-SQL queries. SQL GRANT/REVOKE on tables is then ignored; all table-level security flows from OneLake roles.
This is confirmed in the GA documentation and post-GA technical writeups (e.g. Joel Tan's May 2026 breakdown: https://joeltan.me/microsoft-fabric-onelake-security-ga/).
Two constraints from the GA release that are worth flagging for anyone implementing this:RLS predicate and CLS column policy must be combined in a single OneLake security role ,splitting them across two roles causes query errors. This is a gotcha that catches people out.
OneLake RLS applies to Viewer-role users only ,workspace Admin, Member, and Contributor roles bypass OneLake security entirely by platform design.
Your workspace role assignments need to be tight before L1 enforcement means anything.The "semantic model as primary enforcement" model was the correct design pattern before OneLake Security GA because the storage layer had no enforcement capability.
With GA, the recommended architecture flips: L1 OneLake is primary (enforces across all engines simultaneously), L2 SQL Endpoint is supplementary defence-in-depth, and L3 DAX/OLS covers the Power BI report consumer layer.
All three together give you true defence-in-depth , no single layer is optional. Appreciate your help.
Hi SamyAbdul,
Thank you for the detailed update and for sharing the latest information regarding OneLake Security GA.We appreciate you sharing these updates and documentation references with the community. This information will certainly help others design a more robust defense-in-depth security architecture in Microsoft Fabric.
If you have any other queries, please feel free to raise a new post in the community. We are always happy to help and, Thanks, oussamahaimoud for sharing valuable insights.
Thank you.
