Atlassian Guard and Okta Setup: Provisioning, SSO, SCIM, and Access Reviews

How to connect Okta to Atlassian Guard for SSO and SCIM provisioning, avoid common mistakes, and run access reviews auditors accept.

By Adam Madoukh, Founder and CEO

An Atlassian Guard Okta integration gives your identity team one place to decide who can use Jira, Confluence, and the rest of Atlassian Cloud. Okta handles sign-in and pushes accounts to Atlassian, while Guard enforces the rules on the Atlassian side. The setup is not hard, but the order of steps and a few small settings decide whether the rollout is quiet or painful. This guide walks through both, plus the access reviews auditors ask for.

How the Atlassian Guard Okta integration works

To begin with, Atlassian Guard, formerly Atlassian Access, is the subscription that unlocks enterprise identity controls in Atlassian Cloud. Guard Standard includes enforced single sign-on, SCIM automated user provisioning, API token controls, and the organization audit log. Guard Premium adds data classification, anomalous activity detection, content scanning, and SIEM integrations.

On the other side, Okta uses the Atlassian Cloud app from the Okta Integration Network. That one app handles two jobs. First, SAML single sign-on decides how people authenticate. Second, SCIM provisioning decides who has an account and which groups they belong to.

Job	Okta side	Atlassian side
Sign-in	Atlassian Cloud app, Sign On tab	Identity provider directory, SAML settings, authentication policy
Accounts	Provisioning tab, To App settings, Assignments tab	SCIM base URL and API key
Groups	Push Groups tab	Synced groups, then app access on each site
Reviews	Access certification campaigns	Organization audit log as supporting evidence

Before you start

Subscription. Atlassian Guard Standard on your Atlassian Cloud organization.
Admin rights. Organization admin in Atlassian, plus admin on at least one Jira or Confluence site.
Verified domains. Verify each email domain, then link it to an identity provider directory. Verified domains become managed by your organization.
A break-glass account. Create a backup Atlassian account with site admin and organization admin rights. Atlassian specifies that its email address must not use a domain you verify, so a SAML mistake cannot lock you out.
Test identities. Create test users and a pilot group in Okta before touching production users.

Step-by-step Atlassian Guard Okta setup

We recommend single sign-on first and provisioning second. That way, each change can be tested on its own.

1. Start SAML in Atlassian. In Atlassian Administration, open Identity providers, choose Okta, and start the SAML setup wizard.
2. Exchange values. Enter the Okta issuer, sign-on URL, and signing certificate in Atlassian. Then copy the Atlassian unique ID and your site URLs into the Okta Sign On tab.
3. Test with a policy. Create a test authentication policy, enable single sign-on for it, and add only test users. Once sign-in works, move real users to an enforced policy in waves.
4. Connect provisioning. In Atlassian, select Set up user provisioning and copy the SCIM base URL and API key. Store both securely, because Atlassian does not show them again.
5. Enable the API integration in Okta. On the Provisioning tab, paste the values and test the credentials. Then, under To App, turn on create users, update user attributes, and deactivate users.
6. Push groups and assign users. Push the groups you need, and assign the same groups on the Assignments tab. Pushing a group only creates it in Atlassian; it does not sync any users.
7. Grant app access. Synced groups do not grant access on their own. Finally, add each group to app access on the Jira or Confluence site.

Common Okta mistakes and how to avoid them

Mismatched email attributes. Atlassian identifies users by email. Therefore, if the SAML and SCIM email values differ, users can end up with duplicate accounts. Make the Okta primary email mapping match the application username format, and set the username to update on create and update.
Pushing without assigning. Admins often push a group and expect users to appear. In reality, only users assigned to the Atlassian Cloud app are provisioned.
Relying on just-in-time provisioning. Atlassian supports JIT through SAML, but JIT only creates accounts at first sign-in. SCIM is what deactivates leavers, so treat it as the system of record.
Bitbucket and Trello expectations. Group sync works for Jira and Confluence. However, it is not yet available for Bitbucket or Trello, so plan access for those apps separately.
Expired keys. SCIM API keys created or regenerated since early January 2025 expire after one year. Put the renewal date on the team calendar, since sync stops when the key expires.

Access reviews and deprovisioning for regulated teams

For financial services, healthcare, and government teams, the control that matters most is removal. With deactivate users turned on, deactivating someone in Okta or removing them from the assigned group deactivates their Atlassian account. As a result, an exit processed in HR reaches Jira and Confluence without a separate ticket.

Next, access reviews in your Atlassian Guard Okta setup prove that the remaining access is still needed. Okta access certification campaigns can review the users who hold access to chosen apps and groups. Reviewers approve, revoke, or reassign each item, and Okta can remediate revoked access automatically based on campaign settings. Access certifications sit under Okta Identity Governance, so confirm your Okta subscription includes them.

In practice, one rule keeps the evidence clean: grant Atlassian access by Okta group, never by hand in Atlassian admin. The same pattern applies to Microsoft shops; our Atlassian Guard and Entra ID guide covers that version.

Frequently asked questions

Do we need Atlassian Guard to connect Okta to Atlassian Cloud?

Yes. Enforced SAML single sign-on and SCIM provisioning for Atlassian Cloud require Atlassian Guard Standard.

Can Okta and Entra ID both manage the same Atlassian organization?

Yes. An Atlassian organization can have more than one identity provider directory. Each verified domain links to one directory at a time, which decides which provider updates those accounts.

What happens if SAML is misconfigured?

In that case, users on verified domains may be unable to sign in. That is why Atlassian asks for a backup admin account on an unverified domain and a test policy before enforcement.

How VTPMO can help

Our Atlassian Certified Professionals plan and run identity integrations for regulated teams in financial services, government, and healthcare. We set up Okta and Atlassian Guard in a test-first sequence and document the evidence your auditors expect. See our Atlassian services and DevSecOps services, or contact us to plan your identity rollout.

Sources

We use your email only to send VTPMO Insights updates, and you can ask to be removed at any time. See our Privacy Policy.