The proposal to allow Emergency Alert System functions to be performed in software has received support from a significant portion of the radio industry. But a supplier of EAS products is continuing to express caution.
The FCC’s Further Notice of Proposed Rulemaking (FNPRM) proposes to allow broadcasters and other EAS participants to use software to replace EAS hardware if they wish.
As Radio World has reported, the National Association of Broadcasters, iHeartMedia and National Public Radio are among those in favor of the change.
However, the two major relevant technology suppliers are recommending divergent approaches. Because the universe of companies that make EAS products is so small, Sage Alerting Systems and Digital Alert Systems are seen as key stakeholders in this decision.
Digital Alert Systems
In its filed comments, Digital Alert Systems essentially argues that far more work will need to be done by the FCC or others before software-based EAS can be allowed safely.
It told the FCC that the shift to a software-based model could lead to implementations that are “insufficiently defined, certifiable, inspectable, secure or accountable under Part 11.”
It said it supports “responsible” EAS modernization but strongly cautions against authorizing software-based EAS in a way that separates application code from its operating environment.
DAS noted that modern EAS equipment already relies extensively on software, and it does not contend that software can’t perform basic EAS functions. Nor is it arguing that the FCC should defer consideration of software because the record lacks a complete technical specification for every possible deployment.
“DAS’s concern is narrower and more fundamental,” the company wrote.
“We observe that the FNPRM’s proposed authorization does not yet establish the regulatory object, certification boundary, conditions of authorization, conformity requirements and accountability relationships necessary to make software-based EAS administrable under Part 11.”
Therefore, it thinks the FCC should defer the change until it establishes a rule framework that treats software as one component of a complete certified EAS system configuration.
It said such a configuration would include the host environment within the certification boundary; require disclosure and control of “material external dependencies”; and preserve a clear line between compliance functions and downstream signal-chain functions.
“If the commission proceeds now, any authorization should be narrow and technology-neutral. Software-based EAS should operate only within an identified, certified system configuration, with the host environment and material dependencies included within the certification boundary,” DAS told the FCC.
“Software, appliance and hybrid implementations should be subject to equivalent obligations for cybersecurity, reliability, lifecycle, support, inspection and recovery,” it continued.
“The question is whether the commission can authorize a new implementation model without weakening the reliability, cybersecurity, operational independence, certifiability, accountability and continuity of operation required of national public-warning infrastructure.”
DAS urged the commission to use the proceeding “to determine whether it can establish an enforceable technical and operational framework for authorizing defined, certifiable EAS implementations consistent with applicable federal requirements and guidelines.”
In addition, it said the rules should require disclosure of proprietary or license-restricted dependencies necessary for the certified configuration.
The manufacturer reminded the FCC that EAS is critical public-safety infrastructure, not just a standard broadcast application, and thus requires a certifiable, secure and accountable regulatory framework.
“The rules if adopted should make clear that downstream automation, routing, processing, playout, transport, multiplexing and signal-insertion systems do not become EAS-compliant equipment merely because they carry, route, switch or insert alert content,” it wrote.
DAS recommends the FCC remove terms like “manages” from the FNPRM and exclude software that solely performs monitoring or administrative duties unless explicitly inside the certification boundary.
It also seeks “regulatory parity” if the proposal is adopted.
“If software suppliers face lighter certification, lifecycle or cybersecurity obligations, it creates an uneven playing field, disadvantaging manufacturers that continue to invest in complete certified hardware.”
It said that maintaining strict, uniform standards across form factors would ensure vendor diversity, avoid single points of failure and protect the resilience of national public warning.
Read the DAS comments here. The company also filed a second document that discusses the rest of the steps proposed in the FNPRM, specifically proposals to improve the security, precision, interoperability and public usefulness of CAP and legacy EAS alerting. Read that filing.
Sage Alerting Systems
Meanwhile, Sage told the FCC it mostly supports a move away from custom hardware boxes and into software EAS, which virtualizes ports, displays and audio routing across modern broadcast facility infrastructures.
Sage ceased manufacturing its EAS hardware in 2024 but is expected to offer software if the FCC allows it.
The supplier envisions four deployment models:
- Single-Application Platform: Simplified hardware with virtual ports/displays managed by an EAS vendor.
- Closed Multi-Application Platform (Curated Hardware/Software): Tested broadcast hardware from a third-party vendor running curated, integrated software modules, including software EAS.
- In-House Enterprise Stack: Facility-owned hardware managed by an internal software integrator.
- Generic Downloadable Package: Software sold directly to end-users who must handle security and integration themselves.
Sage told the FCC it supports the first three models but strongly discourages the fourth.
The EAS manufacturer argues that “unmanaged, non-curated software setups pose security risks, whereas curated models retain the security and reliability of standalone hardware.”
The FNPRM considers key technical and policy provision as well. Sage says it agrees with the FCC on mandating digital signature for Common Alerting Protocol (CAP) messages.
However, digital signatures for legacy EAS, while technically feasible, increase vulnerability to signal noise, Sage says.
In addition, the company supports permitting (but not requiring) CAP polygons for filtering alerts, except for National Periodic Tests or Emergency Action Notifications. Sage cautions that using polygons for filtering could disrupt downstream monitoring assignments in state relay networks.
You can review the 150 or so filed comments in PS Docket 25-224. The deadline for reply comments on the FNPRM is Sept. 29.
Read our four-part series about the key proposals in the FCC FNPRM.
