How to restrict Snowflake access to a specific IP address using Conditional Access

This article provides guidance on restricting Snowflake access using Microsoft Entra ID Conditional Access based on trusted IP addresses.  

When Snowflake is configured to use Entra ID as its identity provider through SAML SSO, Conditional Access policies can enforce location-based restrictions before authentication is completed.  

By limiting access to approved networks such as corporate offices or secure VPN connections, organizations can reduce the risk of unauthorized access to sensitive data warehouses, analytics environments, and business intelligence platforms.

Why it’s important to restrict Snowflake access by IP address

Restricting Snowflake access by IP address is a critical security control for protecting sensitive business and analytics data. 

Key benefits include: 

• Block sign-ins originating from untrusted or unknown networks.  
• Ensure access to Snowflake is limited to approved environments.  
• Reduce risk from compromised credentials. 
• Combine Entra ID Conditional Access with Snowflake Network Policies for broader coverage.  
• Restricting access to sensitive data platforms helps support security and regulatory obligations. 

As described in the article, Entra ID Conditional Access only protects authentication flows that use SAML SSO. For comprehensive protection across JDBC, ODBC, SnowSQL, and other non-SSO connection methods, Snowflake Network Policies should also be configured.

Step-by-step: How to restrict Snowflake access to specific IP addresses using Conditional Access

When Entra ID is configured as the identity provider for Snowflake via SAML SSO, Conditional Access policies are evaluated at sign-in time, blocking access from any IP not on your approved list before a SAML assertion is issued to Snowflake.

The approach uses two components working together:

• Named Locations: A saved list of trusted IP addresses or CIDR ranges defined in Entra ID.
• Conditional Access policy: A policy that blocks Snowflake sign-ins originating from any IP not on the trusted list.

Two complementary layers of IP control

Snowflake is unique in that it has its own powerful native IP restriction mechanism—Snowflake Network Policies—that operates independently of Entra ID. For full coverage, both layers should be considered.

IMPORTANT: Entra ID Conditional Access only covers sign-ins that go through the SSO flow. Snowflake connections made via JDBC/ODBC drivers, SnowSQL with key-pair authentication, or any method that does not use SAML SSO will bypass Entra ID entirely. For comprehensive IP restrictions, especially in data engineering and pipeline environments, configuring a Snowflake Network Policy in addition to this Conditional Access policy is strongly recommended.

Prerequisites

Before proceeding, confirm the following are in place

• Microsoft Entra ID P1 or P2 license — required for Conditional Access.
• Conditional Access Administrator role or higher in Microsoft Entra ID.
• Snowflake enterprise app (SAML SSO) registered in your Entra ID tenant with a SAML2 Security Integration configured in Snowflake using the CREATE SECURITY INTEGRATION command.
• Local Snowflake credentials disabled (recommended) — once SSO is validated, remove Snowflake passwords from user accounts using the ALTER USER command. If users retain passwords, they can bypass Entra ID and sign in directly.
• Security Defaults disabled — Security Defaults and Conditional Access cannot run simultaneously.
• Known static IP address — the public IP address or CIDR range of each approved location.
• Break-glass admin account — must be excluded from this policy to prevent administrative lockout.

NOTE: To remove passwords from Snowflake user accounts after SSO is confirmed working, run the following command for each user as ACCOUNTADMIN: ALTER USER <username> SET PASSWORD = NULL;

IMPORTANT: If your approved IP address is dynamic, this approach will not work reliably. You must use a static IP before implementing IP-based Conditional Access.

Step 1: Create a Named Location for your trusted IP(s)

A Named Location defines the trusted IP addresses that Entra ID will reference as a condition in the policy.

1. Sign in to the Microsoft Entra admin center at entra.microsoft.com.
2. Navigate to Protection > Conditional Access > Named locations.
3. Select + IP ranges location.
4. Name the location — for example: Trusted - Corporate Office
5. Check the Mark as trusted location checkbox.
6. Click + and enter your approved IP address or CIDR range. Examples:
   
   1. Single IP address: 203.0.113.10/32
   2. IP range (CIDR): 203.0.113.0/24
   3. Multiple sites: Create a separate Named Location for each site, then reference all of them in the policy.
7. Click Create.

Step 2: Create the Conditional Access policy

Create a policy that blocks Snowflake access from any location not on your trusted list.

1. In the Entra admin center, navigate to Protection > Conditional Access > Policies.
2. Select + New policy.
3. Name the policy — for example: Block Snowflake - Outside Trusted IPs

Assignments: Users  

1. Under Assignments > Users, select All users.
2. Under Exclude, add your break-glass admin account and any service accounts that authenticate from dynamic IPs.

