Planning for the deprecation of single-factor password sign-ins¶

To improve the security posture of all of its customers, Snowflake is rolling out changes to require multi-factor authentication (MFA) for all human users using passwords, and disallow passwords for all service users. These changes will be rolled out across multiple behavior change releases (BCRs). This topic describes how single-factor password sign-ins will be deprecated so you can plan accordingly.

Note

The deprecation process described in this topic does not apply to reader accounts, Open Catalog accounts, and trial accounts. You can continue to sign in to these types of accounts with a single-factor password.

Understanding the rollout process¶

The rollout of the deprecation of single-factor password sign-ins is broken down into multiple milestones.

Each milestone is implemented using Snowflake’s established behavior change release process. In this process, Snowflake releases a behavior change bundle each month. Because changes will be included in a behavior change bundle, enforcement of the new restrictions will coincide with the lifecycle of the bundle.

For more information about the lifecycle of behavior change bundles so you can plan for the enforcement of each milestone, see Behavior change policy.

Human users vs. service users¶

User objects in Snowflake don’t always correspond to human users. There are users who sign in to Snowflake without human interaction — for example, an application or service. These users are considered service users.

Administrators use the TYPE parameter of a user object to define whether a user is a human user or a service user.

For human users, TYPE=PERSON. If you don’t set the TYPE parameter or set it to NULL, the user is treated as a human user.
For service users, TYPE=SERVICE.

Note

The LEGACY_SERVICE user type helps customers transition service users to using a secure form of authentication. Setting a user’s type to LEGACY_SERVICE temporarily allows the user to authenticate with a password even though it’s an application or service. The rollout described in this topic involves the gradual deprecation of this user type.

The distinction between a human user and a service user is important because this rollout affects these two types of users differently. To harden the security posture for both types of users, the deprecation of single-factor password sign-ins consists of the following:

All human users who use password authentication will be required to use a second factor of authentication. For a timeline that describes how Snowflake will meet this goal, see Milestones for human users.
All service users who currently use password authentication will be required to migrate to a more secure authentication method. For a timeline that describes how Snowflake will meet this goal, see Milestones for service users.

Deprecation timeline¶

The following table provides the timeline for the deprecation of single-factor password sign ins.

Estimated date	Affected users	Milestone
May 2025 - Jul. 2025	Human users	Mandatory MFA for all Snowsight users
Aug. 2025 - Oct. 2025	Human users	Mandatory MFA for all new human users
Nov. 2025 - Jan. 2026	Service users	No new legacy service users
Mar. 2026 - May 2026	Human users	Mandatory MFA for all human users
Jun. 2026 - Aug. 2026	Service users	No legacy service users

Milestones for human users¶

Goal: All human users who authenticate with passwords must use a second factor of authentication.

The rollout to meet this goal consists of the following milestones. Each milestone begins with the release of a behavior change bundle (that is, the testing period begins) and ends when the bundle becomes generally enabled. Restrictions associated with the milestone are enforced as soon as the bundle is enabled.

2025_04 bundle (May 2025 - July 2025) [1] : Mandatory MFA for all Snowsight users (new and existing)

Human users must authenticate with a second factor when using a password to access Snowsight, with no exceptions.

Keep in mind the following:

This milestone affects Snowsight only. Human users can continue to use a single-factor password to access the Snowflake service from business intelligence (BI) and similar tools, even after they use Snowsight to enroll in MFA. You can choose to enforce MFA for these other tools; users who are already enrolled in MFA and use MFA outside Snowsight will continue to use MFA.
Authentication policies that implemented optional MFA enrollment for Snowsight are overridden.
Because users authenticating with Snowflake OAuth use the Snowsight login interface, they must be enrolled in MFA.
Single sign-on users are not impacted by this change and can continue to access Snowsight with no changes.
Legacy service users (TYPE=LEGACY_SERVICE) are not impacted by this change and can continue to access Snowsight with a single-factor password.

2025_07 bundle (August 2025 - October 2025) [1] : Mandatory MFA for all new human users

All human users that are created after the behavior change bundle is enabled must authenticate with a second factor, including those using BI tools or similar.

Human users who existed before the bundle was enabled are not affected. These password users can continue to use BI tools or similar (anything but Snowsight) without a second factor of authentication until March 2026.

For example, suppose your administrator opts into the behavior change bundle associated with this milestone on September 10, 2025. All human users created on or after this date must use a second factor of authentication regardless of the surface. Human users who existed before this date can continue to use password-only authentication for BI tools, but not Snowsight.

Bundle to be announced (March 2026 - May 2026) [1] : Mandatory MFA for all human users (no exceptions): When the behavior change bundle associated with this milestone is enabled, all new and existing human users must use a second factor when authenticating with a password, with no exceptions.

Milestones for service users¶

Goal: All service users must use a secure form of authentication.

The rollout to meet this goal consists of the following milestones. Each milestone begins with the release of a behavior change bundle and ends when the bundle becomes generally enabled. Restrictions associated with the milestone are enforced as soon as the bundle is enabled.

Users with TYPE=SERVICE cannot use password authentication, with no exceptions. To temporarily allow services and applications to authenticate with a password, Snowflake provided the LEGACY_SERVICE user type. The migration away from single-factor password sign-ins focuses on the gradual deprecation of this LEGACY_SERVICE user type, so all non-human users must be of type SERVICE.

Bundle to be announced (November 2025 - January 2026) [2] : No new legacy service users

All non-human users created after the behavior change bundle is enabled must be of type SERVICE, which prevents them from using a password. The LEGACY_SERVICE type is no longer available when creating a new user object. In addition, administrators cannot change the type of an existing user to LEGACY_SERVICE.

For example, suppose your administrator opts into the behavior change bundle associated with this milestone on December 10, 2025. After this date, TYPE=LEGACY_SERVICE is an invalid option when executing a CREATE USER or ALTER USER command.

Bundle to be announced (June 2026 - August 2026) [2] : No legacy service users

When the behavior change bundle associated with this milestone is enabled, all non-human users are blocked from using a password to authenticate.

The LEGACY_SERVICE user type is fully deprecated. All existing user objects with TYPE=LEGACY_SERVICE are migrated to TYPE=SERVICE, which prevents them from using a password.

Requiring MFA ahead of schedule¶

Given the improved security associated with preventing single-factor password sign-ins, you might decide to implement it ahead of the timelines provided in this topic. This section describes how to enforce restrictions without waiting for the rollout to complete.

The rollout of mandatory MFA differentiates between Snowsight and other surfaces, and between new and existing users. You can use a custom authentication policy to immediately enforce MFA for all human users across all client types without waiting for the rollout process to complete.

You’ll want to carefully define all parameters of the new authentication policy, but at a minimum it should contain the following parameters to meet the goal of preventing single-factor password sign-ins:

CREATE AUTHENTICATION POLICY require_mfa_policy
  MFA_AUTHENTICATION_METHODS = ('PASSWORD')
  MFA_ENROLLMENT = REQUIRED;

Copy

For more information about these parameters, see CREATE AUTHENTICATION POLICY.

To set the authentication policy for the account so it governs the authentication of all human users, execute the following statements:

USE ROLE ACCOUNTADMIN;
ALTER ACCOUNT SET AUTHENTICATION POLICY require_mfa_policy;

Copy

Enrolling in multi-factor authentication¶

For information about how users enroll in MFA, see Enroll in multi-factor authentication (MFA).