Let me be clear from the outset: this is not an argument against upgrading. Progress matters. New capabilities matter. Security improvements matter. What’s dangerous is not upgrading, but upgrading by reflex, on someone else’s timeline, in the hope that motion equals safety.
That distinction matters, because recent events have shown what happens when choice, visibility and judgment quietly disappear.
Co-Founder & Chief Innovation Officer at Origina.
When Airbus grounded A320-family jets over a flight-control fault linked to solar radiation, it looked like a niche aviation issue. It wasn’t. It was a reminder that even industries built on obsessive safety engineering and change control can be exposed by software risk buried inside critical dependencies.
And if that can happen in aviation, with its redundancy, certification and discipline, it should give every CIO cause for pause.
We’ve seen the same pattern play out elsewhere. The CrowdStrike update that rendered millions of Windows machines unusable. The Cloudflare outage that rippled across large parts of the internet.
In each case, a change or failure introduced far upstream triggered immediate consequences downstream. But the deeper issue wasn’t simply the update. It was the dependency, and the assumptions that came with it.
Hidden dependencies and inherited risk
In the Airbus case, modern fly-by-wire aircraft are inherently dependent on tightly integrated software systems. When those systems encountered a failure mode they were not sufficiently hardened against, there was no simple operational escape hatch.
Aircraft were grounded not because engineers were careless, but because safety demanded certainty, and certainty required change before flight could resume. Cloudflare tells a similar story at internet scale.
Cloudflare runs a strong operation and provides critical services. They are not the villain here. But a vast portion of the internet now depends on a small number of shared infrastructure providers for DNS, routing, security and availability.
Organizations that design their services to rely entirely on those platforms inherit their failure modes. When a core service falters, there is often no graceful degradation, just a very hard stop.
This is the uncomfortable reality of modern IT estates. Dependency is not free. When capability is outsourced, control is diluted. Unless systems are intentionally designed with resilience, diversification and fallback in mind, organizations quietly absorb risks they may not fully understand.
Technical leaders must be explicit about what they depend on, how those dependencies fail, and what happens when they do.
Disruption that crosses the line into safety
This is where disruption stops being an inconvenience and becomes a safety issue. Hospitals, emergency services, utilities and financial markets increasingly operate on layers of software stitched together over decades.
Integrations pile up, accountability fragments, and no one has full visibility of end-to-end impact. In that environment, even “routine” change can carry real risk.
A vendor update or external outage can delay access to patient records, disrupt dispatch systems or interrupt services people rely on in moments that matter. Aviation assumes change is dangerous until proven otherwise. Many digital estates still assume change is safe until something breaks.
Yet the dominant narrative remains unchanged: stay current, move fast, trust the vendor.
That narrative is reinforced by incentives. Vendors are rewarded for upgrade momentum. Support models, revenue and product strategies depend on it. The downstream operational impact, retesting safety cases and retraining staff, sits entirely with the customer.
That’s where greed shows up. Not as malice, but as indifference baked into the business model. The people pushing change do not feel the consequences when it goes wrong.
Choice, not obedience, should drive upgrades
Upgrades are optional. They should happen only when an organization wants the new capability they deliver, not because a vendor declares a version “unsupported.” Software does not carry a best-before date.
There is a dangerous belief embedded in modern security practice that once the latest patch is applied, the risk has been addressed and the job is done. In reality, patching is just one possible response to risk, and sometimes the wrong one.
A patch may reduce exposure, but it can also introduce instability, new vulnerabilities or entirely new failure modes.
The strongest form of defense is not speed, but understanding. Knowing what you are exposed to, how that exposure manifests in your environment, and which controls or mitigations actually reduce risk in practice. That requires evidence, not assumptions. Too often, patching becomes a ritual rather than a decision.
Regulatory pressure can even unintentionally reinforce this behavior. Frameworks designed to improve resilience are sometimes reduced to “apply the latest fix and move on.” Compliance becomes a checkbox.
Assurance becomes performative. A freshly patched system can still be poorly understood, poorly monitored and poorly defended.
Risk should be managed deliberately, using the controls that make sense for your architecture and operating model. Sometimes that includes upgrading. Often it means isolating, compensating, hardening or monitoring instead. Evidence, not fear or vendor pressure, should drive the decision.
CIOs may not be able to change vendor incentives, but they can change their own posture. The real upgrade the industry needs is not a new software version. It is a mindset shift, from compliance to comprehension, from speed to substance, and from “patched” to “resilient.” Because snake oil and critical systems still do not mix.
We’ve featured the best online cybersecurity course.
This article was produced as part of TechRadarPro’s Expert Insights channel where we feature the best and brightest minds in the technology industry today. The views expressed here are those of the author and are not necessarily those of TechRadarPro or Future plc. If you are interested in contributing find out more here: https://www.techradar.com/news/submit-your-story-to-techradar-pro
https://cdn.mos.cms.futurecdn.net/S2k99RTyJJhGbDwQRHUsyg-970-80.jpg
Source link
