Snowflake made verifiable repair the test of shared cloud responsibility

Summary

• Mandiant reported that every Snowflake campaign incident it directly handled traced to compromised customer credentials and found no evidence that unauthorized access stemmed from a breach of Snowflake's enterprise environment. Its campaign report is at https://cloud.google.com/blog/topics/threat-intelligence/unc5537-snowflake-data-theft-extortion.
• The campaign still tested provider responsibility because Snowflake controlled authentication surfaces, product defaults, security guidance, account telemetry, network-policy tooling, Trust Center checks, and post-campaign changes that no individual customer could create alone.
• Verifiable repair means measurable change: default MFA for human users in new accounts, stronger password rules, automatic leaked-password disabling, customer evidence packages, network-origin controls, and adoption metrics that show risk reduction across the installed base.
• Customer accountability remains substantial. Customers controlled user creation, role grants, password rotation, MFA enrollment in existing accounts, contractor access, network allow lists, data minimization, export privilege, and investigation readiness.

The platform was not shown to be breached; the baseline was shown to be permissive

The first discipline is to keep the campaign boundary exact. Mandiant's June 2024 report said unauthorized access in incidents it handled came from compromised customer credentials and that it found no evidence of a breach of Snowflake's enterprise environment. Snowflake's customer guidance, amplified by CISA at https://www.cisa.gov/news-events/alerts/2024/06/03/snowflake-recommends-customers-take-steps-prevent-unauthorized-access, similarly directed customers to investigate unauthorized user access and strengthen identity and network controls. The reviewed record does not establish a Snowflake platform exploit, a cross-tenant escape, or a provider master credential being stolen.

That negative finding matters because it shapes immediate response. A customer should not wait for a provider patch if the active problem is a valid user credential without MFA, no network allow list, and broad role privileges. The customer needs to rotate credentials, disable accounts, inspect login and query history, restrict origin networks, review roles, preserve logs, and notify affected people or regulators when required.

The opposite error is to say the provider had no accountability because the first secret belonged to customers. Snowflake operated the authentication endpoint that accepted those passwords. It supplied the MFA capability and chose when to change default behavior. It exposed or withheld telemetry fields. It provided network-policy controls and Trust Center findings. It could see cross-customer signals that no one tenant could see. It could later build leaked-password protection into the service. That is real control, even if the customer owned the account.

Snowflake's fiscal 2025 annual filing at https://www.sec.gov/Archives/edgar/data/1640147/000164014725000052/snow-20250131.htm states the company's shared-responsibility position and describes legal, regulatory, and reputational consequences following the 2024 activity. A filing is a company representation, not an adjudication. It is nevertheless relevant because Snowflake itself disclosed that the campaign affected business risk beyond any one customer tenant. Shared responsibility became a public company issue.

The article's lens is therefore not "Snowflake breached" or "customers alone failed." It is verifiable repair. After a campaign exploits a foreseeable pattern of password-only access, stale infostealer credentials, and missing network restrictions, the provider and customers need evidence that the next similar campaign will have fewer viable credentials, fewer password-only sessions, fewer unrestricted origins, better alerts, and faster evidence delivery.

The campaign path used ordinary functions under hostile identity

Mandiant described a practical chain. Credentials had been stolen by infostealer malware from systems not owned by Snowflake, including contractor machines used for personal activity in some cases. Those credentials remained valid, sometimes for years. The accounts lacked MFA. Customer instances lacked network allow lists. Attackers connected with standard clients and tools, performed reconnaissance, selected data, staged results, compressed files, and retrieved them. The pattern used supported database functionality under unauthorized identity.

That distinction is central to repair. Encryption at rest was not the decisive barrier. Snowflake's end-to-end encryption documentation at https://docs.snowflake.com/en/user-guide/security-encryption-end-to-end describes encryption at rest and in transit, but also explains that data must be used during table operations and can be unloaded and downloaded by authorized users. An attacker who satisfies the account's authentication and inherits a role can ask the service for readable results. Encryption is not a substitute for identity assurance, role design, export control, and detection.

