Microsoft Fabric security is layered. Workspace roles, item permissions, OneLake security, semantic-model roles, and SQL-endpoint controls can all affect access, but they do not have the same scope. For Microsoft DP-600, the critical architecture skill is knowing which layer authorizes a user and which query paths that control actually protects.
The strongest design follows least privilege and avoids assuming that a row-level rule in one engine automatically protects the underlying data everywhere. Fabric now includes fine-grained OneLake security for tables, folders, rows, and columns, while Power BI semantic models still support their own RLS and OLS behavior. Microsoft SC-100 adds the architecture perspective: security should be explicit from workspace access down to data access, with no accidental bypass path.
Workspace roles grant broad collaborative access
Fabric workspaces use Admin, Member, Contributor, and Viewer roles to control what users can do with workspace content. Admins, Members, and Contributors receive broad capabilities appropriate to content creation and management. Viewers are the primary read-oriented workspace role.
Workspace membership is a coarse control. Use it for collaborators who need to create or manage many items, not merely because it is the easiest way to make one report work. Broad workspace roles should be treated as privileged access and reviewed accordingly. Microsoft’s OneLake security guidance explicitly notes that broad workspace roles can grant access that fine-grained OneLake roles do not override. A user who should see only one lakehouse table usually should not be made a Contributor to the entire workspace.
Item sharing provides narrower access than workspace membership
Fabric items can be shared with users who are not members of the whole workspace. Use this for consumer access where practical because it limits workspace visibility and reduces accidental authoring privilege. Sharing still needs periodic review, especially when groups, external users, or downstream Build permissions can expand what a consumer can do with the item. Item-level sharing is useful when a consumer needs access to a report, lakehouse, warehouse, or another specific object without visibility into every item in the workspace.
Treat item permission as a separate decision from data permission. Sharing can include additional capabilities such as read, reshare, or build depending on the item and experience. Grant only what the user needs, and test downstream behavior such as exporting, building new reports, or querying the semantic model. A user can be allowed to open an item while still needing the correct data access beneath it, depending on the item and query path. Conversely, granting data access directly can create paths that bypass a report-level experience.
OneLake security protects data at the storage layer
OneLake security roles provide fine-grained access to supported Fabric data items. Current role management supports users, Microsoft Entra groups, and security principals, with read and—on supported items—read/write scopes. Read/write roles are not the place for RLS or CLS; fine-grained row and column filters are designed around read-oriented access. Current Microsoft documentation includes object-level controls for tables and folders plus row-level and column-level security for supported Delta data. This gives teams a way to centralize data policy closer to OneLake rather than reimplementing it separately in every consuming engine. Where supported, storage-layer controls can provide file-level security so access to underlying OneLake data is constrained before a semantic model or SQL layer applies its own permissions.
OneLake roles use a grant model. This has an important consequence for least privilege: adding a restrictive role does not cancel access already granted elsewhere. Security reviews therefore need a complete principal-to-permission view rather than a screenshot of one role. They do not provide a universal deny that cancels broader access granted through another role or permission model. Review all effective grants before assuming a restrictive role has reduced access for a user who already has elevated workspace permissions.
RLS, CLS, and OLS solve different data-exposure problems
Row-level security filters which rows a principal can see. Column-level security hides selected columns. Object-level security at the OneLake layer can control access to tables or folders. These controls should be chosen according to the data boundary: geography or business unit may be row-based, sensitive attributes may be column-based, and entire subject areas may be object-based.
Keep rules simple and test them with real user identities. Test both positive and negative cases, including users in multiple groups. Also validate access through each intended engine, because OneLake may filter supported query paths while blocking paths that cannot safely enforce RLS or CLS. Complex expressions can be hard to audit, and OneLake security has product-specific syntax and support boundaries. A rule that references a missing or changed column can fail in ways users experience as missing data or query errors.
Semantic-model security protects the semantic-model access path
Power BI semantic models can implement row-level and object-level security independently of OneLake. Model roles are especially useful when reports are the primary consumption path and business rules depend on DAX relationships or model-specific logic. Keep those roles source-controlled and test them with real identities so a model deployment does not silently broaden access. These rules apply when users query the model through reports, DAX, or other semantic-model interfaces. They are valuable when the semantic model is the governed analytics contract and report consumers do not receive direct access to the underlying data item.
The scope is important: semantic-model security does not automatically restrict another engine reading the lakehouse or warehouse directly. This becomes especially important when analysts have Build permission, SQL access, notebook access, or direct OneLake access in addition to report access. The architecture should identify the authoritative policy layer for each persona. If users can access the source through SQL, Spark, OneLake, or shortcuts, protect those paths separately or centralize policy in OneLake where supported.
SQL-endpoint security has SQL scope and can affect Direct Lake behavior
Warehouses and lakehouse SQL analytics endpoints can use SQL security constructs such as RLS, CLS, and OLS. Those controls should be documented as endpoint-specific unless the architecture deliberately maps them to a broader OneLake policy. A shortcut or Spark path that reads the same underlying data can have a different enforcement model from T-SQL unless OneLake security governs the source. These policies protect SQL execution through that endpoint. Microsoft warns that SQL security semantics do not automatically translate into OneLake security when data is reached by other paths such as shortcuts.
Direct Lake on SQL also interacts with SQL security. When security forces DirectQuery fallback, performance and access semantics can change together. Engineers should not treat a sudden Direct Lake performance regression as only a capacity problem; the cause may be a new SQL-layer security policy or view introduced upstream. Some SQL-layer restrictions can cause errors or DirectQuery fallback because the semantic model must honor endpoint policy. Direct Lake on OneLake uses a different security architecture and can apply OneLake security without relying on SQL-endpoint fallback.
OneLake security can unify enforcement across supported engines
OneLake security is designed around centralized policy with enforcement by Fabric engines and authorized integrations. A supported engine that understands RLS and CLS can filter data according to the OneLake role. If a query path cannot safely enforce the rule, OneLake can block access instead of exposing unrestricted data.
That model is attractive for shared data products consumed through multiple Fabric engines. It also supports a producer-consumer architecture in which a primary workspace owns and secures the data and downstream workspaces consume it through shortcuts. Security remains anchored to the source rather than copied into each consumer workspace. It also requires teams to verify which engines and access paths support the current feature set. Security architecture should be based on documented enforcement behavior, not on the assumption that every third-party tool interprets OneLake roles.
Default roles and overlapping grants need careful review
New Fabric items can include default OneLake roles that grant broad reader access based on workspace permissions. Administrators should review these defaults before assuming a newly created custom role has become the user’s only path. Removing or modifying a default grant may be necessary before fine-grained policy has the intended effect. Before creating a restrictive security role, verify whether the user is already included in a default role that grants more access. Otherwise the new fine-grained role may appear correct while the existing grant still exposes the data.
Overlapping roles also matter because access can be unioned across grants. Build an access test matrix for representative personas such as workspace author, report viewer, SQL analyst, notebook engineer, and external consumer. The same user can have different effective rights through each path, and those differences should be intentional rather than discovered during an audit. Test effective access for representative users and groups, not only the configuration of one role. Security review should answer what the user can actually read through each path.
Govern access as data architecture, not just workspace administration
Microsoft Fabric security works best when workspace ownership, item sharing, data policy, semantic-model policy, and engine-specific controls are designed together. Add auditing to that architecture: access changes, workspace-role updates, OneLake role modifications, semantic-model role changes, and SQL security changes should be traceable to an owner and change reason. Microsoft Purview can support broader governance and information-protection processes, but Fabric authorization still needs precise implementation at the workspace and data layers.
The enterprise lesson in DP-600 Fabric analytics is to treat security as an access-path problem. Identify every way users and workloads can reach the data, choose the control layer that covers those paths, and avoid assuming a restriction in one engine protects another. Layered security is strongest when each layer has a defined purpose and no hidden bypass.