ZTCA Configuration: Restrict Atlassian Cloud sign-ins to trusted IPs using Entra Conditional Access

As part of a ThreatLocker ZTCA deployment, this article outlines how to configure Entra Conditional Access to restrict Atlassian Cloud sign-ins to trusted IP addresses.

Jira is widely used by organizations to plan, organize, and manage projects across teams. It plays a central role in IT operations, development workflows, and service management, and often contains sensitive business data, internal processes, and operational context.

Because of this, unauthorized access to Atlassian Cloud environments can expose critical systems and intellectual property.

This approach is commonly used to ensure that Jira and other Atlassian Cloud applications can only be accessed from approved networks, reducing the risk of unauthorized access from compromised credentials or untrusted environments.

Why you should restrict access to Jira to specific IP addresses

Restricting Atlassian Cloud access by IP address is an important control when protecting development, operational, 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 accessed from controlled environments
• Reduce risk of data exposure from unmanaged or personal devices
• Limit access to corporate networks or approved VPN connections
• Add an additional layer of protection beyond passwords and MFA
• Support compliance and regulatory requirements

While IP based restrictions significantly reduce risk, they should always be layered with other controls such as MFA, least privilege access, and Zero Trust enforcement.

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

The approach uses two components:

1. Named Locations: A list of trusted IP addresses or CIDR ranges defined in Microsoft Entra ID
2. Conditional Access policy: A policy that blocks Atlassian Cloud sign-ins from any IP not included in the trusted list

Important limitations and considerations (read first)

Before implementing this configuration, it is critical to understand how enforcement works in Atlassian Cloud.

SSO enforcement is required

Atlassian Cloud supports both:

• Direct login using Atlassian account credentials
• SAML SSO via an identity provider (Entra ID)

If SSO is not enforced, users can bypass Entra ID entirely.

IMPORTANT: SSO enforcement must be configured via an Authentication Policy in the Atlassian admin portal (admin.atlassian.com).

Without enforcement, Conditional Access policies will not apply.

Conditional Access only applies to SSO-based sign-ins

Conditional Access policies are evaluated only when authentication flows through Entra ID.

This means:

Covered: Interactive user sign-ins via SAML SSO

Not covered:

• API tokens
• Personal access tokens
• Integrations or automation using Atlassian APIs
• Existing sessions until token refresh

For complete coverage, additional controls must be implemented alongside Conditional Access.

Atlassian Cloud is a single application in Entra ID

The enterprise application is named: Atlassian Cloud

A Conditional Access policy targeting this app applies to:

• Jira Software
• Jira Service Management
• Confluence
• Trello

If you need to scope access more granularly, use user or group assignments rather than application selection.

Native Atlassian controls should be used alongside Conditional Access

Atlassian provides additional controls that complement this configuration:

• Authentication Policies (SSO enforcement)
• Session management
• API token governance
• Integration control
  ‍

These should be used to ensure that non-SSO access paths are also protected.

Step 1: Create a Named Location

1. Sign in to the Microsoft Entra admin center
2. Navigate to: Protection > Conditional Access > Named locations
3. Select + IP ranges location
4. Name the location (e.g., Trusted - Corporate Office)
5. Enable Mark as trusted location
6. Add IP(s) or CIDR ranges:
7. Click Create

Step 2: Create the Conditional Access policy

Go to: Protection > Conditional Access > Policies

1. Select + New policy
2. Name it: Block Atlassian Cloud - Outside Trusted IPs
3. Assignments: Users
4. Include: All users
5. Exclude:
   
   • Break-glass account
   • Automation / service accounts

Assignments: Target Resources

Select: Cloud apps → Atlassian Cloud

Conditions: Locations

• Configure = Yes
• Include = Any location
• Exclude = Trusted Named Locations

Access Controls: Grant

Select Block access

Enable policy

1. Set to Report-only
2. Click Create

Always validate before enabling to prevent lockouts across all Atlassian apps

Step 3: Validate the policy

1. Navigate to Identity → Monitoring & health → Sign-in logs
2. Filter for Atlassian Cloud
3. Confirm:
   
   • Trusted IP →  Would succeed
   • Untrusted IP →  Would fail

Step 4: Enable the policy

1. Open the policy
2. Set Enable policy = On
3. Save

All future sign-ins from untrusted IPs will now be blocked before authentication is completed.

Additional recommendations for full Zero Trust coverage

To achieve complete protection:

• Enforce SSO for all users
• Review and restrict API tokens regularly
• Monitor third-party integrations
• Limit session lifetimes where possible
• Combine with:
  
  • MFA enforcement
  • Least privilege access
  • ThreatLocker ZTCA network controls

Summary

This configuration provides identity-layer IP restriction for Atlassian Cloud access.

However, complete enforcement requires multiple layers:

• Entra Conditional Access
• Controls where SSO-based sign-ins originate
• Atlassian Authentication Policies
• Ensure all users are forced through SSO
• Atlassian native controls
• Protect API access, tokens, and integrations

FAQs

Does this block all access to Atlassian Cloud from untrusted IPs?

No. It blocks SAML-based authentication. Other access methods (API tokens, sessions) may still function unless additional controls are applied.

What happens if SSO is not enforced?

Users can bypass Entra ID and authenticate directly with Atlassian credentials.

Can attackers bypass IP restrictions?

Yes. Through:  

• VPN/proxy usage
• Compromised sessions
• API tokens

This is why IP restrictions must be combined with Zero Trust controls.

Can I restrict only Jira?

No. Atlassian Cloud is a single application. Use user/group scoping instead.