Access control determined blast radius after login. Snowflake's access-control overview at https://docs.snowflake.com/en/user-guide/security-access-control-overview describes roles, privileges, ownership, and hierarchy. A stolen credential assigned narrow access is different from one assigned broad read privileges or account administration. A service account built for a pipeline is different from a contractor administrator. Least privilege is not a slogan; it is the difference between a hostile session returning one view and a hostile session walking through major customer tables.

Data classification and masking can reduce consequence. Snowflake's sensitive-data classification documentation at https://docs.snowflake.com/en/user-guide/classify-intro connects discovery of sensitive columns with masking and row-access policies. This does not prove affected customers had such controls. It shows a repair path: customers should identify personal and regulated fields, expose views rather than raw tables where possible, and separate export roles from ordinary read roles.

The observed exfiltration path also makes export a control in its own right. Bulk unloads are legitimate in a data platform. They support analytics, backup, downstream processing, and model workflows. But an unusual session creating temporary stages, exporting large results, and downloading them from an unfamiliar origin is not just "a query." It is a data movement event. Repair should make such events measurable, attributable, and, for high-risk datasets, interruptible.

MFA availability became MFA outcomes

MFA was available before the campaign. The successful accounts in Mandiant's report lacked it. That gap is the heart of the shared-responsibility dispute. A customer administrator could enable MFA, and many did not. A provider can truthfully say the control was available. But a provider that sees many high-value accounts still reachable by password alone has not achieved the security outcome, only made the setting available.

Snowflake's September 2024 announcement at https://www.snowflake.com/en/blog/multi-factor-identification-default/ moved the product posture. It said MFA would be enforced by default for human users in accounts created as of October 2024 and that service users would not be subject to that specific requirement. It also announced stronger password requirements for newly created and altered user passwords. This is meaningful repair because it changes the default path for future accounts.

The distinction between new and existing accounts is equally meaningful. A default for future accounts does not automatically remove every password-only path in the installed base. Existing customers may have legacy users, service accounts, contractors, break-glass accounts, and older clients.

A verifiable repair record should therefore measure legacy risk directly: number and share of human users without MFA, privileged human users without MFA, password users with stale last-login dates, users with known exposed credentials, service accounts using passwords rather than stronger workload authentication, and exceptions with business owners and expiry dates.

Snowflake's authentication-policy documentation at https://docs.snowflake.com/en/user-guide/authentication-policies gives administrators controls over authentication methods, clients, identity providers, and MFA enrollment. Its key-pair authentication documentation at https://docs.snowflake.com/en/user-guide/key-pair-auth gives service accounts an alternative to static passwords. These controls put duties on customers, but they also define the provider's repair surface: the product should make good patterns easier, bad exceptions visible, and migration less risky.

NIST digital identity guidance at https://pages.nist.gov/800-63-4/sp800-63b.html helps state the outcome. Passwords are not replay-resistant. Phishing-resistant or cryptographically bound methods reduce the value of a stolen password. For Snowflake customers, that means human administrators should move through federated identity or strong MFA, while service users should use scoped workload credentials that rotate and can be disabled without impersonating a person.

Leaked-password blocking made shared responsibility measurable

The most direct provider repair after a stolen-credential campaign is not a lecture about password reuse. It is making known stolen passwords stop working. Snowflake's December 2024 announcement at https://www.snowflake.com/en/blog/leaked-password-protection/ said it would automatically disable passwords detected on the dark web through a privacy-preserving process when confirmed as leaked and still valid. This control addresses the campaign's central advantage: credentials stolen long before 2024 remained accepted by the service.

Leaked-password protection does not remove customer duty. Customers still need endpoint security, contractor governance, password rotation, federation, service-user design, and least privilege. But it changes the division of labor. Individual customers often cannot see the global infostealer market as well as a cloud provider can. A provider can buy or receive threat intelligence, match exposed credentials in a controlled way, and disable a password before each customer independently discovers it. That is the kind of provider-level control that turns shared responsibility from a clause into a system behavior.

