Marquis Breach: How One Vendor Exposed 672,000 People Across 74 Banks

One Vendor, One Vulnerability, 74 Banks

On August 14, 2025, the Akira ransomware group breached Marquis Software Solutions, a Texas-based provider of statement processing, document management, and marketing services to community banks and credit unions across the United States. The attack vector was a known vulnerability in a SonicWall firewall appliance — a perimeter device that, when properly patched, would have blocked the initial intrusion.

The breach was not remarkable for its technical sophistication. Akira is a well-documented ransomware-as-a-service operation tracked by ENISA and law enforcement agencies, active since March 2023, known for exploiting VPN and firewall vulnerabilities to gain initial access. The SonicWall vulnerability had been publicly disclosed and patched. What made the Marquis breach significant was its blast radius: 672,000 individuals' data exfiltrated across 74 banking institutions, including names, dates of birth, Social Security numbers, addresses, and financial account information.

This is not a hypothetical scenario in a DORA compliance workshop. This is the empirical evidence that DORA's Pillar IV — ICT Third-Party Risk Management (Art. 28-44) — was designed to address. One vendor, one unpatched firewall, and 74 financial institutions discovered simultaneously that their customer data security was only as strong as their weakest vendor's patch management.

Anatomy of the Attack

Figure 1: The Akira attack chain against Marquis Software Solutions. A single unpatched firewall led to the compromise of data across 74 banking institutions due to multi-tenant architecture.

The attack chain followed a pattern that security professionals have documented hundreds of times — and that financial institutions continue to be exposed to through their vendor ecosystem:

Stage 1: Initial access. Akira operators identified a SonicWall firewall at Marquis Software Solutions running vulnerable firmware. SonicWall had issued patches for the vulnerability prior to the attack. The firewall was not patched. The attackers exploited the vulnerability to gain network access.

Stage 2: Lateral movement and privilege escalation. Once inside the network, the attackers moved laterally through Marquis's infrastructure, escalating privileges to gain access to data stores containing customer records from multiple banking clients. The multi-tenant nature of Marquis's services — processing statements and documents for 74 institutions — meant that a single infrastructure compromise exposed all clients simultaneously.

Stage 3: Data exfiltration. Before deploying ransomware encryption, the attackers exfiltrated data. This dual-extortion approach (steal data, then encrypt systems) has become standard for Akira and similar groups. The exfiltrated data included personally identifiable information spanning all 74 banking institutions.

Stage 4: Ransomware deployment. The encryption payload was deployed across Marquis's systems, disrupting operations and forcing the company into incident response mode.

The Concentration Risk No One Measured

Figure 2: The hidden concentration risk. Each bank assessed Marquis individually without visibility into the fact that 73 other banks shared the same dependency. The aggregate blast radius was invisible at the individual institution level.

Marquis Software Solutions is not a household name. It does not appear on lists of systemically important technology providers. It is not a hyperscaler, not a core banking platform, not a payment processor. It is a mid-market vendor providing what many banks would classify as a non-critical service: statement processing and document management.

And yet, when Marquis was breached, 74 banks simultaneously lost control of their customers' most sensitive personal and financial data.

This is the concentration risk blind spot that DORA Art. 29 was designed to illuminate. Art. 29(2)(c) requires financial entities to assess whether an ICT third-party service provider is one "on which other financial entities rely." The Marquis breach demonstrates that concentration risk is not limited to hyperscalers (AWS, Azure, Google Cloud) or core system providers (FIS, Temenos, Finastra). It exists anywhere multiple financial institutions share a common vendor — including vendors providing seemingly ancillary services.

The 74 banks using Marquis likely did not coordinate their vendor risk assessments. Each bank evaluated Marquis individually, assessed it as a service provider for a specific function, and onboarded it through its own third-party risk process. None of them had visibility into the fact that 73 other banks were making the same dependency decision. The aggregate concentration — 74 institutions, 672,000 individuals — was invisible at the individual institution level.

What DORA Would Have Required

While the Marquis breach occurred in the United States, outside DORA's jurisdictional scope, the incident provides a precise illustration of why DORA's Pillar IV provisions exist. Had Marquis been a vendor to EU financial entities under DORA, the following provisions would have applied:

Art. 28(1): Risk Assessment Before Engagement

Art. 28(1)(a) requires financial entities to "identify and assess all risks in relation to contractual arrangements on the use of ICT services." For a vendor like Marquis, this assessment should have included: the vendor's security posture (patch management practices, network segmentation, encryption at rest), the data types processed (PII, financial account data — both high-sensitivity), and the blast radius of a compromise (multi-tenant architecture serving dozens of institutions).

Art. 28(5): Ongoing Monitoring

