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

[Jonas Nilsson]

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.