Jira Data Center Hardening: Admin Groups, Tokens, Audit Logs and End of Life

A self-managed Jira holds an organisation's roadmaps, incident tickets, customer data and, too often, pasted credentials, and attackers increasingly get in with nothing more than a password harvested by an infostealer. Jira Data Center gives administrators far more control than Atlassian's cloud service, but that control comes with responsibility for patching, network exposure, admin groups, token lifetimes and logging. This guide covers Jira Software Data Center specifically: how identity and global permissions work, how to separate system administrators from Jira administrators, how to control personal access tokens and integration accounts, what the audit log records, a hardening baseline and the end-of-life date that now shapes every plan. It is for Jira administrators, infrastructure teams and security engineers. Atlassian's hosted service is covered in the Atlassian Cloud Security Guide, and Confluence in the Confluence Data Center Hardening Guide.

This is an independent guide from NHI Mgmt Group, based on Atlassian's public documentation as of November 2026. It is not sponsored or reviewed by Atlassian. Product features change, so confirm settings against Atlassian's current documentation.

Key takeaways

• Separate the two admin permissions. Jira System administrators can install apps, change user directories and run backup and restore; Jira administrators cannot. Give the system permission to a small dedicated group.
• Personal access tokens default to no expiry. Set atlassian.pats.eternal.tokens.enabled to false and lower atlassian.pats.max.tokens.expiry.days from its default of 365.
• Disable basic authentication after SSO. Atlassian's Data Center checklist says to turn it off for both login and REST once single sign-on is in place, so stolen passwords cannot bypass the identity provider.
• Ship the per-node audit files. Each node writes to <Jira local home>/log/audit; raise coverage for security areas and forward the files to a separate system.
• Plan for 28 March 2029. Atlassian's published end of life for Jira Data Center is that date, after which instances are read-only and receive no security fixes.

How identity and access work in Jira Data Center

Jira Data Center authenticates users against its internal directory, external LDAP or Active Directory directories, or Atlassian Crowd, and can delegate login to a SAML or OpenID Connect identity provider through Atlassian's Data Center single sign-on. Authorisation then flows through several layers.

• Prefer SSO with MFA at the identity provider: integrate with an identity provider, then disable basic authentication for login and REST requests, as the Atlassian checklist recommends. Keep one local break-glass administrator.
• Enable CAPTCHA on login and control public signup: both are listed in Atlassian's guidance for Data Center. Leave public signup off for internal instances.
• Disable leavers, do not delete them: Atlassian notes that deleting a user anonymises the user ID, which damages audit history. Disable the account in the directory instead.
• Watch shared filters and dashboards: the Create shared objects permission lets users share filters and dashboards globally. If any permission is open to anonymous users, a shared filter can expose issue summaries to the internet.
• Restrict user browsing: Browse users and groups controls who can list users in pickers. Atlassian documents a feature flag, com.atlassian.jira.ignoreBrowseUsersPermissionsInUserPickers, that lets all users list users in pickers; leave it off where staff directories are sensitive.

Admin roles and privileged access

• Split the default group: before Jira 11.2, the jira-administrators group held both admin permissions. Fresh 11.2 and later installs create separate jira-administrators and jira-system-administrators groups, though the initial admin belongs to both. On older or upgraded sites, create a system administrators group, grant it the permission and remove that permission from jira-administrators.
• Turn on the stricter 11.2 properties: jira.jmx.strict.admin.permission, jira.feature.flags.strict.admin.permissions and jira.index.recovery.from.relative.path.only are opt-in and disabled by default. They limit JMX and dark feature changes to system administrators and restrict index recovery paths.
• Separate admin accounts: Atlassian's checklist asks for few admins, no shared accounts, no guessable names such as "admin", and secure administrator sessions with a short timeout so admins re-enter their password before admin functions.
• Restrict the admin interface by network: limit admin paths to specific IP addresses at the reverse proxy. See the Proxies and Forward vs Reverse Proxy Security Guide.
• Keep admins off the servers: Atlassian states that Jira administrators should not have direct filesystem or database access. Run Jira as a dedicated non-root OS user and give the database account only what Jira needs.

Integrations, API tokens and service accounts

Integrations reach Jira Data Center through the REST API, application links to Confluence, Bitbucket and other tools, incoming mail handlers and Marketplace apps that run inside the Jira JVM. Each carries a credential or trust that tends to outlive the project that created it.

Personal access tokens

Jira Software and Jira Core 8.14 and later (Jira Service Management 4.15 and later) support personal access tokens sent as Authorization: Bearer headers. A token matches its creator's current permission level, so a token created by a system administrator is a system administrator credential. Administrators control tokens through JVM system properties, set identically on every node.

• Use dedicated integration users: one non-human account per integration, with access only to the projects it needs, never in an admin group, with a recorded owner. Create its token from that account.
• Review the token list: on Data Center, administrators can view every token on the site with author, creation and expiry dates and last use, and can revoke tokens in bulk. Revoke tokens unused for 90 days and tokens owned by leavers. See How to find long-lived personal access tokens across Atlassian.
• Retire migration and project accounts: accounts created for a migration or a one-off integration keep working long after the work ends.
• Keep secrets out of tickets: Jira issues and comments are a common place for pasted passwords and API keys. Scan them and move findings to a vault. See the Atlassian API Tokens Security Guide.

