Yes, although sensitivity labels in Power BI provide robust data classification and protection tools, there are a number of limitations you should know about when considering their use. These limitations can impact the consistency and effectiveness with which labels are applied across various features, data types, and usage cases.
Some important limitations include:
No enforcement within Power BI visuals or runtime:
Sensitivity labels do not limit what users are able to see within a report—they are used to apply classification and protection at the report file or artifact level, not on individual visual-level data. When users can view the report, they will see all visuals irrespective of the applied label.
Export protection only covers supported formats:
Although labels can impose encryption and access control on exports such as Excel, PDF, or PowerPoint, this protection remains in effect only if the formats are supported and the user exports via the Power BI Service. Export protection doesn't cover screenshots or copy-and-paste copying.
No support for paginated reports or embedded content (in certain cases):
Sensitivity labels can be supported in a paginated report or Power BI content embedded in an external application only up to a point, depending on the configuration of the embedding. Label enforcement is circumvented in some embedded scenarios.
Inheritance gaps:
Labels can fail to inherit in all scenarios—say, from a labeled Excel file to a Power BI dataset or between datasets and downstream reports unless label inheritance policies are configured within Microsoft Purview.
Labels don't encrypt live connections:
When using DirectQuery or Live Connections, the sensitivity label does not encrypt the data source itself. Data protection must be handled at the source level (e.g., SQL Server, Synapse).
