Barry Mishkind

The Broadcasters' Desktop Resource

Worldcast-2

The FCC Cybersecurity Order & NPRM

Barry Mishkind author

By Barry Mishkind

[July 2026] The FCC has become very aware of the increasing attacks on broadcasters, and proposes to “harden” broadcasters IP activities. An example of how important it is, the initial requirements are set to go into effect just 60 days after the publication in the Federal Register. What do you need to know?

After the law was put into place in 2006, the FEMA began to build the Integrated Public Alert and Warning System (IPAWS) to expand Department of Homeland Security (DHS) control and responsibility over a large part of the EAS. 

By 2010, a heavy emphasis on cybersecurity was announced, and the FEMA required EAS receiver manufacturers include security protocols and data certificates as part of EAS. The FCC announced that Part 11, the basis for EAS would be re-written “very soon.”

PLUGGING THE DIKE

On February 11, 2013, the “zombie alert” (warning Americans that “the bodies of the dead are rising from their graves and attacking the living.”) showing rather dramatically that there were still “holes” in the system that needed attention. 

Not only were there many EAS receivers installed that were clearly identified on web search sites such as Shodan, but they continued to use default passwords and allow other vulnerabilities to exist – most stations considered EAS operations to be a burden and gave it little thought after installation. 

Manufacturers struggled, providing updates that many stations did not bother to install. They sought to add features that would make the use of the EAS more effective and palatable to listeners and viewers of broadcast stations. 

Groups like the Broadcast Warning Working Group (BWWG) tried to advertise the problems and offer solutions, filing comments with the FCC and offering help to stations seeking to “harden” their security.

Nevertheless, periodic issues arose, from announcers using old YouTube audio to spark fake EAS alerts to occasional hacks that interrupted codecs used for STLs. 

The FCC is finally closing the loophole that allowed that to happen.

RECENT HACKS

In the recent six to eight months, there have been a spate of attacks on broadcasters, both in the US and abroad. 

Someone, or a group, have been breaking into stations from Washington DC to Wyoming, from Houston to Detroit, and in Europe and other places. After accessing the program audio or RDS data streams, extremely rude, even pornographic announcements and audio were broadcast – in one case for no less that 36 hours before the station took the audio down!

Although not all of these hacks have been reported to the FCC by the stations involved, most of them have become known one way or another. Some were reported to the FBI and there was a report that a person had been arrested by the FBI. 

FCC RE-ENTERS THE ISSUES

Meanwhile, ever since promising a Part 11 re-write, the FCC has been fairly quiet about things. But with the increasing hacks, recent Public Notices indicate there is now a strong desire to secure the program and RDS chains. 

The current result is the Order and Notice of Proposed Rulemaking (NPRM). We can divide its contents into two parts: the Order and the NPRM.

Stations need to understand that there is an expressed urgency – and a limited period for them to comply.

THE ORDER

The main objective is make secure any station equipment accessible via the Internet in any way.

There are three main aspects addressed by the FCC Order; the relate immediately to EAS equipment:

  1. Passwords: All passwords in use by a broadcast facility must be “strong” and unique – defined as at least 15 characters, with no dictionary words included. Furthermore, if there is an actual risk – or a perceived one – of the gear being accessible by other than station personnel, such passwords should be changed immediately. 
  2. Mandatory Patching: The FCC pointed out that “reports from the 2023 Nationwide EAS test found that about 23% of EAS equipment was either using outdated software or operating equipment that was no longer supported with regular software updates.” In order to prevent intrusions to the air chain through outdated or broken units, any updates or code patches to EAS gear must by installed quickly. While “quickly” is not immediately defined, if the FCC senses broadcasters are delaying, it may act “quickly” to inspect and issue fines. 
  3. Firewalls Required. Not just EAS, but all programming equipment connected in any way to the Internet must be behind a network firewall – the exact method is not specified at this point – but, for example, broadcasters need to isolate EAS (any other critical gear in the air chain) from any general purpose local area network so that they are not accessible directly from the Internet. This means all internal users, such as traffic and bookkeeping, etc. 

In plain English, all EAS equipment connected to the Internet must: 

  • * use passwords of 15 or more characters.
  • * operate with the most updated firmware.
  • * be behind properly installed and configured firewall.

RAPID IMPLEMENTATION REQUIRED FOR ALL

These measures must be put into place quickly – within 60 days of the order being published in the Federal Register – even though there are already comments that this is going to be too costly for a lot of smaller stations, many of which have no real IT-oriented staff. 

The FCC acknowledged that problem, but ended up concluding the minimal requirements adopted in this Order are needed to make sure that all broadcasters have at least some security practices in place, saying “we do not expect that this will be burdensome or time-consuming for EAS Participants to identify because firewalls are widely recognized as a basic and cost-effective cybersecurity safeguard appropriate even for organizations with limited resources.”

In other words: “this is happening. Just get it done.” 