The evidence question is adoption and performance. How many valid leaked passwords were found? How quickly were they disabled? How many belonged to privileged users? How many accounts moved from password to key-pair or federated access? How many disabled-password events led to support friction or unsafe workarounds? How many customers still have exceptions? Without metrics, leaked-password protection remains a good announcement. With metrics, it becomes verifiable repair.

CISA's Secure by Design pledge at https://www.cisa.gov/sites/default/files/2024-05/CISA%20Secure%20by%20Design%20Pledge_508c.pdf frames this distinction. It asks manufacturers to move beyond optional controls toward measurable outcomes such as default MFA and adoption metrics. Snowflake's July 2024 pledge announcement at https://www.snowflake.com/en/blog/snowflake-cybersecurity-cisa-secure-by-design/ placed the company inside that public commitment. The pledge is voluntary and not a legal verdict on the campaign. It is relevant because it identifies the type of evidence customers should expect after the event.

Network policy was a second gate

Mandiant identified missing network allow lists as one recurring factor. Snowflake's network-policy documentation at https://docs.snowflake.com/en/user-guide/network-policies states the practical default: without a policy, users can connect from any computer or device. Customers can restrict access by allowed or blocked network locations and use private connectivity patterns for stronger boundaries.

The customer is the actor best positioned to know legitimate origins: offices, VPNs, cloud workloads, managed contractor desktops, and approved integration providers. Snowflake cannot guess every valid path without breaking service. But Snowflake controls whether unrestricted public access is silent or visible. A verifiable repair program should report which accounts lack network policies, which privileged users bypass them, whether internal-stage access is covered, and whether policies actually match business-approved origins.

Network controls are not sufficient alone. An attacker may use an approved VPN, compromise a contractor machine already inside an allow list, or steal a token after authentication. Yet defense should be layered. A stolen password, no MFA, no network restriction, broad role, and unmonitored export is a chain. Breaking any one link can matter. Repair is the process of reducing the number of customer environments where all links remain open together.

The provider should also make lockout management safe. Administrators may avoid network policies because they fear blocking business users or service jobs. Simulation, staged rollout, emergency contacts, temporary exceptions, and clear logs reduce that fear. The better the migration path, the harder it is to treat missing policies as ordinary.

Telemetry is the evidence boundary

After a data-theft campaign, customers need more than general reassurance. They need to know who logged in, from where, with which factor, using which client, under which role, what queries ran, what entities were touched, what data was unloaded, what stages were used, and how much data moved. Snowflake's current documentation describes multiple views that can support such work.

LOGIN_HISTORY at https://docs.snowflake.com/en/sql-reference/account-usage/login_history provides login attempts with source IP, client, success, and factor information. QUERY_HISTORY at https://docs.snowflake.com/en/sql-reference/account-usage/query_history provides query activity, user, role, query text, result size, unloaded rows, and bytes sent over the network. ACCESS_HISTORY at https://docs.snowflake.com/en/sql-reference/account-usage/access_history can help reconstruct entity and column access for eligible editions. Trust Center documentation at https://docs.snowflake.com/en/user-guide/trust-center/overview describes posture checks and detections for MFA, network policies, risky sign-ins, unusual IP addresses, and large transfers.

Those are capabilities. Capability is not proof of investigation readiness. Customers must have rights to query the views, export them to durable security storage, understand latency and retention, and correlate them with identity-provider, endpoint, and ticketing data. Edition differences can change the precision of field-level scoping. Provider views may have delays that matter for active containment. Query text alone may not tell a privacy team which individuals were represented unless the customer has data maps.

Verifiable repair should therefore include evidence packages. When Snowflake notifies a potentially exposed customer, the customer should receive account identifiers, users, timestamps, origin networks, first and second factor status, client identifiers, session and query identifiers, roles, entities touched, stage names, unload volume, confidence, and recommended containment. A label such as "potentially exposed" is acceptable as an opening, but it must be followed by enough data for the customer to decide whether personal information was involved.

