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

Okta is a cloud-based identity and access management (IAM) platform that helps companies control how employees, contractors, and partners access their cloud and on-premises resources.  

It is commonly used for sing-sign-on (SSO) for applications, multi-factor authentication, managing user identities and permissions, automating onboarding and offboarding, and more.  

It is typically connected to other platforms like AWS, Salesforce, Zoom, and more, and it controls access to critical systems and business data. Securing access to Okta is crucial for businesses.

Benefits of restricting Okta access based on IP address

Restricting access to Okta by IP address is critical because Okta controls authentication to multiple downstream applications. 

Key benefits include: 

• Prevent attackers from accessing Okta Admin Console or user sessions from untrusted networks.  
• Since Okta provides SSO, restricting access at the IdP level protects every connected application.  
• Even if credentials are compromised, access is blocked outside approved IP ranges.  
• Apply centralized IP restrictions across admin access, user sessions, and application sign-ins.
• Supports both Okta-first (native controls) and Entra ID-first (Conditional Access) environments.  

As highlighted in this article, Entra ID Conditional Access only applies when Entra ID is the primary identity provider. In most cases, IP restrictions must be configured directly within Okta using native controls. 

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

Restricting Okta access by IP address requires a different approach than other applications. Okta is an identity provider (IdP) meaning it authenticates users and issues access to other applications. It is not itself a SAML service provider that Entra ID controls. This means that for most Okta scenarios, Microsoft Entra ID Conditional Access does not apply, and IP restrictions must be configured natively within Okta.  

The correct approach depends on what you are trying to restrict. Review the table below before proceeding.

NOTE: This article covers both scenarios. Part A covers restricting access to Okta and Okta-managed apps using Okta's native controls. Part B covers the less common case where Entra ID is the primary IdP and Okta is used as a secondary authenticator, which is the only scenario where an Entra ID Conditional Access policy applies.

Part A: Restrict Okta access by IP using Okta native controls

When Okta is your primary identity provider, IP-based access restrictions are configured inside the Okta Admin Console using two features: Network Zones and Policies.

Step 1: Create a Network Zone in Okta

A Network Zone in Okta is the equivalent of a Named Location in Entra ID—a saved definition of trusted IP addresses that policies can reference.

1. Sign in to the Okta Admin Console at your-org.okta.com/admin.
2. Navigate to Security > Networks.
3. Select Add Zone > IP Zone.
4. Name the zone — for example: Corporate Office
5. Under Gateway IPs, enter your approved IP address or CIDR range.
   Examples:
   
   • Single IP address: 203.0.113.10/32
   • IP range (CIDR): 203.0.113.0/24
   • Multiple sites: Add each site's IP range as a separate entry within the same zone.
6. Click Save.

Step 2: Restrict Okta Admin Console access by IP

To restrict which IPs can access the Okta Admin Console, configure the Admin Console App policy.

1. In the Okta Admin Console, navigate to Security > Authentication Policies.
2. Select the Okta Admin Console policy.
3. Select Add Rule (or edit the default rule).
4. Under Conditions, set Device state to Any and set Network to Not in Zone.
5. Select your Network Zone from Step 1.
6. Under Actions, set Access to Denied.
7. Save the rule and ensure it is ordered above the default allow rule.

TIP: Okta evaluates policy rules in order from top to bottom. Place the deny rule above the default rule so it is evaluated first. The default rule at the bottom acts as a fallback.

Step 3: Restrict Okta end-user dashboard and app access by IP

To restrict sign-in to the Okta end-user dashboard and any apps managed through Okta SSO, configure the Global Session Policy and individual App Sign-On Policies.

1. In the Okta Admin Console, navigate to Security > Global Session Policy.
2. Add a rule that denies access when the user is Not in Zone, selecting your network zone.
3. For individual app restrictions, navigate to Applications > select the app > Sign On > Add Rule.
4. Set Location to Not in Zone, select your network zone, and set Access to Denied.

NOTE: Global Session Policy controls whether a user can establish an Okta session at all. App Sign-On Policies control access to individual apps within an existing session. For full IP enforcement, configure both.

Part B: Restrict Okta access by IP using Entra ID Conditional Access

