Snowflake's credential-theft campaign and the limits of shared responsibility

Summary

• Confirmed campaign boundary: Mandiant attributed a financially motivated campaign to UNC5537 and said every campaign incident it directly handled traced to compromised customer credentials. It found no evidence that the unauthorized customer access arose from a breach of Snowflake's enterprise environment. Snowflake likewise said it found no evidence of a vulnerability, misconfiguration, or breach of its platform causing the activity.
• Observed control chain: The successful accounts lacked multi-factor authentication, retained credentials exposed in historical infostealer records, and lacked network allow lists. Attackers then used supported Snowflake clients and SQL operations to enumerate data, stage it, compress it, and download it. Approximately 165 organizations were notified as potentially exposed; that is not a count of confirmed breaches, people, or records.
• Shared-responsibility finding: Customers controlled their users, roles, password rotation, MFA enrollment, network policies, endpoint hygiene, and data minimization. Snowflake controlled which protections existed, how they were presented and defaulted, what cross-customer signals the platform could see, and how quickly warnings and stronger baseline behavior reached the installed base. Those responsibilities are concurrent, not mutually exclusive.
• Sovereignty finding: Choosing a Snowflake region governs where account storage and compute are located; Snowflake's documentation expressly says it does not limit user access. In this campaign, a valid identity could turn a regionally stored dataset into a downloaded copy. Data locality without identity, egress, and evidence controls is a placement decision, not a complete sovereignty control.

The platform was not shown to be breached, but the service relationship was tested

The first discipline in this case is vocabulary. A Snowflake customer instance was not the same thing as Snowflake's own enterprise environment or the shared production platform. A person with valid credentials could enter one customer's account without crossing into another tenant, exploiting a software vulnerability, obtaining a provider administrator account, or breaking the infrastructure that separated customers. The public evidence supports customer-account compromise. It does not support a platform-wide technical compromise.

Mandiant's UNC5537 campaign report is unusually direct on that point. For every incident associated with the campaign that Mandiant itself handled, the root cause was compromised customer credentials. Its investigation found no evidence that unauthorized access to customer accounts stemmed from a breach of Snowflake's enterprise environment. Snowflake's own investigative and hardening notice similarly separated targeted customer accounts from the production platform and gave customers queries and indicators for investigating their own environments. CISA amplified that guidance in a June 3, 2024 alert.

That negative finding matters. Calling the event a breach of Snowflake's platform can imply that a defect in shared code or infrastructure opened every tenant, or that Snowflake lost a master credential that unlocked customers. The reviewed record establishes neither. It would also obscure the actions customers needed to take immediately: identify password-only users, rotate credentials, inspect login and query history, restrict networks, reduce role privilege, and preserve evidence.

The opposite error is to treat the absence of a platform breach as the absence of a provider accountability question. A cloud service is not merely a neutral disk on which a customer happens to place bits. Snowflake built and ran the authentication endpoints that accepted the credentials, the interfaces the attackers used, the query engine that processed their commands, the telemetry that recorded the sessions, and the product controls that could have required a second factor or restricted network origin. Snowflake also had visibility across customers that no individual customer could possess. The fact that a decisive control was configurable by the customer determines who had an operational duty to configure it. It does not answer whether the provider's defaults, warnings, detection, and enforcement were proportionate to the data concentration on its service.

Snowflake's fiscal 2025 Form 10-K formalizes its position. It says Snowflake is responsible for platform and underlying cloud-infrastructure security, while customers select and configure controls for their environments. It attributes the May 2024 access to customers' failure to fulfill obligations such as MFA and network policies, while recording lawsuits, regulatory investigations, lawmaker inquiries, reputational damage, and the possibility of indemnification disputes. That is material company evidence about Snowflake's stated model and business exposure. It is not an independent adjudication that every responsibility or legal claim belongs on the customer side.

The useful question is therefore narrower than "Who was breached?" and broader than "Whose password was stolen?" It is: at each step from stolen secret to downloaded data, which actor could prevent, detect, interrupt, reconstruct, or warn about the action? Accountability follows control over those steps.

The campaign joined old endpoint theft to current cloud authority

Mandiant first obtained threat intelligence in April 2024 concerning database records later traced to a victim's Snowflake instance. That victim engaged Mandiant, which concluded that the intruder used credentials previously stolen by infostealer malware. The relevant account did not have MFA enabled. On May 22, after identifying intelligence pointing to a broader campaign, Mandiant contacted Snowflake and began notifying potential victims. Snowflake published customer detection and hardening guidance on May 30. By the June report, Mandiant and Snowflake had notified approximately 165 organizations that were potentially exposed.

