How a Marquis Software Solutions firewall backup exposed 74 banks

On August 14, 2025, Marquis Software Solutions detected a ransomware attack on its internal systems. Most financial institutions running third-party software had done their due diligence: vendor assessments, contract reviews, MFA enforced at every layer. None of it was structurally relevant to what happened next.

The breach didn't come through any of those controls. It entered through a cloud backup tool Marquis used to manage its own firewall, a dependency so far upstream that none of Marquis's banking clients could see it, let alone control it.

This post covers what happened and what it means for your environment. Your perimeter controls are only as good as the perimeter they cover, and when the attack enters through your vendor's vendor, that perimeter was never in scope.

TL;DR

• What happened: Attackers accessed SonicWall's cloud backup environment, extracted Marquis's firewall credentials and MFA bypass codes, and walked into Marquis's network, stealing financial data from at least 74 banks and credit unions and approximately 1.64 million individuals

• Why it matters: The affected institutions had no visibility into this attack vector and no ability to prevent it. Their own security controls were bypassed before the breach ever touched their environment

• What to do: Prevention-only strategies don't address this risk class. You need recovery and continuity infrastructure that operates independently of your vendor's environment, in place before the incident, not after

Stolen firewall credentials turned a security tool into the breach vector

Marquis alleged in federal court that attackers had accessed SonicWall's MySonicWall cloud backup environment. Stored inside those backup files: Marquis's firewall network configurations and emergency MFA scratch codes, the exact credentials needed to bypass multi-factor authentication entirely and walk directly into Marquis's network.

The security tool built to protect Marquis's perimeter was the perimeter breach.
From there, the cascade was immediate. Marquis served over 700 banks, credit unions, and mortgage lenders. At least 74 were hit. Stolen data confirmed in state attorney general filings included names, addresses, Social Security numbers, Taxpayer Identification Numbers, bank account details, and debit and credit card numbers. Cumulative downstream notifications reached approximately 1.64 million individuals by February 2026.

None of those 74 institutions came into contact with the attack surface itself. Yet, the breach entered through a vendor dependency they couldn't see, and by the time it reached them, it was already too late.

Marquis detected the breach on August 14, but first public reporting didn't land until December 3, 2025, 111 days later. Individual institutions were notified earlier — Community 1st Credit Union got word on August 14 — yet the full scope kept expanding for months.

By February 2026, Marquis was suing SonicWall. By April, it was defending more than 36 consumer class action lawsuits. The breach was done. The consequences were just getting started.

» Assess how exposed your institution is to third-party vendor risk with this quick evaluation.

This is what downstream vendor dependency risk looks like at scale

Marquis isn't an isolated case. Verizon's 2025 Data Breach Investigations Report found that third-party involvement in breaches doubled year-over-year, from 15% to 30% of all reported breaches. Marquis is that statistic with a name attached.

"SonicWall initially told customers fewer than 5% were affected. It later confirmed the breach had reached every customer who had ever used its cloud backup feature."

That pattern, initial minimization and subsequent expansion, is consistent across every major third-party breach on record. The full blast radius is almost never visible from the inside until it's too late to change it.

Had your business been one of those 74 institutions, your firewalls, your MFA policies, your access controls, none of it would have had jurisdiction over the SonicWall cloud environment where this attack originated. The affected institutions were breached through a dependency chain they had no visibility into and no contractual relationship with. They were collateral damage.

In July 2024, CrowdStrike demonstrated exactly that at scale. A routine sensor update containing a logic flaw triggered a kernel crash on 8.5 million Windows devices in 78 minutes. The mechanism was different. The architecture was the same: a trusted vendor's own internal process became the source of the failure, and every downstream customer absorbed the consequences simultaneously. That single update produced an estimated $5.4 billion in direct losses across Fortune 500 companies. Geographic redundancy, multi-cloud architecture, vendor SLAs: none of it applied.

