# Pennsylvania Says Its Statewide 911 Disruption Wasn't a Cyberattack. The Alternative May Be Harder to Defend Against. At about 2:00 p.m. on Friday, July 11, 2025, calls started failing into the Delaware County 911 center. The dispatchers there described the tell that something was wrong: an unnaturally quiet floor, then bursts of calls, dropped connections, and calls that landed with no ANI or ALI attached -- no callback number, no location. Pennsylvania had finished moving its last PSAPs onto the statewide Next-Generation 911 system on April 10, roughly three months earlier. By 3:25 that afternoon, about eighty-five minutes in, PEMA pushed a statewide Wireless Emergency Alert and activated the Emergency Alert System, telling anyone who couldn't reach 911 to call their county center's non-emergency line and check local sources for the number. The disruption ran into the evening. PEMA said during the outage that a majority of calls were still being delivered, and I could find no public statewide count of how many failed. Full service was declared around midnight. Eleven days later, the agency put out a summary of preliminary findings: the cause was "a defect in an operating system," and the disruptions were "not believed to be" the result of a cyberattack. That formal summary did not say which operating system, which component, what triggered it, or how it spread. I want to sit with that, because the instinct in our field is to exhale when we hear "not a cyberattack." No identified adversary, no reported ransom demand, no announced breach. Just a bug. Feels almost comforting. It shouldn't. A no-adversary failure that degrades call delivery across an entire state is, in some ways, the harder problem. There's no one to attribute it to, no indicator of compromise to hunt, no perimeter that would have stopped it. The fault arose inside infrastructure the system was designed to trust, and a perimeter defense cannot, by itself, prevent a failure inside a trusted component. That distinction may matter more than usual here. In the days after the incident, PEMA told at least two news organizations that the problem involved a firewall operating-system error. Its formal July 22 summary described only an "operating system defect," without naming the product or component, so I won't infer a specific device or mechanism. But if the thing that failed was part of the security stack itself, "not a cyberattack" gets less reassuring in a hurry. * * * ## What actually happened, in plain terms Pennsylvania's NG911 runs on Next Generation Core Services -- NGCS. Those are the systems that take a 911 call and the location information the originating network hands over, validate or resolve that location as needed, and route the call to the right PSAP. In Pennsylvania, there are four instances of that core, located at two geographically separate in-state data centers. Comtech Telecommunications Corp. implemented and operates it under a statewide contract. Four instances. Two data centers. That is a lot of redundancy on paper. And whatever the defect was, the disruption still appeared across the statewide system within a relatively short period. That pattern is consistent with a common-mode or shared-fate failure -- where "redundant" components fail together because they share something underneath: the same software build, the same configuration, the same dependency, the same control plane, the same change pushed to all of them. NIST's own systems-security engineering guidance (SP 800-160) is direct about it: redundancy is susceptible to common-mode failure, and diversity is one means of addressing it, rather than simply adding more identical copies. I want to be careful here, because the public record does not prove an identical defect sat on every node. A shared configuration, a shared update path, or a synchronization or load-shedding mechanism could produce the same correlated result. But the lesson survives either way. The redundancy we all point to in our continuity plans -- the "we have a second data center" line -- protects you against a fire, a flood, a fiber cut, a dead power feed at one site. It does far less against a fault that lives in something all the instances share. Redundancy only buys resilience to the extent its failure domains are genuinely independent. If four instances share the same flaw, four copies are still one failure domain with four addresses. > Geographic redundancy is designed to survive losing a place. It does not, on its own, survive losing a piece of logic that every place is running. And this isn't only my read of it. Pennsylvania's own after-action review landed in the same place. When the outside firm running that review presented its findings to the state's 911 Advisory Board in December, one of the recommendations was multi-vendor diversity -- deliberately not building your redundancy out of a single vendor and a single software lineage. A board member raised exactly the right objection, that multi-vendor setups introduce their own interoperability and coordination problems, and the reviewer's answer was honest: yes, it adds cost and complexity, but it's the structural fix for the failure they had just lived through. When the official remediation for your outage is a version of "stop running identical copies of the same thing," the problem was never that you had too few copies. One more thing the public record does not resolve is what set the incident off. On day one, PEMA said it did not appear to result from a pushed software update. Later, WFMJ reported, attributing the account to PEMA, that a routine Comtech software update triggered the operating-system defect. PEMA's formal July 22 release did not reconcile those accounts. Because the public record does not disclose the underlying evidence, I am not going to state the trigger as fact. And if you're tempted to file this under "Pennsylvania's problem," don't. NENA and Carbyne's 2025 Pulse of 9-1-1 survey of 1,379 public-safety professionals found that 88 percent of emergency communications centers had experienced some kind of technology outage in the previous year. The specifics here are Pennsylvania's. The shape of the problem is everyone's. * * * ## What this means for your shop Translate it out of the press release and onto your floor. **For the dispatch floor.** The failure was intermittent, which is operationally worse than a clean outage in one specific way: calls that never reach your normal call-handling environment can be invisible there. Some connect, some don't, some arrive stripped of location and callback data. On a busy floor, that reads as noise before it reads as an outage. I can't tell you it cost Pennsylvania's telecommunicators any particular amount of time -- that wasn't documented, and I'm not going to invent it -- but as a general failure mode, intermittent upstream degradation is exactly the kind of thing that hides inside normal call-volume variation until someone connects the dots. The defense is a rehearsed, low-friction way for a telecommunicator to escalate "something upstream is wrong" in seconds, before they're certain, without a supervisor huddle. **For agency leaders.** Pull your COOP plan and ask whether it has a play for the core degrading as a unit -- even if both data centers remain reachable -- not just for losing a site. If your plan assumes only site loss, it leaves this different failure mode uncovered. Then ask how the public in your jurisdiction learns your backup number on a bad day. Pennsylvania's alert did not hand people a ten-digit number to dial; it told them to call their county's non-emergency line and go find the number themselves, mid-emergency. A WEA is a blunt instrument, and in my opinion an easy one to swipe away. The number needs to be in front of people before the outage, on the county site, in the places they actually look when they're scared. **For IT and technical staff.** Know exactly where the vendor's responsibility ends. Pennsylvania's statewide 911 plan states that Comtech's NG911 cybersecurity obligation ends at the demarcation equipment installed at the PSAP. What sits past that line isn't automatically "all yours" either -- responsibility on the PSAP side often divides between the county and its local vendors -- but you need to be able to draw that boundary from memory, because during an incident, "whose problem is this" is the question that burns the most time. And test the call path for failover for real. Never place uncoordinated test calls to 911; if live-call testing is required, schedule it in advance with the affected PSAP and run it under the approved test plan. **For procurement and contracts.** This is where the paperwork turns into life safety. When your NG911 contract renews, the questions that matter aren't just price and features. What's the root-cause disclosure obligation after an incident, and on what timeline? What's the notification SLA? On that last one you have a federal floor to hold vendors to: as of April 15, 2025, FCC rules require covered 911 service providers and originating service providers to notify potentially affected PSAPs as soon as possible, and no later than 30 minutes after discovering a 911-affecting outage. The rules require subsequent material updates as information becomes available; for originating providers, the first follow-up is due within two hours of the initial contact. APCO argued for fifteen minutes. Know the rule, and treat "we notified you inside the window" as the floor, not the goal. There's a vendor-governance thread here too, and I want to handle it carefully, because the easy version of it is wrong. Comtech spent this period in heavy corporate motion: in October 2024 it began exploring strategic alternatives, including a potential divestiture, for the business containing its 911 operations; in November 2025 it renamed that segment Allerium; in June 2026 it agreed, subject to closing, to sell most of its satellite business and refocus the company around public safety. It is tempting to draw a line from "company in flux" to "that's why 911 broke." Don't. The 911 business remained profitable, with fiscal 2025 operating income rising year over year to $24.1 million, and the parent removed its going-concern doubt by late 2025. Nothing in the public record connects any of this to July 11. The smaller, real lesson for procurement is that ownership, capital structure, and strategic direction are continuity variables worth watching even when the operating unit is healthy, because they shape staffing, roadmap, and support over the life of a contract your community's ability to reach help depends on. * * * ## The part that still bothers me Let me be precise about what is and isn't public, because it cuts both ways. The most detailed public explanation of the cause is still "a defect in an operating system." But the after-action work is not buried. Comtech summarized its root-cause analysis to the 911 Advisory Board in September, covering the network design, the event, the impacts, the restoration, the cause, and corrective and preventative actions. In December the board received the after-action review's findings and recommendations from the outside firm that ran it, along with a corrective-action status update that includes concrete fixes: better outage notifications to PSAPs (multipath text and phone), and a supplementary PEMA notification for the most critical impairments. So this isn't a case of nobody looking, and it isn't total silence. Credit where it's due. What's still missing is the granular technical cause: which operating system, which component, what triggered it, how it propagated across the instances. That's the part every other PSAP running this vendor's core has a direct operational interest in -- Comtech says it holds primary statewide NGCS contracts in eight other states, and whether those deployments share the affected component is unknown. I understand the security-sensitivity argument for holding some of it back. I don't fully buy it at this level of generality. "We found a defect and fixed it" is thin comfort for the people who dial that number when someone is dying, and the withheld technical detail is precisely what would let everyone else check whether they're exposed. * * * ## What to do with this before you close the tab You don't need a cyberattack to degrade 911. A defect in a trusted or shared component can be enough if the architecture does not fully isolate its operational effect. The telecommunicators working that Friday used backup procedures and kept serving their communities while call delivery misbehaved for hours through the afternoon and evening. The reported defect was in an operating system. The architecture was supposed to limit the operational impact, and it did not fully do so. So, three questions for your own shop, this week: * Does your COOP plan have a play for the core failing as a unit, not just a site going dark? * Do your telecommunicators have a two-second way to escalate an upstream failure, before they're sure? * Does your public know your backup number today, not during the alert? If any of those answers is 'no,' that's the first thing to fix this week -- not a note for later.