Every term in that last sentence needs protection from inflation. "Approximately" marks an estimate. "Potentially exposed" describes a notification population, not 165 completed forensic findings. "Organizations" does not mean accounts, databases, people, or records. Some organizations may operate multiple Snowflake accounts, and one account may hold data about a much larger population. The report does not provide a campaign-wide total of confirmed organizations, affected individuals, exported bytes, or extortion payments.

The credential history explains why a cloud login in 2024 could begin with an endpoint infection years earlier. Mandiant found that most credentials used by UNC5537 were present in historical infostealer output, with the earliest associated infection observed in November 2020. At least 79.7 percent of the accounts leveraged by the actor had prior credential exposure. That percentage applies to accounts used by the actor in the analyzed campaign, not to all Snowflake customers or all 165 notified organizations.

Three conditions repeatedly turned exposed secrets into working access. The impacted accounts were not configured with MFA. Passwords found in infostealer records remained valid, sometimes for years. The affected customer instances lacked network allow lists that would restrict connections to trusted origins. None of those conditions is a novel exploit. Together they formed a durable authorization path: know the account locator, username, and still-valid password; connect from an attacker-controlled system; receive a session; inherit the assigned role; query whatever that role may read.

The endpoint dimension was also more distributed than a conventional employee-laptop narrative suggests. In several investigations, Mandiant found the earlier infostealer infection on contractor systems that were also used for personal activity, including gaming or pirated downloads. A contractor device can sit outside the customer's managed endpoint fleet while carrying credentials for several clients. It can also hold an administrative account because specialist contractors are often hired to build or operate data platforms. The customer that created the user remains accountable for the identity and its privileges, but the exposure may be invisible to the customer's own endpoint tooling.

This is a cloud-dependency multiplier. The credential is stolen from one endpoint, perhaps outside either Snowflake's or the data owner's fleet. The credential is accepted by a global service. The role may reach a consolidated warehouse containing years of records from several business systems. The attacker no longer needs to compromise those source systems one by one. The analytical value that made the warehouse useful to the customer also made successful access valuable to an extortion actor.

The attackers bear direct responsibility for stealing, buying, testing, and using credentials; entering customer environments without authorization; taking data; and attempting sale or extortion. Describing the control failures that made those crimes possible does not dilute that responsibility. It explains why the same criminal technique succeeded at scale and where recurrence can be reduced.

Supported features became an exfiltration path

The campaign did not stop at authentication. Mandiant observed access through Snowsight, SnowSQL, drivers, and database tooling. The actor listed users, roles, sessions, organization names, databases, schemas, and tables. It used familiar SQL operations to select data, create temporary stages, copy query output into compressed files, and retrieve those files to a local machine. In several instances, similar commands appeared across different customer environments.

That sequence makes the incident legible as ordinary functionality used under unauthorized identity:

1. A valid customer username and password established a session.
2. The session inherited roles and object privileges assigned by the customer.
3. Reconnaissance identified valuable tables and available stages.
4. Queries selected records the role was allowed to read.
5. Temporary staging and COPY INTO converted results into downloadable files.
6. GET moved files to an attacker-controlled client.

No step in that chain required the database to malfunction. This is why encryption at rest, while necessary, was not the decisive control. Snowflake's end-to-end encryption documentation says customer data is encrypted at rest and under TLS in transit, but it also explains that Snowflake decrypts data while transformations or table operations are performed and permits users to unload and download results. Encryption protects files and transport from parties that lack authorization or keys. It does not prevent an accepted identity with a permitted role from asking the service to return readable results.

The same principle applies to customer-managed keys. Key control can address provider, storage, and revocation scenarios, but a running account must use its key hierarchy to serve authorized queries. Unless a key policy is connected to a separate decision that rejects the session or operation, the database cannot distinguish the account owner from an intruder who has satisfied the owner's configured authentication policy.

Role design therefore controlled the radius after login. Snowflake's current access-control model supports role-based and discretionary access controls, ownership, role hierarchy, and object privileges. A credential assigned only to a narrow database or view presents a different consequence from one holding ACCOUNTADMIN, broad warehouse usage, or select access across raw datasets. A service account used by an integration should not inherit the exploratory reach of a human administrator. A contractor's temporary role should expire with the engagement rather than remain dormant with a valid password.