Art. 28(5) requires that financial entities "monitor on an ongoing basis the performance of ICT third-party service providers" and "assess whether ICT third-party service providers comply with appropriate information security standards." A vendor running an unpatched SonicWall firewall against a known, publicly disclosed vulnerability would fail any meaningful ongoing security assessment.

Art. 30(2): Contractual Provisions

Art. 30(2) specifies minimum contractual provisions that must be included in ICT service arrangements supporting critical or important functions:

Art. 29: Concentration Risk Assessment

Art. 29(2) requires assessment of concentration risk, including consideration of a provider "that is not easily substitutable" and a provider "on which other financial entities rely." Both conditions applied to Marquis: statement processing is a specialized service with limited alternative providers, and 74 banks depended on the same vendor.

The Data Sensitivity Multiplier

The Marquis breach was not a service disruption. It was a data breach — and the data exfiltrated was maximally sensitive: Social Security numbers, dates of birth, addresses, and financial account information. This combination provides everything needed for identity theft, account takeover, and financial fraud.

For each of the 74 affected banks, the post-breach obligations included:

• Individual notification to affected customers (state law requirements vary)
• Credit monitoring services (typically 12-24 months, at $10-25 per individual per month)
• Regulatory notification to state banking regulators
• Investigation costs (forensic analysis, legal review)
• Potential litigation (class action suits from affected individuals)
• Reputational damage (customer trust, media coverage)

With 672,000 affected individuals across 74 institutions, even conservative cost estimates suggest aggregate post-breach costs in the hundreds of millions — distributed across 74 banks that had no control over the root cause.

DORA Art. 9(4) requires financial entities to classify their information assets "according to their criticality" and ensure appropriate protection. For data classified as sensitive (PII, financial account data), the protection requirements are correspondingly higher — and those requirements extend to third-party processors through the contractual provisions of Art. 30.

Lessons for EU Financial Entities

Lesson 1: Classify Vendors by Blast Radius, Not Service Category

The instinct to classify vendors by the type of service they provide (core banking = critical, statement processing = non-critical) misses the actual risk. Marquis was not a core banking provider. But its breach exposed more customer records than most core banking incidents. Classify vendors by the data they access, the number of institutions they serve, and the impact of their compromise — not by their marketing category.

Lesson 2: Demand Patch Management SLAs

The SonicWall vulnerability exploited by Akira had been publicly disclosed and patched. Marquis did not apply the patch in time. Under DORA Art. 30(2)(a), contractual arrangements should specify "updated and relevant service level descriptions, including update procedures." This includes patch management timelines: critical patches applied within 72 hours, high-severity within 7 days, with reporting to the financial entity of any delays.

Lesson 3: Assess Multi-Tenant Architecture Risk

When your vendor serves multiple financial institutions from shared infrastructure, a single breach exposes all clients. Art. 30(2)(c) requires specification of data processing and storage arrangements. Financial entities should assess: is client data logically segregated? Physically segregated? Can the vendor demonstrate that a compromise of one client's data does not expose all clients?

Lesson 4: Exercise Your Audit Rights

Art. 30(2)(e) provides for audit rights and access to the vendor's systems. Most financial institutions include audit rights in contracts but rarely exercise them. A pre-breach security audit of Marquis — even a questionnaire-based assessment — would likely have identified the unpatched SonicWall device. Audit rights that are never exercised provide zero assurance.

Lesson 5: Build Vendor Incident Response Into Your Own Plans

When Marquis was breached, each of the 74 banks needed to simultaneously: assess its own exposure, determine which customers were affected, initiate notification procedures, and manage customer communications. Banks that had pre-planned vendor incident response procedures — including data mapping (which of our customers' data does this vendor hold?), communication templates, and regulatory notification checklists — responded faster and with less confusion than those that had to build these procedures from scratch during the crisis.

The Structural Problem

The Marquis breach illustrates a structural challenge in financial sector vendor management: the institutions that bear the consequences of a vendor breach (the 74 banks) have limited visibility into and control over the vendor's security posture. DORA's Pillar IV provisions — contractual requirements, audit rights, ongoing monitoring, exit strategies — are designed to close this gap. But they only work when financial entities actually implement them with rigor, not as compliance paperwork.

The 672,000 individuals whose data was stolen did not have a relationship with Marquis Software Solutions. They had relationships with their banks. And their banks had delegated the processing of their sensitive data to a vendor that left a known vulnerability unpatched. DORA's fundamental insight is that delegation of processing does not mean delegation of responsibility. The 74 banks remain accountable — to their customers, to their regulators, and under DORA, to a structured framework that makes this accountability operationally enforceable.

---

This analysis references the Marquis Software Solutions breach of August 14, 2025, as reported in public breach notifications and regulatory filings, mapped to DORA Regulation (EU) 2022/2554 Pillar IV requirements.

---