# Snowflake Killed the Service-Account Password. The Reckoning Is Just Starting.
Connor Moucka didn't need a zero-day. He needed a username and a password — and the world handed him hundreds of them.
On August 5, Moucka pleaded guilty to computer fraud, wire fraud, aggravated identity theft, and conspiracy. The charges stem from a campaign that reached 165 Snowflake customer organizations using nothing more exotic than valid credentials: years-old, unrotated, single-factor logins that nobody had bothered to kill. The haul included billions of records and the call and text metadata of nearly every AT&T wireless customer in the United States. Not because Snowflake had a bug. Because its customers had forgotten passwords were still passwords.
Snowflake's response is now coming into Phase 3: mandatory migration of legacy service accounts off password authentication entirely. The LEGACY_SERVICE user type is being deprecated. The new SERVICE type can't store a password at all. By the time individual accounts hit their enforcement dates this autumn, any service account still clinging to password auth will simply stop working.
The technical change is the easy part. What follows is not.
## The Oldest Accounts Are the Worst Accounts
The phased rollout tells you everything about who is left in the room. The first two phases — running from September 2025 through July 2026 — closed the most obvious doors. Human users got pushed to MFA. Every newly created non-human user had to be of type SERVICE. The accounts that remain, the ones now facing the August-October 2026 deadline, are the ones nobody touched for years.
That age is the real risk factor. Old service accounts have had more time for credentials to appear in breach dumps that never triggered an alert. Their original owners have changed teams, left the company, or been laid off. The systems that consume them often lack documentation. The tickets that justified their creation are buried in a ticketing system that's been migrated twice since 2021.
These are not edge cases. They are the norm for any organization that has been running Snowflake workloads for more than a few years. The Moucka campaign targeted exactly this stratum: accounts that were technically valid but organizationally invisible.
## Three Questions, Two of Which Snowflake Can't Answer
The inventory work starts with three questions for every service account:
Which accounts are still authenticating with a password? Snowflake can answer this directly. The ACCOUNT_USAGE schema, combined with 365 days of login history, shows every password-based authentication — including the client and source IP. If a service account last signed in from an EC2 IP in us-east-1 eighteen months ago, that's a data point. If it signed in last Tuesday, that's a fire drill.
Who owns it? Snowflake has no idea. This information lives in someone's memory, or in a 2022 Jira ticket, or nowhere. There's no ownership field in the platform, no alert routing, no automated deprovisioning chain. Organizations are expected to maintain that layer themselves, and most didn't.
What breaks when the password stops working? Again, Snowflake can't tell you. The downstream system that authenticated with this account — whether it's a dbt job, an internal analytics pipeline, or a vendor integration that nobody's touched since the original contractor left — will break silently or loudly, and you will find out at the worst possible time.
The failure mode isn't migration. It's discovering that you don't know what you're migrating.
## Ownership on Paper Isn't Ownership
There's a version of this migration that happens in October, under deadline pressure, where teams frantically rotate keys without ever answering the second and third questions properly. A service account gets a new token. Someone's name goes in the owner field of a spreadsheet. The deadline passes.
Six months later, the named owner has moved to a different team. Nobody updated the spreadsheet. The account still has access to production data warehouses. When it appears in the next breach, the post-mortem will describe it as "orphaned."
Real ownership means someone's pager goes off at 2 a.m. when that account's authentication fails. It means someone signs off on the access scope during quarterly review. It means a deprovisioning process that actually runs when the owner leaves the organization. Anything less is a label, not accountability.
The accounts that make it through Phase 3 with a named owner and a least-privilege scope are the win condition. The ones that get migrated mechanically, token swapped and spreadsheet updated and nothing else, are the next breach waiting to find the right threat actor.
## What Snowflake's Move Actually Signals
Snowflake is not the last platform to run this play. The Moucka campaign produced the scale of damage — AT&T, Ticketmaster, Advance Auto Parts among the victims — that forces industry-wide reckoning. When a single credential management failure affects that many organizations through a shared cloud platform, the platform cannot stay neutral.
Expect more SaaS platforms to deprecate password-based service accounts in the next eighteen months. The combination of enforcement pressure from large cloud providers, increasing regulatory scrutiny of non-human identity, and the demonstrable cost of the alternative is going to push this across the industry. Snowflake is early, not exceptional.
The question for security teams is whether they use this mandate to actually fix their non-human identity inventory, or whether they do the minimum required to pass the enforcement gate and call it done.
---
## HackWire Analysis
The Moucka case should have been the wake-up call, but wake-up calls require someone to be listening. What Snowflake is forcing in Phase 3 is not a technical migration — it's an inventory audit that most organizations have been actively avoiding for years. Non-human identities have always been the dark matter of identity governance: nobody can see them, nobody owns them, and they accumulate quietly until something catastrophic brings them into the light.
The pattern here is well-established. UNC5537's campaign followed the same playbook as prior credential-based cloud attacks: find accounts with no MFA, no network restrictions, and credentials that haven't rotated since a developer left the company. This isn't novel tradecraft. It's opportunism against a surface area that grows every time an integration gets stood up without a deprovisioning plan.
What other coverage is missing: the focus on Snowflake's technical enforcement mechanism obscures the harder organizational problem. Rotating to key-based auth solves the authentication weakness. It does not solve orphaned accounts with excessive privileges, missing ownership records, or the absence of any process for reviewing what non-human identities actually need access to. Security teams that treat Phase 3 as a checkbox will finish October with a fresh set of tokens attached to the same governance void.
For defenders: the Snowflake ACCOUNT_USAGE login history is actionable right now. Pull every service account that has authenticated with a password in the last 90 days and force the ownership question before the deadline does it for you under pressure. The accounts you can't assign an owner to are the ones that should not exist.
The industry has known for years that credential hygiene for service accounts is broken. Snowflake's enforcement is not a lesson. It's a consequence. — *HackWire Editorial*
---
## Related Coverage