Data protection policies can narrow the result even when a role is compromised. Snowflake's sensitive-data classification documentation connects discovery of personal and sensitive columns with masking and row-access policies. That is a current capability description, not evidence that every affected customer had classified or masked its data in 2024. It establishes the design question: did the customer expose full historical tables to identities that needed only aggregates, recent partitions, tokenized fields, or approved views?

Export is itself a privileged business function and should be governed as such. A data warehouse often needs bulk unloads for legitimate pipelines, backups, model training, and downstream systems. A blanket ban is rarely realistic. But creating a stage, unloading an unusually large result, or using an unfamiliar client and network origin should be observable and, for high-risk datasets, may justify approval, rate limits, destination restrictions, short-lived elevation, or a separate export role. The campaign's commands were normal enough to execute, but unusual enough in context to deserve a fast security decision.

The customer owned the setting; Snowflake owned the baseline

MFA is the sharpest shared-responsibility test because both sides can state a true fact. The customer administrator was able and expected to enable it. Snowflake had offered MFA since 2015 and network policies since 2016. At the same time, the successful 2024 accounts were able to authenticate without MFA, which means the service's effective baseline permitted a password-only path for those accounts.

The difference between availability and enforcement is not semantic. A security feature can be free, documented, recommended, and still absent from the sessions that matter. Administrators face old integrations, non-interactive service users, contractors, break-glass accounts, multiple clients, and fear of lockout. Those constraints explain adoption friction; they do not justify leaving privileged human access dependent on a reusable password. They also give a provider information needed to build migration tooling, separate human and service identities, and make exceptions explicit.

After the campaign, Snowflake's public direction moved from recommendation toward stronger defaults. Its July 2024 Secure by Design pledge announcement emphasized MFA policy controls and Trust Center checks. In September 2024, Snowflake said MFA would be enforced by default for human users in accounts created from October 2024, while recommending SSO with identity-provider MFA for humans and OAuth or key-pair authentication for services. The distinction between new and existing accounts matters. A secure default protects future creation; it does not automatically retire every inherited password path in the installed base.

Snowflake later introduced Leaked Password Protection, which uses threat-intelligence feeds to test reported leaked passwords in a privacy-preserving process and disable a password when it is confirmed as still valid. That provider-side control directly addresses one of UNC5537's advantages: old infostealer credentials that remained usable. It is also evidence that shared responsibility can evolve. Customers still have to manage identities and rotations, but the provider can use cross-service intelligence to make a stolen password stop working before each customer independently finds it.

Current authentication-policy documentation lets administrators control permitted methods and clients and require MFA at account or user level. It also warns that client-type restrictions are best effort and should not be the sole security boundary. Current key-pair guidance gives service users an alternative to static passwords. These pages describe capabilities available by 2026; they must not be read backward as proof of the exact features, defaults, or enforcement state for every customer in April 2024.

Standards help explain why provider defaults belong inside the analysis. NIST's current authentication and authenticator-management guidance treats passwords as non-replay-resistant and defines phishing resistance as a protocol property that does not depend on the user's vigilance. The 2024 CISA Secure by Design pledge specifically identifies default MFA, persistent product nudges, baseline SSO support, and publication of adoption metrics as ways software manufacturers can measurably increase MFA use. Snowflake signed that voluntary pledge after the campaign. The pledge is not a legal verdict on Snowflake's 2024 design, but it rejects the idea that offering a checkbox exhausts a provider's role.

The accountable baseline distinguishes identity types. Human administrators should use phishing-resistant MFA or a strongly governed federated identity. Service workloads should use workload credentials that can be scoped, rotated, and attributed without pretending that a robot can answer a push notification. Break-glass access should be rare, monitored, time-bounded, and tested. Contractor identities should have an owner, expiry, approved device posture, and no cross-client credential reuse. Every exception should appear in a dashboard whose denominator is all identities, not only active employees.

Network policy was a second gate, not a substitute for identity

Mandiant's third recurring factor was the absence of network allow lists. A valid credential could therefore be used from infrastructure that had no business reason to reach the customer's warehouse. Network restrictions would not repair a stolen password, but they could make that password insufficient from an untrusted origin.

