This blog post is Human-Centered Content: Written by humans for humans.

If your Tableau connections use a shared Snowflake service account, meaning a single username and password shared among multiple Tableau Creators, I have some bad news and some good news. The bad news: A change to Snowflake security is about to break those connections. The good news: Fixing them is a lot less painful than you’d think, and we’ve been heads-down for the last few weeks building a scripted solution that solves this problem for your organization.

Your Snowflake Connections Are About to Fail

Snowflake, since September 2025, began strengthening its security through their Minimum Authentication Policy. Changes came in phases and the net impact is: Password-only logins are going away, for humans and service accounts alike. This happened in three phases:

• Phase 1 (Sept 2025 – Jan 2026): Human (aka, individual) users signing into Snowsight with a password had to add MFA. BI tools like Tableau were explicitly exempted, and service accounts weren’t touched.
• Phase 2 (May 2026 – July 2026): Every newly created human user needs MFA, and Snowflake stopped letting anyone create new “legacy service” users, the account type that’s allowed to log in with just a password.
• Phase 3 (Aug 2026 – Oct 2026): This is the one that matters here. Every non-human (service) account gets blocked from authenticating with a password, full stop. Existing legacy service accounts get auto-converted to a type that can no longer use one.

As I’m writing this, Phase 3 is weeks away, not months. If a Tableau data source or workbook is connecting to Snowflake as a shared service account with a username and password (an extremely common pattern, since it’s the easiest way to let a whole team’s worth of content share one Snowflake identity), that login will fail. It won’t switch to “prompt for MFA.” It will just stop. Dashboards will pause as a moment in time: live connections will go blank and extracted connections containing static data from the day before, continuing to fail until your organization can get your Creators to act en masse.

InterWorks Has a Solution for This

This isn’t a “rebuild your dashboards” problem, and it shouldn’t be treated as one. The fix Snowflake wants you to move to, key-pair authentication, doesn’t change anything about your data, your Snowflake roles, or how your content is built. It only changes how the connection proves who is authenticating. So that’s exactly what we built: something that flips the login method and leaves everything else alone.

It’s built to be:

• Out of the box: No rearchitecting your Tableau site or your Snowflake account structure. It works with what you already have.
• Scriptable: It runs as a set of scripts against Tableau’s REST API. We point it at your site, tell it which service accounts to fix, and it does the rest.
• Fast: A site’s worth of affected content can be inventoried, downloaded and patched in one pass.
• Low effort for Creators: The heaviest lift on your side is a five-minute, one-time step per content owner (more on that below), not a redesign.

What Is the Solution, Exactly?

For every affected data source or workbook, the process is the same four-step recipe:

• Download the content from Tableau.
• Patch only the authentication settings on the matching Snowflake connection. The server, database, role and username it connects as are never touched.
• Republish it, overwriting the original in place, maintaining original ownership or consolidating ownership to a single user, depending on your needs.
• Link the credential so the content authenticates automatically going forward, with no password prompt.

The one piece that can’t be automated away, by design, is step four. Tableau stores the private key per person, inside each individual Tableau user’s own account, and there’s no admin API that can plant it there on someone’s behalf. So, every content owner must add their key once, through a short self-service setup in their Tableau account settings. It takes about five minutes, and once it’s done, it’s done. Their content authenticates silently from then on.

Everything else is dry-run by default. Nothing gets published back to Tableau until you explicitly say go, so you can see the full list of what’s about to change before committing to it, and a rollback path exists if something needs to be walked back.

Who’s Eligible for This Solution?

This is a good fit if:

• You’re on Tableau Server or Tableau Cloud, connecting to Snowflake, and …
• Your data connections authenticate with a shared service account, a username and password used by many Creators, rather than each person’s own individual Snowflake Oauth login.
• You want an easy fix to this problem so your Tableau content can get back up and running without disruption!

It’s not the right solution if a connection already authenticates as an individual person’s own Snowflake identity, or is already on OAuth, SSO or key-pair auth. Those connections aren’t affected by the service-account password ban in the first place, and Snowflake’s human-user MFA requirements are a separate (and separately solvable) problem.

Extra Considerations

A few things worth planning around before you start:

• License requirements: Adding a saved credential requires a Tableau Creator license. If a content owner is on Explorer, Viewer or Unlicensed, their content needs to be reassigned to a Creator first (this is unlikely but, in rare cases, possible).
• Consolidating ownership: Because the key is stored per person, sites with a lot of individual content owners can optionally reassign all migrated content to a single service-owner account, so only that one account needs the saved key, instead of chasing down every dashboard owner individually.
• Token lifetime: The migration itself runs on a Tableau Personal Access Token, which expires after roughly 15 idle days. Plan your migration window with that in mind if it’s going to stretch out. Note: This is not the same as the private key you are adding to your account as a “Saved Credential.”
• Stage the rollout: You don’t have to flip everything at once. Content can be republished in batches as each owner finishes their one-time setup, so nothing goes down before it’s ready.

These, plus other governance and best practices in Snowflake and Tableau, are all topics our data and analytic experts will be more than happy to help you with as you navigate the ever-changing tech landscape.

What Should My Settings Look Like After Migration?

• Authentication method: Key-Pair Authentication.
  The replacement Snowflake allows for service accounts once password logins are blocked.
• Workgroup auth mode: Prompt (backed by a saved credential).
  Keeps the private key out of the data source/workbook file entirely; it lives only in the owner’s Tableau account.
• Embed credentials: Enabled, tied to the content owner’s saved key.
  Without this, the connection still prompts for a password on every open or refresh (a password that no longer exists).

The Clock Is Running

Phase 3 isn’t a “someday” deadline. It’s weeks out at the time I’m writing this. If your Tableau site has any Snowflake connections riding on a shared service account’s password, now’s the time to find them, not after the first dashboard goes dark. If you want a hand doing that or just want a second set of eyes on your plan before you touch production, reach out to us at InterWorks. We’d love to help you get ahead of this one.