Security in Microsoft Fabric is not one checkbox attached to a report. A user can enter through a workspace, an individual item, a SQL analytics endpoint, a semantic model or OneLake data access, and the permissions evaluated along those paths are not identical. The difficult part of Microsoft DP-600 security scenarios is tracing how an identity reaches information and where a restriction must actually be enforced. A correctly configured report role cannot protect raw tables exposed through a broader storage permission.
Imagine a healthcare analytics team that publishes aggregate operational metrics to department heads. Analysts need to build new visuals from a semantic model. A smaller engineering team needs full access to raw event tables for validation. External auditors may see only approved summary reports. If every person receives workspace membership simply because they need one report, the environment has no meaningful least-privilege boundary. Fabric architecture should instead separate the ability to collaborate on assets from the authority to read specific sensitive data.
Understand the scope of workspace roles
Fabric workspace roles provide a broad administrative and collaboration boundary. Admin, Member, Contributor and Viewer convey different capabilities across workspace items. They are useful for assigning responsibility to engineering teams, report publishers and observers, but they are often too broad for one sensitive report or table. A person may need to consume a published report without becoming a member of the workspace that houses its pipelines, notebooks and source data.
Start with the job. Who can change models? Who can publish or share items? Who can grant additional access? Who merely needs to read a result? Grant roles to managed groups rather than scattering direct user assignments when feasible. A group-based approach supports staff changes and periodic review, but group membership remains a critical control: if an overly broad group inherits workspace privileges, the theoretical role design has already failed.
Workspace roles should be evaluated against other permissions. A user with broad edit privileges may be able to inspect or modify content in ways not available to an ordinary report viewer. Testing row-level restrictions with a highly privileged administrator can therefore be misleading. Validate with accounts that represent the actual end-user roles and consumption routes, not just with the workspace owner who developed the model.
Distinguish item permissions from data permissions
Item-level controls let an owner share particular Fabric assets and delegate relevant operations. For a semantic model, Build permission can allow an authorized user to create reports using that model without being granted general edit rights across its workspace. However, access to a model or report is not automatically permission to read every physical source, and permissions may differ depending on the connection identity and storage mode.
A useful pattern places sensitive engineering assets in a restricted workspace and exposes vetted semantic models to consumers through controlled sharing or downstream presentation. Engineering users retain appropriate access to lakehouse tables; business users work through the approved model. This division can reduce accidental exploration of raw personally identifiable information. The design needs explicit ownership of both the source table and the reporting interface so that changes do not create an unreviewed new path.
The converse also matters. If a user can directly open source files through a separate granted path, semantic-model RLS does not retroactively remove that access. An audit of report sharing alone will not reveal whether a broad OneLake data grant or SQL endpoint permission already exposes the same records. List the important entry points and trace each back to the user or service principal identity that actually reads the data.
Apply row-level security to the intended population
Row-level security, or RLS, filters records available through a model or data access surface according to defined roles or rules. A regional manager might see only orders assigned to the regions they manage. Static roles may work for small fixed populations, but dynamic rules based on a controlled user-to-region mapping can be easier to maintain at scale. The relationship between identity, entitlement and fact rows must be testable and complete.
Consider a sales manager responsible for two regions. A mapping table with one row per authorized region can support evaluation under the manager’s identity, provided the relationships and rule logic propagate the restriction correctly. A manager transferred to another territory requires the entitlement mapping to change at the appropriate time. If the model simply filters on an address field that can be changed by users, it may not provide the intended security guarantee.
RLS should be exercised with known test identities, including people who have no entitlement, people assigned multiple regions and users whose access has just been revoked. Verify totals, drill-through and export paths as well as the primary chart. Be alert to privileged workspace roles that are not constrained like ordinary consumers. RLS is an authorization control, not a data-quality substitute: a record with a missing region key may disappear unexpectedly or be exposed under a poorly designed default rule.
Use object and column controls for sensitive fields
Object-level security can restrict access to model tables or columns, including metadata visibility, for report users subject to those model roles. This matters when a finance model includes salary or commercially sensitive attributes that are not meant to be discovered by ordinary consumers. Simply hiding a column from the field list is not equivalent to a security rule; hiding improves usability but does not establish authorization.
Fabric data access layers can also support more granular restrictions on objects, rows and columns in applicable contexts. Decide where a particular control belongs based on the engines that need access. If a lakehouse table is queried through both Spark and SQL, an endpoint-only rule is not necessarily sufficient for both paths. If users access only a vetted semantic model, model-level OLS or RLS may be an appropriate part of the solution, alongside careful source access restrictions.
Do not combine different layers without a clear evaluation plan. A model may filter rows one way while a SQL endpoint applies a different predicate and a separate storage rule restricts columns. The effective result could be more restrictive than intended or cause a query to take an unexpected execution path. Document which policy is authoritative for each consumption mode, who maintains it and how policy changes are tested before production.
Understand the Direct Lake security interaction
Direct Lake adds an engine-specific question: does the model use Direct Lake on OneLake or Direct Lake on a SQL analytics endpoint? Direct Lake on SQL uses the endpoint for relevant access behavior; certain SQL security features can cause DirectQuery fallback when direct column loading is unsuitable. Direct Lake on OneLake does not rely on SQL endpoint security to govern reads and does not fall back to DirectQuery. Consequently, assuming that one SQL RLS policy protects both query paths is a design error.
Connection identity matters too. Single sign-on may evaluate access using the report consumer’s permissions, while fixed identity arrangements can use a managed identity or other configured credential to reach source data. Neither pattern is inherently secure in every context. A fixed identity may be useful when consumers should not receive direct lake access, but the semantic model’s own authorization must then correctly restrict their view. SSO can align with source-level permissions, but only if each actual user has the required authorized access.
Test the production security path with real role types: a report consumer, a model builder, an engineer and an unauthorized account. Verify that SQL, direct OneLake and model access behave as documented. Also check query behavior after enforcing granular SQL permissions; a security change that unintentionally forces slower DirectQuery requests can become a reliability incident. Performance and governance are coupled, not separate checklist items.
Account for sensitivity labels and endorsement
Sensitivity labels help classify information and communicate handling expectations, with behavior depending on applicable Microsoft Purview and tenant configurations. They do not replace every permission boundary or automatically prevent all possible forms of data exposure. Apply them consistently across the assets to which the policy applies, and understand how they behave when content is exported or shared through supported pathways. A label that nobody reviews when a dataset changes will eventually become inaccurate.
Endorsement helps users identify trusted content, such as a promoted or certified semantic model. It is a governance signal, not a substitute for RLS or item access. Certification of a model should follow a validation process that includes data definitions, refresh reliability, owner accountability and authorized audiences. Users can trust a certified sales metric more readily if they know who maintains it and why its underlying sources are governed.
Security operations should include an asset catalog with owners, classifications and dependency information. If a sensitive dimension is added to a formerly low-risk model, downstream access and labels need review. If a model is shared across departments, the team should know which reports and automated jobs will be affected by revoking a permission. Clear documentation reduces the temptation to grant broad access merely to make a broken report work.
Protect development and operational identities
Interactive users are not the only identities that access Fabric. Pipelines, notebooks, scheduled refreshes and deployment automation may use credentials or service principals. Each identity should have the minimum permissions required for its specific workload. Secrets and tokens must not be embedded in report definitions, notebook output or source repositories. Rotate credentials and prefer supported managed authentication patterns where feasible.
Development and production should not share unnecessarily broad identities. A test workspace using synthetic or reduced data is safer for experimentation with policy rules and transformation code. Deployment processes must make it clear which environment-specific credentials and access mappings are applied after promotion. A permissions change in production should be reviewed for both human users and automation dependencies; either can cause an outage or accidental access expansion.
Security review should cover temporary grants and exceptional access. Record why an exception exists, who approved it and when it expires. Check whether former employees, service accounts and obsolete integrations remain in security groups. Operational governance is not achieved by writing one correct RLS expression; it requires maintaining the surrounding access model while teams and data products evolve.
Prove least privilege with end-to-end tests
For each meaningful persona, test the actions that should work and those that must fail. Can an ordinary viewer open a published report? Can a designated analyst create a report from the shared model? Can the same analyst browse raw lakehouse files or issue a SQL query that reveals restricted data? Can a nonmember reach the workspace through a shared item link? The intended answers differ, and the test plan should record the actual result at every surface.
Keep evidence of role membership, model rules, source grants, connection identity, sensitivity classification and observed data visibility. Re-run the tests when a model changes storage mode, a shortcut is added or a workspace is reorganized. The broader role-based access control principle applies, but Fabric makes the enforcement layers concrete. For DP-600, security competence means explaining exactly why one identity can reach a row through one path but not another—and proving the design under realistic operating conditions.