Snowflake's current network-policy documentation makes the default explicit: without a policy, users can connect from any computer or device. Customers can allow or block IP ranges and private endpoints, apply controls at account or user level, and restrict internal-stage access with additional configuration. Private connectivity and public-access controls can harden high-sensitivity accounts further.

The customer knows its approved offices, cloud workloads, VPNs, contractors, and integration endpoints, so the customer must define the usable allow list. Snowflake cannot infer every legitimate origin without disrupting business. Yet the provider controls the default reachability, the policy syntax, the ability to simulate a change, lockout protection, logging, and whether an administrator is warned when no account policy exists. A platform can preserve customer choice while making unrestricted public access a visible, time-limited exception rather than a silent steady state.

Network rules also have limits. Attackers may obtain a session from an approved contractor device, route through an allowed corporate VPN, compromise a workload inside the permitted cloud, or steal a token after authentication. Large enterprises may have changing egress addresses that make static lists difficult. Private connectivity can exclude SaaS tools that do not support it. These are reasons to pair network controls with strong identity and behavior detection, not reasons to omit them.

The campaign demonstrates the value of independent gates. Password rotation would have invalidated historical credentials. MFA would have required another factor. A network policy would have rejected unfamiliar origins. Least privilege would have reduced visible data. Export controls could have interrupted staging. Detection could have shortened dwell time. No single measure is perfect; the attacker succeeded where several were simultaneously absent or permissive.

For accountability, each gate needs an owner and an effectiveness measure. "Network policy supported" is a product fact. "Every production account has a tested policy covering the service and internal stages" is an operational outcome. "MFA available" is a product fact. "No privileged human can establish a session with a reusable password alone" is an outcome. Shared responsibility becomes meaningful only when both parties can show the outcomes at their boundary.

The provider saw a campaign that each customer could see only as an incident

An individual customer could inspect its own failed and successful logins, clients, IP addresses, query text, roles, stages, and data movement. Snowflake could correlate patterns across accounts: the same infrastructure, unusual clients, repeated reconnaissance, similar staging commands, a surge in password-only logins, or credentials matched to threat-intelligence feeds. This asymmetry is the provider's most important non-contractual responsibility. It is created by operating the service at scale.

Snowflake's current LOGIN_HISTORY view retains one year of login attempts and includes user, origin IP, reported client, first and second factors, success, and related risk detail, with documented latency. QUERY_HISTORY retains one year of query activity and connects a query to the authenticating event, session, user, role, text, result bytes, rows unloaded, and bytes sent over the network. Enterprise customers can use ACCESS_HISTORY to reconstruct accessed tables, views, columns, stages, policies, and modified objects. Those schemas provide the raw material for a high-quality investigation.

Raw history is not the same as detection. A customer must grant analysts access, export or query the data, understand normal behavior, write alerts, route them, retain them beyond native windows if required, and staff a response. A two-hour telemetry latency may be acceptable for retrospective review but too slow for some bulk-export decisions. An Enterprise Edition boundary on column-level access history can also affect how precisely a customer can scope exposure. These product and operating facts should be tested during procurement, not discovered after a theft.

Snowflake's present Trust Center checks MFA enrollment, account network policy, privileged roles, dormant users, risky sign-ins, unusual IP addresses, and large data transfers through security and threat-intelligence scanners. The current documentation also states limitations: some packages must be enabled; some detections may arrive within an hour; and the existence of a configured policy does not prove that its contents achieve the intended objective. Again, current capability is not evidence of what a given customer or Snowflake detected in spring 2024. It shows what a provider can productize once a cross-customer failure pattern is understood.

The warning system should operate on two layers. At the tenant layer, customers need immediate, exportable events and controls to block or suspend activity. At the provider layer, Snowflake needs campaign analytics and a practiced process to notify customers with enough evidence to act. A useful notification includes account and user identifiers, timestamps in UTC, source infrastructure, authentication factor, session and query IDs, commands, objects and columns touched, staging actions, estimated transfer volume, containment status, and confidence. "Potentially exposed" is an appropriate opening label only if it is followed by the evidence needed to resolve the potential.

Provider intervention also needs governance. Automatically blocking a customer session can interrupt production and may exceed the provider's contractual authority. Failing to act can allow continued theft. The design should therefore define risk thresholds, temporary holds, customer escalation channels, emergency contacts, and a rapid override process in advance. Customers should nominate people who can receive a high-severity alert at any hour and authorize suspension. The provider should measure time from cross-account signal to customer contact, time to containment, and the proportion of notified customers that can retrieve a complete evidence package.

