Overview
Restricting Okta access by IP address requires a different approach than the other applications in this KB series. Okta is an identity provider (IdP) — 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.
| Scenario | Who is the IdP | Correct Approach |
| Restrict access to the Okta Admin Console by IP | Okta is the IdP. Entra ID CA does not apply to Okta's own console. | Use Okta's native Network Zones and Global Session Policy. See Part A of this article. |
| Restrict access to apps managed by Okta (SSO) by IP | Okta is the IdP. Entra ID CA does not apply to apps federated through Okta. | Use Okta's native App Sign-On Policies with Network Zones. See Part A of this article. |
| Restrict Okta end-user dashboard access by IP | Okta is the IdP. Entra ID CA does not apply. | Use Okta's native Global Session Policy. See Part A of this article. |
| Entra ID is the IdP and Okta is used as a secondary authenticator (EAM) |
Entra ID issues the authentication. CA policies apply. | Use Entra ID Named Locations and CA policy. See Part B of this article. |
Please Note: This article covers both scenarios. Part A covers the most common case - 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 scenairo 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.
- Sign in to the Okta Admin Console at your-org.okta.com/admin.
- Navigate to Security > Networks.
- Select Add Zone > IP Zone.
- Name the zone. For example: Corporate Office
- Under Gateway IPs, enter your approved IP address or CIDR range. Examples:
| Field/Setting | Value/Notes |
| Single IP address | 203.0.113.10/32 |
| IP range (CIDR) | 203.0.113.0/24 |
| Multiple sites | Create a separate Named Location for each site, then reference all of them in the policy. |
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.
- In the Okta Admin Console, navigate to Security > Authentication Policies.
- Select the Okta Admin Console policy.
- Select Add Rule (or edit the default rule).
- Under Conditions, set Device state to Any and set Network to Not in Zone.
- Select your Network Zone from Step 1.
- Under Actions, set Access to Denied.
- 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 falback.
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.
- In the Okta Admin Console, navigate to Security > Global Session Policy.
- Add a rule that denies access when the user is Not in Zone, selecting your network zone.
- For individual app restrictions, navigate to Applications > select the app > Sign On > Add Rule.
- Set Location to Not in Zone, select your network zone, and set Access to Denied.
Please Note: Global Session Policy control whether a user can establish an Okta session at all. App Sign-On Policies control acess to indvidual 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.
Please 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 use for MFA only, Part B applies. If users sign in to Okta first for all apps, Part A applies.
Prerequisites for Part B
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.
- Okta configured as an External Authentication Method in Entra ID - not as the primary identity provider.
- Security Defaults Disabled in Entra ID - 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.
Step 1: Create a Named Location in Entra ID
A Named Location defines the trusted IP addresses that Entra ID will reference as a condition in the policy.
- Sign in to the Microsoft Entra admin center at entra.microsoft.com
- Navigate to Protection > Conditional Access > Named locations.
- Select + IP ranges locations.
- Name the location. For example: Trusted - Corporate Office
- Check the Mark as trusted location checkbox.
- Click + and enter your approved IP address or CIDR range.
| Field/Setting | Value/Notes |
| Single IP address | 203.0.113.10/32 |
| IP range (CIDR) | 203.0.113.0/24 |
| 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
- In the Entra admin center, navigate to Protection > Conditional Access > Policies.
- Select + New policy.
- Name the policy. For example, Block Okta EAM - Outside Trusted IPs
- Under Assignments > Users, select All users.
- Under Exclude, add your break-glass admin account.
- Under Target Resources, select Cloud apps > Select apps.
- Search for and select the app that triggers Okta EAM authentication in your environment.
- Under Conditions > Locations, set Configure to Yes.
- Under Include, select Any location.
- Under Exclude, select Selected locations, then choose your Named Location.
- Under Access Controls > Grant, select Block access.
- Set Enable policy to Report-only.
- 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 table summarizes the full configuration process.
| Step | Action |
| 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 |
Help Center