Provider intervention also needs prior authority. A cloud provider may see suspicious activity before a customer does, but automatically blocking a session can interrupt production. Failing to act can permit theft. Repair should define thresholds for temporary suspension, emergency customer contacts, evidence preservation, and override. Customers should nominate security contacts who can act at any hour. Snowflake should measure time from cross-customer signal to customer notice and time from notice to containment.

Data locality stopped at access

Snowflake region choice can matter for latency, resilience, privacy, and procurement. The supported-regions documentation at https://docs.snowflake.com/en/user-guide/intro-regions says an account is hosted in one region and that data remains there unless users explicitly copy, move, or replicate it. It also states the key limit: region choice does not limit user access to Snowflake.

The campaign turned that limit into a sovereignty problem. A customer's tables may have been stored in an approved region. A valid identity could still connect from elsewhere, query the data, unload it to a stage, and download a copy. The source account's placement did not prevent remote access or export. The public campaign record does not establish the source and destination countries for every victim, so no universal cross-border legal conclusion is supportable. The architectural lesson remains: storage locality is not access locality.

Snowflake's cross-region sharing guidance at https://docs.snowflake.com/en/user-guide/secure-data-sharing-across-regions-plaforms.html warns customers to confirm legal and regulatory restrictions before replicating data to another region or country. That guidance concerns approved movement. Credential-driven export is different because it can create an uncontrolled copy outside the selected region without changing the source account's region. A data inventory that records only the source region can be accurate and still incomplete after an export.

Data sovereignty repair therefore needs four layers: where authoritative data is hosted, which identities may connect from which devices and jurisdictions, what movement functions may create copies, and what evidence exists after an incident. Snowflake controls region offerings, authentication, network tools, export mechanics, and telemetry. Customers control lawful basis, data fields, role grants, movement approvals, and notification analysis. Both sides need evidence at their boundary.

Customer cases show consequence, not a single master count

The campaign's public shape was influenced by affected-company disclosures. Each record must stay within its own facts.

Live Nation's May 2024 filing at https://www.sec.gov/Archives/edgar/data/1335258/000133525824000081/lyv-20240520.htm said the company identified unauthorized activity in a third-party cloud database environment containing primarily Ticketmaster data and that a criminal actor later offered alleged company user data for sale. The filing did not name Snowflake or provide a confirmed affected-person count.

Ticketmaster Canada's incident page at https://help.ticketmaster.ca/hc/en-us/articles/26420491205009-Ticketmaster-Data-Security-Incident described an isolated third-party cloud database, possible fields for some North American ticket buyers, and the boundary that Ticketmaster customer accounts were not affected. Canada's privacy commissioner later identified Snowflake as Ticketmaster's provider in a parliamentary briefing at https://www.priv.gc.ca/en/privacy-and-transparency-at-the-opc/proactive-disclosure/opc-parl-bp/ethi_20251006/is_20251006/, while also indicating that the investigation remained open and that Ticketmaster Canada remained the controller under review.

AT&T's July 2024 filing at https://www.sec.gov/Archives/edgar/data/732717/000073271724000046/t-20240506.htm described unlawful access to an AT&T workspace on a third-party cloud platform and exfiltration of call and text interaction records. The filing did not name Snowflake. It is useful for understanding one disclosed third-party cloud-workspace incident and its field boundaries, not as standalone attribution.

These examples do not create a campaign-wide person count. Mandiant's roughly 165 potentially exposed organizations is a notification population, not a confirmed victim count, record count, or affected-individual count. Each customer held different data, roles, retention, regions, and notice duties. Verifiable repair must help each customer scope its own facts rather than making a single platform-level number do all the work.

A typography note for evidence packages

When customers receive high-severity cloud security evidence, layout can decide whether the right person acts quickly. A table of sessions, factors, roles, entities, and transfers must be readable under pressure. The following typography block belongs in the public body because evidence design is part of repair.

Typography is the art and technique of arranging type to make written language legible, readable, and visually appealing. It involves selecting typefaces, point sizes, line lengths, line-spacing, and letter-spacing.

