Action Required: Snowflake Blocks All Password Authentication — Keboola Rollout Starts 7 September 2026

Snowflake is completing its move away from single-factor password authentication. In Phase 3: Strong authentication for all users, Snowflake blocks all service users from authenticating with a password and fully deprecates the LEGACY_SERVICE user type, migrating existing users to TYPE=SERVICE.

Service users cannot use MFA. There is no second factor to add, no exception to request, and no setting on Keboola's side that can keep password authentication working. Password access does not get harder — it stops.

This is about your older workspaces

Since 2 April 2026 it has not been possible to create a Snowflake workspace with password authentication — neither in the UI nor via the API. Every workspace created since then already uses key-pair. So this announcement is about workspaces created before April 2026 that are still on password authentication, plus component configurations that were never migrated.

If all your workspaces and configurations already use key-pair, no action is needed.

Who is affected

BYODB and KBDB projects with password-based workspaces. Until now, your projects were the exception. Multi-tenant and Pay-As-You-Go projects lost direct workspace access in January 2026, but projects on a dedicated Snowflake account kept working, including those older password-based workspaces. That exception ends with Phase 3, because it is enforced by Snowflake, not by Keboola.

Those workspaces will stop accepting connections, including from third-party tools such as DBeaver, DataGrip, Snowsight and BI tools.

Any project with component configurations using Snowflake password credentials. This is not limited to BYODB and KBDB. Any Snowflake extractor, writer, transformation or dbt configuration that authenticates with a username and password will stop working once Phase 3 reaches the account it connects to.

Users provisioned through Snowflake DWH Manager. These are neither workspace users nor component credentials, which makes them easy to overlook — and by default DWH Manager creates them as LEGACY_SERVICE, exactly the type Snowflake is deprecating. Anything logging in as one of those users with a username and password is in scope.

When this happens

Enforcement dates for Snowflake accounts operated by Keboola:

Note on September. Snowflake's Phase 3 window runs from August to October 2026, and we originally communicated August. We scheduled enforcement on Keboola-operated accounts for September so that it does not fall in the middle of the summer holiday period, when many teams are away and would not be able to migrate or reach us if something broke. The dates above are final for Keboola-operated accounts.

If you are on BYODB, the enforcement date belongs to your own Snowflake account, not to Keboola. Check the Trust Center in Snowsight for your account's exact rollout date. Snowflake also notifies each account directly with its enforcement date. Do not assume the Keboola dates above apply to you — your account may be enforced earlier.

Important for component configurations. The dates above apply only to Snowflake accounts operated by Keboola. If a configuration connects to a different Snowflake account — your own, a customer's, or a partner's — enforcement follows that account's own schedule, not ours. Snowflake's Phase 3 rollout window is August to October 2026, so such an account may be enforced earlier or later than the dates above. Check each account's Trust Center in Snowsight, and do not use our dates as your planning baseline for external accounts.

Check your configurations for workspace combinations

Most of this we are managing on our side, and for the majority of projects nothing will change. There is one case worth checking yourself.

A configuration that uses a password-based workspace as part of its setup — for example a Snowflake Writer writing into a Keboola-provided workspace with password credentials — is a valid, supported setup today. It is also exactly the combination that stops working at Phase 3.

This is easy to miss on multi-tenant and Pay-As-You-Go projects. Direct human access to those workspaces ended in January 2026, but the platform still connects to those workspace users internally. A password-based workspace can therefore be working for you right now, driving a production flow, without anyone ever logging into it directly.

Please review your Snowflake configurations for any dependency on a password-based workspace and migrate it to key-pair. We will be watching the rollout and handling what is ours to handle, but we cannot rule out that an edge case slips through — and a dependency we cannot see from the outside is one we cannot migrate for you.

Snowflake DWH Manager users

Go through the users your DWH Manager configuration provisions. For each one you have two options, depending on who or what uses the account:

• Key-pair — for anything automated. Set a public key on the user, either with Generate New Key Pair or by supplying your own. This enables key-pair authentication without MFA. Once a public key is in place you can also tick Skip password, so no password is set for that user at all, which additionally stops Snowflake from reporting an expired password.
• PERSON type with MFA — for human users. Use Migrate user to PERSON to change the user type from LEGACY_SERVICE to PERSON, then set up MFA for that user as soon as possible. This migration is one-way and cannot be reversed.

What disappears in Phase 3 is password login without MFA. That is the problem for unattended connections — ODBC, JDBC and BI tools that authenticate with a username and password and cannot answer an MFA prompt. Those need key-pair, not a PERSON migration.

What you need to do

• Workspaces: Open the workspace detail and use Migrate to Key Pair authentication. Your workspace content is preserved. The migration is permanent and cannot be undone. Workspaces still on password authentication are marked with an orange key icon in the workspaces list.
• Component configurations: Open the configuration's credentials, switch the authentication type to key-pair, paste your private key, then save and test. Affected configurations are listed in the warning on your project home page.

If you do nothing

Jobs will start failing — specifically, any job whose configuration authenticates to Snowflake with a password. Configurations already on key-pair are unaffected, so the failures will be scoped to what you have not migrated. Credentials for older password-based workspaces will stop working entirely.

Recovering afterwards means running the same migration anyway — under time pressure, with broken flows, and without the option to test first.

If you need help, submit a support ticket and our support team will walk you through the migration.