A colleague left in September. IT deactivated the account the same afternoon, so the login stopped working. In December an auditor reads your Jira permission data and finds that name in the Administrators role of four spaces. Nobody could have used that access, yet it is a finding, and you have to explain it.
I'm Marcin, founder of Radrly. We build AccessRadar, an access review app for Jira Cloud. This article is mostly the native offboarding check I would run by hand. The app comes at the end.
Why deactivation leaves traces
Deactivating a managed account blocks sign in, but it does not remove the account from groups. Atlassian tracks this as AX-163: "Currently deactivating a user does not remove the user from any groups." Suspending a user's access works the same way: when access is restored, the person gets their roles and group memberships back. Only removing the user from the organization clears group memberships, as described in Remove or suspend a user.
Space roles are separate again. A deactivated person who was added to a role directly stays in that role until someone takes them out.
The checklist
1. List inactive accounts and their groups. In Atlassian Administration go to Directory > Users, open the ••• menu and choose Export users. Pick All users (active, suspended and deactivated) and tick Group membership. The download link arrives by email. Filter the CSV to accounts that are not active. Steps are in Export users from a site.
2. Remove the group memberships. Do it under Directory > Groups. If your groups are synced from an identity provider, change the membership there, or the next sync will put it back.
3. Check space roles. The export has no space role data. Settings > System > Space roles > View Usage shows which schemes use each role, not who is in it. Membership lives in each space under Space settings > People, so this step is one page per space.
4. Check direct user grants. Open Settings > Work items > Permission schemes and look for single user grants that name the person. They survive group cleanup.
5. Spot check what matters most. For your most sensitive spaces, use the Permission helper with the person and a work item from that space. It answers yes or no for one permission at a time.
6. Write down what you removed and when. Next quarter, that note is your evidence.
Where the native check stops
- The user export covers groups and app access. It does not cover space roles or direct grants.
- Step 3 grows with every space you add.
- Nothing tells you when a new inactive account appears with access. You find out at the next manual pass.
The same check with AccessRadar
AccessRadar reads permission schemes, roles and groups into snapshots: weekly on a schedule, or on demand with a manual snapshot. It resolves who can do what and through which path: group, space role, application role or scheme grant.
AccessRadar applies a risk rule called Inactive users with access: deactivated accounts that still hold space permissions. It is one of eleven rules in Standard, rated High. Each row shows the space, the permissions and the role and scheme that grant them.
Inactive accounts that still hold space permissions, with the role and scheme behind each grant.
Select a name to open the person view. It lists the person's groups and every space where they hold a permission, with the path for each one. Jira cannot list global permission holders, so the person view checks global permissions live for that one person.
Person view: groups, spaces and the path that grants each permission.
AccessRadar only reads. It never changes a grant, so you still remove the role or group membership in Jira yourself. The next snapshot shows whether it is gone, and comparing two snapshots lists removed members and role changes.
What each edition adds:
- Standard: the risk rules, the person, space and group views with the "why" path, snapshot comparison, and access reviews with Keep, Revoke or Exception, exported as CSV or PDF.
- Advanced: daily or custom snapshot schedules, an in-app alert when an inactive account with access appears, and remediation checks: each Revoke in a signed review is checked at the next snapshot and marked Verified, Still present or Inconclusive.
Two honest limits. Coverage is shown on every snapshot: work item security levels are not evaluated, and the global admin view is partial. Alerts and reminders stay inside the app, with no email, Slack or webhooks.
Listing: AccessRadar on the Atlassian Marketplace.
How does your offboarding handle space roles today: do you rely on identity provider groups alone, or does someone do a pass through every space?
