Known Limitations
Copyright 2026 Matify. All Rights Reserved.
Access Auditor for Jira reads Jira's configuration through Atlassian's public Cloud REST API. Some things that API does not expose, and some deliberate trade-offs, are listed here so you know exactly what the audit does and does not cover. Everything below is a real boundary of the product, not a placeholder.
Site administration cannot be read directly
Jira Cloud provides no API for global permission grants. There is no endpoint that answers "which groups hold Administer Jira or site administration". We verified this against the Jira Cloud OpenAPI specification, which contains no global-permission operation at all.
Access Auditor therefore does not claim to list your site administrators. Instead it marks a group as privileged when at least one of three verifiable signals applies, and always tells you which one:
| Signal | What it means | Reliability |
|---|---|---|
| Grants product access | The group appears in a Jira application role, so membership hands out a licence | Read directly from Jira |
| Holds project administration | The group holds Administer projects in a permission scheme | Read directly from Jira |
| Matches an administrator naming convention | The group is named like an Atlassian default admin group, for example site-admins or jira-admins-yoursite | A naming heuristic |
The third signal is labelled as a heuristic everywhere it appears in the app. If you have renamed your administrator groups, Access Auditor will not recognise them by name. Add them to the audit by giving them a permission scheme grant, or review them directly in Jira's own global permissions screen.
We considered reconstructing global permissions from the Jira audit log and decided against it. Audit log retention varies by Atlassian plan, so the result would be silently incomplete on exactly the sites that most need it, and a partial list of administrators in a compliance tool invites false assurance. The app does not request the audit log scope at all.
Changes are detected by comparison, not attribution
The Changes tab tells you what changed since the previous scan. It does not tell you who changed it or exactly when, because that would require the audit log described above.
A change is therefore only visible if it existed at the time of one scan and not at the time of another. A permission that was added and removed again between two scans leaves no trace. On the default daily schedule, that window is 24 hours.
The very first scan reports no changes, because there is nothing to compare it against.
Team-managed projects are out of scope
Team-managed projects (Jira calls them "next-gen"; the API marks them simplified) control access inside the project itself rather than through a permission scheme. Their access model is not exposed the way scheme-based access is.
Access Auditor lists these projects and labels them clearly, but shows no permission matrix for them and raises no findings about them. Company-managed projects are fully covered.
Some holders can only be resolved per issue
Several Jira grant types do not resolve to a fixed set of people:
- Current assignee and Reporter depend on the individual issue.
- Project lead resolves to one person, but that person changes with the
project's configuration.
- User custom field value and Group custom field value depend on what is
in that field on each issue.
The app marks these holders as resolves per issue rather than guessing. It reports the grant so you can see it exists, and flags a sensitive permission held through a custom field as its own finding, because such a grant cannot be reviewed from configuration alone.
Shared filters and dashboards: what is visible
Filters are read with Jira's share-permission override, which is what lets the app see filters it does not own. Dashboards are read through the standard search.
If your site restricts either, the app records the capability as degraded and says so on the Overview tab rather than silently reporting fewer results. The filter's JQL body and a dashboard's gadgets are never read — only the name, the owner and the sharing.
Very large sites are collected within caps
Collection is deliberately bounded so a scan cannot run away with your site's API budget:
| What | Cap |
|---|---|
| Projects | 2,000 |
| Groups | 2,000 |
| Members read per group | 2,000 |
| Members read per scan, site-wide | 40,000 |
| Shared filters | 4,000 |
| Dashboards | 4,000 |
When a cap is reached the scan completes and is marked incomplete, and the Overview tab tells you which part was truncated. Group membership counts stay accurate even when the member list is capped, because the app records Jira's own total for the group rather than counting the rows it read.
Group membership is only read for groups that actually carry access — a group referenced by a permission grant, a project role, a shared filter or an application role. Membership of unrelated groups is deliberately not read, which keeps both the scan and your data footprint smaller.
Issue security is checked where it matters
The "project has no issue security scheme" finding is only evaluated for projects that are broadly readable, because that is the only situation in which the absence of issue security is a risk. Reading issue security for every project would cost one extra API call per project for a result no rule would use.
What the app never reads
Issue content. Attachments. Comments. Worklogs. Email addresses. Avatars. Filter JQL. Dashboard gadgets. User profile attributes beyond display name, account type and whether the account is active.
What the app never does
Write to Jira. Change any configuration. Delete anything. Send data outside Atlassian. The app holds twenty read-only Jira scopes, app storage, and the report:personal-data scope Atlassian requires of any app that stores account identifiers — and no write, administration or egress scope of any kind.
Permissions required to use it
The Jira Administer Jira global permission. Every screen verifies this with your own credentials on every request, so a user without it sees an explanation rather than data.
Scheduling
The scan schedule is daily, weekly or manual. The platform trigger fires once a day; a weekly setting simply skips days. You cannot pick the hour it runs.
Questions about any of these? mira.maty@web.de
Jira Service Management
Service Management projects are audited like any other company-managed project, because they use the same Jira permission schemes, project roles and group grants. The app also recognises the holder type that only exists there: a grant to sd.customer.portal.only is reported as "Service project customers (portal only)", and portal customer accounts are excluded from the "every logged-in user" analysis, because a portal customer is not a member of staff and counting them would inflate that finding.
What is not audited is everything Service Management layers on top of the permission scheme:
- Customer organisations and their membership
- Which individual portal customers can reach which portal
- Request type level permissions
- Approver configuration
- Queue visibility
So a Service Management team gets a complete picture of who can administer, browse and work on their projects, and no picture at all of their portal customers. If an access review needs the second, it has to come from elsewhere.