Barry Mishkind

The Broadcasters' Desktop Resource

Software EAS: Unanswered Questions and Unwise Haste

Richard Rudman author

[July 2025] Just as we are seeing an increase in weather, fire, and other emergencies a discussion has grown over the very mechanism of EAS itself: should we convert to “Software EAS?” Are we ready to move past the EAS receivers that have been in every radio and TV station for almost three decades? Richard Rudman considers the concept.

The NAB’s petition to the FCC about “Software EAS” solutions represent a dramatic turning point in how EAS Participants implement Emergency Alert System infrastructure. But the speed with which this proposal is moving — and the relatively uncritical support it has received — should give us pause.

This petition asks the FCC to allow broadcasters to replace dedicated EAS encoder/decoder (ENDEC) hardware with software running on certified general-purpose IT platforms, a/k/a PCs.  But as someone who has spent decades working in broadcast engineering and public warning systems, I have to ask: why are we rushing something this revolutionary and critical to timely, reliable and accurate emergency public warnings for a public at risk?

I am not opposed to innovation. In fact, I have spent much of my volunteer time working with emergency communications systems on legacy and CAP/IPAWS EAS. Proposing a fundamental shift like this — moving EAS from dedicated, certified hardware to general-purpose IT systems — must trigger thoughtful, serious technical, engineering, and legal scrutiny. Unfortunately, we have not seen that yet.

MODERNIZING, YES—BUT AT WHAT COST? 

NAB and its supporters are saying that the petition would give us a voluntary option, not a mandate.

That is a fair point, but we believe that their initiative opens a Pandora’s box that can never be closed.  Once approved, this shift could quickly reshape how EAS is deployed across the industry, especially as hardware support winds down. That could have major impacts across the broadcast market, not to mention to the EAS manufacturers who are still providing and supporting gear.

Sage Alerting Systems — one of only two FCC-certified EAS hardware vendors — ceased new ENDEC production last year. Their support of the NAB petition is understandable for a company that will no longer make EAS hardware.  The concern of the other remaining manufacturer of EAS hardware is also very understandable.

But here is the problem: EAS is not just another audio chain component. It is a mandatory public safety tool designed to function during the worst possible scenarios — power loss, network outages, even cyberattacks. It is a federally regulated, mission-critical infrastructure. That demands careful and thoughtful planning followed by reliability proven through rigorous laboratory testing, not aspirational flexibility. The NAB Petition is literally a “Ready – Fire – Aim” approach.

SAGE’S SPARE PARTS ISSUE UNDERCUTS THE URGENCY ARGUMENT

In recent statements and filings, Sage clarified that it has “parts on hand for repairs” and expects to support the legacy ENDEC “for several years.”

That is good news—but it also undermines the case for urgency some stakeholders have been using to push for a fast-track rulemaking for software EAS. This is not an emergency. We have time to get it right. So why aren’t we?

QUESTIONS NOT YET ANSWERED

Many of us are still waiting for clarity on some fundamental issues:

  • What does FCC certification look like for a software EAS platform?
  • Will there be uniform standards for software performance, installation, and updates?
  • FEMA has been silent so far. Where does FEMA, the other Federal key EAS stakeholder, stand on this, especially regarding IPAWS/CAP?
  • How do we ensure reliable and resilient cybersecurity, especially when IT environments differ widely between stations?  And at what cost?
  • Will smaller broadcasters have the resources, including IT support, to manage patching, server maintenance, updates and fault-tolerant deployment?
  • Could software-based EAS introduce new costs or lock-in models tied to licensing or subscriptions?
  • What if this turns out to be more expensive for broadcasters than what we have now?
  • Are we walking into a potential IP trap, with patents that seem to cover core functions of software-based alerting, at least in HD Radio systems?
  • Has anyone stopped to realize that software-based EAS will still need ways to plug in and export balanced analog audio for the foreseeable future? Sounds like some hardware will have to be built anyway.
  • Computer platforms for software-based EAS will be potential single points of failure for the audio streams for radio, TV and other EAS Participants?
  • How will software EAS be implemented for video delivery media?

WHAT IS THE RUSH?

Here is where my alarm bells start ringing:. For something as critical as EAS, we are hearing surprisingly few hard questions.

Where is the test data? What does a “certified IT platform” even mean in practice? How will the FCC oversee compliance and resilience across a sea of different hardware/software combinations? These systems are meant to function in the worst-case scenario. Who makes sure they actually do?

In the Broadcast Warning Group Reply Comments to the FCC that I co-wrote, we asked what we believe is the core question: Why the rush? A shift of this dramatic nature demands high level engineering input, thorough testing, and clearly defined rules. But instead, we are already seeing pressure to launch a rulemaking without answering these foundational questions.

That is not just bad engineering—it is bad policy.

www.nautel.com

LET US SLOW DOWN AND HAVE A BIGGER CONVERSATION

Broadcast engineering, at its best, is built on rigor, redundancy, and reliability.

Rushing into a yet-to-be-clearly-defined software modality for EAS — especially without a robust certification framework, field testing, or guidance from FEMA/IPAWS — risks undercutting all three. And from a policy standpoint, asking the FCC to greenlight a major shift without clear definitions, guardrails, or stakeholder consensus is shortsighted.

Let us be clear: innovation is welcome. We should be exploring and eventually adopting modern EAS workflows. But we must do so carefully, methodically, and transparently.

This is not just a technical change. It is a cultural one. And if we get it wrong, it will not be an inconvenience — it will potentially be a failure of our emergency system at the times we need it most.

WHO IS ASKING THE HARD QUESTIONS?

A few organizations and engineers have raised these concerns, including me.

Some public safety advocates have also voiced worries about the loss of purpose-built, plug-and-play hardware. But so far, these concerns have not slowed the momentum behind the petition —and that is very troubling.

I understand the desire to modernize. But that has to be done with care. EAS is not an ad-insertion system or an automation widget. It is the last-ditch safety structure that underpins emergency public warnings in a disaster. If we’re going to change how it works, let us do it deliberately — with full stakeholder input, rigorous testing, and a clear understanding of the consequences.

If we do not, we risk trading long term reliability and resilience for a short-term goal — and that is a tradeoff we cannot afford to make.

– – –

Richard Rudman is a regular contributor to The BDR. He is a broadcast engineering contractor and consultant, Chair of the California State Emergency Alert System Committee, and a member of the Broadcast Warning Working Group. He has worked in EAS policy and engineering since the system’s inception, and continues to advocate for technically sound, resilient public warning solutions. 

You can reach Richard at rar01@me.com

– – –

 

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