Snowflake’s stolen logins put the contractor’s laptop inside the bank’s perimeter

The week

For a few weeks in the late spring of 2024, a string of well-known companies disclosed, one after another, that customer data had been taken from databases run by outside providers. At first the announcements looked unrelated. Then a pattern emerged.

In mid-May, Santander disclosed unauthorized access to a database hosted by a third-party provider. It held information on customers in several countries and on staff. On May 31, Live Nation disclosed in an SEC filing that a third-party cloud database containing Ticketmaster data had been accessed.

Behind the scenes the investigation was already weeks old. Mandiant later explained that in April 2024 it had received threat intelligence on database records that came from a client’s Snowflake environment, and notified that client. On May 22, having recognized a broader campaign, it contacted Snowflake and began notifying other potential victims. Snowflake published detection and hardening guidance for its customers on May 30.

In the first days of June, the common thread came into view. Snowflake, a company that provides a cloud data warehouse, said a campaign was targeting customer accounts. A data warehouse is a large, central database where an organization gathers information from many systems so analysts can study it: transactions, customer records, sales figures. Snowflake runs that warehouse “in the cloud,” meaning on its own infrastructure, which customers reach over the internet. Snowflake and two incident response firms, CrowdStrike and Mandiant, said the targeted accounts used single-factor authentication, meaning a password alone with no second check such as a code on a phone. They said they had found no vulnerability in, or breach of, Snowflake’s own platform.

The statement added one detail about Snowflake itself. Attackers had used a former employee’s personal credentials to reach demonstration accounts, which Snowflake said held no sensitive data and were not connected to its production or corporate systems. The detail mattered mainly as a sign of how common the pattern was. Even the provider had a password-only door that someone had forgotten.

On June 10, Mandiant published its findings. A financially motivated actor it tracked as UNC5537 had used credentials stolen by infostealer malware to access customer instances, each customer’s own section of the platform. Infostealers are a kind of malicious software that harvests saved passwords and login details from an infected computer. Some of the stolen credentials dated back to 2020: passwords had sat in criminal hands for years and still worked.

The report was specific. At least 79.7 percent of the accounts used in the campaign had appeared in earlier credential leaks. Mandiant named six infostealer families, including Vidar, RedLine, Raccoon Stealer and Lumma, and traced the earliest related infection to November 2020. Some credentials had not been changed in as long as four years. In several cases the first infection was on a contractor’s computer that was also used for gaming and pirated software.

Mandiant notified about 165 potentially exposed organizations. The affected accounts lacked multi-factor authentication, and many had no network allow-lists, a setting that only permits logins from approved internet addresses.

The attackers’ methods were ordinary. They logged in through Snowflake’s own web interface and command-line client, or through a common database tool, connecting from commercial VPN services. A reconnaissance utility, which Mandiant named FROSTBITE, listed users, roles and databases. The attackers then copied tables into temporary staging areas, compressed them and downloaded the files. Mandiant assessed that the group had members in North America and worked with at least one person in Turkey, and that it extorted victims and offered stolen data for sale on criminal forums.

The disclosures landed against a changing rulebook. On May 16 the SEC had adopted amendments to Regulation S-P. They required broker-dealers, investment advisers and other covered firms to run incident response programs, oversee service providers and notify affected customers. A few days earlier, the FTC’s amended Safeguards Rule had begun requiring many non-bank financial firms to report certain breaches to the FTC.

The striking thing about the campaign was its simplicity. Nobody broke the platform. Attackers used real keys, taken from computers that often belonged to neither the victim company nor the provider, and opened doors that had been left with a single lock.

Discussion of the campaign quickly settled on shared responsibility: the provider secures the platform, the customer secures its accounts. That framing is correct but too tidy. The weak point sat on devices that belonged to neither the bank nor the provider. Mandiant reported that many of the stolen credentials came from infostealer infections, including on contractor machines also used for personal activity.

Banks and other financial firms have particular reason to care. Their data warehouses tend to hold the most complete copies of customer information they have: account histories, identity data, credit attributes and the features fed into fraud and risk models. Those warehouses are also where outside analysts, consultants and model developers most often work. The combination of rich data and broad outside access is exactly what this campaign exploited.

