Every Atlassian Cloud organization has two types of user accounts: managed and unmanaged. Managed accounts are under your verified domain -- their email matches your company domain, and you have full administrative control. Unmanaged accounts are everything else: personal Gmail addresses, contractor emails, partner accounts, and anyone else who was invited to your Jira or Confluence instance with an email you do not control.
Most Atlassian admins focus their user management efforts on managed accounts. That makes sense -- they are the accounts you can see in your organization directory, the ones your SCIM provisioning handles, and the ones your IT policies cover. But unmanaged accounts are consuming the same licenses, generating the same per-user costs, and they are largely invisible to the tools you are already using.
Why Unmanaged Accounts Are Easy to Miss
When you go to admin.atlassian.com and look at your organization's user directory, you see managed accounts -- users whose email domain you have verified. Unmanaged accounts do not appear there. They exist at the site level (your-company.atlassian.net), not the organization level.
This means:
- SCIM does not touch them. Your identity provider (Okta, Azure AD, etc.) provisions and deprovisions managed accounts. Unmanaged accounts were never provisioned through your IdP, so they cannot be deprovisioned through it either.
- Organization-level API calls miss them. The Admin API that most user management scripts use operates on managed accounts. Unmanaged accounts require site-level API calls with different authentication.
- Offboarding processes skip them. When a contractor finishes their engagement and their manager forgets to request access removal, that contractor's personal email account stays active in Jira indefinitely. There is no automated trigger to clean it up.
How Unmanaged Accounts Accumulate
The most common sources of unmanaged accounts are:
- External contractors invited directly to Jira projects with their personal or agency email
- Cross-company collaborators added to Confluence spaces for joint projects
- Early employees who signed up with personal email before the company verified its domain
- Service accounts or bot accounts created with non-domain emails
- Acquired company employees whose email domain has not been verified yet
In organizations that have been using Atlassian products for several years, unmanaged accounts can represent 5-15% of total licensed users. For a 200-user Jira instance, that could be 10-30 accounts consuming licenses without appearing in your standard admin reports.
The Cost Impact
Each unmanaged account with product access consumes a license seat just like a managed account. Under Atlassian's pricing model, there is no distinction -- a user is a user regardless of whether their account is managed or unmanaged.
With Maximum Quantity Billing (MQB) now in effect for monthly subscriptions, every unmanaged account that sits inactive counts toward your peak user count for the month. You cannot get a mid-month credit for removing them.
The security dimension is equally important. Unmanaged accounts are outside your organization's password policies, MFA requirements, and session controls. An inactive unmanaged account with access to sensitive Jira projects is a compliance risk that your standard identity governance tools cannot address.
How to Find Unmanaged Accounts
Method 1: Atlassian Admin Console
Go to admin.atlassian.com and navigate to your organization's Directory. Look for a section called "Unmanaged accounts" or check the accounts list and filter for accounts outside your verified domain. The visibility of unmanaged accounts in the admin console has improved over time, but it still requires manual review.
Method 2: Site-Level User Export
Export the user list from your Jira or Confluence site (not the organization). Compare the email domains against your verified domains. Any email that does not match is an unmanaged account. This is the most reliable method for a one-time audit.
Method 3: REST API
Use the Jira REST API (site-level, with basic auth using an admin email and API token) to query all users. Cross-reference with the organization-level managed accounts list. The difference is your unmanaged account population.
What You Can Do About Them
Remove Product Access
The safest approach is to remove unmanaged accounts from product-specific groups (e.g., jira-software-users, confluence-users). This revokes their license without deleting their account or their historical contributions. If they need access again, they can be re-added.
Claim the Domain
If unmanaged accounts use a domain your organization owns (common with acquired companies or subsidiaries), you can verify that domain in admin.atlassian.com. This converts those unmanaged accounts to managed accounts, bringing them under your organization's policies and SCIM provisioning.
Automate Ongoing Cleanup
A one-time audit cleans up the existing backlog, but unmanaged accounts will continue to accumulate as new contractors and collaborators are invited. Ongoing automation that includes unmanaged accounts in its inactivity monitoring ensures the problem does not rebuild itself.
Full disclosure: I work on User Management Automation for Jira and Confluence, which handles both managed and unmanaged accounts in a single interface. This is one of the key differentiators we built specifically because most other tools only operate on managed accounts through the organization API. There are other approaches (custom scripting with site-level API calls, or combining multiple tools), but the important thing is to include unmanaged accounts in whatever process you use.
Key Takeaways
- Unmanaged accounts consume licenses at the same rate as managed accounts
- They are invisible to SCIM, organization-level APIs, and most standard admin tools
- They typically represent 5-15% of total users in mature Atlassian deployments
- They are a security and compliance blind spot outside your identity governance
- Finding them requires site-level queries, not organization-level queries
- Removing product group access is the safest cleanup method
- Any automation or scripting solution should explicitly handle unmanaged accounts, not just managed ones
If you have not audited your unmanaged accounts recently, it is worth the 30 minutes to export your site-level user list and check. The cost savings and security improvement are usually immediate.