Orange outage: when redundancy fails — and what it means for your business

Wednesday morning, your sales team stops placing calls. Deliveries are coordinated by guesswork. Your IT lead waits for login codes by SMS — and they never show up. It is not your LAN that failed: it is the mobile carrier half your staff rely on. On 21 October 2026, Orange — and its Sosh brand — acknowledged a major mobile network outage in France. Franceinfo quoted the operator: calls, SMS, and mobile data disrupted for part of the customer base; the incident was tied to faulty core network equipment. Orange ruled out a cyberattack and told 01net the issue sat on its new mobile core. Service was declared restored in the evening (around 9 p.m. for the longest-affected subscribers, after problems from roughly 11:20 a.m.).

Two identical sites are not two backups

What surprised specialists was not only duration: redundancy did not hold. ZDNet France describes a software bug on Nokia core gear that authenticates SIM cards. Backup nodes ran the same software version as primaries, so failover spread the failure instead of isolating it. Jérôme Hénique, CEO of Orange France, told Le Figaro the event was unusual because “redundancy did not work.” In your company, the mirror is mundane: two links from the same carrier, two servers patched the same night, two factors that both depend on the same SMS gateway.

A “green” network is not a working service

A Journal du Net column (29 October) stresses a classic trap: signal bars or a successful ping do not prove a user can authenticate, open a session, or reach a line-of-business app. The same applies internally: DNS, identity, or certificates can block work while the switch looks fine. Useful monitoring tracks transactions — sign-in, case opened, order validated — not just component uptime.

Coming back fast can extend the outage

When service returns, clients and apps retry en masse. That reconnection storm can saturate what just restarted — familiar on APIs and databases too. The JDN piece highlights retry limits, staggered recovery, and tracking useful throughput rather than restarted processes. For an SMB, that means simple rules: do not relaunch the same ERP twenty times, prioritise critical flows, defer what can wait an hour.

• Map one dependency: if the mobile carrier fails, who still gets alerts? Who can reach the cloud provider?
• Exercise break-glass access without the channel that just failed (SMS-only admin, for example).
• Decide before the crisis who can roll back after a recent change — not “when we finally reach the director.”
• Measured drill: deliberately cut mobile for one team for half a day and time recovery of one essential business transaction.

If you have never simulated a carrier outage or critical access depends on SMS alone, we can talk it through — fifteen minutes is often enough to list the weak links.