FAA Ground Stop: AI Got the Blame, Old Telecom Got the Cause. Lessons for IT

Status as of 15 November 2026: the cause described below is the official preliminary explanation. The FAA's root cause analysis is still under way and no final report has been published. This article will be updated when one is.

On Friday, 13 November 2026, the Federal Aviation Administration stopped departures at every U.S. airport after a communications outage hit its air traffic control centers. Three days earlier the FAA had said it was expanding SMART, an AI-assisted traffic-planning tool, to all 22 of its en route centers. The timing was enough for many people to conclude that "the AI did it."

Officials say the evidence points somewhere far less exciting: old telecom equipment, an equipment upgrade carried out in the middle of a Friday afternoon, and a network that let one site's problem spread nationwide. For anyone who runs IT, that is the more useful story, because every one of those ingredients exists in ordinary corporate networks.

Who this guide is for

This guide is for IT managers, network and infrastructure admins and anyone who approves changes to production systems. It sets out what officials and the companies involved have said, with attribution, and then turns the incident into practical lessons: when to schedule work, how to find legacy dependencies, how to limit the blast radius of a change, how to reason about "what changed" during an incident, and how to communicate while the cause is still unknown. EpiFive has no inside information about the FAA network; everything below comes from named public statements and news reports listed under Sources.

What happened

All times are Eastern (EST, UTC-5) on 13 November 2026 unless stated.

AVweb described it as the first nationwide ground stop since the FAA's January 2023 NOTAM outage. The disruption was large and the counts depend on who measured and when: TechCrunch, citing aviation data firm Cirium, reported more than 8,200 cancellations on Friday evening and at least 3,000 more on Saturday. NPR, citing FlightAware, reported nearly 25,000 delays and more than 9,000 cancellations on Friday, and, citing Cirium, more than 4,000 Saturday cancellations, 18% of U.S. departures. Bedford said schedules should be back to normal by Sunday evening (NPR).

What officials say caused it

At a White House news conference on Friday evening, Duffy said aging switches and routers in the FAA's telecom network "got overloaded with data" and began producing inconsistent information, and that the agency shut the system down because of it (GeekWire, Scientific American). In the Department of Transportation's readout of the briefing he is quoted as saying "We have TDM telecom–so this is analog telecom," and he added: "Our new IP switches did not go down. It's the old hardware that went down" (GeekWire). He also said the FAA still uses "1980s little copper lines" (Fox Business).

Mullin said the overload appeared to have been triggered by new equipment the FAA was installing, as the agency added "new equipment and new technology" that "was overwhelming the older system" (GeekWire).

On Saturday the account became more specific. Duffy said L3Harris, a longtime FAA contractor, was doing routine maintenance at at least one remote location, replacing copper wire with fiber optics, and that the FAA was still investigating "whether we had incompetence, meaning was it user error, installator error from L3Harris, or did they install a faulty router?" (NPR). The FAA's acting chief technology officer, Rebecca Guy, said two sources were hitting the network at "a thousand connections over every four to five seconds", and that the FAA disabled both and stabilized the network; a root cause analysis is under way (TechCrunch).

L3Harris said in a statement that it is supporting the FAA's investigation and has completed more than 70% of planned copper-to-fiber conversions (NPR). Bedford said: "We want to be clear that we have an equipment issue, and we're working through what this defective piece of equipment was" (TechCrunch). Duffy used the briefings to ask Congress for emergency funding: "I want $50 billion" (Fox Business).

Treat all of this as the official preliminary explanation; the investigation is ongoing. CBS News reported that its sources were receiving conflicting information about the cause, and no final root cause report has been published.

The AI question: SMART

SMART (Strategic Management of Airspace, Routes and Trajectories) is a cloud-based tool that pulls in about 200 data streams, such as weather, flight paths and controller staffing, to recommend schedules and routes. FAA specialists review its recommendations and local facilities decide whether to act on them (GeekWire). Scientific American reports it was piloted around Washington, D.C. in September and was deployed across all 22 regions as of 10 November. It is part of a 12-year, $875 million FAA contract with Boston-based Air Space Intelligence (GeekWire).

Early on Friday, before the evening briefing, Mullin said officials were looking into a possible link to SMART, including through CISA (GeekWire). By the evening, Duffy said: "There was no possible way SMART would have impacted what happened today" (GeekWire). AVweb reports that SMART provides recommendations but "is not connected to the agency's STARS or ERAM systems", the systems behind radar display and flight data. Air Space Intelligence said: "The current ground stop is not based on or a result of the SMART system, any product of ASI or our integration with FAA and ATC" (NPR, GeekWire). Bedford said there was "zero evidence of anything AI-related" (TechCrunch). Separately, the air traffic controllers' union said it had not been consulted on the tool's design (TechCrunch); that is a governance concern about the rollout, not evidence about the outage.

The debate about AI's role exists, mostly online and in TV commentary, and it was fed by the timing. The official position is the one above.

