Digital Signage Network Planning: IT Infrastructure Guide
Effective digital signage network planning prevents the most common deployment problems: screens that work in the pilot but fail at scale, unexpected bandwidth consumption, and security incidents from poorly segmented signage devices. This guide covers every infrastructure decision your IT team needs to make before deploying digital signage across an organisation.

Quick verdict
Put digital signage players on a dedicated VLAN. Use wired Ethernet for permanent installations. Calculate bandwidth requirements before deployment using the formula below. Document firewall rules for outbound signage traffic. These four decisions prevent the vast majority of signage network problems.
Step 1: Network segmentation (VLAN design)
Digital signage players should be on a dedicated VLAN, separated from your corporate IT network and any OT/production network. Reasons:
- Security, a compromised signage player (which has a broader public attack surface than a managed corporate device) cannot reach internal systems on a separate VLAN
- Traffic management, signage traffic (periodic content downloads, cloud CMS sync) can be QoS-managed independently from business-critical traffic
- Simplified firewall rules, a single VLAN allows you to write firewall rules once for all signage devices rather than per-device rules
- Management clarity, it’s clear which devices are signage players and which are corporate endpoints, simplifying asset management and incident response
Typical VLAN structure for a medium-sized organisation: VLAN 10 (corporate LAN), VLAN 20 (guest Wi-Fi), VLAN 30 (VoIP), VLAN 40 (digital signage). The signage VLAN requires outbound internet access to the signage CMS platform but should have no access to VLAN 10 or other internal VLANs unless a specific data integration requires it.
Step 2: Bandwidth planning
Signage bandwidth consumption depends on content type. Use this reference:
| Content type | Typical file size | Bandwidth per screen (sustained) |
|---|---|---|
| Static images (1080p) | 2–5 MB per image | Very low (images download once, play from local cache) |
| Video (1080p H.264, 30 fps) | 300–800 MB per minute | Low (downloads overnight/off-hours, plays from cache) |
| Live web content / dashboards | N/A (streamed) | 1–5 Mbps per screen (continuous stream) |
| Live data widget (REST API calls) | N/A (API calls) | Negligible (<100 kbps per screen) |
| CMS heartbeat / sync check | N/A (small requests) | Negligible (under 10 kbps per screen) |
The critical distinction: most signage content (images, video) downloads to local player storage and plays from cache, the bandwidth hit is a one-time download, not a continuous stream. Live web content and embedded dashboards are the exception, they require continuous bandwidth while displaying.
Practical bandwidth calculation for 50 screens:
- If 30 screens play cached video/image content: minimal sustained bandwidth, plus periodic downloads of 1–2 GB per screen per week = ~50–100 GB/week total download, off-peak
- If 20 screens display live Power BI dashboards or web content: 20 screens × 2 Mbps = 40 Mbps sustained during business hours
- Total: provision 50 Mbps dedicated uplink for this deployment with QoS to prioritise CMS management traffic
Step 3: Wired vs wireless
Use wired Ethernet for all permanent digital signage installations. Wi-Fi is appropriate only for temporary, flexible, or retrofit installations where cabling is not viable.
Reasons to prefer wired:
- Reliability, Wi-Fi connections drop intermittently; wired connections don’t (barring hardware failure)
- Bandwidth consistency, Wi-Fi throughput is shared and variable; wired is dedicated and consistent
- Security, Wi-Fi with strong encryption is acceptable, but wired on a dedicated VLAN is simpler to secure
- Troubleshooting, “the network cable is unplugged” is faster to diagnose than Wi-Fi signal issues
When Wi-Fi is acceptable:
- Content is static images or pre-cached video (not live web content)
- The access point is dedicated to signage devices on the signage VLAN
- The building has good Wi-Fi coverage at the screen location (>-65 dBm signal)
- The installation is temporary or in a location where cabling is genuinely impractical
Step 4: Power over Ethernet (PoE) planning
PoE simplifies signage installations by delivering power and network through a single cable. For small form-factor players (BrightSign HO523, Raspberry Pi with PoE HAT) and room booking panels (Evoko, Joan), PoE eliminates the need for a power outlet at each device location.
PoE standards to understand:
- 802.3af (PoE), up to 15.4W per port. Sufficient for Raspberry Pi 4, most room booking panels, and small Android players
- 802.3at (PoE+), up to 30W per port. Required for Raspberry Pi 5, some BrightSign players, and players with higher processing requirements
- 802.3bt (PoE++), up to 90W per port. Required for some higher-power industrial players and certain PoE-powered displays
Check the PoE budget of your switches before deploying PoE-powered signage at scale. A 48-port switch with a 400W PoE budget can supply about 26 ports at 15W each, a fully populated PoE signage deployment requires careful PoE budget planning.
Step 5: Firewall rules
Signage players on the signage VLAN need outbound internet access to your CMS platform. The required rules depend on your platform:
- Allow outbound HTTPS (TCP 443) to the CMS platform’s domains, required by all cloud platforms
- Allow outbound HTTP (TCP 80) for redirect handling and some content delivery networks
- Allow DNS resolution, signage players must be able to resolve CMS domain names; point DHCP to a DNS server that can resolve public hostnames
- NTP (UDP 123), players must synchronise time for correct content scheduling; allow outbound NTP to a public NTP pool or your internal NTP server
Most signage platform vendors publish a list of specific domains that players communicate with. Request this list from your vendor and create allowlist rules rather than open outbound access. This is better security practice and often required by enterprise security policies.
Step 6: Player remote management access
For troubleshooting, you need access to signage players on the signage VLAN from your management workstation. Options:
- Use your CMS platform’s remote management, most platforms support remote reboot, cache clear, and screenshot from the CMS dashboard without direct network access to the player
- For SSH access to Linux-based players (Raspberry Pi): add a management VLAN route or use a jump host on the signage VLAN
- For Windows-based players: Windows Remote Management (WinRM) or RDP via the management VLAN route
Step 7: Content delivery and CDN
Most cloud signage platforms use a CDN (Content Delivery Network) to serve content to players. Players download content from CDN edge nodes rather than from a central server, which improves download speed globally and reduces load on the CMS. This means your firewall rules need to allow connections to the CDN domains, not just a single CMS server IP.
For organisations in restricted network environments (financial services, government, defence), confirm with your vendor whether a private content delivery option is available, as public CDN access may not be permitted.
Documentation to create before deployment
- VLAN ID and IP range for signage devices (e.g. VLAN 40, 10.40.0.0/24)
- DHCP scope for signage VLAN
- Firewall rules document, source VLAN, destination domains/IPs, ports, protocol
- PoE budget per switch (used vs. available)
- Wi-Fi SSID and password for temporary/Wi-Fi signage devices (separate SSID from corporate)
- Player asset register, MAC address, IP, location, CMS device name, hardware model
Bottom line
Digital signage network planning is not complex but it needs to be done before deployment, not after. The four decisions that matter most: dedicated VLAN, wired Ethernet for permanent installations, bandwidth calculation with live content accounted for, and documented firewall rules. For platform-specific CMS requirements, see our buyer’s guide. For security hardening, see our digital signage security guide.