The attack had three stages, and each was a place where the customer, not Snowflake, held the control: theft of the credential, its use to log in, and extraction of the data. Each is taken in turn below, after a short account of the technology and of what “shared responsibility” actually means.

Who holds which key on a rented data platform

Most large organizations no longer keep all their data on servers in their own buildings. Increasingly they rent capacity from specialist providers. SaaS, or software as a service, describes software a company uses over the internet rather than installing itself. A cloud data platform such as Snowflake is one example: the provider runs the machines, the storage and the software, and the customer loads its data and decides who can use it.

That arrangement creates a natural division of labor, usually called the shared responsibility model. A safe deposit vault works the same way. The bank is responsible for the building, the vault door, the guards and the alarms. The customer is responsible for their own key and for who they lend it to. If a customer’s key is copied and someone walks in with it, the vault has not failed, but the customer’s box is still empty.

In the cloud, the provider secures the underlying platform: its data centers, its software, its own staff access. The customer controls its account settings: who has logins, how those logins are verified, which internet addresses may connect and what is monitored. Many of those settings are optional, and in 2024 several of the most protective ones were not switched on by default.

Three technical terms recur in what follows. Single sign-on means staff log in once through the company’s central identity system, the identity provider, which then vouches for them to other applications. It lets the company apply the same rules, including MFA, everywhere. Local accounts are logins created directly inside an application, with their own passwords, outside that central system. Service accounts are logins used by software rather than people, for example an automated job that moves data into the warehouse every night.

Why the customer’s half is bigger on a data platform

The split of duties is not the same for every kind of cloud service. With infrastructure, such as rented servers, the customer manages a great deal: operating systems, networks, patches. With a finished business application, the provider manages most of it. A data platform falls in between, and the customer’s half concentrates on exactly the controls this campaign tested.

The customer decides how many accounts exist and how each one authenticates. It chooses which roles each account holds and therefore which tables it can read. It sets network policies, decides whether to connect privately or over the public internet, and decides whether logs leave the platform. The provider supplies all of these features. Whether they are used, and how well, is a customer configuration choice made account by account.

That makes a data platform’s security only as good as its least-governed account. A warehouse may have hundreds of human users, dozens of service accounts and a long tail of connections from analytics and reporting tools. Each is its own door, and the attackers only needed one.

With those ideas in place, the three stages of the attack become easy to follow.

Theft: where credentials live

An infostealer harvests saved passwords, browser cookies and session tokens from an infected machine and sells them in bulk. Cookies and session tokens are small pieces of data a website leaves in the browser to remember that a person has already logged in. Stealing them can let an attacker skip the login entirely. The malware usually arrives through ordinary routes: a pirated program, a game add-on, a fake download.

How the stolen-credential market works

Infostealers are sold as a service. A developer rents the malware to other criminals, who spread it as widely as they can. Each infected machine produces a “log,” a bundle of everything the malware could collect: saved passwords for every site, cookies, autofill data and details of the computer itself. Logs are then sold in bulk through online shops and messaging channels.

Buyers search the logs for valuable entries, such as logins to corporate systems, cloud consoles and data platforms. A login to a bank’s data warehouse is a rare and valuable find among millions of streaming-service and social-media passwords. That sorting step is where a crime of opportunity turns into a targeted attack.

The economics favor the criminals. Collecting credentials costs little, and the logs keep their value for as long as the passwords work. Mandiant’s finding that some credentials had gone unchanged for up to four years explains why old infections still paid off. A password rotated after the infection would have been worthless by the time it was used.

An infostealer does not need to target a bank. It only needs to land on any device where someone has signed in to the bank’s data platform. A data engineer at a consulting firm may hold access to several clients’ warehouses from one laptop. If that laptop is also used for games or pirated software, one infection exposes every client at once. The criminals who run infostealers often do not even know what they have. They sell logs of stolen credentials in bulk to others, who sort through them for valuable targets.

