Would your org have caught the Snowflake customer breaches?

The 2024 Snowflake customer data thefts started with stolen credentials, not a flaw in Snowflake. Mandiant traced them to accounts with no multi-factor authentication, old unrotated passwords and no network allow lists. You would have caught it if you can answer yes to the checklist below.

What did Mandiant report?

In June 2024 Mandiant described a campaign by a financially motivated group it tracks as UNC5537, which used stolen customer credentials to access Snowflake customer instances, steal data and attempt extortion. Its investigation found no evidence that access came from a breach of Snowflake's own enterprise environment. Every incident it responded to traced back to compromised customer credentials.

Mandiant named three factors behind the compromises. The accounts had no MFA, so a valid username and password was enough. The credentials, taken earlier by infostealer malware, were still valid, some years after they were stolen, because they had not been rotated. And the customer instances had no network allow lists limiting access to trusted locations.

The report says Mandiant and Snowflake notified approximately 165 potentially exposed organizations. It also says that at least 79.7 percent of the accounts used had prior credential exposure, and the earliest related infostealer infection dated from November 2020. In several cases the infected machines were contractor systems also used for personal activity.

This is a lesson about shared responsibility, not about blame. The platform worked as designed. The customers' controls were the gap, and many of them were doing what looked normal at the time. The useful question is whether your own setup would hold.

What is the checklist?

Authentication

• Is MFA required, not optional, on every account that can reach production data, including service and contractor accounts?
• Can you list accounts that still use only a password?

Credential hygiene

• When were the credentials for your data platform last rotated? Is there a schedule?
• Do you check public and commercial sources for your employees' and contractors' exposed credentials?
• Do service accounts use keys that expire?

Network and access paths

• Are there allow lists, or equivalent conditions, that restrict where logins can come from?
• Can a user log in from a personal, unmanaged device?

Third parties

• Do contractors use managed, company controlled devices to reach your data?
• Is their access reviewed and removed when a project ends?

Detection

• Would you see a large data export from a warehouse account, and from an unusual location, within hours?
• Do you retain enough log history to look back a year, and have you tested a threat hunt on it? Mandiant noted that default retention in the relevant views allowed hunting across the past 365 days.

Response

• If you learned today that a credential was exposed, can you revoke it and rotate every dependent secret within a day?

Where does software supply chain come in?

Credentials leak from code and build systems too. Keys in repositories, container images and CI logs are a classic source. Secrets scanning in the pipeline, with verification that a key is live, helps you revoke what is dangerous first. Safeguard offers secrets scanning for that reason, but it does not replace MFA or rotation. It is one layer.

What to do

1. Turn on and enforce MFA for every human and contractor account on data platforms. For service accounts, use short lived keys or key based authentication where the platform supports it.
2. Rotate credentials now, and set a calendar for the next rotation.
3. Add network allow lists or conditional access on the data platform.
4. Require managed devices for contractors with data access.
5. Alert on bulk exports and logins from new locations.
6. Check credential exposure feeds for your domains.
7. Run a tabletop on a leaked credential and time the revoke and rotate steps.

Quick check

Sources

• Mandiant: UNC5537 Targets Snowflake Customer Instances for Data Theft and Extortion
• Safeguard docs: Secrets Scanning

Last reviewed: 18 October 2026.