Data locality did not make access local

Snowflake markets and documents regional deployment because customers have latency, resilience, privacy, regulatory, and sovereignty requirements. Snowflake's supported-regions documentation says each account is hosted in one region and that data remains in that region unless users explicitly copy, move, or replicate it. The same page contains the critical limit: regions dictate where data is stored and compute is provisioned; they do not limit user access to Snowflake.

That distinction turns the UNC5537 chain into a sovereignty case. Before intrusion, a customer's tables may have been stored and processed in a selected country or regional cloud location. After successful authentication, the attacker could query the regional account from elsewhere, stage results, and download them to a client. Mandiant observed the technical pattern of local retrieval from temporary stages. The public campaign record does not establish the source country, destination country, or legal transfer status for every victim, so no universal claim of unlawful cross-border transfer is supportable. The architecture nevertheless shows that storage locality alone could not enforce user locality.

Cross-region sharing and replication create a separate, legitimate movement path. Snowflake's cross-region sharing guidance tells organizations to confirm legal and regulatory restrictions before replicating data to a different region or country. That is planned movement under customer administration. Credential-driven export is different: it can create an uncontrolled copy outside the selected environment without changing the location of the source account. A data inventory that records only the source region will continue to say "EU" or "Canada" even after an attacker has removed a copy.

Data sovereignty therefore has at least four layers:

• Placement: where the authoritative storage and compute resources are provisioned.
• Access: which human and machine identities may connect, from which devices, networks, and jurisdictions.
• Movement: which queries, unloads, shares, replications, connectors, and downloads may create another copy.
• Evidence and remedy: whether the organization can prove where access originated, what left, which people or regulated records were involved, and how quickly it can contain and notify.

The provider controls important parts of all four layers even when the customer chooses the policy. It offers regions and keeps account data in them. It authenticates requests and exposes network controls. It executes export commands and records query metadata. It holds cross-customer threat visibility and can disable leaked passwords. The customer decides its lawful basis, data categories, roles, allowed origins, masking, retention, and approved movement. A regional hosting commitment without these complementary controls can satisfy a narrow data-center-location requirement while leaving the practical authority to copy data globally exposed.

This is also why encryption and sovereignty should not be conflated. Encryption can protect a stored object from the infrastructure operator or an unauthorized storage-layer reader. An application that must analyze the object necessarily makes data available to an authorized query context. If identity assurance and role scope are weak, cryptographic locality can coexist with operational exfiltration.

Customer disclosures show different consequences, not one uniform breach

The campaign is often described through prominent customer names, but each customer's public record has its own scope, dates, data, terminology, and confidence. It is unsafe to transfer one company's facts to another or to convert a criminal forum claim into a verified population.

Live Nation's May 31, 2024 Form 8-K said it identified unauthorized activity on May 20 in a third-party cloud database environment containing company data, primarily from Ticketmaster. It said that on May 27 a criminal actor offered what it alleged was company user data for sale, and that Live Nation was notifying law enforcement, regulators, and users as appropriate. The filing did not name Snowflake, provide a confirmed affected-person count, or explain the authentication path.

Ticketmaster Canada's incident page gives a different level of detail. It describes unauthorized access to an isolated cloud database hosted by a third-party data-services provider, says the database contained limited personal information of some North American ticket buyers, and lists possible fields including email, phone number, encrypted card information, and other information supplied by customers. It says Ticketmaster customer accounts were not affected. That last boundary is important: compromise of a back-end data warehouse is not evidence that the attacker obtained each person's Ticketmaster login or could transact through the consumer account.

The Office of the Privacy Commissioner of Canada's October 2025 parliamentary issue sheet identifies Snowflake as the third-party provider used by Ticketmaster, gives an April 2 to May 18, 2024 incident window for Ticketmaster Canada, and says personal information of millions, including Canadians, was involved. It also says the investigation remained open and that Ticketmaster Canada, as the data controller under PIPEDA, was the entity under investigation. This is useful regulatory context, but not a final finding that resolves adequacy of safeguards, notice timing, or liability.

