On 5 August 2026, Connor Riley Moucka, 26, of Ontario, Canada, pleaded guilty in United States federal court to computer fraud, conspiracy, and aggravated identity theft in connection with the 2024 campaign against customers of the cloud data platform Snowflake.

The numbers in the plea documents are worth stating plainly. At least 165 Snowflake customer tenants were compromised. The data of more than 100 million people was implicated across the victim set. The conspirators received more than $2.5 million in extortion payments, and Moucka personally obtained at least $495,000 from selling stolen data on criminal marketplaces.

He faces a mandatory minimum of two years on the aggravated identity theft count, with the remaining counts carrying a statutory maximum that brings his total exposure to roughly 32 years. Sentencing is scheduled for 27 October 2026.

Moucka was arrested in October 2024 following an investigation involving Canadian, Australian, Spanish, Ukrainian and Turkish authorities, and was extradited from Canada to the United States in July 2025.

The detail that matters most for compliance teams is the one that does not appear in the indictment as a technical finding:

There was no vulnerability in Snowflake.

What actually happened

The campaign did not involve an exploit, a zero-day, or a flaw in the platform. It involved credentials.

The attackers obtained usernames and passwords for Snowflake customer tenants from infostealer malware logs — commodity credential-harvesting malware that had, in many cases, infected contractor and employee machines years earlier. Those credentials were then used to authenticate to customer Snowflake environments directly.

Three conditions had to hold simultaneously for that to work, and in at least 165 tenants they did:

  1. The credentials were still valid. No rotation had occurred after the infostealer infection, and in some cases after the associated employee or contractor had left.
  2. Multi-factor authentication was not enforced on the account. A valid password was sufficient.
  3. No network policy restricted where the login could originate. The tenant accepted authentication from arbitrary internet addresses.

Once inside, the attackers ran queries against the customer’s own data warehouse — which is precisely what a data warehouse is designed to permit — exported the results, and moved to extortion.

This is the shape of the incident that compliance functions consistently mis-model. The platform did what it was configured to do. The failure sat entirely on the customer side of the line.

The shared responsibility line, and where organisations keep drawing it wrong

Every major SaaS and cloud provider publishes a shared responsibility model. Almost every organisation acknowledges one exists. Comparatively few have translated it into an assignable control matrix.

The Snowflake campaign is the clearest available illustration of the gap. On the provider side sat platform security, infrastructure hardening, and availability of authentication controls. On the customer side sat:

  • Identity configuration — whether MFA was turned on, and whether it was enforced rather than merely available.
  • Credential lifecycle — rotation cadence, offboarding, and response to known infostealer exposure.
  • Network policy — allow-listing, conditional access, and geographic or IP restriction.
  • Monitoring — whether anomalous query volume or bulk export from an unusual source address generated an alert.
  • Data minimisation inside the tenant — how much regulated data was sitting in a queryable warehouse, and for how long.

Each of those is a control an auditor can test. Each of them was, in the affected tenants, unowned.

The instructive failure mode is the second one on that list. Many of the affected organisations had MFA available and had it enabled for interactive human logins through their identity provider. What they did not have was enforcement on service accounts, legacy integration users, and direct-to-platform credentials that bypassed the identity provider entirely. Those accounts are the ones that break automation when you add a second factor, so they are the ones that get an exception — and the exception is rarely time-boxed, rarely documented, and almost never re-reviewed.

An MFA control that covers 95 percent of accounts and exempts the 5 percent with the broadest data access is not a 95 percent control. It is the absence of a control with a compliance artefact attached.

Where the regulatory floor now sits

The 2024 campaign predates several of the mandates that now make this configuration a compliance finding rather than merely a bad idea. That timing is the point: the regulatory response to credential-only access to regulated data has hardened considerably, and organisations that still carry MFA exceptions on high-privilege data platform accounts are now out of step with explicit requirements rather than with best practice.

PCI DSS v4.0.1 requires multi-factor authentication for all access into the cardholder data environment (Requirement 8.4.2), not only for administrative access or remote access, and requires that MFA systems be resistant to replay and cannot be bypassed by any user including administrators (Requirement 8.5.1). A direct-to-platform service credential reaching an environment holding cardholder data does not survive that requirement.

The NYDFS Cybersecurity Regulation (23 NYCRR Part 500), as amended, requires MFA for all individuals accessing any information system of a covered entity, with the broadened obligation now fully in effect. The narrow prior scope — remote access and privileged accounts — is gone.

The HHS Office for Civil Rights has proposed amendments to the HIPAA Security Rule that would move multi-factor authentication from an addressable-by-implication analysis to an explicitly required implementation specification, alongside mandatory asset inventory, network segmentation, and encryption. Regulated entities that have been carrying MFA gaps on data platforms holding protected health information should be treating that direction of travel as settled regardless of the final rule’s timing.

CISA’s guidance and cross-sector performance goals have treated phishing-resistant MFA on internet-accessible systems as a baseline expectation for several years, and the Binding Operational Directive regime has progressively narrowed the space for exceptions on federal systems.

