Power BI Report Consumer Security Planning - Getting Access Right Before You Publish

The most common Power BI security problem I see isn't a hacker or a misconfigured firewall. It's a regional manager in Brisbane opening a sales report and seeing every other region's numbers, including commission figures for people they manage. Nobody did anything malicious. Someone just shared a report with "people in your organisation" because it was the quickest way to stop the access request emails.

That's what report consumer security planning is about. Microsoft has a whole article on it in their Power BI implementation planning guidance, and it's one of the more practical pieces in that series. The idea is simple: before you publish content to a wider audience, decide how people will get access, what they'll be able to see, and what they'll be able to do with it once they're in.

For Australian businesses this matters more than it used to. Privacy Act reforms have tightened expectations around who sees personal information, and boards are asking harder questions about data access. "We shared it with everyone because it was easier" isn't a great answer anymore.

Who counts as a report consumer

A report consumer is someone who views and interacts with Power BI content but doesn't create it. They open reports, filter, drill through, maybe export to Excel. They're usually the biggest group of Power BI users in any organisation, often by a factor of ten or more over creators.

Planning for them is different from planning for creators. Creators need access to data sources, semantic models and workspaces. Consumers need access to finished content and, ideally, nothing else. The guidance breaks down the different ways to give consumers access, and that's where most of the decisions sit.

You can read Microsoft's full article here: Power BI implementation planning - Report consumer security planning.

The ways to give consumers access

There are four main options, and each has a place.

Power BI apps. This is the one we recommend for most consumer audiences. You publish a curated set of reports from a workspace as an app, and grant access to the app. Consumers get a clean, navigable experience and never see the workspace itself. Apps also support audiences, so you can show different reports to different groups from the same app. Finance sees the P&L pages, operations sees the throughput dashboards, everyone gets one link.

Workspace Viewer role. You can add consumers to the workspace as Viewers. It works, but it exposes everything in the workspace, including drafts and test reports. For a small team that's fine. For a wide audience it's messy, and it blurs the line between the people building content and the people using it.

Per-item sharing. You can share an individual report or dashboard directly with a person or group. It's handy for one-off cases, and it's the option that gets abused the most. Share permissions spread quietly, and six months later nobody knows who has access to what. We nearly always find a long tail of direct shares when we audit a tenant.

Sharing links. Links can be scoped to specific people, people in your organisation, or people with existing access. The "people in your organisation" option is the one that causes the Brisbane problem from the start of this post. If your tenant allows it, anyone who gets the link can open the report. I'd recommend most organisations restrict this setting at the tenant level, or at least default links to specific people.

My honest view: apps for broad audiences, Viewer role for small team scenarios, per-item sharing sparingly and with groups rather than individuals, and links scoped to specific people unless there's a real reason not to.

Use groups, not people

This comes up in every Power BI security conversation, and it's worth saying plainly. Grant access to Microsoft Entra security groups or Microsoft 365 groups, not to individual users.

When someone joins the sales team, they get added to the sales group and they automatically see the right content. When they leave, they get removed and they lose access everywhere. If you've granted access to individuals across forty reports and three apps, removing someone becomes an archaeology project.

The trick is getting the groups right. We often work with IT to set up groups that line up with the reporting audiences, rather than reusing email distribution lists that happen to exist. Distribution lists can't be used for Power BI permissions anyway, which surprises people more often than you'd think.

Row-level security is the real control

Workspace roles and app permissions control which reports someone can open. Row-level security (RLS) controls which data they see inside those reports. For most organisations with more than one region, business unit or customer segment, RLS is the part that actually protects sensitive data.

RLS is defined in the semantic model. You create roles with DAX filters, then map users or groups to those roles in the Power BI service. There are two broad approaches:

• Static RLS, where you create a role per region (or whatever dimension) and hard-code the filter. Simple, but it doesn't scale well if you have fifty regions.
• Dynamic RLS, where you have a security table mapping users to what they can see, and the filter uses USERPRINCIPALNAME() to look up the current user. More work up front, far easier to maintain.

We default to dynamic RLS for anything beyond a handful of roles. The security table can be maintained by the business, often sourced from HR or a simple SharePoint list, and new access doesn't need a model change.

A few things to watch out for. RLS only applies to Viewers. If someone is a Member, Contributor or Admin of the workspace, RLS doesn't restrict them. This trips people up constantly. They test RLS as themselves, see everything, and assume it's broken. Use the "Test as role" feature, and make sure consumers are only ever Viewers or app users.

Also, RLS doesn't stop someone from seeing that data exists, only which rows they get. If a report shows "Total company revenue" as a card that isn't affected by the RLS filter, you've leaked information. Design reports with RLS in mind, not as an afterthought.

Object-level security and the stuff RLS can't do

Sometimes the problem isn't rows, it's columns. You want everyone to see headcount, but only HR to see salary. Object-level security (OLS) can hide entire tables or columns from specific roles.

OLS is useful, but it's more fiddly. You can't configure it in Power BI Desktop's UI alone; you typically need an external tool like Tabular Editor. And if a visual uses a column that a user can't see, the visual breaks for that user rather than just going blank. That's technically correct but not a great experience. For a lot of clients we end up recommending a separate semantic model for sensitive data rather than relying on OLS. It's more to maintain, but it's much easier to explain and audit.

Licensing shapes what's possible

You can't plan consumer access without thinking about licensing. If content is in a workspace that isn't backed by Premium or Fabric capacity, every consumer needs a Pro or Premium Per User licence. If the workspace sits on an F64 or larger Fabric capacity (or legacy Premium P SKU), consumers with a free licence can view content.

For organisations with hundreds of report viewers, this is often the biggest factor in the whole decision. We've had clients spend a lot of time planning app audiences and RLS, only to discover that half the audience can't open the app because they don't have a licence. Sort out licensing early.

Export, print and the data leaving the building

Once someone can see a report, the next question is what they can do with it. Export to Excel, export underlying data, analyse in Excel, print, copy visuals. Each of these can take data out of Power BI and into places with weaker controls.

Tenant settings let you restrict export options, and Microsoft Purview sensitivity labels can follow data when it's exported to Office files. If you're handling personal information or commercially sensitive data, labels are worth setting up. They're one of the few controls that keep working after the data has left the report.

I'd be careful about locking down export entirely though. In our experience, if you block export without giving people another way to get what they need, they'll take screenshots or retype the numbers into a spreadsheet. Then you've lost both the control and the audit trail.

What we've seen work

The organisations that handle report consumer security well tend to do a few things consistently. They publish via apps rather than giving everyone workspace access. They use groups for everything. They use dynamic RLS backed by a business-maintained security table. They restrict organisation-wide sharing links at the tenant level. And they review access a couple of times a year, which is the part most people skip.

None of that is complicated. It just needs to be decided up front, before the first report goes out to a wide audience, because retrofitting security onto a tenant with two years of ad hoc sharing is a lot more painful.

If you're planning a Power BI rollout to a larger audience, or you suspect your current sharing setup has drifted, our Power BI consultants do this kind of access review and RLS design regularly. For organisations working through data governance more broadly, especially in regulated sectors like financial services, we can help line up Power BI security with your wider data controls. And if you're moving reporting onto Fabric, our Microsoft Fabric consultants can help plan the capacity and licensing side.