AT&T's July 12, 2024 Form 8-K illustrates why source boundaries matter even when incidents are discussed together. AT&T said an actor unlawfully accessed an AT&T workspace on a third-party cloud platform and exfiltrated files from April 14 to April 25. The files contained call and text interaction records for nearly all AT&T wireless customers and relevant mobile virtual network operator customers for specified periods in 2022 and one day in 2023. AT&T said the files did not contain call or text content, Social Security numbers, dates of birth, or other personal information as AT&T used that term. The filing itself does not name Snowflake or UNC5537. It supports AT&T's incident facts, not a campaign attribution on its own.

These records yield four discipline rules. First, use a customer's filing for that customer only. Second, distinguish a database, organizational account, and consumer login. Third, distinguish data fields from the number of people represented by them. Fourth, preserve negative facts such as "no message content" or "consumer account not affected" alongside the impact. Accountability becomes less credible when analysis expands dramatic claims and drops limiting ones.

Customers remained accountable for the data and identities they delegated

The customer side of shared responsibility is substantial. The organization created or approved Snowflake users, selected authentication paths, assigned roles, loaded data, retained history, chose a region, enabled integrations, and decided which employees and contractors could query the warehouse. It also held the primary relationship with the people represented in its data and usually retained controller duties under applicable privacy law.

A customer could have interrupted the observed campaign at several points. It could rotate passwords after endpoint exposure, prohibit password-only service accounts, require MFA for humans, federate access through a governed identity provider, restrict networks, expire contractor users, reduce role grants, classify and mask sensitive fields, isolate export privilege, monitor login and query history, and rehearse cloud-provider notifications. For regulated or high-impact datasets, those are baseline operating duties, not optional enhancements delegated to procurement.

Endpoint and contractor governance deserve particular attention. A user with a high-impact cloud role should not authenticate from an unmanaged personal computer. Contractors should use customer-controlled virtual desktops or devices with endpoint monitoring where feasible. Their identity should be unique per customer, linked to a sponsor, and automatically expire. The organization should search credential-exposure feeds for its Snowflake account patterns and force rotation when evidence appears, without waiting for confirmed misuse.

Least privilege must be tested against data, not job title. "Analyst" may sound non-administrative while retaining select access to every row in a customer, employee, or transaction table. A role review should ask which rows and columns can be returned, whether raw identifiers are needed, whether bulk result sets can be written to stages, and whether the identity may create new credentials or integrations. Sample queries under the role are stronger evidence than a clean-looking role name.

Customers also own response readiness. They should be able to map a Snowflake user to an employee or contractor, a query to affected data subjects, and an export to a jurisdiction and notification analysis. Native one-year histories may be insufficient for longer legal retention or delayed discovery, so high-risk customers should stream relevant events to an independent security store. Provider alerts need a tested path to the customer security team, privacy office, business owner, and executive decision maker.

NIST's Cybersecurity Framework supply-chain guide recommends defining and communicating supplier requirements according to criticality. Applied here, a Snowflake customer should contract for incident-notice timing, evidence fields, retention, support escalation, regional processing, subprocessor visibility, control-change notice, and assurance access. It should also maintain an exit or isolation plan for the data functions whose loss or compromise would be intolerable. Shared responsibility should be written as testable interfaces, not a paragraph that appears only after an incident.

Snowflake remained accountable for service-level risk reduction

Snowflake did not control the malware on a contractor's personal device or the customer's decision to leave MFA disabled. It did control whether an old password could remain the only factor, whether unrestricted origins were the quiet default, whether risky configurations produced persistent warnings, and what the provider did after it observed a pattern across customers.

Provider accountability in this case has six parts.

Secure baseline. Human privileged access should not depend on a reusable password alone. Service identities should have a separate type and supported non-password methods. New defaults should reach existing high-risk accounts through staged enforcement, explicit exceptions, and migration help rather than protecting only new tenants.

Configuration visibility. The provider should show security administrators a complete denominator: humans without MFA, legacy service users with passwords, dormant accounts, users without network restrictions, privileged roles, and accounts permitting public ingress. Findings should be visible at organization level and exportable for audit.

Cross-customer detection. Reused infrastructure, leaked credentials, unusual clients, reconnaissance sequences, temporary-stage creation, and large exports can form a campaign signal. The provider should detect at the service layer, contact likely victims, and define when high-confidence activity triggers a temporary block.

Actionable telemetry. Customers need authentication, query, object, stage, and transfer evidence with sufficient retention and low enough latency to contain an active theft. Higher-fidelity evidence should not become unavailable precisely where the service stores the highest-impact data.

