Skip to main content
Snowflake is phasing out password sign-ins for non-human users. New service users must be created with TYPE = SERVICE, which cannot have a password, and between August and October 2026 Snowflake blocks password authentication for all existing service users. The exact date for your account is shown in Snowsight under Governance & Security → Trust Center → Strong Authentication Hub. After that date a Datafold connection that still signs in with a password stops working. This page shows how to move an existing connection to key-pair authentication without downtime. For a new connection, follow Snowflake, which already creates a compliant user. The user Datafold connects with is compliant when all three hold:
  1. TYPE = SERVICE. A user without a type is treated as a person and is subject to MFA, which Datafold cannot complete.
  2. No password.
  3. An RSA public key registered, with Datafold holding the matching private key. Datafold generates the key pair and keeps the private key encrypted; you only register the public key in Snowflake.

​
Check the current state

Run this in Snowsight, replacing DATAFOLD with the username configured on the Datafold connection:

​
Migrate an existing connection

The order below never breaks the connection: the key is registered while the password still works, Datafold is switched over and tested, and only then is the password removed.
1

Generate the key pair in Datafold

Go to Settings → Data Connections and open the Snowflake connection. Under Authentication method, select Key pair, then click Generate and Download next to Key pair file. Leave the form open and do not save yet.Snowflake expects the key from datafold.pub without the BEGIN/END lines and without line breaks:
2

Register the public key in Snowflake

As SECURITYADMIN, ACCOUNTADMIN, or the role that owns the user:
Password sign-in still works at this point.
3

Switch Datafold to the key

Back in the Datafold form, click Test connection. When it succeeds, click Save. Datafold now authenticates with the key and drops the stored password. If the test fails, see Troubleshooting; nothing changes for the running connection until you save.
4

Remove the password and make it a service user

The same statements apply to a LEGACY_SERVICE user. Re-run the query from Check the current state; expect SERVICE, false, true.
Repeat for every Datafold connection that still uses a password. Each connection has its own key pair, and a Snowflake user holds at most two public keys, so give each connection its own Snowflake user (for example DATAFOLD_PROD and DATAFOLD_STAGING) with DATAFOLDROLE granted.

​
Rotate the key

Use the second key slot so the old key keeps working until the new one is confirmed:
  1. In the Datafold connection, click Regenerate, then Download. Do not save yet.
  2. In Snowflake: ALTER USER DATAFOLD SET RSA_PUBLIC_KEY_2 = '<new_public_key>';
  3. In Datafold, click Test connection, then Save.
  4. In Snowflake: ALTER USER DATAFOLD UNSET RSA_PUBLIC_KEY;
The next rotation goes the other way: set RSA_PUBLIC_KEY, then unset RSA_PUBLIC_KEY_2.

​
Troubleshooting

  • 390144 (28000): … JWT token is invalid — the key on the Snowflake user is not the one Datafold holds. Usually Regenerate was clicked after the key was registered, the form was closed before saving, or the BEGIN/END lines were pasted into the SQL. Download the public key again and re-run ALTER USER … SET RSA_PUBLIC_KEY. Also check that the Username and Account identifier (<orgname>-<accountname>) match.
  • The connection fails mentioning multi-factor authentication or that a password is not allowed — Snowflake no longer accepts a password for this user. Complete the migration above.
  • ALTER USER fails with insufficient privileges — run the statements as SECURITYADMIN, ACCOUNTADMIN, or the role that owns the user.
  • Key-pair login is rejected although the key matches — an authentication policy on the account or user may not include KEYPAIR in its AUTHENTICATION_METHODS.