Snowflake Enabling MFA by Default on New Accounts Starting October 2024 - What do you need to do?

Streamlit and Snowflake
1

This article is a cross-post from the Snowflake forums. Check it out here for further discussion/questions. :snowflake:

As part of furthering our commitment to protect against cybersecurity threats and to champion the advancement of industry standards for security, we recently announced that Snowflake signed the Cybersecurity and Infrastructure Security Agency (CISA) Secure By Design Pledge, and inline with that, announced a number of security enhancements in the platform — most notably the general availability of Trust Center and a new multi-factor authentication (MFA) policy. As part of our continuing efforts, we are beginning to enforce MFA for all human users in any new Snowflake account starting in October 2024. Service users — accounts designed for service-to-service communication — will not be subject to this MFA requirement. Please see the Timeline and Implementation section below for details on how this will be enforced.

What you need to know:

This new MFA policy only applies to Snowflake users with the TYPE=PERSON or NULL (i.e., human users) that use a Snowflake built-in password to login. Please see the documentation for more information on user types and see the Timeline and Implementation below for additional details on how these policies will be applied.

Timeline and Implementation

The rollout for these changes will follow the standard protocol in Snowflake’s Behavior Change Policy (BCR). Below is a summary of how this change will be enforced over the lifecycle of BCR bundle 2024_08:

  1. Opt-in Period (Oct-Early Jan): During this period, in order for new Snowflake accounts to have the new built-in authentication policy, you must enable the BCR bundle. This policy will not apply to any new Snowflake account created before you enable the bundle.
  2. Enabled by default (Early Jan to Early Feb): All new Snowflake accounts will have the new built-in authentication policy by default unless your Snowflake Account Admin explicitly opts out of BCR 2024_08.
  3. Generally Enabled - built-in policy enforced (Early Feb): All new Snowflake accounts will have the new built-in authentication policy. Your Snowflake Account Admin will not be able to opt-out. Your Snowflake Account Admin can override the new built-in authentication by creating a custom authentication policy and assigning it to the account.
  4. MFA policy for existing users: Over the next few quarters, Snowflake is looking to extend this new built-in authentication policy to all existing accounts.

Exemptions

Reader accounts and trial accounts are exempted. However, if your account converts from a trial account to a paid account, the new account will have a new built-in authentication policy that requires multi-factor authentication (MFA) for password logins for human users. This behavior is NOT controlled by the BCR bundle and the only way to override it is to define a custom authentication policy for your account and setting MFA_ENROLLMENT to OPTIONAL.

What you need to do

We recommend that you start familiarize yourself with whitepaper and this companion migration guide video then depending on how you interact with Snowflake:

  1. If you are building applications that connect to Snowflake (e.g., managed apps, connected apps, native apps, Snowpark Container Services, streamlit), we recommend moving away from using passwords to connect to Snowflake and instead, leveraging strong authentication in your application, by default. Depending on the user type, the recommended strong authentication is as follows:
  2. For human user type:
  3. For SSO users, Multi-Factor Authentication (MFA) on the 3rd party IDP side should be used (preferred)
  4. For Snowflake local users, Snowflake MFA should be used
  5. For service user type:
  6. External OAuth (preferred)
  7. Or key pair combined with network policy should be used
  8. If you manage Snowflake accounts, we recommend following the steps in this whitepaper and this companion migration guide video . More specifically:
  9. When creating new accounts programmatically, use the newly introduced ADMIN_USER_TYPE property for the admin as part of account creation

CREATE ACCOUNT [ ADMIN_USER_TYPE = PERSON | SERVICE | LEGACY_SERVICE | NULL ]

  1. For human users, set ADMIN_USER_TYPE=PERSON. PERSON users will be subject to MFA policies.
  2. For service users, set ADMIN_USER_TYPE=SERVICE. SERVICE users will not be subject to MFA policies.
  3. Service users will not be allowed to use passwords by policy and the caller should specify ADMIN_RSA_PUBLIC_KEY instead of admin password as part of account creation.
  4. If your service users cannot use key pair authentication, set ADMIN_USER_TYPE=LEGACY_SERVICE during account creation and continue setting up passwords. LEGACY_SERVICE users will not be subject to MFA policies.
  5. LEGACY_SERVICE users are not allowed to log in via UI and cannot have a first name / last name. See this link for more details.
  6. LEGACY_SERVICE is a temporary solution and we highly recommend that you fix your tooling.
  7. Read more about user types and their limitations in the create user documentation.
  8. For users created after a new account is bootstrapped,
  9. Make sure to mark the TYPE for all users
  10. For human users TYPE=PERSON, follow the DUO enrollment process and start using MFA
  11. For service users TYPE=SERVICE, make sure to either: 1) use external OAuth (preferred), or 2) use key pair authentication combined with network policy.
  12. If a service user cannot leverage a key pair, mark them as TYPE= LEGACY_SERVICE. This is a temporary solution and we highly recommend that you fix your deployment based on the above.

NOTE: we recommend that you leverage SCIM to automatically provision the user types as outlined in this KB article .

Need help?

For frequently asked questions, please see this KB article .