Warning and coordination. A customer alert must move through a known emergency route and carry evidence, not merely advice to review logs. The provider should track acknowledgment, containment, and recurring exposure, and it should support law-enforcement and regulator requests without collapsing uncertain observations into confirmed victim counts.

Post-incident verification. Announced features and defaults need adoption and effectiveness measures. Snowflake's later changes toward default MFA, leaked-password disabling, Trust Center findings, and stronger identity types address the observed path. The remaining accountability question is coverage: which users and clients are actually protected, what exceptions remain, and how often a control stops a real or simulated attempt?

This allocation does not make Snowflake the data controller for every customer dataset, nor does it make the provider responsible for every customer configuration. It recognizes that a cloud company profits from concentrating data and operating a security boundary. Scale creates duties that only the provider can perform, especially cross-tenant correlation and baseline engineering.

Later litigation tests the same boundary without yet resolving it

Snowflake and affected companies faced consolidated civil litigation after the incidents. In an October 29, 2025 federal court order, the District of Montana held that financial-institution plaintiffs had sufficiently pleaded certain negligence theories against Snowflake and Ticketmaster to survive motions to dismiss. The court treated alleged default MFA and foreseeability as relevant to duty, breach, and causation at that procedural stage.

That order is not a trial finding that Snowflake or Ticketmaster was negligent. On a motion to dismiss, the court tests whether well-pleaded allegations state a plausible claim; it does not resolve disputed evidence, determine the final incident mechanism for every plaintiff, or allocate damages. Snowflake disputed the allegations and argued that customer failures to implement MFA, network policies, and other safeguards caused the harm. The order is significant because it shows that describing MFA as a customer setting did not automatically end every provider-duty claim. It is not a substitute for the final merits record.

The Canadian privacy investigation carried a different allocation. The OPC said Ticketmaster Canada remained the controller and was the entity under investigation, while the office contacted Snowflake for information. That reflects a common privacy principle: outsourcing storage does not outsource the controller's duty to protect and notify. It does not mean the service provider has no contractual, technical, or statutory duties of its own.

Snowflake's own 10-K acknowledged numerous lawsuits, regulatory investigations, and lawmaker inquiries, but did not report a final universal allocation of liability. As of the publication date, the public sources reviewed here do not support declaring that Snowflake was legally exonerated, that every customer was legally at fault, or that a final court or regulator has adopted this article's operational allocation.

Operational accountability can be assessed before final liability. Was password-only access foreseeable? Yes. Could the customer require MFA and network policies? Yes. Could Snowflake design defaults and detect cross-customer activity? Yes. Did criminals intentionally exploit the resulting path? Yes. Those propositions can coexist. Tort, contract, privacy, and securities law may assign consequences differently by jurisdiction and plaintiff, but engineering should not wait for one slogan to win.

A measurable shared-responsibility test

The strongest response is not another diagram with "customer" on one side and "provider" on the other. It is a set of controls whose coverage and failure behavior can be demonstrated.

Control question	Customer evidence	Provider evidence
Can a human use a password alone?	Inventory of all human users, factor and IdP policy, exception owner and expiry	Enforced default, coverage by account age and client, blocked password-only attempts
Can a service identity use a human password?	Workload inventory, key or OAuth rotation, owner, role and network scope	Distinct service type, password prohibition, migration and compatibility metrics
Can a stolen credential connect from anywhere?	Tested account and user network policies, private endpoint coverage, approved exceptions	Warning on unrestricted accounts, policy simulation, lockout-safe enforcement, malicious-origin blocking
Can one user read or export excessive data?	Role-to-data tests, masking, row filters, export separation and approvals	Granular privileges, stage controls, transfer telemetry, high-risk export detections
Can an active theft be seen quickly?	SIEM rules, staffed routing, exercise results, independent retention	Cross-account analytics, detection latency, event completeness, emergency contact success
Can exposure be reconstructed?	Identity ownership, data-subject map, legal playbook, preserved logs	Session-to-query linkage, object and column history, stage and transfer evidence, tenant evidence package
Does a regional account enforce sovereignty?	Approved access jurisdictions, movement register, replication and connector review	Region commitment, origin and destination evidence, egress controls, cross-region warnings
Does remediation operate in reality?	Closed findings, aged exceptions, sampled tests	Adoption metrics, control-trigger metrics, false-positive and override review

