Snowflake kills passwords for service accounts. The cleanup starts now.
The cloud data giant is retiring password logins for machine accounts. Working out what those accounts actually do is the real headache.
Key points
- Snowflake, a cloud data platform used by thousands of large companies, is ending password logins for its legacy service accounts.
- Service accounts are logins used by software, not people, to move data between systems automatically.
- Customers must switch these accounts to passwordless methods such as key pairs or short-lived OAuth tokens.
- The technical switch is the easy part; finding out what each account does and who owns it is harder.
- Identity firm Token Security says most companies don't have a clean inventory of their machine accounts.
Snowflake is retiring password authentication for legacy service accounts, and the change is more consequential than it sounds.
The platform stores and processes data for thousands of large businesses. Service accounts are the logins that software and automated pipelines use to talk to each other without a human at the keyboard. Think of the overnight job that copies sales figures into a reporting dashboard. That job needs a login too.
Until now, many of those logins were protected by a static password sitting in a config file. Snowflake wants them moved to key-pair authentication (a pair of mathematically linked files, one kept secret) and short-lived tokens issued through OAuth, a standard that lets one system grant another temporary access. The company's official service user documentation spells out the timetable and the recommended replacements.
The direction of travel is sensible. Static passwords on machine accounts are among the most reliably stolen secrets in cloud breaches. MFA wouldn't have helped here, because there's no human to tap a phone.
Why is Snowflake doing this now?
Because its own customers keep getting hit through exactly this weakness. In 2024, attackers used stolen passwords from infostealer malware to log into Snowflake customer tenants, including Ticketmaster and AT&T. None of the affected accounts had multi-factor authentication turned on. Closing password logins for machine accounts removes a large part of that entry path.
We've been tracking Snowflake's credential exposure problem since August: our story on 17 August 2026 found that a flaw in one of the company's own repositories could have exposed its internal credentials through the build system.
Should you worry about the migration?
The migration itself isn't the hard part. Generate a key pair, update the client, done. The problem, as Token Security lays out, is that most large organisations have no clean list of their service accounts, no named owner for each one, and no idea what would break if they turned one off.
A typical Snowflake customer might have hundreds of these logins. Some belong to a data pipeline that still runs every night. Others were created for a contractor who left in 2022, or for a proof of concept nobody ever switched off. All of them carry real database access.
| Task | What it involves | Why it is hard |
|---|---|---|
| Inventory | List every service account and where it logs in from | Accounts get created ad hoc, often outside change control |
| Ownership | Assign a named human owner to each account | Original creators have often left the company |
| Right-sizing | Cut each account's permissions to what it actually needs | Requires reading query logs, not just role assignments |
| Rotation | Move from static password to key pair or OAuth token | Every dependent script and tool must be updated in lockstep |
This is the gap between authentication (proving who is logging in) and authorisation (deciding what they're allowed to touch). Snowflake is fixing the first. The second remains the customer's job, and it's where most of the mess lives. Our 6 August story on a healthcare software provider showed how a single stolen credential can unravel layered defences in minutes once that authorisation layer is soft.
What should ordinary customers take from this?
If you run cloud services, machine logins are quietly doing work in the background right now. They rarely appear on security dashboards. Almost none have a named owner. Statistically, they're how attackers get in.
The password is dying for humans. It's taking considerably longer to die for the software they wrote.