The common thread across all four is the collapse of the distinction between “privileged account” and “account with access to a lot of data.” A read-only service account against a warehouse containing 50 million customer records is a privileged account. Control frameworks have caught up with that; access review processes frequently have not.

The notification problem the plea does not solve

There is a second lesson buried in the timeline, and it concerns the gap between criminal accountability and regulatory obligation.

Moucka was arrested in October 2024. He pleaded guilty in August 2026. He will be sentenced in October 2026 — more than two years after the campaign concluded.

The notification obligations of the 165 affected organisations ran on an entirely different clock. Under the GDPR, Article 33 required notification to the supervisory authority within 72 hours of becoming aware of a personal data breach, with Article 34 communication to data subjects without undue delay where high risk existed. Under HIPAA, affected covered entities had 60 days from discovery. Under the SEC cybersecurity disclosure rule, public company victims had four business days from a materiality determination to file an Item 1.05 Form 8-K. State breach notification statutes imposed their own windows, several of them shorter than 30 days.

None of those clocks pause for law enforcement to build a case — with the narrow and specific exception of a documented law enforcement delay request, which must be sought, granted, and time-limited. Organisations that quietly deferred notification because “there is an active investigation” without obtaining and documenting such a request created a second, independent violation on top of the breach itself.

This is a recurring pattern. We covered the same structural problem in the context of CareCloud’s four-month notification gap and in the DentaQuest scope expansion, where a growing understanding of the incident was allowed to postpone the notification the regulator had already required. Criminal proceedings against the attacker are not a defence to a late notification. They are a separate process running in parallel, on a timescale that no regulator’s clock respects.

The infostealer supply line

One further element deserves attention because it is the part organisations have the least visibility into.

The credentials used in this campaign came from infostealer logs — data harvested by commodity malware from infected endpoints, aggregated, and sold or traded in bulk on criminal marketplaces. Many of the compromised credentials had been sitting in those logs for a considerable period before they were used.

That creates a control requirement most access management programmes do not have:

Credential exposure monitoring is a detective control, and it belongs in your access review cycle.

Concretely, this means:

  • Subscribe to and act on infostealer log monitoring for your corporate domains, including contractor and third-party domains that hold credentials to your environments. Treat an appearance in a log as a confirmed compromise of that credential, not as an indicator to investigate.
  • Force rotation on exposure, not on schedule. A 90-day rotation policy does nothing about a credential harvested on day 2 and used on day 30.
  • Extend the scope to non-federated credentials. The credentials that appear in infostealer logs are frequently the ones stored in browsers and password managers on contractor laptops — which is exactly the population of direct-to-platform logins that bypass your identity provider and therefore your conditional access policy.
  • Include contractor and departed-employee accounts in the sweep. Several of the affected tenants in this campaign were reachable through accounts that should have been deprovisioned.

The uncomfortable implication is that your identity perimeter includes machines you do not own and cannot patch. The only workable compensating control is to make the stolen password insufficient — which returns to enforced MFA and network policy.

A control checklist for data platform tenants

For any team operating a Snowflake, Databricks, BigQuery, Redshift, or comparable analytics platform holding regulated data, the following are the specific findings this case supports:

  1. Enumerate every authentication path into the tenant, including service accounts, integration users, key-pair authentication, personal access tokens, and legacy credentials. The enumeration, not the policy, is where programmes fail.
  2. Confirm MFA enforcement is a tenant-level requirement, not a per-user setting. Where the platform supports it, enable an authentication policy that rejects password-only authentication outright.
  3. Apply network policies restricting authentication to known corporate egress ranges and approved integration sources. This alone would have blocked the campaign in most affected tenants.
  4. Time-box and document every MFA exception, with a named owner, an expiry date, and a compensating control. Exceptions without expiry dates are policy fictions.
  5. Alert on bulk export volume and on first-seen source addresses for any account with broad table access. The attackers’ behaviour was anomalous by volume from the first session.
  6. Review data retention inside the warehouse. The severity of every one of these incidents was set by how much historic regulated data was sitting queryable in a single tenant.
  7. Map the shared responsibility model to named control owners and put it in front of your auditors. If no individual owns “MFA enforcement on the analytics platform,” it is not enforced.

What the case actually establishes

Two things follow from the plea.

For SaaS customers: the provider’s security posture is not your security posture. Snowflake was not breached. Its customers were, through the half of the responsibility model that was theirs to operate, using controls that were available to them and switched off. Every attestation, certification, and vendor questionnaire in the procurement file was accurate and entirely beside the point.

For compliance functions: an identity control with a documented exception population is an incomplete control, and the exception population is where the regulated data lives. The accounts that break when you add a second factor are the automated, high-volume, broad-access accounts — which is a description of exactly the accounts an attacker wants. The exception list is the attack surface.

Moucka’s sentencing in October will close the criminal chapter. It will not retroactively satisfy a single notification deadline, remediate a single tenant, or answer a single regulator’s question about why a password alone was enough.

This article is provided for informational purposes only and does not constitute legal advice.