How are you explaining why Atlassian seats are still billable before cleanup?

[Jonas Nilsson Unitlane]

One user-governance problem I keep seeing in Atlassian Cloud is that finding inactive users is only half the job.

The harder part is explaining why the seat is still billable before anyone removes access.

Atlassian's own documentation says users are automatically placed in default groups when you give them access to a cloud app, and that default-group setup can lead to unintended license consumption if it is configured badly:
https://support.atlassian.com/user-management/docs/default-groups-and-permissions/

Their app-access documentation also makes the same mechanism explicit: when you give app access to a user, Atlassian adds them to the default group for that app:
https://support.atlassian.com/user-management/docs/update-product-access-settings/

That is where cleanup starts to get awkward. Between default groups, synced groups, unmanaged accounts, and service accounts, the review usually becomes manual.

Disclosure: I built License Guard for this workflow. It helps review why access is still billable, which supported products are affected, and which accounts should be held back before cleanup. It also keeps proof tied to the review and approval cycle. Current cleanup is group-removal based after approval; it does not delete Atlassian accounts.

I am curious how others are handling this today.

Are you exporting users manually, scripting it, or using a tool?

And when cleanup gets risky in your environment, what is usually the hardest part: default groups, SCIM-synced groups, unmanaged accounts, or service accounts?

[mir_contact_stable_point_io]

Great question — this is exactly where most organizations struggle.

In our experience, identifying inactive users is the easy part. The real challenge is explaining why they are still billable, and that almost always comes down to how access is granted and maintained.

Here’s how we usually break it down:

1. Default groups (most common case)
As Atlassian mentions, users are automatically added to default product groups when access is granted.
Even if they are inactive, as long as they remain in a licensed group, they are billable.
👉 This is often invisible to teams because nobody explicitly added them later.

2. SCIM / synced groups (hardest to clean safely)
When groups are managed via an IdP (Okta, Azure AD, etc.), removing access directly in Atlassian is not enough — it will be re-synced.
👉 Cleanup must happen at the identity provider level, which adds coordination and risk.

3. Service accounts & technical users
These accounts are often intentionally kept active but poorly documented.
👉 The difficulty here is validating whether they are still needed before removing licenses.

4. Unmanaged accounts
These fall outside centralized governance and are easy to miss in audits.
👉 They often require manual review and ownership clarification.

---

What makes cleanup “risky” in practice?
Not the removal itself — but the lack of visibility and traceability:

• Who granted access originally?

• Is the access still required for a workflow or integration?

• Will SCIM overwrite our changes?

---

What has worked well for us:

• Start with group-based analysis, not just user activity

• Map each billable user → product → group → source (default vs SCIM vs manual)

• Separate “removable” vs “needs validation” accounts

• Add an approval step before removal (especially for synced/service accounts)

---

So to your question:
👉 The hardest part is usually SCIM-synced groups, because they require cross-system coordination.
👉 But the most common root cause remains default groups, due to how silently they assign licenses.

Curious to see how others handle the SCIM vs default group trade-off as well.

[Artem Taranenko]

Hi all, please help me understand the issue. I see it discussed, but I think I might be missing something:

I see folks talk about this problem of licensing inactive users, but to me it seems this is more of an IT Operations gap rather than a Jira issue.

If an org uses an IAM, leavers should be taken out of all security groups via that IAM's workflow based on whatever the departure trigger is. If that's not happening, that isn't only a Jira issue but a security concern for that org in general. Leavers should be reverted to some sort of zero-access state. 

if an IAM is in place, it seems unmanaged accounts shouldn't exist for security reasons.

Service accounts seem like the only scenario because it isn't a real user, therefore IAM rules might not apply.

Genuinely curious.

[mir_contact_stable_point_io]

@Artem Taranenko  

I think you’re not missing anything technically — in a mature IAM setup, leavers should absolutely be deprovisioned automatically and removed from access groups. From a security perspective, I completely agree.

The reason this becomes a Jira/Atlassian licensing discussion is that many orgs are not operating in that “fully governed IAM” state in reality.

A few common cases:

• Jira is connected to an IdP, but group cleanup is incomplete or delayed

• SCIM provisioning exists, but deactivation doesn’t always remove product access groups

• Contractors/vendors are managed outside the HR lifecycle

• M&A / legacy environments leave orphaned accounts behind

• Admins grant direct product access outside IAM governance

• Shared/service/automation accounts remain licensed indefinitely

So the “inactive licensed users” problem is often really an identity governance maturity problem — not specifically a Jira flaw.

That said, Jira/Atlassian still gets discussed because:

1. Licensing cost is directly tied to active product access

2. The platform exposes the symptoms very visibly

3. Atlassian orgs often have decentralized admin models, so governance drift is common

In highly mature environments, this issue should mostly disappear except for edge cases like service accounts or intentionally retained dormant users.

So I’d say your point is valid — people are often treating an IAM/process issue as a Jira licensing issue — but in practice many organizations haven’t fully solved identity lifecycle management yet.