• Typography originated with the invention of movable type by Johannes Gutenberg in the 15th century.
• Key elements include font selection, kerning, tracking, and leading.
• Good typography enhances readability and conveys mood or tone in design.

For Snowflake customers, readable evidence means timestamps in one time base, clear user and role labels, separation of confirmed activity from suspicion, visible MFA status, and direct links between queries, stages, transfer volume, and affected data stores. A dense export of logs may be complete but unusable. A concise evidence pack may be the difference between a fast containment decision and a delayed privacy analysis.

Accountability by practical control

The attackers controlled the criminal activity: using stolen credentials, entering customer environments, staging data, taking it, and attempting sale or extortion. They are responsible for that conduct.

Customers controlled many failed gates. They created users, assigned roles, chose whether human users could sign in with passwords alone, retained stale credentials, allowed contractor access, left some accounts without network policies, granted data access, and governed exports. A customer whose high-value warehouse accepted an old password from an unfamiliar origin without MFA or narrow roles cannot shift all responsibility to the provider.

Snowflake controlled the baseline and repair tools. It controlled whether new human users had MFA by default, whether leaked passwords were disabled provider-side, whether risky configurations appeared in Trust Center, which telemetry fields were available, how customers were notified, how guidance was written, and how quickly post-campaign controls shipped. A provider that sees the same pattern across tenants has a duty to reduce the pattern at scale, not only to tell each customer to read the manual.

Identity providers, contractors, and endpoint owners controlled adjacent conditions. Contractor devices used across clients can spread one infostealer incident into several cloud tenants. Identity providers can enforce stronger factors and conditional access. Managed endpoints can keep credentials out of personal machines. Those actors matter, but they do not erase customer and provider duties over the Snowflake account itself.

Regulators, insurers, and procurement teams control incentives. NIST's supply-chain guidance at https://csrc.nist.gov/pubs/sp/1305/final supports defining supplier requirements proportionate to criticality. For a data warehouse, that means contracts and renewals should ask for MFA adoption metrics, leaked-password response, evidence-package fields, retention guarantees, notification timing, support escalation, and regional movement controls. A security questionnaire that asks only whether MFA exists is too shallow after this campaign.

What would prove durable repair

The repair record should include at least ten outcomes.

First, all new human users default to MFA or stronger federated access, and the installed base shows a rising share of protected human and privileged human accounts. Second, service users move away from static passwords toward key-pair, OAuth, or other scoped workload credentials with rotation. Third, leaked-password protection reports confirmed disabling events and average time to disable. Fourth, network-policy coverage increases, especially for privileged accounts and internal stages.

Fifth, Trust Center findings are not merely displayed but remediated with exception owners and expiry dates. Sixth, telemetry retention and export are sufficient for delayed discovery and privacy scoping. Seventh, large unload and unusual-origin detections are tuned and routed to people who can act. Eighth, provider notifications include concrete session, query, role, entity, and transfer evidence. Ninth, affected customers can map queries to people and regulated data categories. Tenth, customer contracts and renewal reviews incorporate evidence rather than relying on shared-responsibility wording.

Litigation can influence the record but should not replace control evidence. The pleading-stage order in the Snowflake multidistrict litigation at https://www.govinfo.gov/content/pkg/USCOURTS-mtd-2_24-md-03126/pdf/USCOURTS-mtd-2_24-md-03126-34.pdf allowed certain allegations to proceed while treating them under procedural standards. That is not a final finding of liability. It does show that courts may examine provider defaults, foreseeability, and causation even when the public story begins with customer credentials.

The installed-base problem

Secure defaults are most effective at creation time. They are harder in an installed base where customers already have automation, service users, contractors, identity providers, old clients, and emergency accounts. Snowflake's default MFA change for new accounts was a material step, but the campaign's risk lived heavily in existing accounts with existing habits. Verifiable repair therefore needs a migration story for the installed base, not only a new-account story.

