Secure private Power BI dashboards on a signage display

How do you show a private Power BI dashboard on a signage screen?

Three paths work for a private dashboard: a signage platform with a native Power BI integration that mints embed tokens, an in-network player that loads an internal URL, and a publish-to-web link you should reserve for reports with nothing confidential in them.

The difference between them is where the report bytes travel and what a stranger needs in order to read them. The table puts the three side by side.

The sections below take the paths in the order you would meet them: why the public link fails first, then the two real options, then the freshness and rotation numbers, and the decision.

Why is a publish-to-web link not secure for production data?

Publish to web gives the report a public URL with no sign-in. Anyone who obtains the link, from a browser history, a player config export or a screenshot, opens the live report, and the link keeps working until you remove the embed code.

The feature is built for public sharing: the report opens for anyone on the internet with no sign-in step, and row-level security does not apply to it.

The wrapper changes nothing either. Some setups put the public report URL behind a screen access token, so the playlist page itself needs a token to open. That protects the outer page and nothing else: the report fetch inside it still needs no credential, so one leaked playlist URL, a photo of a config screen or a shared browser profile hands over the report. For anything with customer names, margins, scrap numbers or unreleased schedules, take this path off the list.

What does a native Power BI integration add over a public link?

A native integration signs the platform in with a service identity, asks Power BI for a per-report embed token, and serves the report only while that token is valid, which is about an hour, so the platform mints a fresh one server side before expiry.

The platform's cloud holds the credentials or the service identity, and the player never sees them. When a screen needs the report, the platform requests an embed token tied to that report and identity, delivers the render with it, and renews on schedule. The embed-token documentation for custom applications describes the same renewal cycle, and platforms that support the integration handle it server side.

Two things follow. First, a captured URL is worthless: the token is short-lived and bound to the report and identity, so replaying it gets an error card. Second, the identity is a real control: scope it to one workspace and apply row-level security, and a compromised screen shows only the rows that screen was ever meant to show.

The platform is designed to renew the token before it lapses; when the renewal service cannot be reached, the screen shows the platform's error card and picks the renewal back up when the path returns. The player needs outbound TCP 443 to the Power BI endpoints, which is the one network change this path usually asks the plant for.

When does an in-network player with an internal URL win?

The in-network path wins when the data must not cross the internet at all: the player sits on the plant network, loads an RFC 1918 address such as 10.0.0.0/8, 172.16.0.0/12 or 192.168.0.0/16, and no packet with report data ever leaves the building.

The render runs in a browser view on the player, pointed at an address a server inside your network serves: an on-premises report server for .pbix reports, or the plant's own web dashboards. The signage side only needs a region type that loads a web page.

A cloud-managed playlist can still drive the screen: the entry it holds is the internal URL string, and only that string ever leaves the site, never a report byte. Run a fully on-premises player instead and not even the URL does. For screens that should never meet a login prompt in the first place, offline dashboard signage for screens without logins covers the account-free playback pattern. And if the screen in question is a card-based offline display with no live path, the realistic route is an exported snapshot; factory data table signage for offline screen content covers building those tables.

What does the internal URL need from the network and the server?

Four things: a DNS name the player can resolve, HTTPS on TCP port 443 with a certificate the player trusts, frame headers that allow the player to embed the page, and a VLAN that reaches the report server.

• A name that resolves. Give the report server an internal DNS record with a fixed address, such as 10.20.4.11 on the plant LAN, and use the name in the playlist so a server move is a DNS edit.
• HTTPS with a trusted certificate. Serve TLS 1.2 or newer on TCP 443, with your internal CA's root installed on the player or a publicly trusted certificate issued for the internal hostname. Plain HTTP would put the report on the VLAN for anyone with a switch port to read.
• Frame headers that allow the embed. If the server sends X-Frame-Options: DENY or SAMEORIGIN, or a content security policy whose frame-ancestor list omits the player, the browser view blocks the page. Open the URL in the player's own web view before you build the playlist. When a dashboard server's frame policy changes and embeds break, the frame policy write-up follows one real case.
• A VLAN with a route. The player needs a route to the report server and, on the strictest sites, no route to the internet at all. Whether the management side needs the internet is a separate question: does an on-premise signage CMS server need internet answers it for the CMS.

