The FCC’s new Emergency Alert System cybersecurity rules take effect on September 29, 2026, and the immediate job for broadcasters is larger than replacing a weak password on an EAS encoder. The rule reaches EAS equipment, studio-to-transmitter-link gear, and remotely managed devices that route, process, or insert programming content—putting a meaningful slice of a station’s operational technology under new security obligations.

A Nautel webinar covered by Radio World lays out the practical issues station engineers will face before that deadline: inventorying remotely accessible equipment, changing default credentials, applying security patches, and placing exposed systems behind a firewall or comparable network segmentation. The webinar’s useful message is that these are no longer merely sound engineering recommendations. They are baseline FCC requirements with enforcement consequences if a compromised station transmits unauthorized content or false alert tones.

The regulatory record adds an important clarification to the webinar’s discussion. The firewall requirement is not limited to the EAS appliance itself, but neither does the text literally require every device on a broadcaster’s entire internal network to sit behind one monolithic firewall. FCC rule 47 CFR § 11.35(d) covers EAS equipment, STL equipment, and any remotely managed equipment that affects the programming stream. That distinction should drive a targeted remediation project rather than a vague, expensive “secure everything” exercise.

High-tech broadcast control room with transmitter racks, cybersecurity displays, monitoring screens, and official documents.The FCC rule turns basic hygiene into a compliance obligation​

FCC 26-38, adopted June 25 and published in the Federal Register on July 31, requires EAS Participants to take three specific actions. First, they must change default passwords before equipment is used to broadcast; passwords must be at least 15 characters, must not include dictionary words, and cannot be reused across the participant’s other accounts, systems, applications, or services. The rule also permits alternative authentication methods that offer reasonably sufficient protection, including certain multi-factor or cryptographic approaches.

Second, stations must promptly test and install manufacturer-issued security patches and security-related firmware or software updates. The Commission allows testing before deployment, but testing has to start promptly and conclude within a time consistent with industry practice. That language gives operators room to avoid breaking an on-air chain with an untested firmware update, but it does not support indefinitely deferring patches because an appliance is inconvenient to take offline.

Third, participants must use a network firewall or comparable segmentation practice to limit remote management to authorized devices and users. The FCC explicitly identifies alternatives such as VLANs, demilitarized zones, and physically isolated management networks. In practical terms, an EAS unit or broadcast processor should not be reachable through a public-facing web management interface simply because remote engineering access is convenient.

The Commission’s own rationale makes clear why it chose prescriptive controls. The order describes repeated compromises in which attackers accessed improperly secured, remotely reachable equipment and transmitted unauthorized audio, false EAS tones, offensive material, or promotional content. The immediate security failure may be a weak password or an unpatched device, but the operational failure is usually architectural: a sensitive appliance was reachable from the public internet without adequate access controls.

“The program chain” needs an accurate inventory​

The webinar featured Nautel’s Jeff Welton, broadcast attorney David Oxenford, and Cumulus Media San Francisco chief engineer Shane Toven. Their emphasis on firewalls, credential changes, VPN access, and segmentation is directionally right, but the first practical task is establishing which equipment actually falls inside the FCC’s defined scope.

For many stations, the answer will include more than a rack-mounted EAS encoder/decoder. It can include STL equipment, remote-access transmitters, audio processors, codecs, automation-adjacent systems, IP switching or routing gear, and control interfaces used to insert or manipulate programming. If the device is remotely managed and can route, process, or insert content into programming, treating it as ordinary office IT is a mistake.

That does not mean that every workstation, newsroom computer, business server, or printer becomes an EAS-regulated device. But it does mean that a flat network shared by office users, production workstations, automation systems, EAS devices, and transmitter controls deserves urgent scrutiny. A malware infection on a user network does not have to directly target the EAS unit if it can laterally reach administrative credentials or a management interface.

