How to Share Power BI Dashboards With External Customers (Without Per-Seat Licensing)

Four Ways to Get a Power BI Dashboard in Front of Someone Outside Your Company

You built the dashboards. Your customers want to see them. And somewhere between those two facts sits a licensing model that was designed for employees, not customers.

Quick answer:

• The four paths: per-seat Pro licenses, publish-to-web, app-owns-data embedding on Fabric capacity, or a third-party embedded portal
• What it costs: Power BI Pro is $14/user/month; Fabric capacity starts at roughly $263/month for an F2; flat-rate portals run a few hundred a month regardless of viewer count
• The rule that matters: with regular sharing your viewers need licenses — with app-owns-data embedding they need none at all
• Who this is for: founders, CTOs, and heads of product at software companies whose customers are asking for analytics

Here is the trap. Power BI licensing is built around the assumption that the person looking at a report works for you. Every path to sharing externally is really a workaround for that assumption, and each workaround has a different cost curve. Pick the wrong one at ten customers and you will not notice. Pick the wrong one at a thousand and it becomes the second-largest line item in your infrastructure budget.

This guide walks all four paths honestly, including the real 2026 numbers and the point at which each one stops making sense. Some of those numbers will favour building it yourself. We have said so where that is true.

Option 1: Give External Users Their Own Pro Licenses

The most direct route. You invite your customer into your Microsoft Entra tenant as a B2B guest, add them to a workspace or share an app with them, and they open reports in the Power BI Service like any employee would.

How B2B Guest Access Actually Works

Microsoft Entra External ID handles the identity side. You send an invitation, your customer accepts with their existing work account, and they appear in your directory as a guest object. From there you grant them access to specific Power BI content.

The licensing rule is the part that catches people out. A guest viewing your content needs a Power BI Pro license — either one they already own in their own tenant, or one you assign them from yours. There is a significant exception: if the workspace sits on F64 capacity or higher, users with free licenses can view the content. Below F64, everyone needs Pro.

That F64 threshold is why so much online advice contradicts itself. Both claims are true, at different capacity tiers.

What It Costs

Power BI Pro is $14 per user per month. Microsoft raised it from $10 on 1 April 2025 — a 40% increase, and worth remembering when you model this out over a three-year horizon. Premium Per User sits at roughly $24 per user per month if you need the larger model sizes and higher refresh rates.

The math is unforgiving because it is purely linear. Ten external viewers is $140 a month. A hundred is $1,400. A thousand is $14,000 a month, or $168,000 a year, to let people look at dashboards you have already built.

When This Works, and When It Breaks

Per-seat is genuinely the right answer for a small number of high-value relationships. If you serve detailed analytics to eight enterprise clients who each pay you six figures, $112 a month is not a line item worth engineering around. Take the simple path.

It breaks on two axes:

• Cost, somewhere around 20 to 30 viewers. This is where the monthly bill starts to exceed the alternatives and keeps climbing with every customer you add. Your analytics cost scales with your success, which is precisely backwards.
• Governance, often sooner. Every external viewer becomes a guest object in your corporate directory. You now own an offboarding problem: when a contact leaves your customer's company, nobody tells you. Guest sprawl is a real audit finding, and it arrives long before the cost does.

There is also a product problem. Your customers land in the Power BI Service, complete with Microsoft's chrome and branding. It looks like a tool you resell, not a feature you built.

Option 2: Publish to Web (And Why You Almost Certainly Cannot)

Search for how to share a Power BI report externally and you will find Publish to Web quickly. It is free, it takes one click, and it produces an embed code that works anywhere.

It is also completely public.

Publish to Web means exactly that. The report is accessible to anyone on the internet with the URL, with no authentication of any kind. It is indexable. It can be shared onward. There is no row-level security, because there is no user identity to apply security against.

Microsoft is explicit that this feature is for public data — election results, published statistics, open datasets. If your dashboard contains a single customer's revenue figures, headcount, patient volumes, or order history, Publish to Web is a data breach with a friendly button.

Most tenant administrators disable it outright for this reason. If yours has not, that is worth a conversation this week.

The only legitimate use in a customer-facing context is a genuinely public marketing dashboard — an industry benchmark report, say, where the data is aggregated and you actively want it spread around.

Option 3: Build App-Owns-Data Embedding on Fabric Capacity

This is the path Microsoft designed for software companies, and it is the one that removes viewer licensing entirely.

How App-Owns-Data Works

In the app-owns-data model, your customers never authenticate to Power BI. They log into your application. Your application then authenticates to Power BI using a service principal — a non-human identity that owns the content — and requests a short-lived embed token scoped to exactly what that user should see.

Because your customers are never Power BI users, they need no Power BI license. Not Pro, not free, nothing. This holds at every capacity tier, from F2 upward. That is the critical difference from Option 1, and it is the distinction most articles on this subject get wrong.