Banks govern their own endpoints, the laptops and desktops their staff use, closely. Contractor and vendor devices usually sit outside that regime, covered at best by contract language and a security questionnaire. The campaign showed that a contractor’s device is effectively part of the bank’s perimeter for whatever that contractor can reach. The “perimeter” is no longer the edge of the bank’s network. It is every device holding a working key.

Three responses follow. First, require contractors to reach sensitive data platforms only through bank-managed devices or a controlled virtual desktop, a computer environment that runs in the bank’s systems and is viewed remotely, so credentials never sit on unmanaged machines. Second, write credential-theft notification into contracts, with a short deadline and an obligation to reset. Third, monitor infostealer log markets for the bank’s domains and platform account names. Commercial services do this, and alerts can shorten a gap between theft and use that in this campaign sometimes ran to years.

The cost of controlling contractor devices

Each of those responses has a price, and the price explains why many firms had not paid it. Issuing bank laptops to contractors means buying, shipping, enrolling and recovering hardware for people who may stay a few months. Virtual desktops carry licensing and infrastructure costs. Data scientists often complain that they are slow for heavy analytical work.

There are middle routes. A firm can require contractors to sign in through its own identity provider and admit only devices that pass a health check, such as current endpoint protection and disk encryption. Managed browsers that keep corporate sessions separate from personal browsing are another option. Each reduces exposure without full device ownership. None removes it, because a compromised personal machine can still capture what passes through it.

The decision should scale with what the contractor can reach. A consultant building dashboards on aggregated data is a different risk from one with read access to raw customer tables. Many firms find that the expensive control is needed for a small number of high-privilege outside users. That makes the cost easier to justify than a blanket rule.

What to do when a stolen credential turns up

Monitoring only helps if someone acts on the alert. A useful runbook names the steps in order. Disable or reset the account, and end its active sessions. Review its login and query history back to the earliest plausible infection date. Identify the device the credential came from, and if it belongs to a contractor, require the contractor to investigate and confirm the result in writing.

The review window matters. Mandiant traced infections back to 2020, so a review that looks back only thirty days may miss the use that matters. The firm should also check whether the same person held credentials to other platforms, since an infostealer log usually contains everything saved on the machine.

Use: what a stolen password can open

A stolen password is only useful if the login accepts it alone. The affected accounts did. How does that happen at a well-run organization? Usually through history. Many data platforms were adopted by analytics, marketing or finance teams and set up with local accounts before anyone connected them to the corporate identity provider. Service integrations, early users and contractor accounts kept passwords. Later, the platform was connected to single sign-on, and most staff moved over. The old password accounts often lingered, out of sight.

The control is to route every human login through the bank’s identity provider with phishing-resistant MFA, and to remove local password accounts. Phishing-resistant MFA uses methods, such as hardware security keys or device-bound passkeys, that cannot be tricked into working on a fake login page. Where a service account cannot use single sign-on, key-pair or token authentication with narrow permissions and scheduled rotation replaces the password. Key-pair authentication admits only the approved software holding a specific cryptographic key; rotation means changing that key regularly.

The difficulty is coverage. The useful test is to ask the platform, not the identity team, which accounts can authenticate without single sign-on. The identity team sees the logins that pass through its system. The platform sees every login that exists. That list is usually longer than the identity team expects.

Running the coverage test

Most data platforms keep a list of users with their authentication settings and a login history that records how each login was verified. A data engineer can query both in an afternoon. The output should show every account that still has a password, every account that logged in with a password alone in the past year, and every account with no login at all in that period.

Each category leads to a different action. Dormant accounts should be disabled after a short confirmation with the business owner. Human accounts with passwords should be moved to single sign-on and their passwords removed. Software accounts should be reclassified as service accounts and given keys. Accounts that nobody can explain are the most important finding of all.

Snowflake itself later formalized the distinction. It separates human users from service users by type, and its published plan phases out a transitional type that let software accounts keep passwords. Firms using any platform can adopt the same discipline without waiting for the vendor: every account is either a person behind single sign-on or a named piece of software with a key.