The Microsoft question

The ground stop came a day after a long Microsoft 365 outage, which we covered in what to do during the Microsoft 365 outage and the root cause lessons for admins. Mullin opened the Friday news conference by saying "there is no connection between this and Microsoft. I know a lot of people are making that jump," and Microsoft said it had no indication the ground stop was related to its service disruption (GeekWire).

Why correlation with an AI rollout is not causation

When something breaks, the most visible recent change gets blamed first. A new AI tool rolled out three days earlier is very visible. But "it happened after X" is a starting hypothesis, not a finding. The useful questions are the ones an incident team asks about any change:

• Is there a data path? A tool can only break what it is connected to. Officials say SMART produces recommendations and is not connected to the radar and flight data systems. If your suspected change has no path to the failing component, it moves down the list.
• Does the timing really match? A tool expanded on Tuesday that breaks something on Friday afternoon needs a reason for the three-day delay. A change made the same afternoon, minutes before the symptoms, does not.
• What else changed? The FAA's own explanation points to a hardware and cabling change at a remote site. Most organizations have several changes in flight at once; pull the full change log for the window, including contractor and carrier work, not just your own team's tickets.
• Does the symptom fit? Connection floods and inconsistent data from overloaded routers are network symptoms. They point at the network first.

The 2023 NOTAM outage is a reminder of how this goes: it prompted fears of a cyberattack, and the FAA later found contract workers had inadvertently deleted critical files (NPR). Keep a written list of hypotheses, attach evidence for and against each, and only remove one when the evidence rules it out. That discipline protects you from both mistakes: blaming the new AI tool without evidence, and dismissing it without checking.

Lesson 1: Change windows, or why 3 p.m. on a Friday matters

TechCrunch reports that Duffy was asked why the work happened at 3 p.m. on a Friday afternoon. He said switchovers at large airports happen late at night, while remote sites are worked during the day, and that "there will be reevaluation of when we do this work."

That reasoning is common in corporate IT too: a small branch site feels low risk, so its change gets a daytime slot. The problem is that the risk of a change is set by what it is connected to, not by the size of the site. For your own change process:

• Classify changes by blast radius, not by location size or ticket effort. Anything that touches a shared network, identity, DNS or a core routing domain is a high-risk change wherever the cable is.
• Put high-risk changes in a window with low business load and full staffing: engineers who can roll back, vendor support on call, and someone with authority to stop the work.
• Avoid the hours before a weekend or holiday unless the change is an emergency. Problems found late on Friday are fixed with fewer people.
• Apply the same windows to contractors and carriers. A contractor's "routine maintenance" on your circuits is your change.

Lesson 2: Legacy TDM and copper dependencies

TDM (time-division multiplexing) is the circuit-switched technology behind T1/E1 lines and older carrier services. Strictly, TDM circuits carry digital signals, so "analog" is loose shorthand; the point that matters is that it is legacy equipment being retired and replaced by IP networks. In the middle of a migration you run both, plus the gateways between them, and that mixed state is fragile.

Most organizations still have some of this. Make a list:

• T1/PRI circuits feeding PBXs or SIP gateways.
• Copper POTS lines for alarm panels, elevator phones, fax machines, door entry, and building management systems.
• Serial or leased-line links to remote sites and industrial equipment.
• Old routers and switches that are past end of support but still carry something important.

For each one, record what depends on it, who the carrier is, what the replacement is and when. Then ask the question this incident raises: can the old equipment survive the traffic patterns the new equipment will send it? Older devices often have far smaller connection tables, CPU and buffers than the gear replacing them.

Lesson 3: Blast radius and the capacity of new equipment

Guy's description of two sources making "a thousand connections over every four to five seconds" is a textbook connection storm: one misbehaving device floods its neighbors until they stop working properly. Duffy said the new IP switches stayed up and the old hardware failed. Whatever the final root cause, the general lesson is that a fault at one site should not be able to degrade a national network.

• Segment so that a fault in one site or region stays there.
• Rate-limit and protect the control plane: connection limits, storm control and control-plane policing on network devices, and circuit breakers in software.
• Load-test the interaction between new and old equipment before cutover, not just the new device on its own.
• Stage the rollout: one low-impact site first, watch it under real load, then widen.
• Monitor for the symptom: alert on connection rates and error spikes, not only on links going down. In this incident the network did not fully fail; Duffy said it produced inconsistent data.

Lesson 4: Rollback plans

The FAA said it stabilized the network by disabling the two sources (TechCrunch). Isolating the new thing is often the fastest recovery, and it only works quickly if it was planned. Every change record should answer, before work starts:

• What exactly is the rollback, step by step, and has it been tested?
• What are the abort criteria (error rates, latency, connection counts) and who watches them during the change?
• Who can call the rollback without a meeting, including when a contractor is doing the work?
• Is the old path kept available until the new one is proven, or is the copper pulled the same day?
• How long does rollback take, and is that acceptable for the systems it affects?

