A common assumption is that Power BI web publishing controls let you make a report link private after publishing it to the web. They do not. Power BI’s Publish to web feature creates a public, unauthenticated viewing experience, so anyone with the link, or anyone who discovers the embedded content, could access the report. Secure report sharing requires a different delivery method, such as Power BI apps, authenticated sharing, Microsoft Entra guest access, Power BI Embedded, and Row-Level Security. The correct choice depends on who needs access, whether the data is confidential, and whether each viewer should see the same information.
What Are Power BI Web Publishing Controls?
Power BI web publishing controls are the administrative and report-level settings that determine whether users can publish Power BI reports to the public web and how those reports are distributed to viewers.
The most important distinction is between Publish to web and secure Power BI sharing. Publish to web generates an embed code or link that does not require viewers to authenticate with Microsoft Entra ID, formerly Azure Active Directory. That makes it suitable only for information that an organization has explicitly approved for public distribution.
Power BI administrators manage the tenant-level setting for Publish to web in the Power BI admin portal. Depending on the configuration, the organization can allow users to create publish-to-web embeds, restrict the feature, or require users to request approval before publishing. The exact administrative experience can change as Microsoft updates Power BI, so administrators should validate the current tenant setting and approval workflow in their own environment.
These controls address several separate decisions:
Whether users can create new public web embeds.
Whether existing publish-to-web embed codes remain active.
Who can publish reports and from which workspaces.
Whether report content is appropriate for public access.
Which authenticated sharing method should replace public publishing.
A tenant restriction is useful, but it is not a complete security program. Existing public embeds need to be identified and retired when necessary. Report permissions, workspace roles, app audiences, dataset access, and data model security still require separate review.
The key information-gain detail is simple: removing a report from a workspace does not automatically make every previously created public embed safe. Organizations need an inventory of published embeds and a defined process for disabling or reviewing them.
Why Is Publish to Web Not Secure Report Sharing?
Publish to web is not secure report sharing because the viewer does not need to prove their identity before Power BI renders the content.
A normal Power BI sharing experience evaluates a viewer’s identity against permissions. Publish to web bypasses that identity-based access model. The resulting report is intended for public consumption, not for customers, employees, suppliers, or partners who need controlled access.
A public embed also creates risks beyond the visible report page. Depending on the report design and data model, viewers may be able to interact with filters, navigate report pages, or inspect information exposed through the report experience. Even if a report appears harmless at first glance, a filter or visual interaction could reveal more detail than the publisher intended.
Several common assumptions create avoidable exposure:
“The URL is hard to guess.”
“The report is not indexed, so nobody will find it.”
“Row-Level Security protects the public embed.”
“Deleting the original report solves the problem.”
The safer position is direct: if a report contains confidential, personal, financial, operational, or customer-specific information, do not use Publish to web.
Which Power BI Sharing Method Should You Use?
The right Power BI sharing method depends on audience identity, data separation, and the surrounding user experience. There is no single secure sharing option for every report.
| Sharing method | Viewer authentication | Best fit | Main security consideration |
|---|---|---|---|
| Publish to web | None | Public information approved for open distribution | Anyone with access to the link may view the content |
| Power BI app | Microsoft Entra identity | Internal users and known organizational audiences | App audiences and workspace permissions must be reviewed |
| Direct sharing | Microsoft Entra identity | Small groups needing access to a specific report or dashboard | Individual permissions become difficult to govern at scale |
| Guest access with Microsoft Entra B2B | External identity authenticated through Microsoft Entra | Known external users or organizations | Guest lifecycle, tenant settings, and data permissions need governance |
| Embed for your organization | Authenticated organizational user | Reports embedded in internal portals or applications | The surrounding application must preserve authenticated access |
| Power BI Embedded for customers | Application-managed authentication | Customer portals and multi-tenant products | Token generation, tenant isolation, and RLS design are critical |
| Exported PDF or PowerPoint | File-based access | Fixed snapshots and offline review | Copies can persist outside Power BI controls |
Power BI apps are generally the clearest starting point for internal report distribution. They separate the report development workspace from the audience experience and allow publishers to organize content for defined users or groups.
Guest access is appropriate when external viewers are known and should authenticate. The organization must manage invitations, guest removal, group membership, and access reviews. External sharing should not rely on a generic link sent through email.
Power BI Embedded is the stronger fit when analytics belong inside a customer-facing application. The application authenticates the customer, determines the customer’s scope, and requests an embed token for the relevant report and dataset. The embedded report does not replace application authorization. It must work with it.
For more background on external delivery patterns, see our guide to Power BI customer report delivery with secure external access.
How Do Power BI Tenant Controls Reduce Publishing Risk?
Power BI tenant controls reduce risk by limiting who can use high-impact sharing features and by creating a review point before public publishing occurs.
The Publish to web tenant setting is the first control to inspect. An administrator should determine whether the feature is enabled for the entire organization, disabled, or limited to specific security groups. A request-and-approval model gives governance teams the opportunity to verify that a report is genuinely public before a user generates an embed code.
Tenant governance should also account for related settings and behaviors:
External sharing and guest access.
Export permissions for Excel, PowerPoint, and PDF.
Copying data from visuals.
Sharing through Microsoft Teams or SharePoint.
App publishing and audience management.
Embed code creation.
Workspace creation and member permissions.
Sensitivity labels and information protection.
Capacity and tenant location requirements where relevant.
A control is only effective when it has an owner. The Power BI administrator may manage tenant settings, while information security, legal, privacy, or business data owners approve specific content. Report authors should not be expected to make classification decisions without guidance.
A practical review process records the report name, workspace, owner, data classification, intended audience, sharing method, approval date, and retirement date. That information makes later audits and access reviews much easier.
The control should also be tested from the viewer’s perspective. Administrators should verify what happens when a user leaves a security group, when an external guest is removed, when a report is moved between workspaces, and when an embed token expires. Configuration screens can look correct while the actual viewer experience remains over-permissive.
How Should You Audit Existing Power BI Web Publishing?
You should audit existing Power BI web publishing by locating public embed codes, identifying their source reports, checking the data exposed, and disabling anything that lacks documented approval.
Start with discovery. Look for published links in websites, intranets, email templates, documentation, source repositories, content management systems, and browser bookmarks used by report authors. The Power BI administrative experience and organizational change records can support this work, but they should not be the only sources because links may have been copied outside the Power BI environment.
For each discovered public embed, document:
The report and workspace that produced it.
The report owner and business data owner.
The datasets and sources behind the report.
Whether the content includes personal, customer, financial, or operational data.
Whether filters expose detailed records.
Where the link is published.
Whether the link has a current business purpose.
The date and evidence of approval.
The action required, such as retain, replace, or disable.
An audit should examine the report itself, not only its title. A report called “Public Summary” could still expose detail through a table visual, drillthrough page, tooltip, export option, or filter combination.
The replacement decision should be explicit. Public content can remain on Publish to web when the organization has approved the information for open access. Internal content should move to a Power BI app or authenticated workspace distribution. Customer-specific content should move to guest access or an embedded application designed for that audience.
Our related guidance on Power BI image hosting and reliable report rendering covers another audit detail that teams sometimes miss: images and other report assets can have access behavior separate from the report itself. A report may be restricted while an image URL is public, stale, or dependent on an internal session.
How Do Row-Level Security and Web Publishing Work Together?
Row-Level Security, or RLS, limits which rows an authenticated user can access based on their identity or role. It does not turn a public web embed into a secure, user-specific sharing method.
In a standard Power BI model, RLS roles might filter data by department, region, account, or customer identifier. A dynamic role can use identity information such as the signed-in user’s principal name to determine the correct filter. That design requires the report to receive a trustworthy identity context.
Power BI Embedded for customers introduces another important pattern. In an application-owns-data model, the application authenticates the customer and generates an embed token containing the permitted report and data scope. The application and semantic model must agree on how tenant or customer identifiers are passed into RLS. If the token, model, or application authorization is misconfigured, the report could expose data across customer boundaries.
RLS also requires testing with representative roles. Report authors and workspace members with elevated permissions may not experience the same restrictions as ordinary viewers. A test plan should include users with no access, users with one permitted scope, users with multiple permitted scopes, and users whose access has been removed.
RLS is therefore one layer in a secure sharing design. It does not replace:
Identity verification.
Workspace and app permissions.
Dataset permissions.
Application authorization.
Embed token controls.
Tenant separation.
Access reviews.
Export and download restrictions.
The report must be secure in the complete delivery path, not only in the data model.
What Should a Secure Power BI Publishing Process Include?
A secure publishing process should connect report development, data classification, approval, distribution, monitoring, and retirement. Treating publication as a one-click action leaves too much responsibility with individual report authors.
A useful workflow begins before the report is built. The owner identifies the intended audience and classifies the data. The team then selects the delivery pattern, designs the model and visuals for that audience, configures permissions, and tests the result with actual viewer roles.
A mature process includes these stages:
Classify the content.
Define the audience.
Select the distribution model.
Configure the model and permissions.
Test the full viewer journey.
Record ownership and review dates.
The testing stage should include more than Power BI Desktop. Power BI Service behavior, embedded delivery, PDF or PowerPoint exports, mobile access, and external identities can produce different results. For example, a report author may see a SharePoint-hosted image while an external viewer receives a broken image because the viewer does not have the same Microsoft 365 permissions.
Common Power BI Web Publishing Mistakes to Avoid
The most damaging mistakes come from treating a publishing feature as if it were an authorization system.
One mistake is allowing Publish to web because users need an easy way to share reports. Convenience does not justify public exposure. If users need simple internal access, a Power BI app provides a more appropriate experience.
Another mistake is relying on a report page that shows only aggregated values. Aggregation reduces detail but does not guarantee confidentiality. A visual with drillthrough, export, or unusual filter combinations can reveal more than the page designer intended.
Teams also create risk by leaving test embeds active after a report moves into production. Development reports may contain sample data, incomplete security rules, or temporary visuals. Every test embed should have an owner and a retirement action.
A further issue is failing to separate report access from asset access. Images, custom visuals, files, and linked documents can have their own URLs and permissions. Review those dependencies as part of the report’s security boundary.
Finally, organizations sometimes approve a sharing method without approving the data lifecycle. A secure report still needs rules for downloads, screenshots, email distribution, cached pages, copied files, and access after an employee or guest leaves the organization.
A Practical Decision for Secure Report Sharing
Power BI web publishing controls are most effective when we treat them as part of a broader information governance process, not as a substitute for authentication. The central decision is whether the report is truly public or whether the audience needs an identity-based access check.
If the report is public by design, Publish to web may fit after data-owner approval and a review of filters, exports, drillthrough pages, and linked assets. If the report is internal, use authenticated Power BI distribution. If the report serves known external users, use governed guest access. If it belongs inside a customer application, design the full Power BI Embedded path, including token creation, tenant isolation, and RLS testing.
The one principle to remember is this: a report link is not a security boundary. Secure sharing depends on the identity of the viewer, the permissions assigned to that identity, the data scope enforced by the model, and the controls surrounding exports and embedded content.
We help organizations review Power BI governance, access controls, report delivery patterns, and embedded analytics requirements. If you are assessing an existing publishing setup or planning a secure replacement, contact our team about your Power BI environment.
