The **Snowflake** data breach, which saw billions of records stolen from over 165 customer organizations, including **AT&T** wireless customers, was not the result of a vulnerability exploit. Instead, attackers leveraged valid, often years-old customer credentials, highlighting a pervasive issue in identity and access management. **Connor Moucka** recently pleaded guilty to computer fraud, wire fraud, aggravated identity theft, and conspiracy, underscoring the severity of the incident. This campaign brought to light a familiar pattern of security failures: credentials remaining valid long after exposure, a lack of multi-factor authentication (MFA), and insufficient network restrictions. ### Snowflake's Proactive Stance on Non-Human Identities **Snowflake** is now compelling its customers to address this identity debt, particularly focusing on non-human identities. Through Phase 3 of its authentication rollout, **Snowflake** is migrating legacy service users to the `SERVICE` type, which will effectively block password-based authentication. While replacing passwords is a mechanical task, the true challenge lies in discovering the purpose of each account, assigning ownership, and determining its necessary access levels. ### The Accounts Still Relied on Passwords Soon, all service accounts will be barred from authenticating with a password. The `LEGACY_SERVICE` user type is being fully deprecated, with existing legacy accounts transitioning to the `SERVICE` type, which cannot store a password. **Snowflake**'s deprecation process unfolds in three phases: * **September 2025–January 2026:** Human users were required to present a second factor in Snowsight. Service users remained unaffected. * **May 2026–July 2026:** All newly created non-human users had to be of type `SERVICE`, precluding password usage. * **August 2026–October 2026:** Legacy service accounts in covered **Snowflake** accounts must migrate off password authentication before their specific Phase 3 enforcement date. The accounts remaining are typically the oldest, having had ample time for credentials to leak, go unrotated, owners to change teams, and dependencies to lose documentation. ### Step 1: Build a Comprehensive Inventory Now Before the October deadline, organizations must answer three critical questions for every service account: * Which accounts authenticate to **Snowflake**? * Who owns each account? * What breaks when the password ceases to function? **Snowflake**'s `ACCOUNT_USAGE` schema provides a user list by type, and login history records authentication attempts for 365 days. This data reveals which accounts still use passwords, their last login, and source IP. The more complex task involves identifying owners, system dependencies, and points of contact. This information often resides in tribal knowledge, old tickets, or, more commonly, nowhere. An inventory hastily assembled under duress is not true governance; it's a snapshot that begins to decay the moment a new account is provisioned. ### Step 2: Assign a Named Owner to Each Account Clear ownership is paramount to prevent service accounts from becoming unexamined liabilities. Ownership implies responsibility, not just for uptime, but for deprovisioning. If no one is alerted when an account's authentication fails at 2 a.m., that account effectively has no owner, raising questions about its very existence. For accounts with unclear ownership, implement a controlled disable window before deletion. Monitor for failures, restore if necessary, and decommission only after validating all dependencies. ### Step 3: Choose Authentication Methods Strategically **Snowflake** offers `SERVICE` users four passwordless authentication methods, each with varying operational costs: | Method | What it costs It is crucial not to limit migration to a single method. Federation is the ideal default when a workload can present an `identity` to **Snowflake**. Key-pair authentication or a role-scoped token serves as a robust fallback when federation is not feasible, with network policies and rotation schedules committed simultaneously. ### Step 4: Treat Replaced Passwords as Compromised Assume that any credential being replaced has already been compromised. Reports from **Mandiant** and **Snowflake** revealed that at least 79.7% of accounts involved in the **UNC5537** campaign had prior credential exposure. Some passwords had been working for over three and a half years after their initial theft. While cutover invalidates the password in **Snowflake**, it doesn't remove copied or reused credentials from secrets stores, CI variables, runbooks, or endpoints. Organizations must search for reuse, revoke dependent credentials, and reduce the account's role scope concurrently. ### AI Agents: Compressing the Identity Lifecycle Problem **Snowflake**'s deadline offers a glimpse into a larger governance challenge posed by AI agents. **Snowflake** already recognizes automated AI agents as a distinct `SERVICE_AGENT` identity type. While the label is new, the fundamental control questions remain: Who owns the agent? Which identity does it use? What can it access? When should that access end? Addressing these questions proactively is essential to establish lifecycle controls before the next platform cutoff forces the issue. This proactive approach is critical for scaling AI safely without compromising control or hindering innovation, starting with robust identity management.