I’ve been saying for years that vendor risk is not a checkbox exercise. I’ve been saying it in blog posts, in conference rooms, in papers, and presumably in my sleep. And then the Marquis vs. SonicWall lawsuit drops and it is the most perfect, catastrophic illustration of exactly that point that I could not have designed it better if I’d tried. Your firewall — the thing that is specifically supposed to prevent unauthorised access — became the instrument through which attackers got in. Because the firewall vendor didn’t secure their own backup service. I need a moment.

Per TechCrunch, Bleeping Computer, and Dark Reading, Marquis Software Solutions — a Texas-based fintech provider that serves dozens of US banks and credit unions — has filed suit against SonicWall in the Eastern District of Texas, alleging that a security breach at SonicWall’s cloud backup service directly enabled the August 2025 ransomware attack that hit Marquis’s network and exposed the data of roughly 400,000 Americans, including Social Security numbers, bank account details, dates of birth, and addresses.

The complaint’s key line is worth reading slowly: “SonicWall allowed a threat actor to obtain the keys to bypass that line of defense and walk right into Marquis’s internal network, the very thing that SonicWall’s firewall was supposed to prevent.”

I mean. What do you say to that?

What Actually Happened

Here is the attack chain as described in Marquis’s complaint and subsequent reporting from TechCrunch and Bleeping Computer.

In February 2025, SonicWall made a code change to one of its APIs. According to Marquis, this change “created a vulnerability exploitable by threat actors.” That vulnerability allowed attackers to access customer firewall configuration backup files stored in SonicWall’s cloud backup service “without proper authentication” — and they could do so by guessing predictable firewall serial numbers. Predictable. Serial. Numbers. Someone at SonicWall thought that was an acceptable authentication model for a service storing the configuration files of enterprise firewalls deployed in financial institutions.

These backup files contained emergency access codes — called “scratch codes” — that allow access to firewalls without the standard authentication process. Think of them as break-glass credentials. They’re supposed to be emergency-only, stored securely, accessible only to authorised administrators. Instead, they were sitting in a cloud backup service that could be accessed by guessing a serial number.

The attackers used those stolen scratch codes to bypass Marquis’s firewall entirely and walk directly into the internal network. From there, they deployed ransomware. Marquis began notifying affected customers in December 2025. The lawsuit was filed in late February 2026, and the vendor blame game — as Dark Reading’s headline neatly put it — is now officially in federal court.

The Scale of Who Got Hurt

Marquis is a fintech company that serves banks and credit unions. This is not a small-scale consumer data breach. The downstream impact cascades through the financial institutions Marquis serves, which means the people whose SSNs and bank account numbers are now somewhere they shouldn’t be are customers of multiple banks who had no direct relationship with Marquis and likely never heard of them before December 2025.

As reported across TechCrunch and LinkedIn coverage of the incident, at least 400,000 individuals were affected across numerous US banks and credit unions, with Texas alone accounting for over 354,000 victims. The full total may reach 1.35 million individuals. These people got a notification letter from their bank telling them their Social Security number and bank account details were exposed because a company called Marquis, which they’ve never heard of, used a firewall vendor called SonicWall, which they’ve never heard of, that had an API that guessed serial numbers as its authentication mechanism.

That is third-party risk materialising in the worst possible way. As I covered when writing about ShinyHunters burning SSO victims through Salesforce credential failures, the chain of trust in modern enterprise vendor relationships means that one compromised supplier can cascade damage through every customer they serve. The Marquis situation is the same structure, just with a firewall vendor in the Salesforce role.

The Root Cause Is So Stupid It’s Almost Impressive

Let’s go through what has to go wrong for this attack to be possible, because it’s instructive.

SonicWall builds a cloud backup service for customer firewall configurations. This is a genuinely useful feature — keeping backup copies of your firewall config means you can restore quickly after hardware failure. Fine. Good product thinking. But the service stores emergency scratch codes alongside the configuration files. And the authentication for accessing these files relies, apparently, on knowing a customer’s firewall serial number — which is not secret, is often visible on the physical hardware, and is in many cases predictable.

This is not sophisticated. This is a missing authentication control on a service storing extremely sensitive security credentials. It’s the kind of thing that should be caught in a basic security review of the service before it goes into production. Firewall serial numbers as the access control mechanism for firewall emergency codes is not a threat model. It’s an oversight.

I’ve written about vendor security failures cascading into client breaches before — most recently when covering how Conduent’s ransomware compromise exposed 25 million Americans through Safepay. The pattern is consistent: a vendor holds sensitive data about multiple clients, the vendor’s security is inadequate, and the damage fans out across every client simultaneously. The attacker doesn’t need to breach each target individually — they breach the shared vendor once and collect the keys to every client’s front door.

The IBM X-Force 2026 data that I covered — AI turbocharging attackers while your basics still suck — explicitly calls this out: adversaries are increasingly targeting shared infrastructure and common third-party dependencies because the return on investment is massively higher than attacking individual targets. One compromised backup service. Dozens of financial institutions. Hundreds of thousands of victims. That’s the maths attackers are doing.

And as I’ve written about at length in my research on Bitcoin, dark web, and extortion risk models, ransomware operators specifically look for targets that have exposure across multiple clients — the multiplier effect on damage and thus ransom leverage is a deliberate part of their targeting logic.

What Needs to Happen and Won’t Until It Does

The lawsuit is interesting. It’s potentially precedent-setting — Marquis is arguing that SonicWall’s negligent security practices directly caused their breach, and seeking damages. Dark Reading frames this as “the breach blame game” going to court, which is accurate, but undersells the structural significance. If vendors start being held financially liable for security failures that cascade into client breaches, the economics of vendor security investment change. Right now, security costs money and there’s limited financial consequence for shipping insecure products. Legal liability changes that calculus.

Whether Marquis wins or not, this case should be required reading for every CISO who has ever signed a vendor contract with indemnification language that basically says “if we get hacked and it ruins you, not our problem.” That language is everywhere. And it’s why vendors can ship a cloud backup service that authenticates on guessable serial numbers without meaningful consequence — until a federal lawsuit in Texas.

What You Do to Avoid Being Marquis

First: audit your vendor relationships right now. Every vendor that holds your configuration data, credentials, keys, or access mechanisms is a potential attack vector. Marquis trusted SonicWall to secure backup files that contained emergency access codes to their own firewalls. What are your vendors holding on your behalf, and what’s their security posture?

Second: as I’ve written before, your device’s IP exposure and the way credentials are stored around perimeter devices matters enormously in the attack chain here. If scratch codes and emergency credentials exist, they need to live in a secrets manager with proper authentication — not in a vendor’s backup service accessible by guessing serial numbers.

Third: specifically for financial institutions and other regulated industries with extensive vendor ecosystems — your third-party risk programme needs to include technical security assessments of how vendors store and protect data derived from your environment. SOC 2 Type II reports and security questionnaires are not sufficient. Someone needs to ask “how does your backup service authenticate access to the backup files?” and actually verify the answer.

Fourth: ransomware response planning needs to explicitly account for vendor-originated breach scenarios. If a shared vendor is compromised, your incident response timeline may be compressed significantly because the attacker already has your access credentials before you know anything has happened. The “detect, contain, eradicate” model assumes you have a detection window. In this attack, Marquis may have had zero detection window between the SonicWall breach and the ransomware deployment.

Fifth: read your vendor contracts. Find the indemnification clauses. Understand what happens if your vendor’s negligence causes your breach. If the answer is “nothing, you bear all the cost,” consider whether that’s an acceptable risk to carry.