Network rules and their trade-offs

Network policy adds a second gate. Snowflake and most comparable platforms can restrict logins to known address ranges. Mandiant found many affected accounts had none. An allow-list limited to the bank’s egress addresses (the internet addresses its own traffic leaves from) and approved vendor ranges would have rejected logins from attacker infrastructure even with a valid password. The trade-off is operational. Remote analysts and vendors need stable routes, which pushes access toward the same managed environments recommended above.

Allow-lists have to cover more than people. Business intelligence services, data integration tools and scheduled jobs often connect from the vendor’s cloud, with address ranges that change. Each must be listed, and the list must be updated when the vendor changes. Firms that find this burdensome often move toward private connectivity, in which traffic between the bank’s cloud network and the platform never crosses the public internet. That is stronger but needs network engineering and, on some platforms, a higher service tier.

Why MFA alone is not the finish line

MFA would have stopped this campaign’s logins. It would not stop every variant. Infostealers also collect session cookies, which represent a login that has already passed MFA. An attacker who replays a valid session can act as the user until the session expires or is revoked.

That is why session length and device binding matter. Shorter session lifetimes for sensitive platforms limit how long a stolen cookie works. Conditional access rules that require a known, healthy device make a replayed session from an unknown machine fail. Phishing-resistant methods also defeat the push-notification fatigue attacks that weaker MFA invites, where a user approves a prompt just to make it stop.

Extraction: noticing the data leave

Once inside, the attackers ran queries to find valuable tables and exported data in bulk. That pattern differs sharply from normal analytical work, which reads aggregates, such as totals and averages, and writes results back. An analyst asks how many customers in a region opened accounts last quarter. An attacker asks for every column of every customer record and downloads it. Yet several victims appear to have learned of their exposure from outside parties.

The attacker’s footprint in the logs

Mandiant’s report described the sequence in enough detail to build detections. The attackers listed tables across databases, then selected entire tables. They created temporary stages, storage areas inside the platform that disappear when the session ends. They copied query results into those stages as compressed files and downloaded the files to their own machines.

Each step leaves a trace. The login records the client software, and Mandiant listed client identifiers that included its reconnaissance tool and a commercial database tool. Listing commands touch the platform’s catalog. Creating temporary stages and downloading from them are distinct actions in the query history. A user who has never created a stage before, from a new address and an unfamiliar client, doing so at volume, is about as clear a signal as security monitoring gets.

The temporary stage also shows why logs matter. Once the session ends, the staged files are gone. The query history is what remains to show what was taken.

Detection on a SaaS data platform depends on the customer collecting the platform’s own logs. Login history, query history and data export or unload events need to reach the bank’s security monitoring. Alerts should cover new locations, unfamiliar client tools, discovery queries against system catalogs (the platform’s own list of what tables and columns exist, which an intruder searches to find valuable data), and exports above a set volume.

Each alert needs an owner who knows what normal looks like for that platform, often a data engineering lead rather than a security analyst. The bank should then test the alerts by running a controlled bulk export and checking that someone responds. An alarm that has never been tested is a hope, not a control.

Making there less to take

Detection limits the damage. Design limits what can be taken in the first place. Most analytical work does not need raw identifiers. Masking policies can show analysts a partial account number or a hashed customer ID. Row-level rules can restrict a regional team to its own region. Sensitive columns can live in a separate, more tightly controlled area.

Role design matters as much. An attacker inherits whatever the stolen account could read. Contractor and integration accounts often hold broad roles because narrowing them took effort nobody scheduled. Reviewing those roles, starting with outside users and service accounts, shrinks the blast radius of the next stolen password.

Both measures have costs. Masking and narrow roles create friction for analysts and slow model development, and data teams will push back. The trade-off is easiest to argue table by table: which tables hold direct identifiers, who truly needs them unmasked, and what it would mean if a full copy left the building.

Regulatory framing reinforces this. The interagency third-party risk guidance of 2023, the Gramm-Leach-Bliley Act safeguards obligations and, for SEC-registered firms, amended Regulation S-P all expect customer information to be protected wherever it is processed. A warehouse full of customer records is a critical system whoever hosts it.

