- Home
- AccessWarden - Project Access, Audits & Governance for Jira — Setup Guide
AccessWarden - Project Access, Audits & Governance for Jira — Setup Guide
AccessWarden helps answer three practical questions across your Jira Cloud environment:
- Who has access to what across your Jira projects?
- Is that access still appropriate, or has it become a governance risk?
- What should you do next, and how can you show evidence of that action?
Thank you for installing AccessWarden for Jira from the Atlassian Marketplace. This guide walks Jira administrators through setup, first scan, and the key areas of the app so you can start monitoring access risk quickly and confidently.
Try it for free
Before you begin
| Requirement | Details |
|---|---|
| Your Jira role | You must be a Jira Administrator to install and use AccessWarden |
| Jira plan | Works on Jira Cloud |
| Jira Service Management | Optional. Needed for Login Activity (T2) and organisation-based checks |
Important: AccessWarden is intended for Jira Cloud administration and governance workflows. Some advanced signals, such as login activity and organisation-aware checks, depend on Atlassian organisation capabilities and optional JSM-related context.
Run your first scan
Before scanning, the Overview page walks you through a quick one-time setup:
- Configure a policy — Each recommended policy card has a Configure button. Click it, review the thresholds, and save. The policy is created in a paused state.
- Enable it — Click Enable on the card. Once at least one policy is active, the Run First Scan button unlocks.
- Run the scan — Click Run First Scan (or Run Scan in the top-right corner on subsequent visits).
During the scan, AccessWarden reads your Jira site structure and governance signals, including projects, roles, groups, users, and recent activity. When the scan completes, you will see:
- A count of findings detected
- A breakdown of High, Medium, and Low risk findings
- The number of enabled policies
- The number of projects scanned
- Last scan date and time
Your first scan establishes the baseline posture of your Jira site. From there, the rest of the app helps you review, explain, and act on what was found.
Overview page
The Overview page acts as the main dashboard for the app. It gives you a quick posture snapshot and highlights where to begin.
- Recommended policies you can enable quickly
- Open findings alert when risks need attention
- Summary counters for Findings, Policies, Users, and Projects
| Policy | What it means |
|---|---|
| Dormant Project Access | Active and already included in scans |
| Inactive Account Cleanup | Needs configuration before it runs |
| External User Access | Needs configuration before it runs |
| Too Many Admins | Active and already included in scans |
Policies
The Policies section is where you define what AccessWarden should look for. Each policy represents a governance rule. You can enable, pause, or configure policies based on your organisation's standards.
A policy is a practical rule such as "flag dormant project access," "identify inactive accounts with roles," or "warn when admin access is over-assigned."
Dormant Project Access
What it finds: Users who still have a project role but have not shown activity in that specific project for a long time.
Why it matters: Access often remains after team changes, role changes, or project handoffs.
- Click Configure for Dormant Project Access.
- Set the inactivity threshold in days.
- Save the policy.
Once saved, the policy runs in future scans and flags dormant project-specific access.
Inactive Account Cleanup
What it finds: Jira accounts that are deactivated or have had no activity for an extended period but still hold project roles.
- Click Configure for Inactive Account Cleanup.
- Set the inactivity threshold in days.
- Choose a severity level.
- Save the policy.
External User Access
What it finds: Contractors, vendors, or external users with access to projects your organisation considers sensitive or restricted.
How it works: You define project keywords and external-group keywords, and AccessWarden looks for matching exposure.
- Click Configure for External User Access.
- Add sensitive project keywords such as finance, payroll, hr, or restricted.
- Add contractor or vendor group keywords such as contractor, vendor, or partner.
- Save the policy.
You do not need exact names. Partial matching helps you start broad and refine as you learn how your Jira environment is structured.
Too Many Admins
What it finds: Projects where more people hold administrator-level access than your organisation considers acceptable.
- Click Configure for Too Many Admins.
- Set the maximum allowed number of admins per project.
- Save the policy.
Scan Findings
After a scan, open Scan Findings from the sidebar to review the risks that were detected.
Summary cards
| Card | What it means |
|---|---|
| Total pending | All findings waiting for review or action |
| High risk | Requires immediate attention |
| Medium risk | Should be reviewed soon |
| Low risk | Informational or lower urgency |
How to read the findings table
| Column | What it tells you |
|---|---|
| Risk | Severity level of the finding |
| Policy Type | The policy that produced the finding |
| User / Group | The affected identity or identities |
| Project / Scope | Where the risk exists |
| Detected | When the finding was first seen |
| Status | Whether it is pending or has a ticket created |
Filter findings
- Use the search box to look up users, projects, or groups
- Use the Governance policy filter to isolate one policy
- Use the Risk level filter for High, Medium, or Low
- Use the top tabs to switch between grouped severity views
- Use Export to download findings as CSV or JSON
Decisions
The Decisions page tracks the actions taken on findings, including suppressions and remediation tickets.
Actions on a finding
| Action | What it does |
|---|---|
| Create ticket | Creates a Jira issue for investigation or remediation |
| Suppress | Records the finding as an accepted risk until the suppression expires |
| View access path | Shows exactly how the access was granted |
Active Suppressions
| Column | What it means |
|---|---|
| Finding | The suppressed finding |
| Policy | The rule that generated it |
| Scope | The affected project and user |
| Reason | The explanation entered during suppression |
Best practice: Always set an expiry date on suppressions. Open-ended suppressions can hide real risks for too long and weaken auditability.
Remediation Tracker
| Status badge | Meaning |
|---|---|
| OPEN | The Jira remediation ticket is open |
| STUB | No Jira project has been configured for ticket creation |
| RESOLVED | The ticket has been marked resolved |
After access is removed in Jira, resolve the ticket and run a new scan to confirm the finding no longer appears.
Roles & Permissions
This area provides a searchable view of permission assignments across your Jira site, including users, groups, projects, and roles.
By Project
Helps answer: "Which roles exist on this project, and how many people are in each?"
- Check whether a project has too many admins
- See which roles have no members
- Get quick access counts
By User
Helps answer: "What does this specific person have access to?"
| Tag | Meaning |
|---|---|
| Active | User has recent Jira activity |
| Dormant Nd | User has been inactive for N days |
The Via Group column shows whether access was inherited from a group or assigned directly.
By Group
Helps answer: "Which projects does this group have access to?"
- Audit contractor or vendor groups
- Find unexpectedly broad group access
- Review role exposure before making changes
Use Export CSV to download the full permissions view for compliance or offline analysis.
Access Paths (Access Trace)
The Access Paths screen answers one of the most important governance questions: How exactly did this user get access?
- Open Scan Findings.
- Click the three-dot menu on a finding.
- Select View access path.
| Step | What it represents |
|---|---|
| 1 — User account | The user being traced |
| 2 — Group has project role | The group or direct assignment linking the user to a role |
| 3 — Project role has permission | The permission scheme tied to that role |
| 4 — Permission scheme grants | The permissions granted through the scheme |
| 5 — Project scope | The project where the access is effective |
The right-side summary typically shows access type, project, source, and current status. Path statistics help you understand whether the chain is direct, group-based, role-based, or scheme-based.
At the bottom, What Can This User Do? lists the effective permissions the user has on the project.
Jira Activity — Admin Changes
The Jira Activity section helps you understand governance changes, user behavior, and non-human access patterns.
This view shows a timeline of administrative actions in Jira, such as role assignments, workflow changes, group membership changes, and configuration updates.
| Filter | How to use it |
|---|---|
| Search box | Search by user, project, or event description |
| Event type | Filter to a specific change type |
| Project | Focus on a specific Jira project |
| Human / System / All | Separate user-driven and automated events |
| Access / Configuration / Integration / Process | Filter by governance layer |
| Colour | Category | Examples |
|---|---|---|
| Blue | Access | Role assigned, user created, group membership added |
| Purple | Configuration | Custom field changed, screen modified |
| Orange | Process | Workflow updated, transition changed |
Use Sync to refresh the latest audit records immediately. Export CSV when you need evidence for reviews or compliance reporting.
User Activity
This view shows how active Jira users are through actions such as comments, status updates, worklogs, and issue changes.
- Search for a user by name or email
- Review recent project activity
- Validate whether a dormancy finding matches real activity patterns
Activity data refreshes hourly, and you can also use Refresh Data for an immediate update.
Login Activity
Login Activity shows when users last signed in through Atlassian organisation-level login signals. This feature requires additional setup.
- Go to admin.atlassian.com.
- Generate an organisation API key.
- In AccessWarden, open Login Activity.
- Click Configure Org API Access.
- Paste the key and save.
| Check | What it catches |
|---|---|
| Dormant Global Admin Login | Global admins who have not logged in recently |
| Unmanaged Global Admin | Global admins not controlled by your Atlassian organisation |
| MFA Disabled Admin | Global admins without MFA enabled |
Apps & Automations
This section highlights non-human identities such as bots, service accounts, and automation users, then helps you review whether they hold more access than required.
- Review identified non-human accounts
- Check which projects and roles they hold
- Create remediation issues for unnecessary admin-level access
- Refine recognition patterns in policy settings if needed
Automation and service accounts are often over-permissioned over time. This section is especially useful for least-privilege reviews.
App Audit
The Audit Log records actions taken within AccessWarden itself, including scans, policy changes, remediation actions, and suppressions.
| Counter | What it counts |
|---|---|
| Total events | All logged actions |
| Scans run | Number of triggered scans |
| Policy changes | Policy creates, updates, and deletes |
| Exceptions | Saved suppressions |
| Remediations | Created remediation tickets |
| Badge | What it means |
|---|---|
| Scan started | A scan was initiated |
| Scan completed | A scan finished successfully |
| Policy created | A new policy was added |
| Policy updated | A policy configuration was changed |
| Policy deleted | A policy was removed |
| Exception saved | A finding was suppressed with a reason |
For compliance reporting, export both Scan Findings and the App Audit log to show not only what risks existed, but also what actions were taken.
Quick Reference
| Section | The question it answers |
|---|---|
| Overview | What is my current risk posture at a glance? |
| Policies | Which checks are running, and how are they configured? |
| Scan Findings | What risks did the last scan find? |
| Decisions | What has been done about findings? |
| Roles & Permissions | Who has access to what across Jira? |
| Access Paths | How exactly did this user get access? |
| Admin Changes | Who changed what, and when? |
| User Activity | Who is active, and who is dormant? |
| Login Activity | When did users last log in? |
| Apps & Automations | Do non-human accounts have too much access? |
| App Audit | What actions were taken inside AccessWarden? |
Need help?
- miniOrange Support: miniorange.atlassian.net/servicedesk
- Email: atlassiansupport@xecurify.com
- Marketplace: marketplace.atlassian.com
AccessWarden is built and maintained by miniOrange. Your Jira governance data remains within the Atlassian platform.
Did this page help you?
