This website uses cookies to ensure you get the best experience on our website. Learn more
Marquis Sues SonicWall: What the Lawsuit Reveals About MFA Recovery Risks
Table of Contents
On Monday, February 23, 2026, fintech provider Marquis Software Solutions Inc. filed a lawsuit against SonicWall in the U.S. District Court for the Eastern District of Texas. The legal action follows a 2025 cybersecurity incident where Marquis alleges that a breach of SonicWall’s cloud backup service directly enabled a ransomware attack on its own internal networks.
While the outcome of the litigation remains to be seen, the technical details cited in the complaint provide a critical look at a growing vulnerability in modern security stacks: the protection of secondary authentication data.
According to the filing, the breach allegedly exposed configuration files for every customer using the backup service, impacting at least 400,000 individuals. The sensitive data stolen included Social Security numbers and financial records.
What happened in the Marquis vs SonicWall case?
The lawsuit claims the breach originated from a code change SonicWall made to its API in February 2025. This vulnerability reportedly allowed threat actors to access customer firewall configuration backups without proper authentication by guessing predictable serial numbers.
The specific risk highlighted in this case is not a failure of the firewall’s primary defenses, but rather the data contained within those cloud backups. According to the filing:
“SonicWall’s cloud backup breach provided threat actors with critical data, including credentials and MFA scratch codes, that enabled them to bypass firewalls and gain access to customer networks.”
By obtaining these “scratch codes” (static codes intended for emergency account recovery) attackers were able to circumvent the multi-factor authentication (MFA) Marquis had in place.
They didn’t need to “break” the MFA; they simply used the legitimate bypass tools that had been exfiltrated from the vendor’s storage.
This case is a sharp reminder to security professionals that:
- Recovery mechanisms must be protected as rigorously as primary factors
- Backup files containing authentication data are sensitive assets
- Attackers will target secondary access paths if they are easier, therefore access security must be layered
- Strong identity security requires visibility and control across all authentication pathways, not just the primary one.
What this incident teaches us about MFA
The Marquis/SonicWall incident offers a stark contrast to our previous analysis of the City of Hamilton, where insurance was denied because MFA wasn’t implemented correctly.
Marquis, however, represents a more advanced stage of the security journey. MFA had been implemented and Marquis had followed standard security protocols. The failure point shifted from a lack of controls to a vulnerability in the supply chain’s handling of recovery secrets. This reinforces that while MFA is essential, the “backdoor” recovery paths must be guarded with the same level of rigor as the front-end login. The broader lesson is about how identity systems are constructed.
“MFA is critical, but it is only one part of the control plane. If recovery paths are exposed, they effectively become alternate login routes. Strong identity security requires layered validation of identity, binding the user to a trusted device, and enforcing device posture at access time and continuously thereafter, without generating friction for the end user.”
Darren James, Senior Product Manager at Specops, commenting on the incident
How to secure password recovery and strengthen MFA
There are several practical lessons organizations can draw from the Marquis – SonicWall incident:
1. Treat recovery codes as high-risk credentials: MFA scratch codes and backup authentication artifacts should be stored securely, rotated when appropriate, and monitored for misuse.
2. Enforce MFA consistently across Windows environments: In many organizations, MFA enforcement is strongest at the identity provider level but weaker at Windows logon, RDP, or VPN layers.
Solutions such as Specops Secure Access extend MFA enforcement to Windows-based authentication scenarios, reducing gaps where credentials or recovery codes might otherwise be used alone.
3. Secure self-service recovery workflows: Self-service password reset is essential for usability, but it must enforce strong identity verification before allowing reset actions. Specops uReset enables users to securely reset their Active Directory or Entra ID passwords and update local cached credentials from any locations, device, or browser. hybrid Active Directory environments, reducing helpdesk dependency while protecting against social engineering and weak recovery processes.
4. Monitor for compromised credentials: If authentication-related data is exposed in a third-party breach, organizations should assume credentials may eventually be tested elsewhere. Continuous password screening against known breached datasets reduces the likelihood of credential reuse and lateral movement.
Specops Password Policy enables organizations to block passwords found in a database of more than 5 billion compromised credentials, helping prevent the use of known-exposed secrets in Active Directory environments.
5. Incorporate device trust into access decisions: Even when credentials are valid, access from an unknown or unmanaged device introduces risk. A Zero Trust approach that evaluates device posture in addition to identity can limit the impact of exposed authentication artifacts.
Specops’ Zero Trust solution Specops Device Trust binds identities to authorized hardware and verifies device posture in real time, both at login and continuously throughout the session. Access decisions are based on the device’s current security state, not historical compliance. If posture changes, access can be adapted or revoked, and users can remediate issues through guided self-service actions.
Don’t let recovery paths become your weakest link. Learn how Specops solutions help secure credentials, enforce MFA, and protect against authentication bypass attacks. Contact us today or book a demo with one of our experts.
Last updated on March 23, 2026