Lesson 5: How to communicate during an incident

The public explanation of this incident changed over 24 hours: an initial FAA statement marked "preliminary and subject to change", officials looking into the AI tool in the afternoon, a telecom overload explanation in the evening, and the contractor upgrade on Saturday. That is normal for an investigation; it is also why careful wording matters.

• Say what you know, what you don't, and when the next update is. Label causes as preliminary until confirmed.
• Don't name a suspect you can't support. Speculating about a cause, whether AI, a vendor or an attack, becomes the headline and is hard to take back. "We're investigating all recent changes" is accurate and safe.
• Rule things out explicitly once you can, as officials did about Microsoft and cyberattack evidence. Users want to know what it is not.
• Use a channel that does not depend on the broken system. The Microsoft 365 outage the day before showed why; our Microsoft 365 outage guide covers telling users without email or Teams.
• Publish a post-incident review with the root cause, timeline and fixes once it is known, as our Microsoft 365 root cause article recommends for any provider.

A checklist for your next network change

• Blast radius assessed, and the risk class is based on what the change touches, not the site size.
• Scheduled in an approved window with full staffing; contractor and carrier work included.
• Legacy dependencies (TDM, copper, end-of-support devices) identified for the affected path.
• Interaction between new and old equipment load-tested.
• Rate limits, storm control and monitoring for connection spikes in place.
• Rollback written, tested and timed; abort criteria and decision owner named.
• Old path kept available until the new one is proven.
• Incident communication template ready, on a channel that does not depend on the system being changed.

What we checked

• Opened the TechCrunch report of 14 November (Anthony Ha) on 2026-11-15: L3Harris copper-to-fiber work, the "3pm on a Friday" question, Guy's connection figures, Bedford's quotes, Cirium cancellation counts and the union's comment. It does not mention TDM, a dollar figure or Air Space Intelligence.
• Opened GeekWire's updated report (Todd Bishop, 13 November): Mullin's and Duffy's statements, Microsoft's statement, the SMART description, the 12-year $875 million Air Space Intelligence contract and the company's denial, 3:36 p.m. ET start of instability and 5:15 p.m. Pacific reopening.
• Opened AVweb (13 November) for the 3:54 p.m. start and 8:15 p.m. EST lift and the statement that SMART is not connected to STARS or ERAM; Scientific American for the SMART pilot and the 10 November nationwide deployment; NPR (14 November) for the L3Harris statement, Saturday's account and FlightAware/Cirium counts; Fox Business for the "1980s little copper lines" and $50 billion quotes; CBS News for its conflicting-information note.
• Opened the FAA's own statement on faa.gov ("preliminary and subject to change"). The Department of Transportation readout page and the Washington Times article returned HTTP 403 to our requests, so the "TDM telecom" quote is as reproduced from the DOT readout in search results and matches GeekWire's report of the same remarks; Washington Times claims are not used.
• Compared cancellation counts across sources; they differ by data provider and time of day, so each is attributed rather than combined.
• Not verified: the final root cause (not published), which equipment failed, and any claims circulating on social media.

Last tested: 2026-11-15

Sources

• FAA, Statement on Nationwide Ground Stop (13 November 2026): https://www.faa.gov/newsroom/faa-statement-nationwide-ground-stop
• U.S. Department of Transportation, ICYMI: Secretary Duffy announces lifting of nationwide ground stop: https://www.transportation.gov/briefing-room/icymi-us-transportation-secretary-sean-p-duffy-announces-lifting-nationwide-ground
• TechCrunch, Transportation secretary blames routine equipment upgrade for grounding flights nationwide: https://techcrunch.com/2026/11/14/transportation-secretary-blames-routine-equipment-upgrade-for-grounding-flights-nationwide/
• GeekWire, Officials blame aging FAA telecom gear as U.S. airspace reopens, see no link to Microsoft or AI: https://www.geekwire.com/2026/dhs-chief-sees-no-microsoft-link-to-faa-ground-stop-says-possible-ai-role-being-investigated/
• AVweb, FAA nationwide ground stop lifts: https://avweb.com/aviation-news/faa-nationwide-ground-stop-lifts-smart-ai/
• Scientific American, FAA grounds all U.S. flights days after expanding its AI air traffic system: https://www.scientificamerican.com/article/faa-grounds-all-u-s-flights-days-after-expanding-its-ai-air-traffic-system/
• NPR, FAA blames Friday's ground stop on "equipment issue" during telecoms network upgrade: https://www.npr.org/2026/11/14/nx-s1-6040952/faa-ground-stop-airplane-travel
• Fox Business, Duffy sounds alarm over aging FAA system after nationwide air travel shutdown: https://www.foxbusiness.com/politics/duffy-sounds-alarm-over-aging-faa-system-after-nationwide-air-travel-shutdown
• CBS News, FAA lifts nationwide ground stop: https://www.cbsnews.com/news/faa-issues-nationwide-ground-stop/