Station Compliance›Field Notes

If you have deployed ATSC 3.0, or you are planning to, the question worth asking about the September 29 security deadline is not whether 3.0 brings extra obligations. It does not. The question is how much more the same three requirements are protecting.

The regulatory position, stated plainly

When the Commission authorised ATSC 3.0 as the next-generation broadcast television standard, it required 3.0 broadcasters to comply with the EAS rules. That has been settled since the authorisation, and § 73.3801 carries the simulcast obligations that sit alongside it.

§ 11.35(d) then applies to every EAS Participant without distinction — no separate 3.0 rule, no separate date, no exemption for a facility mid-transition. Strong passwords, prompt patching, and a firewall or comparable network segmentation limiting remote management access, by September 29, 2026.

So the compliance answer is short. The engineering answer is not.

Why the third requirement matters more here

A legacy plant has a limited number of network-connected devices, and the video path between them is baseband or transport stream over dedicated links. A 3.0 plant is IP from end to end: the gateway, the scheduler, the broadcast core, the links to the transmitter, and the management interfaces on all of it.

That means:

• More devices sit inside the scope language. "Routes, processes, or inserts content into the transmission" describes most of a 3.0 signal chain.
• More of them speak IP natively, so they are reachable by anything else on the same network by default rather than by exception.
• The studio-to-transmitter path may be IP, which is explicitly named in the rule as studio transmitter link equipment.
• More equipment is remotely managed, because that is one of the operational advantages of the architecture.

None of this is a criticism of 3.0. It is the point of 3.0. But a requirement to limit remote management access to authorised devices and users is doing considerably more work in a plant where nearly everything is remotely manageable.

What the Commission is proposing next

The Further Notice attached to the same order — the half nobody reads — proposes allowing EAS capabilities to be implemented in software instead of hardware. For television that is potentially significant, and it points directly at 3.0-style architectures.

The Commission is not naive about the tradeoff. Its own reasoning notes that unlike physical devices, software platforms have large attack surfaces including APIs, databases and remote interfaces, and that EAS software may be more prone to cyberattack by virtue of its IP interconnectedness. It also tentatively lands on a 72-hour figure in the context of resilience against ransomware and other attacks.

Read that as a signal about direction. Any future software-EAS rule will come with security conditions attached, and those conditions will look like § 11.35(d) with more teeth.

Which means the segmentation work you do this month is not a one-off. A station that can demonstrate a properly segmented plant is a station positioned to adopt whatever comes out of that docket. One that cannot will find the door open and be unable to walk through it.

Nothing in a Further Notice is a requirement, though, and proposals change substantially between notice and order. Do not buy anything on the strength of one. The full rundown of what was proposed is here.

What to actually do

1. Inventory the 3.0 chain as program chain equipment, because that is what it is. Gateway, scheduler, broadcast core, encoders, and the IP links between them.
2. Separate management from transport. Management interfaces on their own segment, reachable only through a VPN or a jump host, is the cleanest way to satisfy the third requirement in an IP-native plant — and it is easier to state and demonstrate than a pile of firewall rules.
3. Check what your vendors ship as defaults. IP-native broadcast equipment frequently ships with management interfaces enabled on all ports and default credentials, on the assumption it lands on a trusted network.
4. Confirm the patch path exists before you need it. Ask each vendor, in writing, how security updates are distributed and what their support window is. The rule requires prompt installation of security patches; a vendor with no mechanism to deliver them is an exception you should document now rather than discover later.
5. Do not forget the simulcast side. If you are running 3.0 alongside an ATSC 1.0 simulcast, both signal paths carry the same obligations, and the 1.0 chain is the older one with the older passwords.

The short version

ATSC 3.0 changes nothing about what § 11.35(d) requires and a great deal about what it is worth. The station getting the most out of this deadline is the one with the most IP in its air chain, which is precisely the station that finds the work largest.

The TV scope guide covers the full television equipment list, and the rule reference covers the three requirements in detail.