Snowflake Wants Stronger Authentication. Power BI & Azure Data Factory May Not Be Ready

A real-world look at ADF, Power BI & Fabric implementation

Prelude

In 2025, Snowflake announced the retirement and deprecation of single-factor password sign-ins in favor of stronger authentication methods, and we are in full swing.

You can read the official timeline here:

[embed]Planning for the deprecation of single-factor password sign-ins | Snowflake Documentation To improve the security posture of all of its customers, Snowflake is rolling out changes to require multi-factor…docs.snowflake.com

Multi-cloud architectures are extremely common, especially in large enterprises (as I wrote in a previous post). It’s very common to see data warehouses hosted in Snowflake, ETLs running in Microsoft Fabric or Azure Data Factory (ADF), and semantic models managed in Power BI.

In this kind of scenario, Snowflake’s announcement has a direct impact because it may require reconfiguring how different services connect to Snowflake databases.

Disclaimer: I’m not a Snowflake expert. This post is written from the perspective of an experienced Power BI & Fabric consultant and “accidental Snowflake developer” working on real-world integration projects.

Service Accounts First

One golden rule we always try to follow in our projects is to use service accounts for ETL automated processes involving read/write operations on Snowflake instead of relying on personal user accounts.

For service accounts, Snowflake recommends moving away from basic authentication and adopting stronger authentication methods that avoid password-based logins entirely.

Depending on the tool you are using to connect, the available authentication methods may differ. Not every connector supports the same approaches, and even when they do, they may not behave consistently.

In a recent project, we helped a customer enforce this new security policy across their architecture by changing how both Azure Data Factory and several Power BI semantic models authenticated against Snowflake.

Azure Data Factory: Switching to Key-Pair Authentication

From Azure Data Factory, the only practical option is moving from basic authentication to key-pair authentication.

This means:

1. Generating a private/public key pair with OpenSSL
2. Assigning the public key to the Snowflake service account

1. Generate the Private Key

Start by creating the private key and encrypting it using AES-256-CBC (use the algorith of your choice):

openssl genrsa 2048 | openssl pkcs8 -topk8 -inform PEM -out private_key.p8 -v2 aes-256-cbc

You’ll be prompted for a passphrase, make sure to store it securely because it will be needed later.

2. Extract the Public Key

Next, extract the public key:

openssl rsa -in private_key.p8 -pubout -out public_key.pub

You can now send the public key to your Snowflake administrator, who can associate it with the service account using a command like:

ALTER USER example_user SET RSA_PUBLIC_KEY='MIIBIjANBgkqh...';

For additional details, refer to the official Snowflake documentation:

[embed]Key-pair authentication and key-pair rotation | Snowflake Documentation Snowflake supports using key pair authentication for enhanced authentication security as an alternative to basic…docs.snowflake.com

3. Storing the Private Key in Azure Key Vault

Once the Snowflake side is configured, you can update the Azure Data Factory linked service.

As a best practice, avoid storing both the private key and passphrase directly inside ADF. Instead, use Azure Key Vault.

1. Open your Azure Key Vault
2. Create a new secret
3. Open the encrypted .p8 file
4. Copy the entire content (including -----BEGIN ENCRYPTED PRIVATE KEY---- and -----END ENCRYPTED PRIVATE KEY-----)
5. Paste the full content into the secret value
6. Save the secret
7. Create another secret containing the private key passphrase

4. Configuring the Linked Service in ADF

Once both secrets are available:

1. Open the Linked Services pane in Azure Data Factory
2. Open your Snowflake linked service
3. Set the authentication method to Key Pair
4. Configure the private key to be retrieved from Azure Key Vault
5. Select the secret containing the private key
6. Configure the passphrase to be retrieved from Azure Key Vault
7. Select the passphrase secret
8. Test the connection
9. Save the configuration

Image showing the ADF linked service setup with key-pair retrieve by AKV

Mind the version

Even though key-pair authentication was introduced in the Snowflake connector v2.1.0, there seem to be issues related to reading the private key and PEM block correctly from Azure Key Vault.

You may see something like this:

“Failed to parse PEM block containing private key”

If you are struggling to make the connection work when using Azure Key Vault, double-check which connector version you are using.

If you are still on v2.1.0, switching to v2.1.1 may immediately solve the issue.

Image showing linked service leveraging Snowflake connector V2 1.1

Power BI and Snowflake: A Different Story

So far, so good. Half of the architecture has been migrated from basic authentication to key-pair authentication.

Now it’s time to deal with Power BI.

I strongly believe standards should be enforced consistently across the architecture, and authentication methods should be one of those standards. If key-pair authentication is the chosen approach, ideally it should be used everywhere, including Power BI.

Unfortunately, as of May 2026, the Snowflake connector in Power BI appears not to support key-pair authentication as it should.

Issues in Power BI Desktop

In Power BI Desktop, you are asked to paste:

• The private key content
• The passphrase

Image showing the Snowflake Power Query connector with key-pair auth method

However, even though no validation feedback is provided, refresh operations will fail with errors related to reading the PEM block correctly.

Image showing “Failed to parse PEM block containing the private key” during model refresh

Issues in Power BI Service / Fabric

The cloud configuration behaves even differently when you create a Shared Cloud Connection for Snowflake with key-pair.

Instead of pasting the private key content, you are asked to upload the private key as a file. Even if you provide the exact same private key and passphrase that work elsewhere, authentication still fails with “wrong credentials” errors.

Image showing the setup of Shared Cloud Connection to Snowflake giving KO

Leveraging Azure Key Vault reference in Fabric portal you can try to reference the exact same secrets you’re using in Azure Data Factory directly into the Shared Cloud Connection but, it will fail with similar error.

Image showing the setup of Shared Cloud Connection to Snowflake with AKV reference giving KO

My Guess on What’s Happening

This is only speculation, but it feels like something may have changed on the Snowflake side that broke how Power BI Desktop, Power BI Service / Fabric and ADF v2.1.0 connector handle key-pair authentication.

…Something addressed in the ADF v2.1.1 connector.

Working setup for Power BI

After several attempts, my conclusion is that, as of today, Power BI integrations with Snowflake require a different stronger authentication method: External OAuth.

In our case, we used Microsoft Entra ID.

Using:

• A Microsoft account
• A Workspace Identity
• A Service Principal

you can obtain an Entra token and use it to authenticate against Snowflake.

Image showing the connection setup on Fabric portal using Microsoft Account

Conclusions

If your architecture interacts with Snowflake, you will need to adapt your setup to comply with the deprecation of single-factor password sign-ins.

However, the implementation strategy depends heavily on which tools are connecting to Snowflake.

Current observations:

• Azure Data Factory can successfully use key-pair authentication if you are using the Snowflake connector v2.1.1
• Power BI / Microsoft Fabric currently seem to require External OAuth authentication through Microsoft Entra ID

Final Disclaimer: Everything described in this post reflects the situation at the time of writing and may evolve over time as connectors and platform integrations improve.