How do Publish to Web, secure embedding and Power BI Embedded differ in who can see the data?

## The axis that matters: whose identity is used Every embedding question in Power BI reduces to one thing — **which identity does the data get filtered by, and who proved it?** Hold that axis and the options sort themselves. ## Publish to Web: no identity at all Publish to Web produces an embed code (an `iframe` snippet and a public URL) for a report. Anyone who has the link sees the report. There is no authentication, no licence requirement, and the content can be crawled and indexed. It is designed for genuinely public content — a public-sector statistics page, a marketing dashboard, a conference exhibit. What makes it interview-worthy is the failure mode: someone reaches for it because "sharing was too complicated" and puts customer or financial data on the open internet. Two guardrails exist. First, the platform blocks it for content it knows is sensitive — notably semantic models secured with row-level security, and certain live/gateway-backed connection types, cannot be published to web. Second, the tenant admin setting can restrict or disable the feature outright and there is an admin view of existing embed codes; disabling it and auditing what already exists is a standard governance action. Never assume the first guardrail covers you: a model with no RLS defined has nothing to block, so a perfectly confidential report with no RLS is publishable. One more property people miss: published-to-web content is served from a cache, so what the public sees can lag the model — another reason it is not a general sharing tool. ## Secure embedding / embed for your organization: the viewer's own identity This is the pattern behind embedding a report in an internal portal, a SharePoint Online page, or a Teams tab, and the "secure embed" URL you can generate for a report. The embedded frame requires the viewer to sign in with their organisational account. Everything the ordinary Service enforces still applies: the viewer must have access to the content (through workspace role, direct share or an app), must hold the licence the workspace's capacity requires, and is filtered by the RLS roles their account belongs to. The trade-off is that it only works for people who exist in your directory — internal staff, and guests you have deliberately invited. If your audience is thousands of customers, you cannot give each of them a directory identity and a licence, which is precisely the gap the next option fills. ## Power BI Embedded / embed for your customers: the application's identity Here your application is the tenant of record. It authenticates as a **service principal** (or, historically, a master user account), calls the API to generate an **embed token** for a specific report, and embeds it in your product. The end user never signs in to Power BI and needs no Power BI licence — they may not know Power BI is involved at all. The critical piece is that RLS is not lost: the embed token carries an **effective identity** — a username and the roles that user should have — so the model's RLS expressions evaluate as if that person were signed in. This makes your application responsible for security: whoever mints the token decides whose data is returned. A bug in that call is a cross-tenant data leak, so the token-minting path deserves the same scrutiny as any authorisation code, and tokens should be short-lived and generated server-side, never in the browser. This option requires dedicated capacity to serve the embedded workload. Capacity naming and SKUs have changed repeatedly across the platform's generations, so describe the requirement ("it needs purchased capacity sized to concurrency") rather than quoting an SKU you half-remember. ## Choosing - Content is genuinely public and you accept anonymous, cached access → **Publish to Web**, with the tenant setting deliberately left on for that case. - Audience is internal, already has accounts, and you want the normal permission and RLS model → **secure embedding** in a portal, SharePoint or Teams. - Audience is external customers of your product, at scale, with no Power BI identity → **Power BI Embedded**, service principal, embed tokens with effective identity, capacity sized to concurrency. ## The sentence that scores "Publish to Web is anonymous public publishing — no identity, cached, blocked for RLS models, and usually disabled by tenant policy. Secure embed keeps each viewer's own sign-in, permissions and RLS, so it needs directory identities and licences. Embedded is app-owns-data: my service principal mints an embed token with an effective identity, RLS still applies, the customer never has a Power BI account, and I pay for capacity."