What it does
Two embedding solutions with different licensing shapes. Embed for your customers (app owns data) authenticates non-interactively with a service principal or master user, and the end users need no Power BI licence. Embed for your organisation (user owns data) authenticates each user against Microsoft Entra ID, and every one of them needs a licence.
Key facts
- Embed for your customers targets external users, uses your own authentication, and the app users don't need a Power BI licence. R and Python visuals aren't supported in this mode.
- Embed for your organisation targets internal users, authenticates interactively against Entra ID, and each app user needs a Power BI licence. R and Python visuals are supported, subject to region restrictions.
- Both scenarios need capacity in production. Microsoft's embedding table lists F (any size), P, or A/EM SKUs as the options.
- For embed for your organisation and for embedding in Microsoft 365 surfaces such as SharePoint Online and PowerPoint, F SKUs smaller than F64 and all A SKUs require each consuming user to hold Pro, PPU or an individual trial licence. F64 and above, or P capacities, allow viewing on a free Fabric licence.
- Free embed trial tokens exist for development testing with a Pro licence. Microsoft states plainly that production requires a purchased capacity.
- Secure embed is the no-code option — a URL or iframe into any portal that accepts one. The viewer still needs the appropriate Power BI licence, so it carries the same licensing shape as embed for your organisation.
- A SKUs are the Azure-billed Power BI Embedded capacities. They support Power BI items only, not Fabric items.
- Whoever builds and publishes the embedded content still needs Pro or PPU, in every scenario.
- RLS behaves differently between the two. In embed for your customers the app supplies the effective identity, which means the app can pass any username value it likes.
When to use / skip
The decision is almost always made for you by who the audience is. External customers of an ISV product means embed for your customers, service principal, and no per-user licensing to worry about. Internal staff inside a company portal means embed for your organisation, and then the licensing is exactly the same conversation as any other Power BI distribution — capacity size against per-user licences.
The scenario to argue about is internal embedding below F64. Clients like the idea of embedding a report into an intranet page for everyone, then discover every viewer needs Pro because the capacity is F32. Establish the SKU before anyone writes embedding code.
Configuration decisions
- Which solution the audience actually calls for. External and unlicensed means app owns data; there's no halfway house.
- Service principal or master user for non-interactive authentication. Service principal is the answer on anything you'd have to support in two years' time.
- The capacity SKU, and specifically whether the internal scenario clears the free-viewing threshold.
- Whether secure embed is enough. If the requirement is genuinely "put this report on that page", the no-code route saves a development project.
- How effective identities and RLS roles are constructed and validated in the app-owns-data case, because the app is the only thing enforcing who sees what.
Gotchas
- The below-F64 rule applies to Microsoft 365 embedding too — SharePoint Online and PowerPoint. Clients treat those as free surfaces and they aren't.
- Free trial tokens work well enough in development that teams forget they're not a production path. Budget the capacity at the start.
- Master user accounts are the shortcut everyone takes and the thing that breaks when that account changes password, gets MFA enforced, or leaves.
- In embed for your customers, the app can pass any value as the effective identity username. RLS rules that assume the value is one of a known set will silently return all rows for a typo. Write rules that fail closed.
- A SKUs won't carry Fabric items, so an embedded architecture on A SKUs can't later pick up Direct Lake or lakehouse-based models without changing SKU family.
Consultant notes
- Get the ISV commercial model on the table early. If the client is reselling analytics, capacity is cost of goods sold and needs to appear in their pricing, not in an IT budget line.
- Where the answer is embed for your organisation, stop calling it an embedding project. It's a Power BI distribution project with an iframe on the end, and the licensing conversation is the normal one.
- Recommend service principals in writing. Master users are a documented pattern and a known operational liability.
- Prices and the finer licensing rules live in Microsoft's pricing pages and licensing documentation. Point at them; don't paraphrase a number.
Recheck the SKU table and the below-F64 rule before scoping any internal embedding work — this is where quotes go wrong