Tenant isolation comes from passing an effective identity into the embed token, which activates row-level security in the underlying semantic model. Customer A's token resolves to Customer A's rows. If you have already worked through connecting Power BI to your source systems, this sits on top of that modelling work.

The Real Cost: Capacity Has a Floor

Removing per-seat licensing does not make this free. Production embedding requires dedicated capacity, and capacity is billed whether anyone is looking at a dashboard or not.

The standalone A-SKUs that used to serve this purpose were retired in 2024. Embedding rights now come bundled with Microsoft Fabric F-SKUs, priced at roughly $0.18 per capacity unit per hour in a typical US region. The arithmetic is linear and easy to run yourself:

• F2 — 2 CU x $0.18 x 730 hours = about $263/month
• F4 — about $526/month
• F8 — about $1,051/month
• F64 — about $8,410/month pay-as-you-go, or roughly $5,000/month on a one-year reservation

Reserved capacity saves 30–40% over pay-as-you-go, and you can pause pay-as-you-go capacity when idle — though that is rarely practical for a customer-facing product that needs to be up.

The honest caveat: F2 is the entry point, not the realistic answer. It is a small amount of compute, and a real customer-facing workload with concurrent users and scheduled refreshes will push you up the ladder. Capacity throttling under load is the most common complaint from teams who sized this optimistically.

What You Still Have to Build Yourself

The capacity bill is the visible cost. The engineering is the one that gets underestimated:

• Service principal auth and token lifecycle — acquiring, caching, and refreshing embed tokens before they expire, without leaking them to the browser
• Multi-tenant row-level security — mapping your application's tenants onto RLS roles and proving, repeatedly, that the mapping cannot be subverted
• White-labeling — theming reports to look like your product rather than Microsoft's
• Access control UI — deciding which of your users see which reports, and giving your customer admins a way to manage that
• Audit logging — recording who viewed what, which your enterprise customers will eventually ask for in a security review
• Ongoing maintenance — the Power BI embedding APIs change, and this code is now yours forever

Teams consistently estimate this at a few weeks and land at a quarter. The build is not conceptually hard; it is a long tail of security-sensitive detail where being 95% correct is not a passing grade.

When Building Is the Right Call

Build this yourself when analytics is your product rather than a feature of it, when you have a dedicated data platform team who will own the code after the original authors move on, or when you need deep custom interaction between the dashboards and the rest of your application. Companies in that position should not outsource their core surface, and no vendor should tell them otherwise.

Option 4: Use an Embedded Analytics Portal

The fourth path buys the layer described above rather than building it. A portal product sits between your BI tool and your customers, handling multi-tenant isolation, white-labeling, authentication, and access control as configuration instead of code.

Two Very Different Flavours of Vendor

This category splits in a way that matters more than pricing, and it is worth understanding before you evaluate anyone:

• Rebuild-in-their-layer. Tools like Luzmo, Explo, and Qrvey give you their own visualization engine. You construct dashboards inside their product. The results are often excellent and deeply customisable — but your existing Power BI work does not come with you. You are migrating, not embedding.
• Embed-what-you-already-built. Tools in this group — including embedportal and Reveal — take the dashboards already live in your BI tool and wrap them in a multi-tenant, branded portal. Your semantic models, your RLS, your existing reports.

If you have no Power BI investment yet, the first group is worth a serious look. If you have spent a year building semantic models your team trusts, throwing that away to solve a distribution problem is an expensive way to get where you are going. This is broadly the same build-versus-buy calculus we walked through in our guide to embedded business intelligence.

The Cost Shape

Portal products generally charge a flat monthly fee independent of viewer count — typically a few hundred dollars a month at the small-to-mid end. The strategic point is not the absolute number but the shape of the curve: it is flat. Adding your two-hundredth customer costs nothing extra, which means your analytics cost stops scaling with your growth.

Note that this usually sits alongside your existing BI licensing for the people who build dashboards. Your analysts still need Pro. What disappears is the per-viewer cost for everyone consuming them.

When a Portal Is the Wrong Choice

Being straight about this is more useful than a feature list. Skip this category entirely if:

• You have fewer than roughly ten external viewers. Per-seat Pro is cheaper and simpler. Come back when you have grown.
• Analytics is your actual product. If customers buy you for the dashboards, that surface is your differentiation and belongs in-house.
• On-premises deployment is a hard requirement. Most portal vendors are cloud-first, and a self-hosted requirement narrows the field sharply.
• Your team has already committed to building. If the engineering is scoped, staffed, and underway, a vendor is a distraction rather than a shortcut.

Side by Side: What Each Path Costs at 10, 100, and 1,000 Viewers

Figures below are monthly, current as of July 2026, and exclude the licenses your internal dashboard authors need in every scenario. Verify against Microsoft's pricing page before you budget — Pro moved 40% in a single change in 2025.

Three things are worth drawing out of that table.

At ten viewers, per-seat licensing genuinely wins. It is cheaper than every alternative and requires no engineering at all. Anyone who tells you otherwise is selling something. The crossover arrives somewhere between 20 and 40 external viewers depending on which path you compare against.