Retention is part of the same question. Platform query logs are kept for a limited period by default, and an investigation that starts months after the theft may find the trail gone. Mandiant noted that Snowflake’s default retention supported threat hunting across roughly the past year. Exporting logs to the bank’s own storage, on the bank’s retention schedule, is what lets it later answer which customers were affected and whether notice is required.

A consultant’s account nobody removed

Suppose a regional bank uses a cloud data warehouse for marketing analytics and risk reporting. It hired a small analytics consultancy two years ago for a customer segmentation project. The consultant on the project logged in with a local password account, because the platform had not yet been connected to single sign-on.

The project ended, the bank moved its staff onto single sign-on with MFA, and everyone assumed the platform was secure. The consultant’s account was never removed. Meanwhile, the consultant’s personal laptop, also used for work, picked up an infostealer from a downloaded game. The bank’s warehouse password ended up in a bulk log sold online.

Now run the three stages. At the theft stage, a contract requiring managed devices or a virtual desktop would have kept the password off the laptop, and infostealer monitoring might have flagged it. At the use stage, removing local accounts or restricting logins to known addresses would have made the password useless. At the extraction stage, an alert on large exports, owned by someone who knew the platform, would have caught the download in progress. Any one of these controls breaks the chain. None of them sits with the provider.

If the chain had not been broken

Follow the same bank one step further, to the day it learns of the theft from an extortion email. The clock starts on several obligations at once. As a banking organization, it must tell its primary federal regulator within 36 hours of determining that a notification incident has occurred, under the interagency rule in force since 2022. State breach notification laws set their own triggers and timelines for telling customers.

Meeting those obligations requires answers the bank may not have. It needs to know which tables the account touched, which customers appear in them and when the access began. If the bank kept a year of query history in its own systems, a data engineer can answer within days. If it relied on whatever the platform still held, the answers may be partial, and the notice will have to be broader to be safe.

The bank then faces decisions about the consultancy. Its contract may say little about personal devices or credential theft. The bank may have no right to see the consultancy’s forensic findings. Both gaps are cheaper to close at signing than during an incident.

Who owns this inside the organization

One reason accounts like these go unwatched is that cloud data platforms tend to fall between teams. The platform may have been bought by a business unit, set up by data engineers, connected to single sign-on by the identity team, reviewed once by procurement and never mentioned to the security operations center. Each group can reasonably believe someone else is covering the gap.

A clearer split of ownership helps. The business owner of each platform, often the head of analytics or the chief data officer, is accountable for knowing what customer data it holds and who needs access. The identity team is responsible for making single sign-on with MFA the only route for people, and for flagging any account that bypasses it. The data engineering lead owns service accounts, their keys and their permissions, and is the person who knows what normal activity looks like. The security team owns the monitoring: collecting the logs, writing the alerts and making sure someone answers them. Third-party risk and procurement own the contractor and vendor terms, including device requirements and credential-theft notice.

The executive question is not which of these teams is “responsible for Snowflake.” It is whether, for every platform that holds customer data, each of those five roles has a named person, and whether those people have met. In many organizations, the first time they sit in the same room is during an incident.

Boards can help by asking for a single page per critical data platform: what it holds, who the five owners are, how many accounts bypass single sign-on, whether network restrictions are on, and when the export alert was last tested. That page is short enough to read in a meeting and specific enough to reveal a gap. It also turns a vague worry about “the cloud” into a list of concrete, checkable facts.

Ownership also needs a rhythm. A quarterly review in which the data engineering lead runs the platform’s own account list, the identity team compares it with the identity provider, and the business owner signs off on the differences takes an hour once the queries exist. Its value is in the differences: every account that appears in one list and not the other is a question someone must answer by name.

What an examiner will ask to see

Bank examiners and auditors working from the 2023 third-party guidance tend to ask for evidence rather than assurances. For a data platform that means the inventory of accounts with their authentication method, and the date and result of the last access review. It also means the network policy as configured, the log pipeline and the alert rules, and a record of the last alert test.