Taken together, these controls protect against infostealer-harvested credentials: short token lifetimes, SSO with basic authentication disabled, retired migration accounts and alerts on bulk API reads each break a link in that chain. See the Infostealer Logs Monitoring and Response Guide.

Application links and Marketplace apps

• Application links: configuring non-OAuth application links is a system administrator task. Remove unused links and review what each linked application can do on a user's behalf.
• Marketplace apps: installing apps is also system administrator only, and apps run with Jira's own privileges and often expose their own REST endpoints. Keep an inventory with owners, remove unused apps and include apps in patching.

Logging and detection

The Jira audit log groups events into coverage areas, each set to Off, Base, Advanced (Data Center only) or Full. New installations keep database records for three years by default (20 years on migrated sites), capped at 10 million rows by plugin.audit.db.limit.rows. Each node writes audit files to <Jira local home directory>/log/audit, up to 100 files of 100 MB each, intended for tools such as ELK, Splunk, Sumo Logic and Amazon CloudWatch. System administrators and Jira administrators can view the full log; setting plugin.audit.log.view.sysadmin.only to true restricts it to system administrators. Atlassian also recommends monitoring access logs and keeping logs unreachable from external networks.

Metrics that show it is working

• Patch latency: days from an Atlassian critical advisory to production upgrade (target under seven days for internet-reachable instances).
• System admin footprint: members of groups holding Jira System administrators (target: a handful of named admin accounts).
• Token hygiene: tokens without expiry, older than 90 days or unused for 90 days.
• Authentication coverage: share of logins through SSO and number of REST calls still using basic authentication.
• App inventory: installed apps without a named owner or behind on updates.

Hardening baseline

Phased rollout

1. Exposure check: confirm the version, internet reachability and which Atlassian security advisories apply; patch first.
2. Compromise check: review admin group membership, recent new users, installed apps, tokens created by admins and access logs before trusting the instance.
3. Admin model: create or confirm the separate system administrators group, move admins to dedicated accounts, enable the 11.2 strict properties where available.
4. Authentication: enable SSO for a pilot group, then everyone, keep a local break-glass admin, then disable basic authentication.
5. Tokens and integrations: set the PAT properties on every node, create integration users, revoke stale tokens and remove unused apps and links.
6. Logging: raise audit coverage, forward node files and access logs, build the detections above.

Testing and rollback: make PAT and SSO changes on a staging instance first; system properties need a restart and must match on every cluster node, and max.tokens.expiry.days only affects new tokens, so existing long-lived tokens must be revoked separately. Keep the break-glass admin so a broken SSO configuration can be reverted, and keep the previous JVM argument set to restore if integrations fail.

Plan for end of life

Atlassian's schedule ends Data Center sales to new customers on 30 March 2026, ends expansions for existing customers on 30 March 2028 and ends life for Jira Data Center on 28 March 2029, with critical security fixes until then. Afterwards instances become read-only, and Atlassian strongly advises against keeping a read-only instance connected to the internet. Smaller organisations will usually migrate or export and archive; large or regulated ones that must stay self-managed should decide early and plan network isolation for any archive (NIST SP 800-53 SA-22 Unsupported System Components). Service desk instances need their own review; see Jira Service Management Security.

Common misconfigurations

• One admin group with both permissions: upgraded sites where jira-administrators still holds Jira System administrators, so every project-level helper can install apps and change directories.
• Basic authentication left on after SSO: scripts and attackers bypass the identity provider and its MFA with stolen passwords.
• Non-expiring tokens created by administrators: a leaked token is a permanent admin credential.
• Forgotten migration and integration accounts: password-based accounts kept after a migration, as in the Schneider Electric case.
• "Anyone on the web" permissions: shared filters and dashboards exposing issue data to the internet.
• Logs only on the node: an attacker with code execution can delete the evidence.

Framework mapping

Practitioner checklist

• Check the running version against Atlassian's security advisories and patch.
• Remove direct internet exposure or put an authenticating proxy and WAF in front of Jira.
• Give Jira System administrators to a small dedicated group and remove it from jira-administrators.
• Enable SSO with MFA at the identity provider, then disable basic authentication for login and REST.
• Set atlassian.pats.eternal.tokens.enabled=false and a lower maximum expiry on every node, then revoke existing long-lived tokens.
• Create owned integration users and retire migration and one-off accounts.
• Remove "Anyone on the web" grants and review Bulk change and Create shared objects holders.
• Raise audit coverage and forward node audit files and access logs to a separate system.
• Decide the migration or archive plan for the 28 March 2029 end of life.

Standards and references

• Atlassian: Data Center security checklist and best practices
• Atlassian: Managing global permissions in Jira Data Center
• Atlassian: Using personal access tokens
• Atlassian: Auditing in Jira
• Atlassian: Data Center end of life
• Atlassian: Security Advisories
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: Atlassian Cloud Security Guide · Confluence Data Center Hardening Guide · Atlassian API Tokens Security Guide · Infostealer Logs Monitoring and Response Guide