Boards should receive outcomes rather than feature inventories. Useful measures include the percentage of human users protected by phishing-resistant MFA, the number of password-capable service users, the age of every break-glass exception, the percentage of accounts with tested network policies, the number of privileged contractor identities past expiry, median time to alert on unfamiliar origins, time to suspend a high-confidence session, and time to produce a field-level exposure package.

Snowflake should publish aggregate progress where it can do so without exposing customers. CISA's pledge explicitly contemplates adoption statistics by user and MFA type. A statement that MFA is available is less informative than the distribution of password-only sign-ins over time. A statement that Trust Center is enabled is less informative than how many critical findings remain open beyond a defined period. A statement that suspicious customers were notified is less informative than notification latency and evidence-package completeness.

Customers should demand the same rigor from themselves. A provider cannot save an organization that creates broad roles, ignores findings, keeps old contractor users, and has no one answering the emergency contact. The purpose of stronger defaults is not to transfer ownership of customer security to Snowflake. It is to make predictable omissions less likely to become mass data theft.

What the public record still does not establish

The evidence is strong enough to reconstruct a campaign pattern, but not every victim incident.

The public record does not identify all notified organizations, confirm that all 165 suffered unauthorized access, or provide a final campaign-wide total of affected individuals, tables, records, or downloaded bytes. It does not show which victims paid extortion demands or whether promised deletion occurred.

It does not publish the user type, role hierarchy, MFA history, network configuration, endpoint owner, session sequence, accessed columns, or export volume for each organization. Contractor-device findings from several investigations should not be assigned to every victim. The 79.7 percent credential-exposure statistic should not be turned into a victim percentage.

It does not establish a software vulnerability, cross-tenant escape, compromise of Snowflake's production platform, theft of a provider master credential, or access to every Snowflake customer. The observed use of supported clients and commands is evidence of credential abuse, not proof that the product code was exploited.

It does not prove that regional data crossed a national border in every incident. The architecture permitted remote access and local download; legal transfer analysis would require source, destination, data-subject, contractual, and jurisdiction facts for each customer.

It does not allow Ticketmaster's possible fields, AT&T's call-detail scope, or any criminal forum count to be generalized across other customers. Live Nation's filing did not name Snowflake. AT&T's filing did not name Snowflake or UNC5537. External association may be relevant to further investigation, but the filings should be quoted for what they actually establish.

Finally, current Snowflake documentation does not prove the operation of controls in April and May 2024. Later default MFA, leaked-password protection, Trust Center detection, authentication policies, and identity changes may reduce recurrence, but public evidence of adoption, exception coverage, detection performance, and independent effectiveness remains more limited than the feature descriptions.

Shared responsibility must survive the moment a recommendation is ignored

The Snowflake campaign is not best understood as a contest between two absolute stories. One story says the platform was hacked and the provider alone failed. The evidence does not support it. The other says customers lost passwords and therefore the provider question is closed. That is technically incomplete.

UNC5537 found a scalable junction between endpoint compromise and cloud concentration. Historical passwords remained valid. Human and service identities were not always separated. MFA and network gates were absent. Supported query and staging functions moved data quickly. The provider could see a pattern across tenants, while each customer saw only its own account. A chosen storage region could hold the source data in place even as an authenticated session created an uncontrolled copy elsewhere.

Customers had the clearest duty to govern their users, roles, endpoints, contractors, and data. Snowflake had the clearest duty to secure and observe the service boundary, make high-value protections easy and increasingly unavoidable, detect campaign behavior, and supply evidence. The attackers had direct responsibility for the criminal acts. Regulators and courts must assess legal duties on the facts and law applicable to each organization. These allocations overlap because the controls overlap.

The post-campaign product direction implicitly recognizes the gap between capability and outcome. Default MFA for new human users, leaked-password disabling, stronger authentication policy, service-user migration, and Trust Center findings move security closer to the provider baseline. They do not erase customer responsibility. They make the shared system less dependent on every administrator finding and enabling every correct option before a stolen password is tested.

That is the durable accountability test for a cloud data platform. Assume a customer will miss a warning, a contractor device will be infected, a credential will remain valid, and an attacker will use ordinary product functions. Then ask whether the default blocks the login, another gate rejects the origin, the role reveals little, the export triggers intervention, and the evidence reaches the customer in time. Shared responsibility is credible only when the service remains defensible after one party's predictable mistake, and when both parties can prove what they did before and after it.