On Thursday 12 November, around six in the evening UTC, Microsoft's Exchange Online started failing. Outlook went with it, and so did Teams meetings and chat, Intune, Defender for Office 365, Copilot and the admin centres that IT teams would normally use to diagnose the problem. More than a day later, Microsoft was still writing: "We do not have an ETA for full recovery yet." (The Register)
For most companies that meant a lost Friday. For some organisations it meant more. The Los Angeles County Sheriff's Department said the outage was disrupting its email and other communication platforms. The City of Austin's employees couldn't send or receive email. Some NHS hospitals in the UK reported email disruption, and government ministries in Japan posted paper notices to tell journalists their schedules (Gizmodo).
O-LINKMicrosoft said it saw no sign of malicious activity. That is the point. If an ordinary fault at one vendor can do this, consider what a deliberate cut, a storm, a power failure or a jammer does to the same chain.
Critical infrastructure runs on a borrowed voice
Power, water, ports, dams, hospitals and emergency services have spent years hardening their operational technology: redundant feeds, backup generators, segmented control networks. Yet the way their people actually talk to each other, the messages, the call-outs, the "who's on site?", usually runs on a commercial cloud and a commercial cellular network, end to end. Both sit outside their control. Both fail together in exactly the situations they are meant for.
- The cloud fails on its own schedule. November's outage was one of several Outlook incidents this year. You don't get a say in when it happens or how long it lasts, and the tools you would use to work around it may be down too.
- Cellular fails where you need it most. Rural sites, valleys, tunnels and plant rooms never had good coverage. In an incident the network is overloaded by the crowd, cut by the damage, or switched off on purpose.
- Disruption is now a tactic. Drone incidents at critical sites come with jamming, power cuts and overloaded cellular. A detection or a call-out that can't reach the people on the ground is not much use.
UK MP Dame Chi Onwurah, who chairs the Commons Science and Technology Committee, said the outage showed "the dangers that this dependency can pose to our security, economy and public services" (The Register). She is right, and for critical infrastructure the answer isn't a second cloud. It is communications that don't depend on anyone else's cloud at all.
What "your own platform" should mean
Owning your communications doesn't mean building a telecom network. It means four properties that a commercial service can't promise:
- No single point of failure. No central server that, when it stops, stops everyone.
- Any link that survives. Internet when it is there; site Wi-Fi with no internet; phone to phone; radio; satellite. The system should pick whatever works, on its own.
- Encrypted on the device. Whatever carries the message, a relay, a radio, a teammate's phone, should only ever see ciphertext.
- Under your direct control. Your organisation enrols the phones, sets the rules, can revoke or wipe a lost device, and hosts any server the system uses. No vendor can switch your team off.
How O-LINK does it
O-LINK is our answer, built for exactly these teams. It runs on the Android phones and iPhones your people already carry, and it doesn't rely on any single network. It has several layers of redundancy, and it moves a message to whichever one is still working:
And around that, everything a team needs in an incident:
- Nothing gets lost. A message waits on a teammate's phone until a path to its recipient appears. SOS and emergency traffic go ahead of everything else.
- End-to-end encrypted, always. Messages, push-to-talk voice, calls, positions and files are encrypted on the phone before they leave. It can't be switched off.
- Yours to run. Enrol a team with one QR code, push team rules, see each phone's status, revoke or wipe a lost device, and keep an audit log of metadata, never content.
- Your own relay, on your own servers. When phones are too far apart for a direct link, an O-LINK relay carries their encrypted traffic over cellular data or the internet and holds messages for a phone that is away. You can host that relay yourself, on-premises or in your own data centre, so even the long-distance path runs on your infrastructure, not through Teams, Slack or anyone else's cloud. The relay only ever sees ciphertext.
- Made for incidents. Push-to-talk in every chat, urgent alerts that ring through silent until someone takes them, SOS and man-down, last-known positions on a shared map, and voice and video calls phone to phone.
On Thursday night, a team on O-LINK would have kept talking: across the site over Wi-Fi and phone to phone, and between sites over cellular through a relay in its own server room. Not because it had a better cloud, but because it had none to lose.
Data sovereignty: your messages stay yours
Availability is half of it. The other half is who holds your data. When a utility's call-outs, incident chatter and staff locations live in a foreign provider's cloud, they sit under that provider's terms, in that provider's data centres, and under the laws of the country it answers to. For critical infrastructure, that is a national-security question, not just an IT one.
- Keys stay on the phones. Messages, voice, positions and files are encrypted on the device, and only the intended phones can read them. No server, ours included, holds a key.
- Servers where you choose. Host the relay in your own building, your own data centre or your own country. Nothing about your team's traffic has to leave your jurisdiction.
- Metadata under your roof. The admin console's audit log records who did what, never content, and it stays with your organisation.
- No third-party platform in the loop. No Teams, no Slack, no consumer messenger: nobody else's outage, policy change or data request decides whether your team can talk.
- Not even plain SMS. The usual fallback for call-outs is text messages, but SMS isn't encrypted end to end: the carrier can read it, a sender can be spoofed, and it rides the same cellular network that fails first. When O-LINK uses SMS or satellite SMS as a link, it carries the same encrypted packets as every other link.
Now available: your system alerts on every phone
The same mesh that carries a message can carry an alarm. O-LINK already turns counter-drone detections into emergency alerts on every enrolled phone, over SAPIENT, with no network dependency anywhere in the chain. As of O-LINK 0.2.80 it does the same for syslog, the standard log format that firewalls, routers, SCADA gateways, UPSs and servers already speak.
- Point your devices at the O-LINK bridge. It sits on your site network and takes syslog over UDP or TCP, in both the classic and the current format. No cloud service in between.
- Critical events reach every phone first. Emergency, alert and critical go out at emergency priority, with a red banner and vibration, over phone-to-phone links, site Wi-Fi or radio, even when the corporate email and chat that would normally carry the alert are the thing that's down. Errors follow at normal priority. You choose where the line sits.
- A noisy device can't flood the mesh. Repeats of the same message are merged into one alert with a count.
- One person takes it. Anyone can claim the alert with one tap, so the team knows who's on it.
If you'd like to see it on your site, tell us what sends your logs.
The question to ask this week
If your email, your chat and your carrier network went down together tomorrow morning, how would your control room reach the person at the far end of the site? If the answer involves someone else's data centre, it's worth fixing before the next outage, not during it.
— Baruch
Keep your team talking when the network doesn't
O-LINK is free for teams up to 50. We'll help you set up a pilot on your site, with your phones.