Although the clock has not started yet, it is likely to happen very soon. Small stations and groups especially should make plans right now to implement the requirements – before the FCC comes looking and asking questions. Station engineers are encouraged to verify the firmware version of the their EAS units (DASDECs should be version 5.4 or higher and Sage endecs should have version 96.00 or higher).

THE NPRM

With the immediate requirements out of the way, the FCC then asks for comments on various proposals they think may lead to better operation and use of the EAS. 

To get everyone started, the FCC is proposing, among other things:

  • Requiring Message Authentication: Before alerts are transmitted, better authentication needs to be made.
  • Killing “Alert Fatigue” (Duplicate Phone Alerts): Currently, if you get an alert on your phone and then drive into a new cell tower’s range, or your phone drops from 5G to 4G, your phone might blare the exact same alert again. The FCC proposes a “Universal Alert Message ID” (UAMID) acting as a unique fingerprint. If your phone sees an alert it has already shown you, it will silently suppress the duplicate.
  • Constant 60-Second Re-Broadcasting: The FCC wants to force cell carriers to re-broadcast active alerts every 60 seconds. This ensures that if you drive into a disaster zone 15 minutes after the initial alert was sent, your phone will instantly go off.
  • Software: The FCC is proposing to allow broadcasters to use EAS software on their existing servers. The question remains if it is possible to have a manageable system that is as secure and reliable as the current hardware systems.
  • Mandatory Digital Signatures: To prevent bad actors from spoofing government agencies, all Internet-based EAS messages will need to use a valid cryptographic digital signature to be broadcast. If it lacks a signature, stations will automatically reject the fake alert.
  • The “Forced Location” Privacy Compromise. Right now, cell alerts are supposed to be targeted to a 0.1-mile radius of an emergency. But if you have Location Services turned off on your phone, you might get blaring alerts for a county hundreds of miles away. The FCC proposes a wild technical workaround: when an emergency alert hits your phone, your phone will temporarily force its location services ON, even if you disabled them. (To protect privacy, the FCC proposes a strict rule that the location data can only be used for that exact moment to see if you are in the danger zone, said location cannot be transmitted off the device, and it must be deleted immediately.
  • Text-to-Speech for Earthquakes. Because earthquakes happen with zero notice, every second matters. The FCC proposes that earthquake alerts bypass the standard beep-and-read method and instantly trigger Text-to-Speech. This way, your phone would loudly announce: “Earthquake! Expect shaking. Drop, Cover, Hold On!” so you can dive under a table without having to pull your phone out of your pocket.
  • Retiring 90-Character Alerts. During the flip-phone era, emergency managers had to write two versions of an alert: a modern 360-character one, and a backup 90-character one for 2G/3G networks. The FCC is officially proposing to retire the 90-character requirement, saving emergency managers precious time during a crisis.
  • Visual Symbols / Emojis for Non-English Speakers. The FCC is exploring a requirement for universal, standardized visual symbols or icons to accompany text alerts on your phone and TV (e.g., a standardized tornado, fire, or flood graphic). Studies show this drastically speeds up comprehension for people with limited English proficiency or reading disabilities.
  • Custom Local Names (The “Key West” Rule). Currently, older TV/Radio alerts use rigid, clunky county codes based on the National Weather Service (NWS) FIPS codes. For example, an alert might say “Southwest Monroe County” instead of “Key West,” confusing tourists and locals alike. The FCC is creating a streamlined process for local authorities to request custom, easily recognizable geographic names for their alerts.

EAS AT A CROSSROADS

As noted, this is a major update for the EAS. It may or may not make the EAS better and more valuable to broadcasters.

One thing is certain: as has long been pointed out, unless the Owners/General Managers and Program Directors buy in to the EAS and help make it fit into their operations, the EAS will remain crippled in many emergency situations. 

  • For example, stations can and should ask the FCC to do something similar to the Killing “Alert Fatigue” idea above. By using a UAMID, stations could stop NWS message flooding as storms roll through an area. 
  • This could pertain to the location of alerts. For example, stations can and should ask the FCC to have the NWS is city names, not county names, as the core of any alert. And, just as with cellphone alerts, drivers on the highways often have no clue as to the county name. But “15 miles West of Springfield” might give drivers time to act for safety. 
  • The current “voluntary” aspect of Emergency Managers cooperation should be strengthened so emergency alerts get to broadcasters quickly and clearly. 

You may think of other ways to salvage the EAS that is misused or ignored is so many places. Get your comments ready, and let the FCC know how the EAS can serve  your station(s) and the public.

Do not let another 15 years go by to strengthening what could be a valuable tool for making broadcasters essential to local audiences.

– – –

Would you like to know when more articles like this are published? It will take only 30 seconds to
click here and add your name to our secure one-time-a-week Newsletter list.
Your address is never given out to anyone.

 

Return to The BDR Menu