Okta or Atlassian Guard for user provisioning: Okta decides, Guard enforces

Okta should handle user provisioning and deprovisioning for Atlassian, because Okta is the source of truth for who works for you and which groups they belong to. Atlassian Guard is the Atlassian side of that same connection: it receives what Okta sends over SCIM and adds controls only Atlassian can apply, so the answer is both, each with its own job.

Teams often frame the two as alternatives, and that frame leads to the wrong plan. Okta decides. Guard receives, enforces, and records.

Each side has one job

Okta answers who someone is, for every application you run. It is the directory of record and the place a joiner, mover, or leaver event begins.

Atlassian Guard answers what must be true inside your Atlassian organization. SCIM user provisioning is a Guard Standard feature, so Guard is not a rival to Okta here. It is the receiving end. Guard Standard also covers SAML single sign-on, multiple authentication policies, user API token management, external user security policies, data security policies, and the organization audit log for admin activity. Guard Premium adds data classification, threat detection, sensitive data detection, audit logs for user-created activity in Jira, Jira Service Management, and Confluence, and SIEM integrations.

What SCIM from Okta does in Atlassian

SCIM is the standard Okta uses to send user and group changes to Atlassian. With it turned on, Okta can:

• Create or link accounts. If no Atlassian account exists for the email address, one is created. If one exists, it is linked.
• Update profile details such as display name, email, job title, department, time zone, and preferred language.
• Deactivate accounts for users from your verified domains.
• Push groups that you map to app access in Atlassian. Group syncing works for Jira and Confluence today, and not yet for Bitbucket.

Groups pushed from Okta arrive read-only in your Atlassian directory, and you edit them only in Okta. Membership lives in one place, and permission schemes and space roles in Jira, and space permissions in Confluence, point at those groups instead of at individuals.

What has to be in place first

• Atlassian Guard Standard, or an Enterprise plan. SAML single sign-on and SCIM provisioning both need Guard Standard, and the Atlassian Cloud Enterprise plan includes it at no additional cost. Guard Standard connects one identity provider. An Enterprise plan can connect several.
• Okta Lifecycle Management. Atlassian's Okta guide asks for the user provisioning functionality on your Okta account, which is Okta Lifecycle Management.
• Verified domains. Verify each email domain with a DNS TXT record or an HTML file on your website. DNS changes can take up to 72 hours. After you verify a domain, you claim its accounts, and claimed accounts become managed accounts you can edit, deactivate, and apply policies to.
• An identity provider directory in Atlassian Administration, with your verified domains linked to it.
• The right Okta app. Use the Atlassian Cloud app in the Okta Integration Network, which Atlassian builds and maintains. Okta's older Jira Cloud and Confluence Cloud apps do not push deactivations.
• A backup organization admin whose email is not on a domain you verify, created before you configure SAML, so a bad setting cannot lock everyone out.
• One email attribute. Map the same attribute to the primary email for SCIM and to the application username for SAML, as Atlassian's Okta guide describes.

What happens when someone leaves