The Fabric column is a range because it is a decision, not a price. Where you land depends entirely on concurrency and refresh load, and the "plus build" is doing enormous work — a quarter of engineering time amortized over the life of the product, plus permanent maintenance. Model that as real money, because it is.

The flat column does not move. That is the entire proposition. Whether the shape is worth it depends on how fast you expect your external viewer count to grow over the next two years.

The Security Questions to Answer Before You Share Anything

Whichever path you take, your first enterprise customer's security review will ask some version of these three questions. Having answers ready is faster than inventing them under deadline.

Row-Level Security and Tenant Isolation

Row-level security filters data based on who is asking. In an embedded context you pass an effective identity in the embed token, and Power BI applies the matching RLS role to every query.

The failure mode to guard against is a mapping bug between your application's notion of a tenant and the RLS role actually applied — the class of bug that shows Customer A a row belonging to Customer B. Test this deliberately and negatively: assert that a token for one tenant cannot retrieve another tenant's rows, and keep that test in CI forever.

Token Lifetime and Leaked URLs

Embed tokens are short-lived by design, and shorter is better. Ask what happens if a token or embed URL escapes — pasted into a support ticket, captured in a browser extension, logged by a proxy. A token that expires in minutes and is scoped to a single tenant's data limits that blast radius to something survivable. A long-lived, broadly-scoped token does not.

Audit Trails

You will eventually need to answer "who viewed this report, and when" — for a customer's compliance team, or for your own incident response. Decide early whether those events flow into your SIEM, because retrofitting audit logging after an incident is a bad week.

How to Choose: Five Diagnostic Questions

Answer these honestly and the path usually picks itself:

• How many external viewers will you have in 18 months? Not today — 18 months. Under 20 and per-seat is fine. Over 100 and per-seat is already a problem you have not noticed yet.
• Is analytics a feature of your product, or the product itself? Feature means buy. Product means build.
• Do you have engineers you can lose for a quarter? Not "could you technically build this" — everyone could. Can you spare the people, and the people who will maintain it afterwards?
• Does it need to look like your product? If customers must never see Microsoft branding, Option 1 is out immediately.
• How much does one customer's data leaking cost you? If the answer is "the company," that rules out Publish to Web and raises the bar on your isolation testing regardless of path.

Frequently Asked Questions

Do external users need a Power BI license?

It depends on the path. With regular sharing or B2B guest access, yes — each viewer needs a Pro license, unless the content sits on F64 capacity or higher, where free licenses can view. With app-owns-data embedding, no license is required at any capacity tier, because your service principal authenticates rather than the user.

Can I share a dashboard with someone who has no Microsoft account?

Not through normal sharing — B2B guest access requires an identity Entra can authenticate. App-owns-data embedding sidesteps this completely: your customers log into your application with whatever credentials you already issue them, and never touch a Microsoft login. For customer-facing analytics this is usually the deciding factor.

Is Power BI Embedded still a separate product?

Not as its own SKU. The standalone A-SKUs were retired in 2024 and embedding rights are now bundled into Microsoft Fabric F-SKUs. The capability is very much alive — the purchasing path changed. Older tutorials referencing A1 through A6 capacities are out of date, which is a common source of confusion when researching this.

What is the cheapest way to share dashboards with 100 customers?

Not per-seat licensing — that is $1,400 a month. The realistic contest is between Fabric capacity with app-owns-data embedding you build, and a flat-rate portal. Capacity alone may be cheaper on the invoice; the portal is usually cheaper once engineering time and ongoing maintenance are priced in. The right answer turns on whether you have engineers to spare.

Can I white-label Power BI?

Partially, and only when embedding. You can apply custom themes, hide chrome, and control the container it renders in. You cannot meaningfully rebrand the Power BI Service itself, which is why Option 1 always looks like Power BI to your customers. Full white-labeling means embedding — built or bought.

The Short Version

Power BI licensing assumes your viewers are employees. Every method of sharing externally is a way around that assumption, and the right one depends almost entirely on how many external viewers you expect and whether you have engineers to spare.

Under 20 viewers, buy Pro licenses and move on to a more interesting problem. If analytics is your product or you have a data platform team, build app-owns-data embedding on Fabric properly. Between those poles — a growing number of customers, a lean engineering team, and dashboards you have already built and do not want to rebuild — a flat-rate portal is usually the shape that fits.

Whatever you choose, decide it deliberately rather than discovering it in an invoice. And never, under any circumstances, solve it with Publish to Web.

atSpark's embedportal takes dashboards you have already built in Power BI, Tableau, QuickSight, or Metabase and wraps them in a white-labeled, multi-tenant portal with row-level security and SSO — flat monthly pricing, unlimited viewers. It is listed on Microsoft Marketplace. If you are weighing the options above, we are happy to tell you when one of the other three is the better fit.