[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$flxSdX6SgwuJoilh9R8RAUERhlVbNfvIH6uDNWMn4pyw":3},{"article":4,"iocs":50},{"id":5,"title":6,"slug":7,"summary":8,"ai_summary":9,"brief":10,"full_text":11,"url":12,"image_url":13,"published_at":14,"ingested_at":15,"relevance_score":16,"entities":17,"category_id":27,"category":28,"article_tags":32},"a824484c-fdc1-4803-8f96-8b3e14e9026a","Snowflake ends service-account passwords. Now comes the hard part","snowflake-ends-service-account-passwords-now-comes-the-hard-part-64bb7d","Snowflake is ending password authentication for legacy service accounts, forcing organizations to migrate them to passwordless methods. Token Security explains why the harder challenge is identifying what uses each account, who owns it, and how much access it still needs. [...]","Snowflake is phasing out password authentication for legacy service accounts, pushing customers to adopt passwordless methods. This move, prompted by past breaches like the one involving Connor Moucka, highlights the challenge of managing non-human identities. The real difficulty lies not in implementing new authentication, but in identifying account usage, ownership, and necessary access levels.","Snowflake mandates passwordless authentication for legacy service accounts, shifting focus to identity management.","Snowflake ends service-account passwords. Now comes the hard part Sponsored by Token Security August 26, 2026 10:01 AM 0 Written by: Ido Shlomo, Co-founder and CTO, Token Security Connor Moucka did not exploit a vulnerability in Snowflake. He and his co-conspirators used valid customer credentials, many of them years old, to log in, reaching more than 165 Snowflake customer organizations. They stole billions of records, including the call and text records of nearly all of AT&T’s wireless customers. Moucka pleaded guilty on August 5 to computer fraud, wire fraud, aggravated identity theft, and conspiracy. The campaign exposed a familiar identity failure: credentials remained valid long after their exposure, the affected accounts lacked a second factor, and network restrictions were often absent. Snowflake is now forcing customers to confront that identity debt by focusing on non-human identities. During Phase 3 of its authentication rollout, Snowflake is migrating legacy service users to the SERVICE type, which will block password-based authentication. Replacing those passwords is the mechanical part. Discovering what uses each account has, assigning an owner, and deciding how much access it still needs is the real challenge. The accounts that still have a password Soon, every service account will be blocked from authenticating with a password. The LEGACY_SERVICE user type is being fully deprecated, and existing legacy accounts are being migrated to SERVICE, which cannot store a password. Snowflake runs the deprecation in three phases, and the first two have already closed most of the doors: September 2025–January 2026: Human users had to present a second factor in Snowsight. Service users were untouched. May 2026–July 2026: Every newly created nonhuman user had to be of type SERVICE, which cannot use a password. August 2026–October 2026: Legacy service accounts in covered Snowflake accounts must migrate off password authentication before their accountspecific Phase 3 enforcement date. The remaining accounts are the oldest. They have had more time for credentials to leak and go unrotated, for owners to change teams, and for dependencies to lose their documentation. Don't let chaotic agents ruin your day Identity is the key to securing agents from the get-go. Token Security discovers every agent, maps risky access, and automatically enforces intent-based policies. Scale AI safely without losing control or slowing down innovation, starting with identity. See for yourself Step 1: Build the inventory now, not in October Three questions have to be answered for every service account on the platform: Which ones authenticate to Snowflake? Who owns each one? What breaks when the password stops working? Snowflake answers the first question itself. The ACCOUNT_USAGE schema stores the user list for each account's type, and the login history records the client and source IP for each authentication attempt for 365 days. Together, they give you the set of accounts that are still signed in with a password, when each last did so, and from where. The second and third questions are more complicated. Snowflake can’t tell you who asked for a service account, which system depends on it, or who to call when it stops working. That information lives in the memory of whoever set it up, in a 2022 ticket, or (likely) nowhere. An inventory assembled in October, because a deadline forced it, is not governance. It captures a single moment and starts decaying the next time someone provisions an account. Step 2: Attach a named owner to each account The owner record is what keeps the next service account from going unexamined for years. Ownership can't be just a line in a spreadsheet, though. Who accepts the alert when that account's authentication fails at 2 a.m.? If the answer is \"no one\", the account has no owner, and the question is no longer how to migrate it but whether it should exist. Ownership means responsibility for deprovisioning as much as for uptime. Where ownership remains unclear, use a controlled disable window before deletion. Monitor for failures, restore the account if necessary, and decommission it only after validating its dependencies. Step 3: Choose a method per account, not one for the estate Snowflake gives SERVICE users four ways to authenticate without a password, each with different operating costs. Method What it costs Workload identity federation Snowflake's recommended option. Secretless, so there is nothing to store or rotate. Requires the workload to run somewhere that can present a federatable identity. External OAuth Strong, and requires the expertise to configure a third-party IdP as the authorization server. Key-pair authentication Passwordless at the request, but still a long-lived secret, and the one method with no guardrails attached. Snowflake recommends network policies and a rotation strategy but doesn't require either, and there's no forced expiry the way there is on tokens. Programmatic access tokens The most direct password replacement. For SERVICE users, Snowflake requires a network policy and role restriction by default, although authentication policies can relax both. Rotation does not recheck those prerequisites at rotation time, so teams should validate the network policy, role grant, expiration, and owner during every rotation. Don't try to limit yourself to one method. Federation is the right default where the workload runs on a platform that can present an identity to Snowflake. Key-pair, or a role-scoped token, is the fallback when it cannot be used, with the network policy and the rotation schedule committed in the same change rather than filed as follow-up work. A long-lived secret migrated without either one will pass the Phase 3 deadline without objection, but it's the same control failure in a new format. Step 4: Treat the replaced password as burned Assume the credential you are replacing is already sitting in an infostealer log. Mandiant and Snowflake found that at least 79.7% of the accounts used in the UNC5537 campaign had prior credential exposure. The earliest infostealer infection tied to one of those credentials dated to November 2020, which means that password was still working roughly three and a half years after it was stolen. Cutover invalidates the password in Snowflake, but it does not remove copied or reused credentials from secrets stores, CI variables, runbooks, or endpoints. Search for reuse, revoke any dependent credentials, and reduce the account’s role scope during the same change. AI agents compress the same identity lifecycle problem Snowflake’s deadline is a preview of the governance problem AI agents will make much larger. Snowflake already recognizes automated AI agents as a distinct SERVICE_AGENT identity type. The label is new, but the control questions are familiar: Who owns the agent? Which identity does it use? What can it access? When should that access end? Book a technical demo to see how Token Security can identify ownerless identities, map hidden dependencies, and establish lifecycle controls before the next platform cutoff forces the issue. Sponsored and written by Token Security.","https:\u002F\u002Fwww.bleepingcomputer.com\u002Fnews\u002Fsecurity\u002Fsnowflake-ends-service-account-passwords-now-comes-the-hard-part\u002F","https:\u002F\u002Fwww.bleepstatic.com\u002Fcontent\u002Fposts\u002F2026\u002F08\u002F25\u002Ftoken-key-rack.jpg","2026-08-26T14:01:11+00:00","2026-08-26T16:00:25.307046+00:00",7,[18,21,24],{"name":19,"type":20},"Snowflake","product",{"name":22,"type":23},"Connor Moucka","threat_actor",{"name":25,"type":26},"Token Security","vendor","2c8f44d4-b56e-47cf-9677-04f22c9ee78d",{"id":27,"icon":29,"name":30,"slug":31},null,"Identity & Access","identity-access",[33,35,40,45],{"category":34},{"id":27,"icon":29,"name":30,"slug":31},{"category":36},{"id":37,"icon":29,"name":38,"slug":39},"2e06f76c-d5b9-4f54-9eef-4d3447b10730","Breaches","breaches",{"category":41},{"id":42,"icon":29,"name":43,"slug":44},"c5c77cdb-f7d7-4990-9436-c81dcbff1163","Policy","policy",{"category":46},{"id":47,"icon":29,"name":48,"slug":49},"e7b231c8-5f79-4465-8d38-1ef13aea5a14","Threat Intelligence","threat-intelligence",[]]