Snowflake is moving legacy service accounts away from passwords, according to BleepingComputer, forcing customers to deal with a class of non-human identities that often outlive the systems and teams that created them. The reported change comes in Phase 3 of Snowflake’s authentication rollout. BleepingComputer says Snowflake is migrating legacy service users to the SERVICE type, which blocks password-based authentication because SERVICE users cannot store a password. The LEGACY_SERVICE user type is being fully deprecated, and every service account is expected to lose the ability to authenticate with a password. That makes password replacement the easy part. BleepingComputer, drawing on analysis from Token Security, frames the harder work as operational discovery: which jobs, applications or integrations use each account; who owns it; and whether it still needs the access it has. Older service accounts are especially risky because credentials may have leaked, owners may have moved, and dependencies may no longer be documented. The context is Snowflake’s recent credential-abuse exposure. BleepingComputer reports that Connor Moucka and co-conspirators did not exploit a Snowflake software vulnerability; they used valid customer credentials, many of them old, to access more than 165 Snowflake customer organizations. The campaign included theft of billions of records, including call and text records of nearly all AT&T wireless customers, and Moucka pleaded guilty on August 5 to computer fraud, wire fraud, aggravated identity theft, and conspiracy. The identity failure described in the report is familiar: credentials remained usable after exposure, some affected accounts lacked a second factor, and network restrictions were often missing. Snowflake’s passwordless move targets that failure mode for service users, but it does not automatically answer whether an account should still exist or retain its current permissions. BleepingComputer says Snowflake does provide some discovery hooks. The ACCOUNT_USAGE schema can show the list of users and each account’s type, while login history records authentication attempts, including client and source IP, for 365 days. Together, those records can help identify accounts still signing in with passwords, when they last did so, and where those attempts came from. The limits are organizational rather than purely technical. Snowflake can show usage data, but it cannot know who requested a service account, which internal system depends on it, or who should respond if the account fails. Token Security’s analysis argues that an inventory built only to meet a deadline starts aging as soon as new accounts are created. For security teams, the immediate migration task is to find password-using service accounts and move them to supported passwordless methods. The longer-term control is ownership: deciding who receives alerts, who approves access, and who is accountable for deprovisioning when an account no longer has a clear purpose. Who benefits: Organizations with mature identity inventories and clear service ownership should be able to migrate with less disruption. Security teams also gain a forcing function to review old non-human identities that may have avoided scrutiny. Who's exposed: Customers with undocumented service accounts, stale credentials, unclear owners, or brittle integrations face the greatest migration risk. If no one can say what an account supports, disabling it may break a workflow—or reveal that the account should have been retired earlier.