That's the reality of vendor dependency risks. They don't beat your security controls, they go around them. If your resilience strategy is built on what you can see and govern directly, it has a ceiling. Everything above that ceiling belongs to your vendors, and their vendors, and the tools their vendors use to manage their own infrastructure. You can't audit your way to safety there.

The 74 institutions downstream from Marquis were running the same dependency model that most of the market runs. That's what a structural ceiling produces: when it fails, it fails broadly, and it fails everyone sitting below it at the same time.

» Read how the CrowdStrike event exposed the true cost of third-party software dependency.

How to protect your software against supply-chain breach

The instinct after an incident like this is to tighten vendor due diligence: more assessments, stricter SLAs, deeper security reviews of your direct providers. That work is worth doing. It just doesn't get you out of a breach that entered above it. Ransomware appeared in 44% of all reported breaches in 2025, and most of those environments had backup infrastructure in place, inside the same environment that was compromised. Here's what recovery infrastructure that sits outside it looks like:

• Failure: Marquis was embedded in customer communications, analytics, compliance reporting, and campaign operations across 700+ institutions. When it entered incident response, its clients couldn't migrate. They didn't control Marquis's hosted environment, deployment logic, or operational documentation. SaaS Escrow maintains a continuously updated copy of your provider's full operating environment, databases, configurations, credentials, third-party dependencies, stored outside their infrastructure. When your vendor freezes, your recovery doesn't depend on their availability.

• Attacks: Once attackers are inside a vendor's environment, they reach connected backups too. Standard backup infrastructure sitting inside the same environment gets encrypted alongside everything else. Codekeeper's Software Backup stores your critical software systems in immutable, encrypted, versioned vaults, isolated by design. Even if every connected backup is compromised, the vault holds.

• Non-compliance: Regulators don't distinguish between your failure and your vendor's. DORA, NIS2, ISO 27001, and SOC 2 all require documented proof of resilience before an incident occurs, not a good-faith explanation after one. Verification runs full software build tests, deployment validation, and admin access reviews, producing audit-ready certification that satisfies regulators before they ask for it.

• Broken: Untested software accumulates defects invisibly: logic errors, corrupted dependencies, build configurations that haven't been validated against a clean environment. The first confirmation that something is wrong is often the outage itself. Software Escrow ensures the source code, documentation, and build materials needed to restore are stored, current, and accessible, so recovery starts from a known good state, not a guess.

If this happened to your business

It's a Tuesday morning when a press article confirms what your account manager still hasn't told you: your vendor was hit by ransomware, customer data was stolen, and you don't yet know which records were exposed. You start trying to scope your exposure, but the inventory of what your vendor actually held on your behalf, some of it dating back years, was never something you had clear sight of. Your phone is already ringing.

Days pass and the operational reality sets in. You want to migrate to another provider, but you don't have the source code, the deployment configurations, or the operational documentation needed to make that move. Your customer communications, your compliance reporting, your analytics: all of it still running on infrastructure you don't control, managed by a company now consumed by its own incident response. You join a queue of dozens of peer institutions waiting on the same vendor.

Then the regulatory letters arrive. Your compliance team needs to confirm what data was held, when you first became aware, and what steps you took in response. You can't fully answer the first question, and that gap is now a compliance problem that sits entirely on your side of the table, regardless of where the breach originated.

» Book a call with our experts to map your current exposure to each of these failure categories.

Vendor dependency failure is the operating environment, not the exception

System intrusion accounted for 53% of reported incidents in 2025. That's the environment your vendors are operating in every day, which means it's yours too, one dependency removed.

The Marquis attack resolved relatively quickly for Marquis. For the 74 institutions downstream, the consequences played out across months: regulatory scrutiny, notification obligations, migration paralysis, litigation exposure they hadn't caused and couldn't accelerate. Your perimeter controls had no jurisdiction over any of it. Independent continuity infrastructure is the only kind that does.

The contractual rights, the deposited environments, the verified recovery paths: they need to be in place before the breach, because after it, there's no time to build them.

Explore how Codekeeper's Software Escrow and Verification solutions keep your recovery independent of your vendor's environment. Book a call today.