FCC Proposals on Modernizing EAS: Where Industry Agrees …. and Where It Doesn’t

By Edward Czarnecki, Ph.D.

[September 2026] The FCC record shows an industry ready to strengthen emergency alerting—but wary of reforms that could exchange familiar limitations for new and less visible points of failure.

As the deadline for comments to the FCC’s latest EAS proceeding on modernizing EAS draws here, here is a rundown of industry positions from the first round of comments to the proceeding (footnote: Modernization of the Nation’s Alerting Systems; Protecting the Nation’s Communications Systems from Cybersecurity Threats; Wireless Emergency Alerts; Amendment of Part 11 of the Commission’s Rules Regarding the Emergency Alert System, FCC 26-38, Report and Order and Further Notice of Proposed Rulemaking, PS Docket Nos. 25-224, 22-329, 15-91, and 15-94 )

Emergency alerting systems are not judged by how efficiently they operate on an ordinary day. They are judged by whether they still work during the wildfire, hurricane, cyberattack or communications outage that has already disrupted everything around them.

That reality runs through the record in the FCC’s latest Emergency Alert System modernization proceeding. Broadcasters, cable operators, equipment manufacturers and public-media organizations generally support stronger security, more accurate targeting and greater operational flexibility. But the industry’s center of gravity is equally clear: modernization should be technically mature, backward-compatible and demonstrably resilient before it becomes mandatory.

CYBERSECURITY: THE CLEAREST CONSENSUS

Cybersecurity offers the strongest area of agreement. Commenters including the National Association of Broadcasters, NCTA, Sage Alerting Systems and the AWARN Alliance support closing the gap that permits unsigned Common Alerting Protocol messages to enter some EAS workflows.

The industry appears comfortable with requiring valid digital signatures for CAP alerts, provided the transition includes workable certificate management, actionable failure notifications and the ability to authenticate alerts when internet connectivity is unavailable. Security cannot create a new dependency on a live network precisely when communications infrastructure may be impaired.

Securing legacy EAS is more complicated. Broadcasters and cable operators remain concerned about cost, transmission delay and compatibility with NOAA Weather Radio and installed receivers. The emerging position is not to abandon legacy security, but to develop and test a backward-compatible standard before imposing a mandate.

Authentication of defined EAS header information must also be distinguished from the more difficult—and potentially impractical—task of authenticating an analog audio waveform.

The most fully developed proposal in the proceeding so far addressing both legacy EAS security and message identity is the EAS Data Extension, or EDX. Proposed by Digital Alert Systems, EDX would be a open, non-proprietary supplemental data layer that leaves the existing EAS header unchanged. It could carry authentication information, a unique message identifier and evidence that a legacy alert originated from authenticated CAP. Updated equipment could use these capabilities while existing receivers continue operating normally, providing a path to stronger legacy security without abandoning installed infrastructure.

PRESERVING ALERT IDENTITY

A unique alert identifier more broadly receives qualified support. Many commenters see value in preserving an alert’s identity as it moves among CAP, EAS, NOAA Weather Radio and newer digital platforms. Such an identifier could help equipment distinguish a duplicate from an update or cancellation.

The difficult question is what the identifier represents. An incident may generate several legitimate messages. A workable standard may therefore need both a persistent incident or alert-thread identifier and a separate identifier for each revision.

Broadcasters do not want automated duplicate suppression to discard an expanded evacuation order, revised warning area or cancellation. An identifier also must be authenticated; otherwise, a fraudulent or corrupted identifier could itself become a means of suppressing a valid warning.

IMPROVING GEOGRAPHIC ACCURACY

On geographic accuracy, the industry generally supports allowing EAS equipment to use CAP polygons and circles when deciding whether to relay an alert. NAB, NPR, Sage, NCTA, America’s Public Television Stations/PBS and AWARN largely favor permissive rather than mandatory use.

Their filings also emphasize a physical limitation: a conventional radio or television signal cannot stop at the boundary of an alert polygon. CAP geometry can improve station, channel or output selection, but that is not the same as geofencing individual receivers.

More precise reception will depend on location-aware digital technologies, including advanced television services. In the meantime, CAP geometry can still help broadcasters avoid transmitting clearly irrelevant alerts, provided filtering rules account for coverage areas, downstream monitoring assignments and the risk of excluding audiences near a polygon boundary.

On a related topic, there was general agreement on assigning more useful text location names to partial county codes (PCC).

SYMBOLS SHOULD SUPPLEMENT THE MESSAGE

The industry is similarly receptive—but cautious—on alert symbols. Standardized pictograms could help viewers recognize hazards quickly and reduce language barriers. Yet the record does not support replacing alert text, audio or protective-action instructions with icons.

Broadcasters generally favor voluntary adoption while symbol systems undergo public-comprehension and accessibility testing. The strongest common principle is that symbols should supplement complete warning information, use text, shape or pattern in addition to color, and avoid interfering with captions and other accessibility features.

An icon may help a viewer immediately recognize a wildfire, tornado or flood. It usually cannot communicate the affected location, evacuation route, expiration time or protective action by itself. Symbology should therefore be treated as a rapid-recognition aid, not as a substitute for the alert.

www.digitalalertsystems.com

SOFTWARE EAS: THE SHARPEST DIVIDE

Software-based EAS produces the sharpest disagreement. NAB, iHeartMedia, NPR, New York Public Radio, NCTA, DIRECTV and APTS/PBS support an optional software path, citing easier updates, integration with IP-based facilities, redundancy and potentially lower costs. Most also want certified hardware to remain available.

Other commenters caution that moving EAS functions into software does not necessarily modernize the warning system. Art Botterell (often referred to as the “godfather of the CAP protocol”) questions whether software that primarily emulates legacy EAS changes the system in a meaningful way. Richard Rudman (California SECC) calls for rigorous certification, minimum host-platform standards and direct treatment of cybersecurity risk. Digital Alert Systems argues that separating alerting software from an integrated certified implementation changes the compliance boundary by introducing additional hosting, integration, recovery and accountability obligations.

These concerns are not simply a “hardware versus software” debate. Modern EAS appliances already depend extensively on software. The relevant distinction is between software operating within a defined, certified environment and the same functions operating alongside other workloads, operating systems and network dependencies.

A shared-platform failure, configuration error or compromised update could affect several nominally redundant software instances at once. Remote patch delivery also does not establish that EAS service has been restored. The host, interfaces, network routes and connection to the broadcast air chain must all be functioning before an alert can reach the public.

This helps explain the industry’s resistance to simply assuming that software EAS will automatically be less expensive, more secure or faster to repair. It also underlies opposition from NAB, NYPR and Sage to a uniform 72-hour repair-notification deadline. Their filings generally favor retaining a longer period, while NCTA proposes 30 days, recognizing that the complexity of diagnosis, testing and multi-vendor coordination can outlast the installation of a patch. Implicitly, this seems to hint at more burden on the broadcast engineer, not less.

A PRACTICAL PATH FORWARD

Taken together, the record points toward a practical sequence: require signed CAP where the technology is ready; develop interoperable standards for legacy authentication and message identity; permit improved geographic filtering without overstating broadcast precision; encourage accessible symbology; and evaluate software EAS according to the resilience, certification and lifecycle obligations applied to any system performing the same public-safety function.

The industry’s message is not opposition to change. It is that modernization must be measured by what reaches the public when surrounding systems are failing—not simply by what appears more flexible on an architecture diagram.

– – –

Edward Czarnecki, Ph.D., is the VP for Gov’t & International at Digital Alert Systems. You can reach Ed at: ed.czarnecki@digitalalertsystems.com