Does an on-premise signage CMS server need internet

What the server needs, and what it must not have

Three requirements, all internal:

• A gigabit LAN port. One on-premise CMS vendor names a gigabit network connection in its published server requirements. Give the server that class of port, because content pushes to the fleet are the heaviest traffic your LAN carries.
• Listeners from the players only. The same published requirements ask for TCP 80 and TCP 443 coming in from players for content and administration, plus UDP 123 if the server also serves network time. Your vendor's install guide lists its exact set.
• No default route. The on-premise licensing module manages the player licenses, but the validation sessions the vendor counts are the players' own, so the server has no reason to send a packet to the internet. Leave the gateway field empty or pointed at an internal router with no uplink, and create no outbound rule for the server's address.

Keep the list of listeners closed to the player VLAN and the admin workstations. A path from the internet to the server that holds the whole signage estate is attack surface, and licensing gives you no reason to open one.

One exception exists: a vendor whose on-premise module phones home from the server for administration or content. At least one on-premise vendor publishes a stable server internet connection as a requirement, so the requirements page for the module you bought decides which side talks out. Under the license-per-player model this page describes, the shape above is the one that works.

What the players need from the internet

Each player validates its own license, direct to the vendor's licensing endpoints. The floor the vendor publishes is one successful check inside every 30-day window, and the check is HTTPS, so the firewall rule reads: player VLAN to the licensing hostnames, TCP port 443, outbound, nothing else.

The hostnames come from the vendor. Every CMS that works this way publishes its player licensing requirements with the endpoint list included, so ask for that document by name and copy its hostnames into the rule. Two things travel with HTTPS and fail quietly:

• DNS. The player has to resolve those hostnames. If your internal DNS refuses to forward the licensing domains, an open TCP 443 changes nothing.
• The clock. A TLS certificate check fails on a clock that is far off, and a player with no internet cannot reach a public time server. Point the estate at your own NTP source on UDP 123 and the certificate checks pass for the right reason.

Where the content flows

Content never crosses the internet in this design. A player pulls its playlist and media from the server's LAN listener, so the transaction starts and ends inside the building. When those LAN downloads break, the symptom is missing media on screen, not a license alarm. The page on CMS media downloads failing behind a reverse proxy walks through that failure, and serving LAN share images to a web app safely covers the serving side.

A worked example: the firewall rule for 12 players on a 30-day clock

Inputs, with their sources:

• 12 Android players. The deployment's own size; substitute your fleet count.
• 1 successful license check per player per 30 days. The vendor's published licensing floor.
• TCP port 443 outbound. The HTTPS port the checks ride on.
• TCP 80, TCP 443 and UDP 123 coming in on the server, and a gigabit LAN. One on-premise vendor's published server requirements.

The rule in words: every player must complete one successful outbound HTTPS session to the licensing endpoints inside every 30-day window, and the server completes none, because it has no outbound path.

Arithmetic:

• Fleet floor: 12 players x 1 check per 30 days = 12 successful checks per 30 days across the fleet, an average of 12 / 30 = 0.4 checks per day.
• Alarm line: 30 days / 2 = 15 days. A player with no successful TCP 443 session in the firewall log after 15 days is halfway through its window with zero successes, and 15 days remain to fix DNS, a stale hostname or a moved endpoint before the floor is missed.
• Rule count: 1 outbound rule, players to licensing hostnames on TCP 443, plus 0 rules for the server. On the LAN side, 3 listeners on the server: TCP 80, TCP 443 and UDP 123, from the player VLAN only.

Result: the estate runs on one outbound internet rule and three LAN listeners.

Decision: if every player's log shows a TCP 443 hit inside each 30-day window, the design meets the published floor. If any player passes day 15 with no hit, raise it. If it passes day 30, the floor is missed and what happens next belongs to the vendor's enforcement policy. If the customer refuses any outbound path at all, the design cannot meet the floor, and the screens move to players with no license server.

When a player misses its window

What the player software does at day 31 is the vendor's decision, so ask it at purchase, before a branch depends on the answer. The pattern is real elsewhere: the automation runtime TwinCAT is documented to stop every 30 days on Beckhoff I/O PCs, and why TwinCAT stops every 30 days on Beckhoff I/O PCs shows what a hard license clock costs when it cannot renew. Treat day 30 as a hard date and let the day-15 log line be the alarm that keeps you off it.

When no outbound path is allowed at all

Some security teams refuse every internet path, players included. A license-checked player cannot meet a 30-day floor on such a network, so the honest choices are two: ask your CMS vendor whether they offer an offline licensing arrangement, or move those screens to players with no license server in the loop.

A card-fed player sidesteps the question. Our lobby displays run the free IMD Signage Player, which plays JPG and MP4 content straight from a microSD card or USB stick with no network and no subscription, keeps a copy in internal memory so the show carries on if the card comes out, and syncs, if you want it, over HTTPS to your own web server on a timer. For the occasional content change on a screen with no network, updating an offline signage screen with a phone hotspot is the practical route. The wider choice between a cloud-only player and an offline one is covered in the digital signage player guide.

The decision

Recommendation: Keep the CMS server off the internet: no default route, and incoming TCP 80, TCP 443 and UDP 123 from the player VLAN only. Give the players one outbound rule, TCP 443 to the licensing hostnames from the vendor's player licensing requirements document, and alarm at day 15 of the 30-day window. If the customer refuses any outbound path at all, stop trying to satisfy the license floor and move those screens to card-fed players with no license server.

Questions