When a software-as-a-service (SaaS) platform fails, it doesn’t just fail one customer; it fails whole sectors. That’s the security problem hiding inside organisations becoming more and more dependent on SaaS providers. Customers need to focus on resilience, availability and security. They should ask ‘Will it work when we need it, can we trust it with our data, and what happens when it fails?’ As AI makes it cheaper to write software, these become the real differentiator, not instead of being impressed by smooth functionality and slick interfaces.
We’ve just seen a very real example of risks in sectoral dependency on SaaS platforms. A breach in the Canvas learning management system in the first week of May 2026 exposed student records and took systems offline, affecting 275 million users at more than 8,800 institutions. Affected organisations in Australia included the Queensland Department of Education and top-tier universities such as the Australian National University, the University of Melbourne and the University of Technology Sydney. Learning and assessments were disrupted for several days until Canvas’s parent company, Instructure, said it had reached an agreement with the attackers to have the data destroyed. This has been widely assumed to mean that the company paid a ransom.
The incident brings home the question of how we have become so dependent on SaaS, and what expectations we should have of providers of such services. The journey to today’s concentrated, heavily outsourced service provider landscape has been a long one. Two decades ago, organisations were busy outsourcing back-office functions, based on the theory that a specialist could do it better and cheaper than an in-house team. Technology outsourcing came next, first to infrastructure as a service, in which cloud providers bought the hardware and rented it out. Over time, more of the stack was owned and managed by third parties, leading to platforms as a service and ultimately to SaaS. Under SaaS, the supplier provides the physical data centre, the hardware, the operating system and the software application, and rents out the whole package for users to remotely access and use. The proposition has been that specialists could deliver at scale in a way that in-house teams could not match, freeing customers to focus on their core business.
And this was very true. Few universities would want to build and maintain their own learning management system. The Canvas case makes this point unusually sharply, because any institution is free to download the source code and run its own instance at no licence cost. However, the overwhelming majority choose not to, instead paying Instructure for a managed, hosted version. This plainly shows they are not buying the software, but the hosting, integration, patching, round-the-clock availability and, supposedly, security.
But now we have seen the other side of the bargain. When thousands of organisations depend on a single system, even if that is physically distributed around the world, that system becomes an enormously attractive target. A system-level incident or attack becomes a major incident for an entire sector.
It will probably be some time before we know for certain why the security measures failed and hackers succeeded – but whatever the root cause, the outcome was that all the organisations using Canvas struggled to function when it became unavailable. Meanwhile, organisations hosting their own solutions were not swept up in the same incident. This difference should make us stop and reassess exactly we should expect from SaaS providers.
Nowadays, many SaaS providers market themselves on the basis of slick user interfaces, rich functionality and, more recently, integration with AI tools. However, the marginal value of features and slick interfaces is falling as AI makes code writing cheaper and faster. Building a high quality, consumer-grade SaaS application is no longer the multi-year undertaking it once was, leading some to predict the demise of the industry, a SaaS-pocalypse.
However, this framing misses what remains genuinely hard and genuinely valuable. This is everything that surrounds the code: running the service reliably at scale, defending it against capable adversaries, keeping it available when something goes wrong, supporting customers through incidents and demonstrating that the trust placed in the provider is warranted.
For customers, that means asking different, harder questions before signing contracts. How is the system secured? How do they minimise the risk of downtime? What fallbacks are available if the online system goes down? How quickly can service be restored if the worst happens, and what happens to customers’ data if they need to leave?
For providers, it means recognising that their competitive advantage will increasingly come from being demonstrably trustworthy, not from another animation on the dashboard. This is the argument that ASPI’s In Whose Tech We Trust framework makes about hardware and critical infrastructure.
The lesson of the Canvas breach is not that SaaS is a bad idea. It’s that customers need to change the questions they ask of their supply chain, and providers should expect future advantage to come from how they perform on the worst day, not from the next feature on the roadmap.
This article first appeared in the ASPI Strategist