NOTE: Snowflake service accounts used for data pipelines, ETL tools, dbt, or BI connectors that authenticate via key-pair or password rather than SSO will not be affected by this policy. Those connections bypass Entra ID and should be controlled using a Snowflake Network Policy instead.

Assignments: Target Resources

1. Under Target Resources, select Cloud apps > Select apps.
2. Search for and select Snowflake.

Conditions: Locations

1. Under Conditions > Locations, set Configure to Yes.
2. Under Include, select Any location.
3. Under Exclude, select Selected locations, then choose your Named Location from Step 1.

TIP: This configuration reads: apply this policy to sign-ins from any location, except the trusted named location. Any Snowflake sign-in originating outside the trusted IP will be blocked before Entra ID issues a SAML assertion to Snowflake.

Access Controls: Grant

1. Under Access Controls > Grant, select Block access.
2. Click Select to confirm.

Enable policy

1. Set Enable policy to Report-only.
2. Click Create.

IMPORTANT: Do not set this policy to On immediately. Always validate in Report-only mode first.

Step 3: Validate the policy

Before enabling enforcement, confirm the policy is evaluating sign-ins correctly.

1. In the Entra admin center, navigate to Identity > Monitoring & health > Sign-in logs.
2. Filter by the Snowflake application.
3. Open a sign-in from a user on your trusted IP and confirm the Conditional Access tab shows Would succeed.
4. If available, review a sign-in from an untrusted IP and confirm it shows Would fail with the location condition listed as the reason.
5. Investigate any unexpected Would fail entries for users on trusted Ips. This typically indicates the network is presenting a different egress IP than what is entered in the Named Location.

TIP: Use the What If tool under Protection > Conditional Access to simulate how a specific user signing in from a specific IP would be evaluated without waiting for a real sign-in event.

Step 4: Enable the policy

1. In the Entra admin center, navigate to Protection > Conditional Access > Policies.
2. Select the policy created in Step 2.
3. Change Enable policy from Report-only to On.
4. Click Save.

From this point forward, any Snowflake sign-in via SSO from an IP address not included in your Named Location will be blocked. Entra ID will not issue a SAML assertion to Snowflake, and the user will be denied access at the identity provider level.

NOTE: Users who are already signed in to Snowflake when the policy is enabled will not be immediately signed out. The block takes effect on the next sign-in or token refresh. For complete IP enforcement across all connection methods including JDBC, ODBC, and programmatic access, configure a Snowflake Network Policy in addition to this Conditional Access policy.

Summary

The following table summarizes the full configuration process:

FAQs

Does Snowflake support Conditional Access through Entra ID?
Yes. Snowflake supports SAML SSO with Entra ID, allowing Conditional Access policies to be enforced during authentication. 

Does Conditional Access protect all Snowflake connection methods?
No. Conditional Access only applies to authentication flows that use SAML SSO. Connections using JDBC, ODBC, SnowSQL with key-pair authentication, or other non-SSO methods bypass Entra ID.  

What is a Snowflake Network Policy?
A Snowflake Network Policy is a native Snowflake feature that restricts access based on IP address at the Snowflake account or user level. It can enforce restrictions independently of Entra ID. 

Should I use both Conditional Access and Snowflake Network Policies?
Yes. Using both provides layered protection. Conditional Access secures SSO authentication, while Snowflake Network Policies secure direct and programmatic connections.  

Can users bypass Conditional Access using local Snowflake credentials?
Yes, if Snowflake passwords remain enabled. To prevent bypass, remove local passwords from user accounts after validating SSO.  

How do I remove local Snowflake passwords?
After confirming SSO works correctly, run the following command as ACCOUNTADMIN: 

ALTER USER <username> SET PASSWORD = NULL; 
‍
Can this work with dynamic IP addresses?
No. This configuration requires static IP addresses. Dynamic IPs will result in unreliable enforcement.  

What is a Named Location?
A Named Location is a list of trusted IP addresses or CIDR ranges defined in Microsoft Entra ID and used as a condition within Conditional Access policies.  

Why should I use Report-only mode first?
Report-only mode allows you to validate policy behavior safely before enforcing it, helping prevent accidental lockouts. 

Do I need to exclude any accounts?
Yes. Always exclude a break-glass (emergency) admin account and review any service accounts authenticating from dynamic IPs. 

Will existing Snowflake sessions be terminated immediately after enabling the policy?
No. Existing sessions remain active until the next sign-in or token refresh. 

What happens if the policy is misconfigured and enabled?
Because the policy may apply to all Snowflake users, a misconfiguration can prevent users and administrators from accessing Snowflake through SSO. Always validate thoroughly in Report-only mode before enabling enforcement.