When you unassign a person from the Atlassian Cloud app in Okta, or deactivate them in Okta, Okta sends the deactivation (if deprovisioning is turned on in the app's provisioning settings) and Atlassian deactivates their managed account. A deactivated account loses access to every Atlassian cloud app, because each person has one Atlassian account that carries their access across all of them. Deleting the user in Okta also deactivates the Atlassian account. Reactivate the person in Okta and the account comes back, as long as they are still assigned to the app through a group.

Test it the plain way. Pick one account, unassign it in Okta, and count how many places you have to visit before the access is gone. The answer should be zero. Run the same test in reverse: a new starter in the right Okta group should reach the right Jira and Confluence spaces on day one, without a ticket.

Service accounts sit outside this flow. Atlassian does not let you provision service accounts from an identity provider, so each one needs a named owner whom Okta does manage. Your leaver process should reassign what a person owns before Okta deactivates them.

Group push and name clashes

Pushing a group does not create accounts on its own. Members must also be assigned to the Atlassian Cloud app in Okta, and Okta does not support using the same group for app assignment and Group Push, so use one group to assign the app and a separate group to push. Assign by group, not by person: Okta notes that a person assigned on their own gets no app access until they join a group.

Name clashes are the usual surprise, especially after a migration, when groups came across with the Migration Assistants and SCIM was turned on later. If an Okta group has the same name as an existing Atlassian group, Atlassian flags the conflict. You can review and accept or reject the membership changes, change the Okta group's members, or rename the Okta group to keep the Atlassian one. Once the sync runs, the Okta group overwrites the Atlassian group, so some people can lose or gain app access. Compare the two lists before the first push. Two more rules: default groups cannot be managed through SCIM, and if you delete a group in Okta that granted access, re-syncing it or recreating a group with the same name does not bring that access back.

The SCIM API key expires

Atlassian SCIM API keys now expire one year after you create or regenerate them. When the key expires, provisioning and deprovisioning between Okta and Atlassian stop, so a person you deactivate in Okta stays active in Atlassian until someone replaces the key. Regenerating a key stops the existing one, so paste the new key into Okta in the same sitting. Atlassian Administration shows the expiration date in the provisioning section of your identity provider directory. Put that date on a shared calendar and in your admin runbook.

External users

An external user is someone whose Atlassian account your organization does not manage, such as a contractor on their own company's domain. When you deactivate an external user in Okta, Atlassian removes them from the SCIM-provisioned groups, so they can lose the app access those groups granted, but they keep site access until an admin removes them from the site. Guard Standard's external user security policies cover the rest: you can require single sign-on, set session expiration, and block user API tokens for external users.

The decision map

Decision	Okta	Atlassian Guard
Who your people and groups are	Decides, as the directory of record	Receives them; synced groups are read-only
Creating and deactivating Atlassian accounts	Sends create, update, and deactivate over SCIM	Applies them to managed accounts
Sign-in and multi-factor	Authenticates people under its sign-in policies	Authentication policies enforce single sign-on for managed accounts
Which Atlassian apps a person can use	Group membership decides	Groups are mapped to app access
External users	Syncs them only if you assign them, but cannot deactivate their accounts	External user security policies: single sign-on, session expiration, API token blocking
User API tokens	Not its job	Token management, and expiry set through authentication policies
Data export and sensitive content	Not its job	Data security policies; data classification and sensitive data detection in Guard Premium
What happened inside Atlassian	Logs provisioning events	Organization audit log; user-created activity with Guard Premium or Enterprise
Risky activity in Jira and Confluence	Sees sign-in, not activity inside the apps	Threat detection in Guard Premium
Service accounts and agents	Holds the human owner	Service accounts live in Atlassian Administration; Guard Standard allows up to 250

Three places the boundary goes wrong

Treating Guard as the directory. Teams manage access inside Atlassian because it is closer to the work and quicker to change. It is quicker, and it splits the leaver process into two halves that can disagree. Once SCIM is on, push groups from Okta and stop creating local groups to grant access.

Treating Okta as the whole job. Single sign-on works, provisioning works, and the team calls identity done. Okta does not see what happens after sign-in: a page export, an admin change, sensitive data added to a page. Guard's data security policies and audit log, plus threat detection and content scanning in Guard Premium, are built for that.

Leaving non-human identities in neither. Service accounts, tokens, and agents get created wherever it was convenient. Atlassian service accounts cannot be provisioned from an identity provider, and Rovo agents use an Atlassian account, either their own or the account of the person using them. Each needs a named owner whom Okta manages. The scale is real. The Palo Alto Networks 2026 Identity Security Landscape (2,930 cybersecurity decision makers) found an average of 109 machine identities for every human, including 79 AI agent identities per human. The 2026 CISO AI Risk Report from Cybersecurity Insiders and Saviynt (235 large-enterprise security leaders) found that 92 percent of organizations lack full visibility into AI identities. Our guide to service accounts and agent identities covers the ownership record.

Where to start

Okta in place, no Guard. Okta cannot provision Atlassian yet. Add Guard Standard or confirm your Enterprise plan, verify your domains and claim company accounts so they become managed accounts, and create the identity provider directory.

Guard in place, no Okta provisioning. Atlassian is well governed, and joiners and leavers are still manual. That is how dormant accounts build up. Turn on SCIM from Okta and run the leaver test.

Both in place and disagreeing. Fix the join before adding anything. Decide that group membership starts in Okta, move Atlassian-only groups into that model, settle name clashes, and then stop editing access locally.

The fastest route is our Okta SSO and SCIM quick start: a fixed-scope setup, about three weeks, that confirms your Guard tier, verifies domains, connects SAML and SCIM through Okta's Atlassian Cloud app, maps pushed groups to app access, and writes down a deprovisioning test for your auditor. To see where you stand first, our free Atlassian identity check reviews expiring keys and tokens, single sign-on gaps, external users, and unowned service accounts, and we change nothing. For a rollout told end to end, read how SSO and user provisioning closed an Atlassian access gap. For external users, service accounts, and API tokens, see our full Okta SSO and SCIM service.