JPMorgan Chase’s top cyber cop has fired a warning shot across the digital economy, calling out SaaS as a systemic risk with the potential to trigger catastrophic and systemic failure.
The bank is the world’s fifth largest, with total assets of US$4trillion. It also houses the world’s highest-grossing investment bank, and sits comfortably within the top echelon of the Fortune 500. In other words, its warnings will reverberate.
In an open letter to the bank’s sprawlingthird-party supply chain, Chief Information Security Officer Patrick Opet saidthe very architecture of software-as-a-service, now the backbone of marketing, CX, and commerce, is enabling cyber attackers and creating single points of failure that pose catastrophic and systemic risks.
And with AI and automation piling on new risks, the world’s fifth-largest bank says the clock is ticking for urgent reform.
What’s more he acknowledges the first-hand impact on the financial services giant’s own operations.
According to Opet, over the past three years, its third-party providers have experienced “a number of incidents within their environments,” prompting the bank to act “swiftly and decisively,” including isolating compromised providers and dedicating substantial resources to mitigation.
That detail suggests that at JPMorgan Chase, software-as-a-service (SaaS) is now firmly viewed asa heightened structural risk.
“The modern ‘software as a service’ (SaaS) delivery model is quietly enabling cyber attackers and – as its adoption grows – is creating a substantial vulnerability that is weakening the global economic system,” he says.
Opet argues that, the global shift to SaaS has created “single points of failure with potentially catastrophic systemwide consequences.” The inherent risk lies not in the concept of SaaS itself, but in how it is implemented and integrated across modern enterprise environments.
Layer cake mistake
It's an issue familiar to Chris Brinkworth, managing partner at Civic Data, a specialist privacy consulting firm with a fast growing footprint in the FSI and health sectors. "In many modern marketing environments that we assessmultiple tools are layered atop each other – each introducing new scripts, cookies, or integrations. Over time, this sprawl has become unmanageable, with overlapping functions going unmonitored or even forgotten," per Brinkworth.
"Basic marketing pixels, for example, often incorporate code from third-party providers that update behind the scenes. What was once deemed secure or compliant can silently morph into a vulnerability as new features are added, third-party libraries change hands, or host providers alter their configurations."
Brinkworth told Mi3the challenges faced by home-grown financial services firms (FSIs)parallelexactlyJPMorgan's isconcerns, but with some unique challenges layered atop. "Here, however, we have APRA's CPS 230– whichdemands robust third-party risk management."Yet, he says, the company's'privacy' audits consistently reveal even basic marketing pixels that were secure upon implementationhave oftenevolved to introduce precisely the dependencies CPS 230 (unrelated to Privacy)seeks to govern."Risk, Securityand other teams are unaware of the exposure –even if 'Privacy teams' may have picked up on it."
He further notedthat marketers are often blindsided to learn that hashed emails and phone numbers used in personalisation and adtech campaigns also fall squarely under APRA's CPS 234 when re-identification is possible – which it nearly always is with modern data analytics - and he says thisis also why Privacy Commissioner Carly Kind and the November's OAIC guidance on pixels, focus on individuation and identifiersfrom an AustralianPrivacy Principles perspective.
"This creates a dual compliance burden where even seemingly 'anonymised' customer identifiers require the same rigorous security controls as plaintext data, particularly for financial institutions already scrambling to manage exploding third-party dependencies, he said.
Concentration, complexity, collapse
JPMorgan Chase'sOpet warned industry is walking itself down a blind alley:“SaaS has become the default and is often the only format in which software is now delivered.”
Heavy reliance on a limited set of providers embeds concentration risk into global infrastructure. While it brings efficiency and innovation, the trade-off is fragility. In previous eras, he noted, software lived in dispersed environments with unique controls, limiting the blast radius of any compromise.
Now, an exploit at a single SaaS provider can cascade across its entire customer base, creating a domino fallout effect.
But concentration is only one vector. Modern SaaS integration patterns, according to Opet, are eroding long-standing security architectures. Where firms once maintained strong segmentation between internal systems and the outside world – via protocol termination, tiered access, and logical isolation – the shift to cloud-based services and identity federation has dismantled those controls.
He describes a scenario in which an AI-driven calendar tool uses “read-only roles” and “authentication tokens” to directly access a firm’s email system. While this setup improves productivity, if compromised, it grants attackers “unprecedented access to confidential data and critical internal communications.”
What could possibly go wrong?
Per Opet, quite a lot.
“In practice, these integration models collapse authentication (verifying identity) and authorisation (granting permissions) into overly simplified interactions, effectively creating single-factor explicit trust between systems on the internet and private internal resources. This architectural regression undermines fundamental security principles that have proven durability."
Move fast, break things ... Oops
At the heart of Opet’s letter is a warning to software vendors: the relentless drive for feature releases is exposing customer ecosystems to avoidable risk. Security, he argues, must be “built in or enabled by default.”
“Fierce competition among software providers has driven prioritisation of rapid feature development over robust security,” he writes. “This often results in rushed product releases without comprehensive security … creating repeated opportunities for attackers.”
Compounding the problem are weak authentication mechanisms, opaque fourth-party dependencies, and “software providers gaining privileged access to customer systems without explicit consent or transparency.” The proliferation of new services in automation and AI only amplifies these risks.
Opet quotes Microsoft Threat Intelligence, which recently observed that Chinese state actors are now targeting common IT tools like remote management and cloud apps to gain footholds in enterprise systems.
Rebuilding trust in the stack
To mitigate the growing threat, Opet calls for urgent reform. Providers must prioritise demonstrable security effectiveness, not annual box-ticking compliance. Customers should demand default-secure configurations and better transparency. The ecosystem, he argues, must reject brittle integration models outright... unless safer alternatives are available.
He points to technologies such as confidential computing, customer self-hosting, and bring-your-own-cloud as viable paths to restoring customer control. (Suggestions whichprompta multitude of Perplexity searches.)
“We must establish new security principles and implement robust controls that enable the swift adoption of cloud services while protecting customers from their providers' vulnerabilities," per Opet.
"Traditional measures like network segmentation, tiering, and protocol termination were durable in legacy principles but may no longer be viable today in a SaaS integration model. Instead, we need sophisticated authorisation methods, advanced detection capabilities, and proactive measures to prevent the abuse of interconnected systems.”
The most dangerous aspect of customer experience technology is its dynamic nature – a simple pixel deemed secure three years ago can often become a significant vulnerability todayortomorrow through automatic updates, creating challenges for compliance with both operational resilience requirements for APRA (when it comes to FSI) as much as the OAIC's privacy framework
— Chris Brinkworth, Managing Partner, Civic Data