How fresh can the numbers on the screen be?

Scheduled refresh caps the cadence at eight runs per day on a Pro workspace and 48 per day on Premium capacity, so 30 minutes is the fastest steady schedule, and anything fresher needs DirectQuery or a push dataset rather than a timer.

The caps are limits of the cloud service: eight a day is one run every 180 minutes, and 48 a day is 1440 divided by 48, exactly one run every 30 minutes. You set the schedule on the semantic model in the workspace, from the model's settings page in the service. Fresher than every 30 minutes takes the model out of the scheduler: DirectQuery queries the source at render time and a push dataset receives each new row as it lands, so the cap stops mattering.

Data freshness and screen rotation are two separate timers. The rotation interval lives on the player or playlist; the data cadence lives on the dataset. Keep the distinction in mind at a vendor demo: a report cycling every 10 seconds says nothing about the age of the numbers on it.

What does a worked example look like for one production line?

One line, three private reports (output, scrap, downtime), one player inside the plant network: 30 seconds per report gives a 90-second cycle, and DirectQuery keeps each report showing data no older than the historian's 15-minute poll.

Situation. One machining line, one screen at the line end, three reports behind a customer NDA that covers throughput. The historian polls the line every 15 minutes, and the plant manager wants the screen no staler than that.

Data check. A 15-minute refresh schedule needs 1440 ÷ 15 = 96 runs a day, past the 8 a Pro workspace allows and the 48 a Premium capacity allows. Scheduled refresh cannot carry 15-minute data in the cloud, so the honest choices are 30-minute data on Premium (1440 ÷ 48 = 30) or a DirectQuery model that queries the historian at each render, which no cap counts.

Security check. The NDA rules out the public link, and the plant's egress policy rules out a cloud render, so the decision falls to the in-network path: a player on the line VLAN, an on-premises report server at 10.20.4.11, HTTPS on 443 with a plant CA certificate, and frame headers set to allow the player origin.

Display check. Three reports at 30 seconds each give 3 × 30 s = 90 s per cycle, and the player's keep-mounted option holds each report's view loaded so nothing reloads or re-authenticates at each switch.

Result: data no staler than 15 minutes, a 90-second cycle, and no report byte off the plant network.

Which path should you pick for each case?

Pick publish-to-web only for dashboards with nothing confidential, the native integration when your screens already live on a managed cloud fleet, and the in-network player when production data is covered by an NDA or the network team will not grant egress.

Publish-to-web fits a count of safe days, a town-hall countdown, a summary with no names and no margins. The native integration fits private reports on a fleet the platform already manages, where granting the player outbound TCP 443 is a one-line firewall note. The in-network player fits audited networks, NDA-covered data and any plant where the screens must render off the LAN.

Recommendation: For production data on a factory floor, run an in-network player loading an internal report URL over TCP 443 with a certificate the player trusts, and keep the player on a VLAN with a route to the report server and none to the internet. Where the screens already live on a cloud-managed fleet, take the native Power BI integration with a service identity scoped to one workspace and row-level security on the rows that screen should show. Keep publish-to-web for reports that carry nothing private.

Three questions sort the vendors fast: does the integration mint per-report embed tokens and renew them server side, can a region load an internal URL, and does it keep a slide's view mounted while it is not visible, so the cycle never reloads. Harden the player either way: one credential set per screen, revoked the day it comes off the wall, and a locked-down player image, because a general-purpose hobby board on a default public image is a standing finding in security audits. For the rest of the screen questions, the shop-floor screens and andon-style boards category collects them, and the offline vs cloud signage guide settles the cloud-versus-on-premises question underneath all three paths.

Questions