How to restrict Jira (Atlassian Cloud) access to specific IP addresses

Jira is used by many businesses to plan, organize, and manage projects across their teams. It is used widely in IT operations, workflow automation, and task tracking and stores valuable and private business information.  

This article walks through restricting Jira access to one or more approved IP addresses using Conditional Access in Microsoft Entra ID.  

This is commonly used to ensure that Jira and other Atlassian Cloud products in your organization can only be accessed from a corporate network, reducing the risk of unauthorized access to project data, tickets, and internal workflows from untrusted networks.

Why you should restrict access to Jira to specific IP addresses

Restricting Atlassian Cloud access by IP address is an important security measure for protecting development, support, and collaboration platforms.  

Key benefits include:

• Block sign-ins from untrusted networks where credentials may be compromised.
• Ensure Jira, Confluence, and related tools are only accessible from secure environments.
• Reduce risk of data exposure from unmanaged devices.
• Limit access to corporate networks or VPN connections.
• Add additional identity controls beyond passwords and MFA.
• Support compliance and security frameworks.

As outlined in the article, this approach ensures Atlassian Cloud applications are only accessible from trusted locations, reducing the risk of unauthorized access to project data and internal systems.

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

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 Atlassian Cloud sign-ins originating from any IP not on the trusted list.

NOTE: In Entra ID, the enterprise application for Jira is named Atlassian Cloud—not Jira. This single app covers all Atlassian Cloud products connected to your organization, including Jira Software, Jira Service Management, Confluence, and Trello. A Conditional Access policy targeting the Atlassian Cloud app will apply to all these products simultaneously.

IMPORTANT: Atlassian Cloud SAML SSO requires an active Atlassian Guard subscription (formerly Atlassian Access). SSO cannot be enforced without it. Additionally, SSO enforcement in Atlassian Cloud is controlled through Authentication Policies at admin.atlassian.com—not through Jira settings. If SSO is not enforced via an Authentication Policy, users can still sign in directly with their Atlassian account credentials, bypassing Entra ID and this policy entirely.

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.
• Atlassian Guard Standard or Premium subscription — required to configure and enforce SAML SSO for Atlassian Cloud. Included free with Atlassian Cloud Enterprise plans.
• Atlassian Cloud enterprise app (SAML SSO) — registered in your Entra ID tenant with SSO configured and verified in the Atlassian admin portal.
• SSO enforced via Authentication Policy — in the Atlassian admin portal at admin.atlassian.com, an Authentication Policy must be configured with Enforce single sign-on enabled and assigned to the relevant managed accounts.
• 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.

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:
   
   • 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

Create a policy that blocks Atlassian Cloud 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 Atlassian Cloud - Outside Trusted IPs

Assignments: Users

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

Assignments: Target Resources

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

NOTE: Selecting Atlassian Cloud applies the policy to all Atlassian products in your organization: Jira Software, Jira Service Management, Confluence, and Trello. If you need to restrict only specific Atlassian products, scope your user assignments by group rather than by application, as Atlassian Cloud does not expose individual product apps in the Entra ID gallery.

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 Atlassian Cloud sign-in originating outside the trusted IP will be blocked before Entra ID issues a SAML assertion to Atlassian.

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. A block policy applied to All users that is misconfigured will lock all users out of all Atlassian Cloud products instantly. 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 Atlassian Cloud 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. 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 Atlassian Cloud sign-in attempt from an IP address not included in your Named Location will be blocked. Entra ID will not issue an SAML assertion to Atlassian, and the user will be denied access to Jira and all other Atlassian Cloud products covered by the policy.

NOTE: Users who are already signed in when the policy is enabled will not be immediately signed out. The block takes effect on the next sign-in or token refresh, typically within one hour. Confirm that Enforce single sign-on is active in your Atlassian Authentication Policy at admin.atlassian.com to prevent users from bypassing Entra ID using direct Atlassian account credentials.

Summary

The following summarizes the full configuration process:

Prerequisites

Confirm Atlassian Guard subscription, Atlassian Cloud SAML SSO configured, SSO enforced via Authentication Policy, Security Defaults disabled, static IP(s) identified

Step 1

Create a Named Location with your trusted IP address(es) in Entra ID

Step 2  

Create a CA policy targeting Atlassian Cloud, excluding the Named Location, with Block access  

Step 3  

Validate in Report-only mode using sign-in logs and the What If tool  

Step 4

Switch Enable policy to On

FAQs

Does restricting Jira access block access to all Atlassian products?

Yes. The Entra ID application is named Atlassian Cloud, and a policy targeting it applies to all connected products, including Jira Software, Jira Service Management, Confluence, and Trello.  

Can I restrict only Jira and not other Atlassian products?

Not directly by application. Atlassian Cloud is a single enterprise app in Entra ID. To scope access, you must assign the policy to specific user groups rather than targeting individual products.  

What happens if SSO is not enforced in Atlassian?

Users can bypass Entra ID and sign in directly with Atlassian account credentials. To prevent this, SSO must be enforced via an Authentication Policy in the Atlassian admin portal.  

Do I need a special license for this?

Yes. Atlassian Guard (formerly Atlassian Access) is required to configure and enforce SAML SSO for Atlassian Cloud.  

Can this work with dynamic IP addresses?

No. This configuration requires static IP addresses. Dynamic IPs will lead to inconsistent 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 in Conditional Access policies.  

Why should I use Report-only mode first?

Report-only mode allows you to validate policy behavior without enforcing it, helping prevent accidental lockouts across all Atlassian services.  

Do I need to exclude any accounts?

Yes. Always exclude a break-glass (emergency) admin account and any service or automation accounts that authenticate from dynamic IPs.  

Will this immediately sign users out of Jira or other Atlassian apps?

No. Existing sessions are not terminated immediately. The policy takes effect on the next sign-in or token refresh, typically within about one hour.  

What happens if the policy is misconfigured and enabled?

Because the policy applies to all users and all Atlassian Cloud services, a misconfiguration can lock users out of Jira, Confluence, and other tools simultaneously. Always validate in Report-only mode first.