On the contractor side, examiners look for the contract clauses, the due diligence performed before onboarding and any monitoring since. A questionnaire completed three years ago and never revisited is weak evidence. A quarterly confirmation from each high-privilege contractor that their access route and devices still meet the contract is stronger, and costs little to collect.

What a bulk export costs a bank

Customers and notice. Data warehouses often hold the richest, broadest copies of customer information an organization has. A bulk export can affect huge numbers of people at once, triggering notice duties and lasting reputational damage.

Regulators. Banking and securities regulators expect firms to manage third-party risk and protect customer information wherever it is held. “The cloud provider was not breached” is not a defense if the firm’s own settings were the weak point.

Contractors and vendors. Most firms rely on outside talent for data work. Each contractor’s device, and its owner’s habits, become part of the firm’s risk unless access is deliberately channeled through controlled environments.

Cost of investigation. Without exported logs, a firm may be unable to say which records were taken. That uncertainty can force broader notifications, longer investigations and harder conversations with regulators.

Which rules reach the warehouse

The obligations differ by type of firm, and a holding company with several charters may face several at once. Organizations should check with counsel on which apply, but the outline is clear.

• Banks answer to the interagency safeguards guidelines under the Gramm-Leach-Bliley Act, the 2023 third-party risk guidance and the 36-hour regulator notification rule.
• Federally insured credit unions fall under the NCUA, whose rule since September 2023 requires notice of a reportable cyber incident within 72 hours.
• Broker-dealers and investment advisers fall under amended Regulation S-P. It requires written policies for overseeing service providers, which must notify the firm within 72 hours of a breach, and customer notice within 30 days. Larger firms had to comply by December 2025 and smaller ones by June 2026.
• Firms licensed in New York fall under the state’s amended cybersecurity regulation, which required MFA for anyone accessing the firm’s information systems from November 2025.
• Non-bank lenders and many fintechs fall under the FTC’s Safeguards Rule, which since May 2024 has required notice to the FTC within 30 days for breaches involving at least 500 consumers’ unencrypted information.

Card data adds a separate layer. Version 4.0 of the payment card industry standard required MFA for all access into the cardholder data environment from March 2025. A warehouse that holds full card numbers is in scope, wherever it runs.

The common thread is that none of these rules asks who hosts the data. Each asks whether the firm protected it, oversaw its providers and can say what happened. A configuration gap at a SaaS platform is the firm’s compliance gap.

A bank that can account for every login

A well-prepared firm can show, for each data platform, a list of every account that can log in, how it authenticates, from where and on whose device the credential is likely stored. Human logins pass through single sign-on with phishing-resistant MFA. Service accounts use keys with narrow permissions. Network policies limit where logins can come from. Logs flow to the firm’s monitoring and storage, and a tested alert fires on bulk exports.

A practical exercise for a bank or broker-dealer takes a few days per platform. List every account that can log in, how it authenticates, from where, and on whose device the credential likely sits. Then check whether a bulk export from each would raise an alert someone would see. The exercise usually surfaces a forgotten integration account, a former contractor or a network policy that was never applied.

The case for blaming the provider

A reasonable critic could argue that the article puts too much on the customer. Snowflake allowed password-only logins and left MFA optional. A platform holding the most sensitive data of thousands of firms could have enforced stronger defaults earlier, and later did. Customers pay providers partly to make good security the easy path.

That criticism has force, and the provider’s later changes concede part of it. Defaults shape outcomes across thousands of customers in a way individual firms cannot. But the argument does not move the bank’s obligations. Regulators assess the firm, not its vendor’s defaults. A stronger default also addresses only the login stage. Theft from contractor laptops and unnoticed bulk exports would remain the customer’s problem under any default the provider could reasonably set.

A second objection is cost. Managed devices for contractors, private connectivity and log pipelines add up, and smaller banks and credit unions have thin security teams. The answer is sequencing. Removing password-only accounts and turning on network policies cost almost nothing. Log export is moderate. Device controls can start with the handful of outside users who can read raw customer data.

