# Snowflake key-pair authentication: migrate Fivetran, Airbyte, dbt and BI connections

Canonical URL: https://www.martechdevs.com/blog/snowflake-key-pair-authentication

By [Jafrin Akter Alo](https://www.martechdevs.com/authors/jafrin-akter-alo)

Data Engineer and Co-founder, martechdevs

Published: 2026-09-22

Last updated: 2026-10-13

Snowflake key-pair authentication lets a service prove its identity with a private key while Snowflake stores the matching public key. It is a supported replacement for service-user passwords. Snowflake's strong-authentication rollout runs per account through August to October 2026, so check your account's enforcement notice, inventory unattended connections and test their replacement credentials before retiring the old method.

Timeline checked against Snowflake's current rollout documentation.

A connector can keep its configuration unchanged for months and then stop authenticating when an account policy changes. The resulting stale data reaches revenue dashboards, lifecycle audiences and AI answers before everyone notices the failed job.

## When does Snowflake block password authentication?

Snowflake's published final phase is an estimated August to October 2026 rollout with an account-specific notification. It requires a second factor for human password users and prevents non-human users from authenticating with passwords. Existing `LEGACY_SERVICE` users move to `SERVICE`. Reader accounts, trial accounts and Snowflake Postgres are outside the documented phases. [Snowflake's enforcement timeline](https://docs.snowflake.com/en/user-guide/security-mfa-rollout).

Use the notification for your account rather than assuming every customer shares one deadline. A vendor may also impose an earlier connector-specific change. Record both dates in the migration plan.

`PERSON` represents an interactive human; an unset or null user type is treated as a person. `SERVICE` represents a non-human workload. Relabelling an unattended job as a person creates the wrong operating model and does not solve the need for supported unattended authentication.

[Martechdevs' warehouse implementation work](https://www.martechdevs.com/data-warehouse-cdp) includes the connections and operating documentation around the warehouse. For the broader architecture, see [how to design a marketing data warehouse](https://www.martechdevs.com/blog/data-warehouse-design).

## What should you check first when a connection fails?

Establish whether the failure is authentication, authorisation, networking or job logic. Changing keys will not fix a missing table privilege, a blocked network route or an incompatible connector release.

Record the exact time, username, connector version and redacted error. Check whether the account's enforcement date has passed and whether the job still uses a password. Compare recent successful and failed runs without exposing credentials in screenshots or tickets.

Snowflake's [LOGIN_HISTORY view](https://docs.snowflake.com/en/sql-reference/account-usage/login_history) records authentication details and failure information. The following read-only query is a starting point for an authorised administrator; replace the example service-user name:

```sql
SELECT event_timestamp,
       user_name,
       reported_client_type,
       first_authentication_factor,
       is_success,
       error_code,
       error_message
FROM snowflake.account_usage.login_history
WHERE event_timestamp >= DATEADD('day', -7, CURRENT_TIMESTAMP())
  AND user_name = 'SVC_DBT_MARKETING'
ORDER BY event_timestamp DESC;
```

Account Usage is not an instantaneous log stream. Check connector-side evidence during a live cutover and return to the warehouse history when records are available. Restrict log access because operational metadata can itself be sensitive.

## How should you inventory service users?

List every unattended path, including jobs that run weekly or monthly. Fivetran and Airbyte destinations are obvious; scheduled BI refreshes, notebooks, CI jobs, reverse ETL, scripts and AI connections are easier to miss.

For each connection, record:

- Snowflake account, username and current authentication method.
- Runtime, connector or driver version and supported alternatives.
- Role, warehouse, database and schemas it actually needs.
- Secret location, technical owner and rotation procedure.
- Schedule, last successful run and maximum acceptable delay.
- Acceptance test and supported recovery method.

Use a separate service identity for separate workloads where practical. A shared credential makes it harder to revoke one connection, attribute activity or rotate keys without coordinating every consumer at once.

## How do you create and register a key pair?

Snowflake requires an RSA key of at least 2,048 bits and supports two public-key slots for rotation. Encrypted private-key support depends on the client. Follow the current [key-pair and rotation documentation](https://docs.snowflake.com/en/user-guide/key-pair-auth) and your connector's format requirements.

The following example creates an encrypted PKCS#8 private key and its public key. Run it in an approved secure location with restrictive file permissions. OpenSSL prompts for the passphrase; keep that secret out of command history and source control.

```bash
umask 077
openssl genrsa 2048 | openssl pkcs8 -topk8 -v2 aes-256-cbc -inform PEM -out service_key.p8
openssl rsa -in service_key.p8 -pubout -out service_key.pub
```

Store the private key and passphrase through the runtime's secret-management mechanism. Assign only the public key body to the Snowflake user, excluding the PEM header, footer and line breaks. The placeholder below is deliberately not a working key:

```sql
ALTER USER SVC_DBT_MARKETING
  SET RSA_PUBLIC_KEY = '<PUBLIC_KEY_BODY>';

DESC USER SVC_DBT_MARKETING;
```

Inspect the existing key slots before assigning a key. If the first slot already supports another live consumer, use the available second slot after confirming ownership. Never overwrite a live key just because a setup example uses the first slot.

An administrator needs the appropriate privilege to change that user's authentication settings. The service itself should receive only the data and compute privileges required for its work. Authentication establishes identity; role grants still determine what the identity can do.

## How do you migrate Fivetran?

For a Snowflake destination, edit its connection authentication to use the supported key-pair option, supply the service username and private-key material, and provide the passphrase if the selected format is encrypted. Preserve the existing database, role, warehouse and network configuration unless a separate change is required. Follow Fivetran's [destination setup guide](https://fivetran.com/docs/destinations/snowflake/setup-guide).

Run the connection tests, then an ordinary incremental sync. Confirm source progress, destination row freshness and the expected job identity. A successful login test does not establish that the connector can create or update all required objects.

Keep the authentication migration separate from a destination rebuild. Recreating connectors or resetting sync state can trigger unnecessary historical processing and additional cost. If Snowflake is the source rather than the destination, use Fivetran's separate source-connector instructions and test that read path.

## How do you migrate Airbyte?

Airbyte's Snowflake destination documentation says username/password authentication is deprecated from connector version 5.0.0 and lists key-pair authentication and programmatic access tokens as alternatives. Use the method supported by your installed version and deployment. [Airbyte's current Snowflake connector guide](https://docs.airbyte.com/integrations/destinations/snowflake).

For key-pair authentication, provide the full private-key PEM content, including its header and footer, and the passphrase if encrypted. Confirm the selected username matches the user holding the public key. A public key pasted into the private-key field cannot authenticate the client.

Test one representative stream before resuming the normal schedule. Inspect destination updates, staging permissions and any schema changes needed by the connector. A programmatic token has its own expiry and rotation requirements; choosing it does not remove credential lifecycle work.

## How do you migrate dbt?

Use a dedicated deployment identity for scheduled jobs and the authentication configuration supported by your dbt engine and Snowflake adapter version. Current dbt v2 documentation supports a key path or inline PEM and recommends PKCS#8 with AES-256 encryption; it does not support legacy 3DES or headerless key formats. [dbt's Snowflake setup](https://docs.getdbt.com/docs/local/connect-data-platform/snowflake-setup).

An illustrative profile using secrets supplied by the runtime looks like this:

```yaml
marketing:
  target: prod
  outputs:
    prod:
      type: snowflake
      account: "{{ env_var('SNOWFLAKE_ACCOUNT') }}"
      user: SVC_DBT_MARKETING
      role: MARKETING_TRANSFORMER
      database: ANALYTICS
      warehouse: TRANSFORM_WH
      schema: MARKETING
      threads: 4
      private_key: "{{ env_var('DBT_ENV_SECRET_SNOWFLAKE_KEY') }}"
      private_key_passphrase: "{{ env_var('DBT_ENV_SECRET_SNOWFLAKE_PASSPHRASE') }}"
```

This is a configuration pattern to adapt, not a credentialed production file. Preserve multiline key content using the secret system's supported mechanism and verify the environment-variable handling in your dbt runtime. Hosted deployment credentials may be configured in the platform interface instead.

Run the connection diagnostic, then a selected model and its relevant tests in the intended deployment environment. A developer's successful local run does not prove that a scheduled job can access the same secret, network path or role.

## What changes for Metabase and Tableau?

Metabase's current Snowflake settings include RSA key-pair authentication and workload identity federation. Key-pair setup uses a local or uploaded private-key file, with a passphrase when encrypted; Metabase Cloud requires the uploaded-file route. Check your version against the [Metabase connection documentation](https://www.metabase.com/docs/latest/databases/connections/snowflake).

Test a saved question, a dashboard and a scheduled delivery or refresh. The interactive connection test can succeed while a background worker lacks access to a mounted key file. For self-hosted deployments, ensure every relevant runtime can read the approved secret location.

Tableau's [Snowflake connector documentation](https://help.tableau.com/current/pro/desktop/en-us/examples_snowflake.htm) lists key-pair support from Desktop, Prep and Cloud 2024.3, and Server 2025.1, with Snowflake ODBC 3.4.0 or newer. It also documents publishing and web-authoring constraints. Validate the complete Desktop-to-published-source-to-scheduled-refresh path.

For interactive users, supported OAuth may be the better fit. For unattended work, evaluate supported key-pair, OAuth client credentials or workload identity options against the exact product version. There is no benefit in forcing every connection into one method when the tools support different operating models.

## How do you rotate keys without interrupting every job?

Use an overlap period: register a new public key in the free slot, update the intended clients, verify their actual jobs and then remove the old public key. Snowflake's two-slot design supports that sequence.

![Register a new public key in the free slot, update and verify one client, migrate remaining consumers, then remove the old key only after confirming it is no longer needed.](https://www.martechdevs.com/assets/blog/snowflake-key-pair-authentication.svg)

Document which slot holds which key fingerprint and which systems consume it. A key's age alone cannot tell you whether a monthly job still depends on it. Include infrequent jobs in the observation window or run an appropriate controlled test.

Once service-user password authentication is blocked, rollback cannot depend on restoring the password method. Preserve a valid prior key or another approved supported method during the cutover. If compromise prompted rotation, the security response may require immediate revocation instead of a long overlap.

## What does a practical migration plan look like?

Consider an illustrative 25-person SaaS company with eight unattended connections: two ingestion destinations, two dbt environments, three BI refreshes and one internal reporting job. Four owners share responsibility across them.

Budget, for planning only, 45 minutes per connection for inventory and configuration, another 30 minutes for workload verification, and two hours for shared documentation and coordination. That totals twelve hours. At an assumed loaded engineering rate of $90 an hour, the internal effort is $1,080 before connector upgrades or unexpected compatibility work.

Sequence low-risk jobs first, then ingestion, transformation and reporting dependencies. Record the last successful source checkpoint and normal freshness before each switch. Afterward, verify that downstream models and dashboards resumed with current data.

The success measure is supported authentication plus current, reconciled outputs. A completed credential form is only one step in that result.

## A migration checklist

- [ ] Read the account-specific Snowflake enforcement notice.
- [ ] Inventory unattended users and infrequent jobs.
- [ ] Check connector, driver and runtime compatibility.
- [ ] Confirm each service identity's necessary roles and network access.
- [ ] Generate and store keys through an approved secret process.
- [ ] Register the correct public key without overwriting an unreviewed live slot.
- [ ] Update one connection and run its actual workload.
- [ ] Verify data freshness, permissions and downstream outputs.
- [ ] Keep a supported recovery method during cutover.
- [ ] Complete all consumers before retiring old credentials.
- [ ] Record owner, fingerprint, secret location and next rotation procedure.

At Martechdevs, we connect warehouse access, data movement and reporting into a documented operating setup. Start with the [free martech AI audit](https://www.martechdevs.com/martech-ai-audit), or explore an [AI assistant built around your approved workflows](https://www.martechdevs.com/custom-martech-ai-agent).

If the connection will serve an AI assistant, use the [MCP security checklist](https://www.martechdevs.com/blog/mcp-security-checklist) to review the surrounding client, permissions and logs as well as the key.

## Frequently asked questions

### Is key-pair authentication the only replacement for passwords?

No. Supported alternatives can include OAuth, workload identity federation and programmatic access tokens. The correct choice depends on the client, whether a human is present and how your organisation manages credentials.

### Does a service user need MFA with a key pair?

A service identity uses a supported unattended authentication method. It should not depend on someone approving a recurring MFA prompt. Keep human interactive access and automated workloads under their appropriate user types and policies.

### Can we reuse one key across every connector?

It can make ownership and rotation harder because several consumers depend on the same secret. Separate identities and credentials make it easier to limit access and revoke one workload. Consider the operational cost as well as the initial setup effort.

### Why does login work but the sync still fail?

The identity may authenticate successfully while lacking a required role, warehouse, schema or object privilege. Network access and staging permissions can also differ across job steps. Inspect the failing operation rather than repeatedly regenerating keys.

### How do we know the migration is finished?

Every required workload must run with supported authentication, produce current expected outputs and have a documented owner and recovery process. Include scheduled jobs that do not run daily. Then retire old credentials once their consumers have been accounted for.

## Sources

1. Snowflake, [Deprecation of single-factor password sign-ins](https://docs.snowflake.com/en/user-guide/security-mfa-rollout), checked October 2026.

2. Snowflake, [Key-pair authentication and rotation](https://docs.snowflake.com/en/user-guide/key-pair-auth), checked October 2026.

3. Snowflake, [LOGIN_HISTORY view](https://docs.snowflake.com/en/sql-reference/account-usage/login_history), checked October 2026.

4. Fivetran, [Snowflake destination setup](https://fivetran.com/docs/destinations/snowflake/setup-guide), checked October 2026.

5. Airbyte, [Snowflake destination connector](https://docs.airbyte.com/integrations/destinations/snowflake), checked October 2026.

6. dbt Labs, [Snowflake connection setup](https://docs.getdbt.com/docs/local/connect-data-platform/snowflake-setup), checked October 2026.

7. Metabase, [Snowflake connection settings](https://www.metabase.com/docs/latest/databases/connections/snowflake), checked October 2026.

8. Tableau, [Snowflake connector](https://help.tableau.com/current/pro/desktop/en-us/examples_snowflake.htm), checked October 2026.