As reported by BleepingComputer, Snowflake is entering the final and most difficult phase of its authentication overhaul: forcing legacy service accounts off password-based authentication entirely. The move is a direct response to the 2024 campaign led by Connor Moucka, who compromised over 165 Snowflake customer environments not by exploiting a technical vulnerability, but by using valid, stale service-account credentials — many lacking MFA and network restrictions. The breach underscored a systemic blind spot that persists across the industry: non-human identities are poorly governed, rarely rotated, and frequently orphaned.

Cloud Security Alert: The move is a direct response to the 2024 campaign led by Connor Moucka, who compromised over 165 Snowflake customer environments not by exploiting a technical vulnerability, but by using valid, stale service-account credentials — many lacking MFA and network restrictions.

Why This Matters Beyond Snowflake

Snowflake's enforcement is notable, but the underlying problem is industry-wide. Service accounts, API keys, and machine credentials have accumulated across enterprise environments for years with minimal oversight. They connect ETL pipelines, BI tools, automation platforms, and increasingly, AI agents. The Moucka campaign demonstrated that a single exposed credential — sometimes years old — could unlock billions of records. Snowflake is effectively forcing customers to confront identity debt that should have been addressed proactively.

The remaining password-based accounts are the oldest ones. They have had the most time for credentials to leak, for owners to leave, and for documentation to rot. These are precisely the accounts most likely to be exploited.

The Migration Timeline

Snowflake's rollout spans three phases, with the final window open between August and October 2026:

Why This Matters Beyond Snowflake
Phase 1 (Sep 2025–Jan 2026): MFA required for human users in Snowsight. Service accounts untouched.
Phase 2 (May 2026–Jul 2026): All newly created non-human users must use SERVICE type, which cannot store passwords.
Phase 3 (Aug 2026–Oct 2026): Legacy service accounts must migrate to passwordless authentication (key pairs or OAuth) before account-specific enforcement dates.

Phase 3 is where the friction lives. These accounts are embedded in production pipelines, scheduled jobs, and third-party integrations. Removing password authentication without first mapping dependencies will cause breakages — and breakages create pressure to delay or bypass security controls.

The Real Challenge: Identity Inventory, Not Migration Mechanics

The technical migration to key-pair or OAuth-based authentication is well-documented by Snowflake. The harder problem is answering three questions for every service account:

  • What authenticates to Snowflake using this account? — ETL jobs, BI dashboards, scripts, third-party connectors, AI agents.
  • Who owns it? — Ownership has often transferred, been forgotten, or was never formally assigned.
  • What breaks when the password is removed? — Undocumented dependencies become visible only at failure time.

Snowflake's ACCOUNT_USAGE schema provides the user list, but it does not tell you which downstream systems depend on each credential. That mapping requires cross-referencing with CI/CD pipelines, secret managers, infrastructure-as-code repositories, and application configuration stores.

Shield53 Recommendations

Immediate Actions

  • Inventory now, not in October. Query SNOWFLAKE.ACCOUNT_USAGE.USERS and LOGIN_HISTORY to identify all service accounts still using password auth. Cross-reference last-login timestamps to identify active vs. dormant accounts.
  • Map dependencies before migrating. Search secret managers (Vault, AWS Secrets Manager, Azure Key Vault), code repositories, and CI/CD configurations for stored Snowflake credentials. Each match is a dependency that must be updated.
  • Assign ownership and document. Every service account must have a named owner, a business justification, and an access review cadence. Accounts without an owner should be disabled, not migrated.
  • Right-size permissions. Use this migration as a forcing function to apply least-privilege. Many legacy service accounts hold ACCOUNTADMIN or SYSADMIN roles they never needed. Downgrade before cutting over.
  • Migrate to key-pair authentication. Generate RSA key pairs, store private keys in a managed secret store, and configure the SERVICE account with the public key. Disable password auth only after confirming successful key-based login from all dependent systems.
  • Enable network policies. Restrict service-account access to known source IP ranges or allowlists. The Moucka campaign exploited accounts with no network restrictions — this control alone would have blocked most of the intrusions.
  • Set up monitoring. Alert on failed authentication attempts, password-based login attempts (which should be zero post-migration), and any access from unexpected IP ranges.

Broader Implications

Organizations should expect this pattern to repeat across SaaS platforms. The era of password-based non-human authentication is ending, driven by breach fallout and regulatory pressure. Teams that build a repeatable identity-inventory and migration process now will be positioned to handle the next platform's enforcement without crisis-driven shortcuts. Those that wait will face the same choice Snowflake customers face today: migrate under pressure, or accept the risk of being the next breach headline.

For AI-agent deployments specifically, the stakes are higher. Agents that authenticate with static credentials inherit all the same risks as legacy service accounts — with the added complexity that agent workflows can change dynamically, making access patterns harder to predict. Non-human identity governance must become a first-class discipline, not an afterthought addressed only when a vendor forces the issue.