What a network team worries about
A signage player is often the least managed device on a network. The questions are what it needs to reach, whether anything can reach it, how it proves it belongs on the network, and what a compromised one could get to. Each has a short answer below, and the hardening guide covers the settings on your side.
How a screen uses your network
- 01
Outbound only
Screens make outgoing connections only, on ports 443, 123 and 53. No inbound rule, no port forwarding and no per-IP limit: any number of screens can sit behind one public address.
What the network needs - 02
An allowlist of hostnames
On a filtered network, allow a short list of hostnames for Screenly and, on ScreenlyOS, for Ubuntu Core. Allow the names, not their addresses: the service sits behind Cloudflare and the addresses change. Screenly's domains use DNSSEC.
Hostnames and ports to allow - 03
Mutual TLS to the cloud
Applies to: ScreenlyOS
Traffic between a device and Screenly is encrypted, and both sides prove who they are before anything is exchanged. On a device with a TPM, the private key is kept in it.
- 04
A certificate for your own servers
Applies to: ScreenlyOS 26.2.0 and later
Every device has its own certificate, signed by the Screenly certificate authority. Your server, CDN or load balancer can require it, so an internal page opens for your screens and is refused to everything else on the network.
How credentials stay secure - 05
802.1X network access
Applies to: ScreenlyOS
Devices authenticate to 802.1X networks with PEAP, over Wi-Fi and wired Ethernet. Certificate-based 802.1X (EAP-TLS) is not supported yet.
- 06
Your private network, nothing exposed
Applies to: ScreenlyOS
Devices can join your Tailscale network, set up once for the workspace, and reach internal pages and private APIs without anything being opened to the internet.
- 07
Its own VLAN
Screenly assumes its devices sit on a hostile network. Putting them on a VLAN that allows only outbound connections limits the other direction: what a compromised device elsewhere could reach.
What is not supported
Stated plainly, so your design does not depend on it.
| Topic | What to do instead |
|---|---|
| A proxy for all outbound traffic | ScreenlyOS cannot route through a proxy; give the devices an exception. The Screenly app uses the proxy of the device it runs on |
| Certificate-based 802.1X (EAP-TLS) | Use PEAP, or a VLAN for the screens |
| An air-gapped network | Screenly needs an outbound connection. Screens keep playing through an outage, but changes wait for it |
Questions
Do we need to open any ports?
No. Screens connect outbound only. The one optional inbound connection is Prometheus metrics on port 9100, from your own monitoring to a ScreenlyOS device, and it is off by default.
Is traffic between the device and the cloud authenticated?
Yes, ScreenlyOS devices use mutual TLS. On devices with a TPM, the key is kept in the TPM.
Can devices join a network that requires 802.1X?
Partly. ScreenlyOS devices join 802.1X networks with PEAP over Wi-Fi and Ethernet. Certificate-based 802.1X (EAP-TLS) is not supported.
Can our internal pages be served only to our screens?
Yes. A ScreenlyOS device presents its own certificate when it loads your pages, so a page can refuse anything else.
Do screens keep playing when the network goes down?
Yes. ScreenlyOS devices keep playing what they hold and switch playlists on schedule, and restart their own networking or reboot if contact with Screenly does not come back.