The installed-base problem has several layers. First, old human users may still authenticate directly with passwords because federation was never completed. Second, privileged users may have exceptions because administrators fear lockout. Third, service users may be misclassified as humans or humans may use service-style credentials. Fourth, contractors may retain access after a project ends. Fifth, dormant accounts may still have roles that reach sensitive data. Sixth, integrations may fail if password rules or network policies change suddenly.

The provider can reduce this friction without taking over the customer's tenant. It can show administrators a prioritized list of risky identities, split by privilege and data reach. It can provide dry-run policies that show who would be blocked by MFA or network restrictions. It can require exception owners and expiry dates. It can distinguish break-glass accounts from ordinary legacy accounts. It can provide migration aids for service users moving to key-pair or OAuth patterns. It can send repeated product nudges tied to real risk rather than generic banners.

Customers then have to act. A customer that receives a dashboard showing privileged password-only users and leaves them unchanged for months owns that residual risk. A customer that cannot tell whether a contractor account is still needed owns an identity governance failure. A customer that lets a service account read entire raw tables because "the pipeline used to need it" owns excessive role scope. Shared responsibility becomes concrete when the provider shows the evidence and the customer either remediates or records an accountable exception.

The repair record should separate three states: remediated, excepted, and unknown. Remediated means the risky condition is gone. Excepted means a business owner accepted it with compensating controls and a date for review. Unknown means no one has taken responsibility. A mature program drives the unknown count toward zero. Public reassurance often skips this distinction; verifiable repair depends on it.

Customer evidence must connect technical logs to people

Snowflake can expose rich technical telemetry, but privacy and legal response require a bridge from technical entities to people and obligations. A query identifier, role name, or stage path is only the start. The customer must know which table held which personal fields, which data subjects were represented, which country or state rules apply, which contractual notice duties exist, and which downstream systems received copies. Without that bridge, the customer may know that bytes left but not know whom to notify.

That bridge should be prepared before an incident. Data owners should maintain field inventories for regulated data, business purpose, retention period, masking policy, and approved export routes. Security teams should know where Snowflake logs are retained outside the platform and how long. Privacy teams should be able to ask for a list of affected tables and receive a mapping to categories of people and fields. Legal teams should know which regions and customer contracts attach to those records.

Provider evidence can make this easier. If a notification includes the exact roles, entities, stages, and volume, the customer can avoid a broad and slow search. If the provider also labels whether MFA was present, whether the source was unusual, and whether leaked-password protection later disabled the credential, the customer can understand cause and containment. If the provider gives only general advice, the customer must reconstruct the evidence while the clock for notice and extortion response is already running.

The campaign also exposed a retention question for telemetry itself. Native histories may cover a year, but legal disputes, delayed discovery, and regulator inquiries can extend longer. High-risk customers should stream logs into an independent security store with retention aligned to their obligations. A provider should make such export practical and documented. The customer should prove it works by periodically reconstructing a sample access path from login through query to data category.

Repair cannot rely on customer shame

After a credential campaign, it is tempting to treat customers without MFA as the story's lesson. That is partly true and still limited public evidence. Publicly shaming customers does not disable leaked passwords, redesign defaults, or deliver evidence packages. It can even make customers hide weak configurations until an incident forces disclosure.

The better model is progressive hardening. The provider starts with visibility, then stronger defaults, then targeted warnings, then exception governance, then enforcement for risk categories where the consequence justifies it. Customers receive migration time and tooling, but they also lose the ability to leave high-risk gaps invisible. Procurement teams then ask for adoption metrics and exception counts, not only feature lists.

This approach recognizes that cloud platforms are shared operating systems for business data. A provider that makes a safer default may briefly increase customer friction, but it also reduces the pool of targets available to criminal groups. A customer that accepts enforcement may need to update scripts or identities, but it gains a stronger story for regulators, insurers, and data subjects. Repair works when both sides can point to changed conditions, not changed messaging.

Procurement should demand repair telemetry

