On the morning of December 6, 2018, roughly 32 million O2 UK subscribers picked up their phones and found the data plane gone. Voice worked. SMS worked. Anything that touched the packet-switched network — maps, banking apps, Uber, WhatsApp, email — did not. The outage was not a cable cut, not a DDoS, not a config push. It was a single expired software certificate inside a piece of Ericsson network gear that neither Ericsson nor O2 had a monitor on.
The same certificate was deployed in the same product across eleven countries. SoftBank Japan lost tens of millions of subscribers on the same day for the same reason ( The Register, December 6 2018, retrieved 2026-09-03). Sprint and other operators around the world felt echoes.
O2 later sought approximately £100 million in damages from Ericsson ( iTnews, December 2018, retrieved 2026-09-03). The industry calls this incident a certificate outage. It is, but the framing under-sells it: this was a certificate outage at telecom scale that changed how regulators, insurers, and the CA/Browser Forum think about certificate lifecycle.
The day it happened
O2's data services died at approximately 05:30 UTC on December 6, 2018. Subscribers on the O2, giffgaff, Tesco Mobile, Sky Mobile, and Lycamobile brands (all riding the O2 core network) lost 3G and 4G data simultaneously. Voice and SMS stayed up because they ride the circuit-switched side of the network, which does not depend on the same certificate chain.
Symptoms first surfaced in customer forums and social media. On the operator side, engineers saw the SGSN-MME nodes — the piece of infrastructure that authenticates and routes packet-switched traffic — throwing certificate errors on inter-component TLS. The gear stopped accepting sessions. Every attempted attach failed. Existing sessions expired at their normal lease intervals and could not renew.
The 24-hour timeline
Reconstructed from The Register and iTnews reporting in December 2018.
- 05:30 UTC, Dec 6 — SGSN-MME nodes across O2's UK core reject inter-component TLS. Data services fail simultaneously across the operator's footprint.
- 07:00 UTC — SoftBank Japan reports the same failure at scale. Analysts trace the dependency: both operators run the same Ericsson SGSN-MME release.
- ~11:00 UTC — Ericsson identifies the expired software certificate as the root cause. A patched software build with a renewed certificate is prepared for emergency deployment.
- Afternoon UTC — Ericsson pushes the fix. Operators begin restoring service in priority order.
- Late night UTC, Dec 6 → Dec 7 — O2 UK restores data services for the majority of subscribers.
- Dec 7 — Full recovery. Both O2 and SoftBank publicly attribute the outage to Ericsson software ( iTnews, December 2018, retrieved 2026-09-03).
Total data-plane downtime for the average O2 UK subscriber: roughly 24 hours. Total Ericsson equipment affected: 11 countries. Total certificate involved: one.
The root cause — one expired software cert
Modern telecom gear uses TLS internally. The SGSN-MME control plane authenticates to other network functions with certificates issued by a private CA embedded in the vendor's software distribution. Those certificates have their own expiry dates, unrelated to any public web-facing cert your users would ever see.
The certificate in the affected Ericsson build expired on December 6, 2018. Because the cert was inside the software distribution and the software distribution had not been updated on a schedule that anticipated the expiry, the failure was invisible to any monitor watching public-facing certificates. There was nothing wrong with O2's public web SSL. There was nothing wrong with the cert chain on the customer-facing portal. The failing cert had never been visible to anyone outside the Ericsson supply chain — until it stopped working.
This is the specific class of failure a public-cert monitor cannot catch. It is also the class of failure that a monthly certificate inventory — vendor-supplied gear included — would have surfaced weeks ahead.
The £100M bill
In the aftermath, O2 pursued Ericsson for approximately £100 million in damages. The figure combines direct SLA credits owed to O2's own subscribers (an estimated £5 per affected customer under the operator's compensation policy), lost revenue from prepaid customers who could not top up during the outage, brand and churn cost, and knock-on effects to O2's business customers and MVNO partners ( The Register, December 6 2018, retrieved 2026-09-03).
Ericsson's public financial disclosure in Q4 2018 booked a provision for the outage; the settlement was not fully disclosed. The precise number matters less than the shape of the claim: a certificate expiry on inter-component TLS became a nine-figure liability for the vendor and a nine-figure interruption for the operator. Neither party was doing anything exotic. Neither party had a certificate monitor on the failing surface.
Why "auto-renew" fails for real infrastructure
Most engineers hear "certificate expiry" and think Let's Encrypt or AWS ACM — two systems where auto-renewal is a solved problem. The O2 outage was neither. The failing certificate was inside a vendor's proprietary software distribution, tied to a build number, and renewed by shipping a new software release. There is no ACME challenge. There is no auto-renew cron. The renewal path is vendor patch management.
Same story shows up across every enterprise stack, not just telecom:
- Kubernetes ingress controller certs — most set up with cert-manager, but the controller pod itself often uses a bootstrap cert that expires quietly.
- Load balancer management certs — the cert on the LB's own admin plane is different from the cert on the services it fronts. Auto-rotate rarely covers the management plane.
- VPN concentrator IKE certificates — 3-year lifetimes, no auto-rotation on many appliance models. Renewal is a scheduled maintenance window.
- Client certificates for mTLS between microservices — SPIFFE and cert-manager cover the well-designed case; the reality in most production estates is a mix of hand-rolled scripts, SREs' laptops, and one Confluence page from 2020.
- Code-signing certificates — dev signs binaries with a cert that expires; the binary keeps running but new signatures fail; installers fail on new machines only. Detection delay: weeks.
Every one of these is invisible to a monitor pointed at the public web-facing hostname. Every one has landed as a customer-visible outage in a public post-mortem in the last five years.
Why 47-day certificates make O2 a rehearsal
Public TLS certificates have been on a shrinking-lifetime trajectory since 2015:
- 2015 — 39 months max
- 2018 — 27 months max
- 2020 — 398 days max (13 months), Apple-forced
- 2029 — target 47 days max, CA/Browser Forum Ballot SC-081
In April 2025 the CA/Browser Forum passed Ballot SC-081v3 (retrieved 2026-09-03), which phases certificate maximum validity down to 47 days by March 15, 2029. Intermediate steps: 200 days by 2026, 100 days by 2027, 47 days by 2029.
What this means operationally: any certificate you renew today on an annual manual process needs to be automated by 2029. There is no supported path where a human touches a cert eight times a year across a production estate of any size. The organisations that survive this transition are the ones with a certificate inventory today.
Ericsson's failure in 2018 was a certificate the operator did not know existed. In a 47-day world, every certificate whose renewal path is not fully automated and monitored is a candidate to become the next O2. See the SSL certificate primer for the protocol mechanics and the SSL/TLS glossary entry for the terms.
What SMBs miss that Ericsson missed
A small operator with 50 domains reads this incident and concludes it does not apply — Ericsson is a global vendor, O2 is a national operator, we're just running a webshop on Cloudflare with Let's Encrypt in front of it. The mistake is the same one Ericsson made: assuming the certs you can see are the only certs that matter.
- You have vendor SaaS with your certs on it. Zendesk, Shopify, HubSpot, Intercom — all serve your subdomain with a certificate that they manage. When that renewal fails, your support portal goes down and you find out from a customer email.
- You have subdomains you don't remember provisioning. Every apex domain accumulates subdomains over time. Marketing stood up
events.brand.comtwo years ago on Netlify. The DNS still points there. The Netlify cert may or may not still be valid. No one is watching. - You have client-facing certs on non-web protocols. IMAP, SMTP-TLS, MTA-STS all use certificates. A DMARC-forwarded email that hits your MTA-STS-protected mail host with an expired cert bounces. The sender's DMARC report shows the failure days later.
- You have code-signing and API-gateway certs. Internal, unglamorous, invisible. The build breaks; the API gateway starts throwing 502s; the on-call engineer spends two hours tracing before anyone looks at the cert chain.
The fix is not exotic. Inventory every certificate that touches anything customer-facing, even indirectly. Set the alert threshold to 30 days out for renewals under human control and 7 days out for renewals under automation (which sometimes fails silently). Monitor at the per-host level, not the apex level.
FAQ
How could one expired certificate take down 11 countries?
The same Ericsson SGSN-MME software release was deployed at operators in eleven countries. The certificate that expired was embedded in that release — not per-operator. Every operator on that release hit the same expiry at the same second. Software-supply-chain concentration risk in one number.
Why did voice and SMS stay up while data went down?
Voice and SMS ride the circuit-switched side of the mobile network. Data rides the packet-switched side. The Ericsson SGSN-MME is a packet-switched component. Different certificates, different chains, different failure modes. In a modern VoLTE deployment this separation is thinner and the same failure would probably take voice with it too.
Would an ACME auto-renewal have prevented this?
No. The expired certificate was inside proprietary vendor firmware, issued by a private CA, tied to a software build. ACME is a protocol for issuing publicly-trusted certs to services you control. The Ericsson cert was neither publicly-trusted nor issued to anyone with an ACME endpoint. Only a certificate inventory that covered vendor-supplied gear would have caught it.
Is £100M an accurate figure for the damages?
It is the figure O2 publicly pursued according to contemporary reporting. The final settlement between O2 and Ericsson was not fully disclosed. Ericsson booked a provision in its Q4 2018 financial statements consistent with a large multi-operator claim. The precise final number is private; the order of magnitude is public.
What's the 47-day certificate rule and when does it start?
The CA/Browser Forum passed Ballot SC-081v3 in April 2025, phasing publicly-trusted TLS certificate maximum validity down over four years: 200 days by 2026, 100 days by 2027, 47 days by March 15, 2029. It applies to certificates chained to browser-trusted root CAs. Internal private CAs (like the one that failed at Ericsson) are unaffected by the ballot but still subject to whatever policy the operator chooses.
What is the fastest way to get a certificate inventory across an estate?
Certificate Transparency logs cover every publicly-trusted certificate ever issued for your domains. crt.sh exposes this as a free JSON API. Combined with a subdomain enumeration pass (CT + brute-force wordlist), you get a first-pass inventory in under an hour. The gap is vendor-supplied gear — appliances, internal PKI, embedded certs — which do not touch CT. Those require a management-plane inventory separately.