This scenario applies only when Microsoft Entra ID is configured as the primary identity provider and Okta is used as an External Authentication Method (EAM)—meaning Entra ID handles authentication and calls out to Okta for MFA or additional verification. In this configuration, Entra ID issues the authentication token and CA policies apply.

NOTE: If you are unsure which scenario applies to your environment, check whether users sign in first to Okta or first to Microsoft. If users sign in to Microsoft first and Okta is used for MFA only, Part B applies. If users sign in to Okta first for all apps, Part A applies.

Prerequisites for Part B

• Microsoft Entra ID P1 or P2 license — required for Conditional Access.
• Conditional Access Administrator role or higher in Microsoft Entra ID.
• Okta configured as an External Authentication Method in Entra ID — not as the primary identity provider.
• 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.

Step 1: Create a Named Location in Entra ID

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. Enter your approved IP address or CIDR range and click Create.

Step 2: Create the Conditional Access policy

1. Navigate to Protection > Conditional Access > Policies and select + New policy.
2. Name the policy — for example: Block Okta EAM - Outside Trusted IPs
3. Under Assignments > Users, select All users. Exclude your break-glass account.
4. Under Target Resources, select Cloud apps > Select apps, then search for and select the app that triggers Okta EAM authentication in your environment.
5. Under Conditions > Locations, set Configure to Yes. Set Include to Any location and Exclude to your Named Location.
6. Under Access Controls > Grant, select Block access.
7. Set Enable policy to Report-only and click Create.

IMPORTANT: Validate thoroughly in Report-only mode before enabling. Use sign-in logs and the What If tool to confirm the policy evaluates correctly for both trusted and untrusted IPs before switching to On.

Summary

The following summarizes the full configuration process:

Identify your scenario

Determine whether Okta or Entra ID is the primary IdP — this determines which approach applies

Part A — Step 1

Create a Network Zone in Okta Admin Console with your trusted IP(s)

Part A — Steps 2 & 3

Apply IP restriction rules to the Okta Admin Console policy, Global Session Policy, and individual App Sign-On Policies

Part B — Step 1

Create a Named Location in Entra ID (only if Entra ID is the primary IdP with Okta as EAM)

Part B — Step 2

Create a CA policy targeting the relevant app, excluding the Named Location, with Block access

FAQs 

Can I use Entra ID Conditional Access to restrict Okta access? 
In most cases, no. If Okta is your primary identity provider, Entra ID Conditional Access does not apply. You must configure IP restrictions using Okta’s native controls. 

When does Entra ID Conditional Access apply to Okta? 
Only when Entra ID is the primary identity provider and Okta is used as an External Authentication Method (EAM), such as for MFA. In this scenario, Entra ID issues authentication and Conditional Access policies apply. 

What is a Network Zone in Okta? 
A Network Zone is Okta’s equivalent of a Named Location in Entra ID. It defines trusted IP addresses or ranges that policies can reference. 

What Okta components should I configure for full IP restriction? 
You should configure: 

• Network Zones (trusted IPs) 
• Admin Console policy (for admin access)  
• Global Session Policy (for user session control)  
• App Sign-On Policies (for individual application access) 

What’s the difference between Global Session Policy and App Sign-On Policy? 
Global Session Policy controls whether a user can establish an Okta session at all, while App Sign-On Policies control access to individual applications within that session. 

Can users bypass restrictions if policies are incomplete? 
Yes. If you only configure one layer (e.g., App policies but not Global Session Policy), users may still gain access. For full enforcement, configure all relevant policy layers. 

Can this work with dynamic IP addresses? 
No. Static IP addresses are required for reliable enforcement. 

Do I still need a break-glass account? 
Yes. Whether using Okta policies or Entra ID Conditional Access, always maintain an emergency access account that is excluded from restrictions. 

How do I know which scenario applies to my environment? 
Check the login flow: 

• If users sign in to Okta first → use Okta native controls (Part A)  
• If users sign in to Microsoft first and Okta is used for MFA → use Entra ID Conditional Access (Part B)  

What happens if policies are misconfigured?Because Okta controls authentication for multiple applications, a misconfiguration can block access to all connected apps. Always validate policies carefully before enforcing them.