A buyer of a high-value data platform should treat post-campaign telemetry as a procurement requirement. The question is not only whether the provider now offers MFA, network policies, leaked-password controls, and Trust Center findings. The question is whether the buyer can receive evidence that those controls are active, complete, and tested in the buyer's own account. Feature availability is supplier language. Control coverage is operating language.

The procurement record should ask for an identity coverage report, including human users, privileged users, service users, dormant accounts, external contractors, federation status, MFA status, and password exceptions. It should ask for network coverage by account, user class, internal stages, and private endpoints. It should ask whether leaked-password protection is enabled, what event notices it produces, and how a disabled password is reflected in audit records. It should ask which Trust Center findings are available at the contracted tier and how long the relevant history is retained.

Incident terms should be equally concrete. A generic notice clause is weak after this campaign. Customers need timelines for high-severity notification, evidence fields that will be included, emergency contacts, support escalation, preservation of logs, and cooperation in data-subject scoping. A customer that holds regulated personal data should require sample evidence packets before renewal, not after theft. A tabletop exercise can test whether the provider and customer can move from suspicious login to affected-field analysis within the necessary window.

This does not shift all work to Snowflake. The customer must maintain its own maps, retain logs, and know its privacy obligations. But the provider controls many facts needed for the map to become usable. A procurement process that asks only for attestations will miss the operational issue. A process that asks for repair telemetry will reveal whether shared responsibility is ready for the next campaign.

The same evidence should appear in renewals. If a customer remains on password-heavy access a year after the campaign, renewal should force a named exception or a funded migration. If a customer cannot receive ACCESS_HISTORY-level detail because of edition, the renewal should document whether that limitation is acceptable for the data stored. If network policies are absent, the renewal should identify the operational blocker clearly. Repair should be reviewed before leverage disappears into another contract term.

Renewal evidence should also separate platform change from tenant change. Snowflake can ship a stronger default, but the customer's account may still contain password-only users, broad roles, stale contractors, and unreviewed stages. The buyer should ask for the account's own exception ledger, not only the provider's product roadmap. That distinction prevents a familiar post-incident drift: the provider announces a control, customers assume the risk has moved, and the installed base remains materially exposed.

For boards and privacy teams, that tenant-level record is the bridge between technical repair and legal confidence. A claim that "MFA is available" does not answer whether the affected account used it. A claim that "network policies exist" does not answer whether the stolen credential could reach data from an unusual origin. A claim that "telemetry is retained" does not answer whether the organization can map queries to regulated fields. Verifiable repair lives in those account-specific answers.

What not to infer

A restrained account should avoid four leaps. First, the campaign does not prove Snowflake's production platform was breached. Second, it does not prove every notified organization lost data. Third, it does not prove every affected customer had the same fields, people, or legal duties. Fourth, post-campaign product changes do not by themselves prove negligence before the changes. Security products evolve after incidents for many reasons, including better threat intelligence and changed standards.

At the same time, restraint does not require silence about provider duty. A provider can be free of a platform-breach finding and still be accountable for default design, telemetry quality, and cross-customer warnings. A customer can be at fault for weak identity controls and still need the provider's data to investigate. A litigation order can be non-final and still show that default MFA and foreseeability will be scrutinized. Balanced accountability keeps all of those propositions alive at once.

The final assessment is high impact and high confidence. The confirmed evidence supports a customer-credential campaign, not a Snowflake platform breach. But the evidence also shows why provider defaults, telemetry, and cross-customer security automation are part of accountability. Shared responsibility is credible only when both sides can show the gates they closed. After this campaign, Snowflake's test is not whether it can say MFA existed. It is whether fewer stolen passwords can become sessions, fewer sessions can reach broad data, and more customers can prove exactly what happened before data leaves.

Typography

Typography is the art and technique of arranging type to make written language legible, readable, and visually appealing. It involves selecting typefaces, point sizes, line lengths, line-spacing, and letter-spacing.

• Typography originated with the invention of movable type by Johannes Gutenberg in the 15th century.
• Key elements include font selection, kerning, tracking, and leading.
• Good typography enhances readability and conveys mood or tone in design.