Snowflake Is Deprecating Password-Only Sign-ins: Here’s What You Need to Know

Snowflake is taking a firm stand on security. By November 2025, all non-multi-factor authentication (MFA) using passwords alone will be blocked.

This change follows Snowflake’s Secure by Design pledge with CISA and builds on previous steps like making MFA (Multi-Factor Authentication) the default for new accounts since October 2024. Now, they’re taking it further by rolling out a phased deprecation of password-only sign-ins across all user types.

Here’s what’s changing — and what you should do about it.

What’s Changing

Snowflake has introduced a new user-level attribute called TYPE, which helps define whether a user is a human (interactive) or a service account (programmatic). This field is now central to how authentication policies are applied, and incorrect classification can lead to blocked access or unintentional policy enforcement.

Here’s what each value means:

• PERSON: A human user who logs in interactively (e.g., via Snowsight or CLI). These users will be required to use MFA.

• SERVICE: A machine or service account used for programmatic access (e.g., dbt Cloud, scheduled jobs). These users must authenticate using OAuth or key-pairs — passwords and SSO are not allowed.

• LEGACY_SERVICE: Temporary support for legacy apps that still require passwords. This type is exempt from MFA for now but will be deprecated in November 2025.

By default, existing users will have TYPE = NULL, which Snowflake treats as PERSON when applying MFA policies. So, unless explicitly updated, many users may unexpectedly fall under stricter enforcement.

Snowflake is rolling out stronger authentication in three phases:

• May 2025: MFA will be enforced for human users accessing Snowsight with a password.

• August 2025: MFA will be mandatory for all new human users using passwords, even if you’ve set custom authentication policies.

• November 2025: Password-only sign-ins will be fully blocked. No new LEGACY_SERVICE users (used for legacy app access) will be allowed.

Importantly:

• SSO (SAML, OAuth) and key-pair users are not affected.

• Service users (TYPE = SERVICE) will be exempt from MFA policies but cannot use passwords.

• LEGACY_SERVICE users are temporary exceptions and will be phased out by November 2025.

What You Should Do

Snowflake recommends  a four-phase approach for secure migration, and we’ve highlighted the tasks to take note of in each step:

1. Detect Risky Users and Credentials:

Start by using Snowflake’s Trust Center or the Threat Intelligence Scanner to identify users at risk — specifically, human users still logging in with only a password and service users labeled as LEGACY_SERVICE who rely on password-based access. To get a clearer picture, supplement this with queries from the LOGIN_HISTORY table to analyze how each user is authenticating (e.g., PASSWORD, SAML, or OAuth). Then, ensure all users are correctly classified using the TYPE attribute: PERSON for interactive logins, SERVICE for programmatic access, and LEGACY_SERVICE for legacy use cases.

✅ Tip: Even users primarily using SSO may be vulnerable if a password is still set and not protected by a second factor.

2. Plan a Secure Migration

Begin by setting user types correctly to align with Snowflake’s authentication model. Use PERSON for interactive users who require MFA, SERVICE for programmatic users who should authenticate via OAuth or key-pairs, and LEGACY_SERVICE only as a short-term workaround for legacy systems — this type will be deprecated in November 2025. Once user types are defined, match each user’s access method with a strong authentication option: internal staff and analysts should use SAML or SSO, while applications and scripts should connect via OAuth. For legacy tools that don’t yet support modern authentication, consider transitioning them to Programmatic Access Tokens (PATs) or using key-pairs, combined with network restrictions to limit risk.

⚠️ Caution: LEGACY_SERVICE users are meant strictly for migration and should not be part of your long-term strategy.

3. Protect with Strong Policies

• Establish strong authentication policies tailored to each user type. Enforce MFA for all PERSON users to ensure secure interactive access, and restrict SERVICE users to OAuth or key-pair methods only. For emergency access scenarios, implement fallback or "break-glass" authentication policies that leverage Snowflake-native MFA.

• In addition, define robust password and session policies by setting strict standards, such as a minimum 32-character password length, mandatory 2FA enrollment, and timeouts for idle sessions, to reduce exposure.

• Network policies are equally critical. Limit access by user type and application, starting with user-level policies for granular control. Then, apply account-level policies to cover broader defaults across users without specific configurations. Also, proactively remove any unused Snowflake-native passwords for users who already authenticate through SSO (SAML or OAuth), as these stored credentials create unnecessary security risk.

4. Continuously Monitor and Improve

To maintain a strong security posture, schedule regular scans in the Snowflake Trust Center to detect new risks such as leaked credentials or users bypassing MFA. Complement these with native alerts that notify you when risky activity occurs, such as the creation of new users with insecure settings, continued use of legacy authentication methods, or service users operating without network restrictions.

🔁 Security is an ongoing process, not a one-time fix. Continue to audit user activity, rotate credentials regularly, and refine policies as your environment evolves.

How We Can Help

At Database Tycoon, we’ve got you covered. Transitioning away from password-only authentication in Snowflake isn’t just a checkbox — it’s a foundational shift in how your organization approaches security.

At Database Tycoon, we help data teams:

• Audit user and service access across Snowflake

• Implement SAML, OAuth, and key-pair auth with minimal disruption

• Set up and enforce MFA, session, and network policies

• De-risk legacy service users and automate PAT/token rollouts

• Monitor access posture using Trust Center insights

Whether you need a quick consult, a custom migration plan, or hands-on implementation, we’re here to help you get compliant, secure, and future-proof.