Why credentials on screens are a risk
A screen sits in a lobby, a branch or a shop floor, often unattended, and it has to keep showing data that lives behind a login. The usual shortcuts each leave the credential somewhere it can be taken: a shared account signed in on a browser, a token pasted into a URL, a password typed into a page by a script. Anyone with a moment alone at the device, or with access to the dashboard, can read it.
How Screenly keeps them safe
Six measures, each for a different kind of screen and source. Most screens use two or three of them together.
- 01
Secrets are encrypted for one device
Applies to: All screens
Anything sensitive an app needs, such as an API key or a password, is stored as a secret. A secret is encrypted for a single device, so it cannot be decrypted on any other; it is write-only once saved, so nobody can read it back in the dashboard, other administrators included; and it is decrypted only on the device that owns the app instance, never appearing in the page source.
Settings and secrets - 02
The device key lives in hardware
Applies to: ScreenlyOS devices with a TPM
On devices running ScreenlyOS that have a TPM, such as Screenly Player Max, the device key is held in the TPM, a chip that keeps it on the board. On other hardware the key is a device-specific certificate on disk, so a secret encrypted for one device still cannot be decrypted on another.
- 03
Services are connected once, not pasted into screens
Applies to: All screens
Dashboard and calendar apps read from services such as Power BI, Grafana, Salesforce, Google Calendar and Outlook. Screenly holds the connection for the whole workspace, so every app that reads from a service uses that one connection. Nobody pastes a token into a screen.
Connected services - 04
Devices prove who they are
Applies to: ScreenlyOS
ScreenlyOS players talk to Screenly over mutual TLS: every ScreenlyOS device holds a client certificate, and the player and the server each prove who they are before anything is exchanged. Your own servers can ask a screen for the same proof, so an internal page or dashboard opens only for your screens and for no other device.
Client certificates - 05
Screens reach your private network without opening it
Applies to: ScreenlyOS
Some content is not on the public internet at all: an internal dashboard, an intranet page, a rates service behind the firewall. With Tailscale on screens, ScreenlyOS players join your own Tailscale network and reach those services the way your own machines do, without exposing anything publicly.
Reaching your private network - 06
Where a device cannot keep a secret, the secret stays with us
Applies to: The Screenly app on TVs, sticks and browsers
Some screens run the Screenly app rather than ScreenlyOS: a Samsung, LG or Android TV, a streaming stick, or Screenly in a web browser. Those devices cannot keep a secret safely, so a page or app that needs credentials is rendered on Screenly's servers, and the screen receives only the picture. No credential reaches the device. The trade-off is that the picture needs the connection to update.
Screenly on TVs, sticks and browsers
Which to use
Each kind of source has a way to reach it without a password sitting on the screen.
| What the screen shows | Use |
|---|---|
| Data from an API that needs a key | An app, with the key stored as a secret |
| A dashboard in Power BI, Grafana or Salesforce | The app for it, through a connected service |
| An internal page your server can check | A web page with the client certificate sent (ScreenlyOS) |
| A service on your private network | Tailscale on screens (ScreenlyOS) |
| Anything sensitive on a TV, a stick or a web browser | The Screenly app, which renders it on our servers |
Questions
Can someone read a password off a screen?
Not one stored as a secret. Secrets are decrypted only on the device that owns them, never shown in the page source, and cannot be read back in the dashboard.
Do credentials ever appear in a URL?
They do not need to. Apps take credentials as secrets, connected services hold the connection for the workspace, and web pages can be checked with the device's client certificate instead of a token in the address.
What happens to the secret if a player is lost?
A secret is encrypted for that one device, so it cannot be decrypted on any other.
Is all of this on every screen?
Secrets and connected services work on every screen. The TPM is used on ScreenlyOS devices that have one, such as Screenly Player Max; client certificates and Tailscale are on ScreenlyOS, and on TVs, sticks and web browsers the Screenly app renders pages and apps on our servers, so credentials never reach a device that cannot hold them.