A backup connection can keep everything running while leaving a service one more failure away from an outage. September’s FAA fiber cut brings that uncomfortable distinction into focus: the backup was already in use when it was cut.
When flights stop, the visible story is passengers waiting at gates. The less visible story is the web of connections that allows people and systems to coordinate those flights. The FAA’s separate November 13 communications problems have put that infrastructure back in the headlines. Current reporting describes communications issues affecting multiple air traffic control centers; it does not establish a fiber cut as the cause. To understand one of the risks behind communications resilience, September’s confirmed incident offers a useful case to examine. The two events should not be conflated.
First the Switch. Then the Cut.
According to the FAA’s later account, reported by Reuters on September 23, warning messages led L3Harris to recommend moving a Philadelphia air traffic control connection to backup fiber on Sunday, September 20, while the original circuit was investigated. On Monday, a New Jersey Transit contractor accidentally cut the backup line near New Brunswick, New Jersey.
In plain English: the spare was already doing the job when it was damaged. That is why the order of events matters.
Our September article on the FAA fiber cut explored the value of physical network visibility. The later FAA account sharpens that discussion: understanding a network’s normal design is not enough. Teams also need to understand its condition after a fault, maintenance action or change.
Switching to backup is often exactly what a system is designed to do. The harder question comes afterward: while the service is running on its alternative, what happens if that alternative fails too?
The Spare-Tire Problem, at Infrastructure Scale
Imagine changing a flat tire and driving away on the spare. The car moves again. But until you repair or replace the damaged tire, you no longer have an unused spare for the next flat.
A network with two usable connections can face a similar situation. When one is taken out of service, the other may keep an airport, hospital or campus connected. Unless another suitable path is available, however, the service now depends on that remaining connection.
Conceptual illustration, not a reconstruction of either FAA incident. A successful switch can preserve service while reducing the protection that remains.
People using the service may notice nothing. Behind the scenes, its ability to absorb another failure has changed. That creates an important period of exposure: the time between moving to the remaining connection and restoring a verified alternative. We cannot calculate the likelihood of a second failure from the September reports, or infer every option available to the FAA. But we can identify the operating question other organizations should ask.
“Service restored” and “protection restored” need separate checkmarks. Someone must own the second one, with a clear plan for what happens before it is complete. Otherwise, “temporary” dependence on one connection can become a condition that nobody is actively resolving.
Two Roads. One Bridge. One Shared Problem.
Picture two roads to the same destination. They look like alternatives, until you discover that both cross the same bridge. If the bridge closes, the choice of road stops helping. Communications connections can have a similar hidden dependency, even when they come from different providers.
Federal communications-resiliency guidance warns that providers may share lines, conduits or facilities. In practical terms, two bills from two companies may still lead back to the same underground pipe or building. The physical route matters, not just the provider’s name.
These are two different failure patterns. One removes protection over time: a path becomes unavailable, leaving another to carry the load. The other can defeat multiple paths at once: a shared physical location is damaged. The September account supports examining the first pattern; it does not prove the second occurred.
Two different risks: one connection becomes the only usable path, or multiple paths depend on the same physical location. Conceptual illustration, not a reconstruction of either FAA incident.
For infrastructure owners, the useful question is therefore specific: Which cables, structures, equipment and providers does this service depend on, and which of those dependencies would the alternative avoid? Where the route is unknown, the honest answer is “not verified,” not “diverse.”
A Cable on a Map Is Only the Beginning
Suppose a construction crew damages a cable outside a campus. Finding that cable on a map is a start. The next questions are more consequential: What uses it? Which buildings or systems could lose their connection? Does the alternative avoid the damaged section? This is a general example, not a claim about what happened in either FAA incident.
Answering those questions means connecting the physical route to the fibers inside the cable, the equipment at each end and the services those connections support. A map, an equipment list and a spreadsheet may each contain part of the answer. During a disruption, assembling those pieces is work the team would rather have done already.
Start with the physical route: this netTerrain product example places recorded fiber connections in their geographic context. It is not an FAA or BWI network map, and a map alone does not verify that routes are independent. Click to enlarge.
This is a practical role for netTerrain OSP: bringing geographic routes, cables, strands, conduits, equipment and circuit records into connected views. Its mapping and tracing capabilities help teams investigate the relationships they have documented, rather than reconcile separate drawings and spreadsheets during an incident.
Then examine the connections inside the cable: this product example relates individual strands to named circuits and termination ports. It illustrates documented relationships, not live FAA or BWI service status. Click to enlarge.
The qualification matters: a clear picture of incomplete records is still incomplete. Documentation needs owners, updates after changes and field or provider verification where appropriate. Software supports those processes; it does not independently certify a buried route, prevent excavation damage or replace an operational recovery plan.
What Better Records Look Like in Practice: BWI Airport
Our customer BWI Airport offers a separate, concrete example. Our case study reports that netTerrain reduced the time required to document a circuit from approximately 30 minutes to less than one minute.
A closer look at physical infrastructure: netTerrain can bring conduit layouts, splice enclosures, connections and field photographs into a detailed view. This is a product example, not BWI’s network. Click to enlarge.
That result measures documentation work, not outage prevention. Its practical value is straightforward: maintaining a connection record becomes less burdensome. Keeping those records current helps put usable information in reach when someone needs to plan a change, investigate a fault or evaluate an alternative.
Why a Cut Cable Is Not a Quick Reconnection
A fiber repair is more involved than joining two visible ends. The Fiber Optic Association’s restoration guidance describes a sequence: determine whether the problem is equipment or cable, locate the damage, obtain safe access, and bring trained technicians with the right tools and compatible materials.
Damaged cable may need to be cut back. If there is not enough spare length, crews may need to insert a replacement section, creating a joint at each end. The affected fibers then need to be joined and tested. Temporary restoration and a completed permanent repair may be different milestones.
That helps explain the expense: specialized labor, access, replacement materials, joining and testing, plus the consequences of the interruption. There is no useful universal repair price or deadline. The FOA cautions against a meaningful average; the damage and availability of technicians and equipment can make a substantial difference.
Why Finding the Right Connection Can Be Expensive
The consequences of poor connection records extend beyond a repair crew’s invoice. Someone may need to travel to a remote site, inspect equipment, identify the correct connection and return with the right information before the work can proceed. Three more of our customers show why that effort matters in very different settings:
- Pitkin County: distance and difficult access. Its communications environment includes 13 mountaintop sites, 34 microwave hops and more than 1,800 radios. The county case study describes the burden of fragmented records and physical inspections. Making network and strand information accessible changes how much investigation requires a site visit.
- Pan American Silver: the cost of going underground. The mining company’s Ontario case study describes difficult physical access and underground work premiums. Detailed work orders helped reduce costly inspections.
- Notre Dame: answers before the trip. Its outside-plant case study describes staff previously traveling to verify connector types and available capacity. With documented information accessible from the office, the university reported answering questions in minutes rather than hours.
“In just five minutes, I have everything I need whereas before it could have been hours of running around.”
These are vendor-published accounts of documentation and operational improvements, not studies proving fewer fiber cuts or a particular reduction in outage duration. Their common lesson is narrower and useful: finding out what you have can itself be a costly part of the job. Better records can reduce that preliminary work before a technician starts the physical task.
The Conversation to Have Before the Next Failure
You do not need to be a network engineer to ask a useful question: “If the connection we are using fails today, what happens next?” The answer should be clear enough for both the technical team and the person responsible for the service.
- Before the switch: verify the alternative’s route, capacity and essential dependencies, not just its existence.
- While it is carrying service: identify who is restoring protection, what risks remain and when the condition will be reviewed.
- If it also fails: establish which services can continue, which must stop safely and who makes that decision.
NIST’s contingency-planning guidance supports testing and maintaining recovery plans. Physical safeguards matter too: documentation does not replace 811 notification, utility locating and safe excavation practices.
The answer will depend on the service, the available alternatives and the consequences of interruption. More connections are not automatically the right investment. In safety-critical settings, reducing or stopping operations can be the correct response when necessary protection is unavailable. The essential step is deciding those limits before an incident forces the conversation.
The question is not only “Did the backup work?” It is “What protection do we have left?”
September’s incident makes this lesson concrete. A successful switch can buy time. What the organization does with that time matters: restore a verified alternative, make the remaining risks visible and establish a safe operating plan until protection returns.
Learn about Graphical Networks’ 2026 IDC MarketScape recognition.
See how netTerrain connects geographic routes with the cables, strands and equipment behind your services.
Explore netTerrain OSP
Analysis based on reporting reviewed November 13, 2026. The September fiber cut and November communications problems are separate incidents. This is an analysis of general resilience principles, not a forensic finding about either incident or a claim that a product would have prevented it.