The rule therefore rewards documented network boundaries. A station should be able to show which devices comprise its protected broadcast-management segment, which systems are permitted to administer it, which ports and protocols are necessary, and how off-site engineers authenticate. A firewall purchased at a retail store may be better than direct internet exposure, as Toven suggested during the Nautel session, but a default configuration with broad inbound rules, universal administrator access, or a permanently exposed remote-desktop service will not meet the underlying security objective.

Password requirements are stricter than a routine reset​

The 15-character requirement is more specific than the broad “strong password” policies found at many small stations. The FCC also bars reuse of the password across other accounts, equipment, applications, and services. An engineer cannot satisfy the rule by assigning one long shared password to the EAS appliance, transmitter web interface, VPN, automation server, and a vendor support portal.

The alternative-authentication provision is significant for IT teams with mature identity systems. The FCC’s final text permits measures such as one-time-password devices, out-of-band authentication, and single- or multi-factor cryptographic authentication when they reasonably mitigate unauthorized access. That gives larger operators a path to stronger controls than static passwords, while smaller stations can still comply with unique credentials and properly restricted network access.

The hard part is not setting a compliant password once. It is controlling the lifecycle around it. Shared engineer accounts, contractor access, inherited credentials, vendor support accounts, former employee access, and credentials written into browser password stores all create exposure that can persist long after a station believes it has completed a reset.

A useful immediate control is to create named administrator accounts wherever the platform allows them, reserve a separate break-glass account for an outage, and document who holds recovery information. Systems that only support a single local administrator account need compensating controls: password-vault access, change records, a tightly restricted management network, and a process that forces credential changes when staff or vendors change.

Patching will expose unsupported equipment problems​

Radio World reported that Oxenford cited FCC data from the 2023 nationwide EAS test showing that 23% of equipment units—representing roughly 4,500 participants—ran outdated software or hardware no longer receiving regular updates. Whether or not that exact figure maps cleanly to a particular station’s equipment fleet, the FCC’s rule creates a serious problem for owners of end-of-life devices: “promptly install” is easy to say when a vendor still issues a patch and impossible to do when it does not.

The final order deliberately stopped short of requiring wholesale replacement of obsolete equipment. The FCC abandoned broader proposed risk-management mandates and did not impose a general end-of-life replacement requirement. That is meaningful relief for small broadcasters facing capital constraints.

It is not a safe harbor for ignoring a device that cannot be patched. An unsupported device connected to the public internet, especially one that can influence programming or EAS delivery, remains a foreseeable operational risk. If no patch is available, the defensible remedy may be isolation: removing direct internet reachability, limiting administration to a dedicated management network, allowing access through a VPN with multi-factor authentication, disabling unused services, and restricting traffic to the precise internal hosts and ports needed.

Operators should also distinguish ordinary feature updates from security-related firmware and software releases. The FCC’s requirement concerns security patches and security-related updates issued by the manufacturer. A change-management process should record the vendor notice, testing date, deployment decision, rollback plan, and reason for any delay. That record is valuable both for avoiding an outage and for demonstrating reasonable compliance after an incident.

Prepare for incident review, not routine network inspections​

Oxenford’s point in the Nautel webinar—that the FCC is unlikely to proactively probe every broadcaster’s network—is realistic. The Commission does not need to scan every station to enforce the rule. A compromised airchain, a false EAS transmission, an investigation following a complaint, or evidence of exposed management infrastructure can put a station’s security practices under scrutiny.

The FCC’s order was prompted by a history of systems being hijacked to send false alerts or unauthorized material. In that context, the likely enforcement question after an incident is straightforward: did the participant change default credentials, apply available security updates, and restrict remote administrative access using a firewall or equivalent segmentation?

That makes evidence part of the technical work. Stations should retain an equipment inventory, supported-version status, network diagrams, firewall rule reviews, account lists, patch logs, remote-access procedures, and records of credential changes after staff departures or suspected compromise. These are not paperwork substitutes for security controls. They are the proof that controls existed before a problem appeared.

The deadline is now close enough that broadcasters should stop treating EAS security as a narrow engineering task. By September 29, the station should know what can remotely affect programming, who can administer it, whether each device remains supported, and whether public internet access has been removed or tightly controlled.