The gaps it finds tend to be the same ones:

• Stopping at “the provider was not breached.” Shared responsibility means the customer’s half still has to be done.
• Trusting the identity dashboard. It cannot see local accounts that bypass single sign-on.
• Ignoring contractor devices. A questionnaire answer is not control over a personal laptop.
• Leaving network policy blank. Optional settings left off are an open door.
• Collecting logs nobody reads. Alerts without an owner, or never tested, give false comfort.
• Relying on default log retention. By the time an investigation starts, the evidence may be gone.

What to ask about each platform

• Which cloud data platforms hold our customer data, and who in the business owns each one?
• If we ask each platform directly, how many accounts can log in without single sign-on, and why do they still exist?
• Can contractors reach customer data from their own devices, or only from machines and virtual desktops we control?
• Would a large data export from our warehouse tonight raise an alert, who would see it, and when was that alert last tested?
• How long do we keep each platform’s login and query logs, and are they stored in our own systems?

The same five checks apply beyond data warehouses. Customer relationship systems, file-sharing services and analytics tools hold customer data under the same shared model. A firm that has answered them for its warehouse has a template it can reuse for each of the others.

With hindsight

The list of victims kept growing after the first disclosures. In July 2024 AT&T disclosed that call and text records of nearly all of its wireless customers had been taken from an AT&T workspace on a third-party cloud platform, widely reported to be Snowflake. Other companies confirmed exposure through 2024, and arrests of people alleged to be involved followed later that year. Confirmed victims spanned industries, among them the retailers Advance Auto Parts and Neiman Marcus and LendingTree’s QuoteWizard insurance-quote business. The spread showed that the common factor was configuration, not sector. What began as a handful of separate-looking announcements turned out to be a single, wide-reaching campaign.

AT&T’s filing showed how long the tail could be. The company said it learned of the claim on April 19, 2024, and that files had been taken between April 14 and April 25. The records covered calls and texts from roughly May to October 2022 and one day in January 2023, without their content. The Justice Department twice decided, in May and June, that a delay in public disclosure was warranted. The public learned in July of a theft that predated Mandiant’s first warning to Snowflake.

The provider side moved too. Snowflake let administrators require MFA for all users in an account and announced a phased end to single-factor password sign-ins. Its published timeline put the final phase, requiring MFA for every human user with a password and blocking password sign-in for legacy service users, at August to October 2026. In effect, the safer settings that customers once had to choose are becoming the rule.

The phases were staged. MFA for password sign-ins to Snowflake’s web interface came first, in a window from September 2025 to January 2026. Strong authentication for new users followed from May to July 2026. The final phase applies to all users, human and non-human. Existing transitional service accounts are converted to the service type, which cannot use a password. Snowflake’s plan excludes reader accounts and trial accounts, so firms that share data with partners through reader accounts still have to set their own authentication rules there.

Regulation moved on its own schedule. The amended Regulation S-P compliance dates arrived in December 2025 for larger firms and June 2026 for smaller ones. New York’s requirement for MFA across firms’ information systems took effect in November 2025. For many financial firms, the controls this campaign exposed became explicit legal obligations within two years.

Those defaults close the login gap the campaign used. They do nothing for credentials, tokens and sessions harvested from contractor machines, or for exports that nobody monitors. The theft and extraction stages remain the customer’s to control. A stolen session token can still open a door that MFA already approved, and a bulk download that nobody watches is still invisible, whatever the login policy says.

The infostealer trade also outlasted the campaign. Law enforcement disrupted the RedLine and META stealers in October 2024, and Microsoft and the Justice Department moved against Lumma’s infrastructure in May 2025. Those actions raised criminals’ costs without ending the market, and stolen session tokens remained a common route into cloud services.

Shared responsibility is a map of which locks belong to whom, and it hands off no risk. Providers can and did tighten their defaults, and that helps. But the devices that hold the keys, the accounts nobody remembers creating and the alarms on the way out of the building all sit on the customer’s side of the line. Firms that inventory those three things for every platform holding customer data, and test them, are in a much stronger position than those waiting for the next default to change.