One Router, One Friday, One Nationwide Ground Stop: What the Hell Happened to the FAA?
Well, we finally have a pretty good idea what happened to America's air traffic control system on Friday, November 13.
And somehow, the explanation is simultaneously less dramatic and more disturbing than the cyberattack theories that circulated all over the internet while it was happening.
A contractor was upgrading a telecommunications connection from copper to fiber at a remote FAA facility. You know, the kind of network maintenance that IT departments have been performing for decades. The kind of thing that happens in every bank, hospital, school district, and insurance office in America, usually without a press conference. Except this particular upgrade went sideways. And the next thing you know, the FAA is ordering aircraft across the entire United States to stay on the ground.
Wonderful.
As someone who's spent a considerable amount of time working with networks, routers, switches, and systems that occasionally decide to ruin everyone's afternoon, I find this story fascinating. Not because something broke. Things break. It's because of how far the consequences traveled. And because of what the official explanation quietly admits about the way we build these systems.
A Thousand Connection Attempts Every Four to Five Seconds
At a press conference at the Department of Transportation on Saturday, November 14, Transportation Secretary Sean Duffy walked through the sequence.
"In at least one of our remote FAA locations, a contractor was doing routine maintenance to switch telecommunication lines from old copper wire, and they were bringing it over to fiber," Duffy said.
He added that the copper line wasn't being retired as part of some grand modernization push. It was being discontinued by the carrier. It was going away whether the FAA was ready or not.
Then came the part that matters.
"Either through contractor error or a faulty piece of equipment, that router that was being replaced as we switched from copper to fiber, it started flooding other routers in our air traffic control system," Duffy said. "So specifically, we had over 1,000 connection attempts every four to five seconds, and what that did was gave us issues with our communication with airplanes, and it also caused some disruption with our radar feeds."
Read that number again.
More than a thousand connection attempts every four to five seconds. Call it 200 to 250 per second.
Now, to somebody outside networking, that might sound like an enormous amount of traffic. It isn't.
Plenty of ordinary internet-facing systems handle vastly more than that without anyone noticing. A mid-sized ecommerce site shrugs off more than that during a lunchtime sale. Two hundred and fifty connections per second is not a volumetric attack. It's not a botnet. It's not a state actor with a grudge. It's the kind of load a competent network engineer would call a Tuesday. Which is precisely why this is a bigger story than a bad router. Because the critical question isn't how much traffic there was. It's what kind of connections these were, what equipment was processing them, and how that equipment was arranged relative to everything else. Because apparently this particular network didn't appreciate the attention.
The result wasn't a nationwide radar blackout. Not every radio in America went silent. What happened was intermittent, unreliable communication in an environment where unreliable communication is absolutely unacceptable. Duffy said the disruption hit both controller-to-pilot communications and radar feeds reaching controllers.
That's the moment the decision gets made for you. You don't manage an aircraft problem you can't see. You stop departures, handle what's already in the air, and get the system stable.
The FAA issued the ground stop for all U.S. airports citing "extraordinary circumstances and for reasons of safety." It stayed in effect for more than four hours before it was lifted. By Saturday, more than 12,500 flights had been canceled across the two days.
All because of a network maintenance task.
How Does One Router Become Everybody's Problem?
This is the part I really want to understand.
Modern networks are supposed to have mechanisms for preventing individual failures from taking down everything around them. Segmentation. Traffic filtering. Redundancy. Rate limiting. Fault isolation. Route dampening, if you want to be specific about this failure mode, because a router advertising reachability it can't deliver is a very old problem with a very old set of mitigations.
These aren't revolutionary concepts. Many of them are older than the people now operating these networks. And yet, according to the preliminary explanation, a router installed during routine work at one remote facility was able to interfere with services across a much wider operational network, in a system that carries the flying public.
That's a serious architectural question, and it doesn't go away when the router gets replaced.
Was the device misconfigured? Was there a software defect? Did a connection-management process begin behaving in a way nobody anticipated? Did legacy equipment lack protection against traffic patterns that only appear when newer technology is introduced into an old environment? And the one I'd most like answered: why didn't this stay inside the building where the work was happening?
We don't have those answers yet. Duffy was explicit that the root cause could be contractor error or faulty hardware. The Verge reported him listing a misconfigured router or, in his words, "incompetence" on the part of contractor L3Harris as possibilities. FAA Administrator Bryan Bedford said the agency is working through "what this defective piece of equipment was" and will share the root cause analysis when it's complete.
That matters. L3Harris has been identified as the contractor performing the work. The L3Harris name is on the FAA Telecommunications Infrastructure program, which is the private network carrying much of this traffic. But identifying who was working on the box is not the same as establishing what the box did or why the network around it couldn't contain it.
From a digital forensics perspective, here's the list I'd want on the table: the router configuration before and after, interface counters, event logs, firmware versions, connection tables, the change ticket and approved maintenance window, and a synchronized timeline of the first system alarms across every facility that saw one. Because the work order tells you what somebody intended to do. The logs tell you what the network actually did.
Those two stories are rarely the same.
And Who Schedules This Stuff on a Friday?
Here's another question, and it's not a rhetorical one.
Why was potentially disruptive maintenance happening during operational hours on the thirteenth of the month?
We don't know the approved maintenance window. We don't know whether the work happened inside it or outside it. We don't have the change-management records, and I'm not going to pretend otherwise.
But traditionally, when you're modifying infrastructure at this level, the process looks a certain way. You schedule a window. You test the change in a lab or a non-production slice. You write a rollback procedure and you know how long it takes to execute. You notify the operations side. And ideally, you make sure that if the change goes catastrophically wrong, it fails inside the smallest possible blast radius.
The difference between a routine upgrade and a nationwide aviation emergency shouldn't be one router having a bad afternoon. And there's a detail hiding in this story that I suspect will matter more than the root cause.
According to reporting on the FAA's modernization plans, the agency intends to replace this network entirely, with an AT&T-led effort due by December 2028. Which means the system that failed on Friday is a system that everybody already knows is being retired. It's carrying the load in the meantime, because it has to, because you can't turn off air traffic control while you migrate it.
That's not an excuse. But it does explain the shape of the risk. The most dangerous moment in the life of any legacy system is the long middle, after everyone has agreed it must be replaced and before anyone has replaced it. It's still running. It's still the thing. And the people maintaining it are performing surgery on a patient who is also flying the plane.
The FAA's Technology Problem Is Worse Than You Think
Here's where this gets particularly uncomfortable.
In September 2024, the Government Accountability Office published an assessment of the FAA's aging air traffic control systems, titled "Urgent FAA Actions Are Needed to Modernize Aging Systems." The word "urgent" is GAO's, not mine.
Of 138 systems examined, 51 were rated unsustainable. Another 54 were rated potentially unsustainable. That's 105 of 138, or roughly 76 percent, with serious or potential long-term sustainability concerns. And 58 of those 105 systems had critical operational implications for airspace safety and efficiency.
Six of those systems are more than 60 years old.
So this isn't a situation where everyone suddenly discovered the FAA owns some old routers. The federal government has been documenting this in writing, with page numbers, for years. And the modernization work is necessary. Nobody serious argues otherwise. The problem is the paradox underneath it.
The FAA has to replace aging infrastructure while simultaneously depending on that same infrastructure to run the busiest aviation system on earth.
It's like rebuilding your car's engine while driving down Interstate 95.
At 75 miles an hour. With three million passengers. And no shoulder.
And on Friday, a routine part of that rebuild reached back and touched the part that was still holding everything up.
Was It a Cyberattack?
No, according to everyone with access to the evidence.
At the Saturday briefing, Bedford was about as direct as a federal official gets. "We see zero evidence of anything nefarious, and zero evidence of anything AI-related," he said. "So we want to be clear that we have an equipment issue, and we're working through what this defective piece of equipment was."
Duffy's version of the same conclusion was more useful, because it explained the mechanism. "Once we were able to isolate the work that was being done at this remote location, all of our systems came back online, so we don't believe this was cyber at all. This was an FAA system that didn't meet the moment."
Homeland Security Secretary Markwayne Mullin told reporters there was no indication the incident stemmed from a cyberattack, with the caveat that investigations were ongoing.
And the SMART AI-assisted traffic management system, which rolled out to all 22 air traffic control centers on November 10, took a preemptive swing at the speculation. The company behind it, ASI, said the ground stop was "not based on or a result of the SMART system, any product of ASI," or the systems it integrates with.
That disclaimer was necessary because the timing was practically begging the internet to start connecting dots. Four days after a nationwide AI rollout. Microsoft in the middle of a massive cloud disruption. Friday the 13th. If you were writing a thriller, you'd cut the scene for being too on the nose. But the evidence doesn't support the thriller version, and the restoration sequence actively undercuts it. You don't fix a coordinated intrusion by isolating one facility's maintenance work and watching everything come back.
What you do fix that way is a localized technical change with wide network consequences.
The Microsoft Coincidence Is the Real Story
Here's the part I keep coming back to, and it's the part nobody seems to be connecting.
That same weekend, Microsoft had one of its more embarrassing outages in recent memory. Outlook, Teams, Copilot, and a wide swath of Microsoft 365 went sideways. It dragged into a second day. Microsoft apologized, said it was "deeply sorry for the disruption," and clarified that the cause was a technical issue, not a cyberattack, and not AI.
The mechanism? An unexpected usage spike.
Sit with that for a second.
The largest aviation regulator on the planet was brought to its knees by 200 to 250 connection attempts per second against communications infrastructure. The largest enterprise software company on the planet was brought to its knees by an unexpected spike in usage. Neither one was attacked. Neither one was sabotaged. Nobody needed to be clever. Both just received more of something they were built to receive, in a shape they weren't built to absorb, and both fell over. And both had to come out afterward and assure the public that artificial intelligence had nothing to do with it.
We spend an enormous amount of energy worrying about what a sophisticated adversary could do to our infrastructure. And I'm not suggesting that worry is misplaced. But look at the actual record. The events that keep grounding airplanes and locking people out of their email aren't attacks. They're demand. They're volume. They're load arriving in a pattern the design assumed away.
The most effective attacker of a system built for the average day is an above-average Tuesday.
The Real Problem Isn't That Something Failed
Here's what concerns me, and it isn't the router.
We're living in an era where governments and corporations are building increasingly sophisticated digital infrastructure. AI-enabled systems. Automated decision-making. Cloud computing. Advanced telecommunications. Autonomous everything.
Everything is becoming faster, more capable, and more interconnected. But interconnection comes with a price. When systems share infrastructure, they share failure modes. A mistake in one place produces consequences somewhere completely different, and the distance between cause and effect gets long enough that the people in the room can't see the connection.
Sometimes those consequences are inconvenient. Sometimes they interrupt business operations. And sometimes the FAA tells an entire nation to stop launching airplanes.
The danger isn't that an individual component can fail. It's that the architecture allows an individual failure to become everybody else's problem.
This is why replacing old hardware with newer hardware isn't enough, and it's why the $50 billion conversation needs to be about more than procurement.
A faster router doesn't fix a poorly isolated network. Fiber doesn't eliminate configuration mistakes. Redundancy doesn't help if both paths terminate on the same logic. And throwing AI at the problem won't help if the underlying infrastructure can't reliably deliver what the AI depends on. Bedford's "zero evidence of anything AI-related" is reassuring about causation and completely silent about that vulnerability.
Modernization has to include resilience, not just performance. Systems that fail safely. Faults that stay local. Changes tested under realistic load rather than happy-path load. And backup paths that don't share a single point of failure with the primary, which is a lesson the industry has been relearning every few years since the first time somebody put both circuits in the same conduit.
The Question Washington Needs to Answer
Duffy has asked Congress for $50 billion in emergency funding for air traffic control, on top of the $12.5 billion already approved over five years in July 2025.
Given the documented age and condition of some of that equipment, there's a legitimate argument for major investment. GAO made it in writing, in triplicate, two years ago. But before anybody writes a check of that size, I'd like six questions answered on the record.
What generated the connection flood? Why did other routers struggle to absorb it? What prevented the fault from staying isolated to one facility? What testing was performed before the change, and under what load? What specific engineering changes have been made in the last 48 hours to prevent a repeat? And who signed the change ticket? Because identifying a bad router isn't the same as explaining how it took down a national system. And restoring service isn't the same as fixing the vulnerability.
There's also a political reality that arrived before the technical one. New York Governor Kathy Hochul called on Duffy to resign, or for the president to remove him, citing controller shortages and "repeated communications breakdowns" and saying he's been "more focused on starring in his own reality show than addressing the crisis at his agency." You can think that's fair or you can think it's opportunistic. Either way, it tells you what the next congressional hearing is going to be about, and it won't be router firmware.
Happy Friday the 13th
Friday's ground stop may ultimately turn out to have come from something as mundane as a defective device or a misconfigured interface on a network that was already scheduled for demolition.
No foreign intelligence operation. No rogue artificial intelligence. No elaborate conspiracy. Just an ordinary infrastructure upgrade producing extraordinarily unpleasant consequences.
Which brings us to the uncomfortable conclusion.
We keep worrying about sophisticated adversaries finding ways to bring down America's critical infrastructure. We fund programs around that fear. We write strategies around it.
Apparently we should also be worrying about what happens when somebody plugs in a router. Our infrastructure really got into the spirit of the holiday.
Editor's note: This article reflects preliminary official findings as of November 14, 2026. The precise technical fault, responsibility for the incident, and the effectiveness of permanent corrective measures all remain under investigation. Bedford said the FAA will publish its root cause analysis when it is complete.
Sources and further reading
Rich Washburn is a technologist, strategist, and Founder & Chief AI Architect of ARIA AI Labs, working at the intersection of AI, infrastructure, communications, and capital. He also serves as Managing Partner and Chief AI Officer at Eliakim Capital.
Comments