How to find long-lived personal access tokens across Atlassian: Cloud and Data Center audit

Personal access tokens and API tokens in Jira, Confluence and Bitbucket outlive the scripts, people and integrations that created them, and many were created with no expiry at all. This guide walks through finding them across Atlassian Cloud and Atlassian Data Center: where each product lists tokens, which settings allow never-expiring tokens, how to triage what you find and how to cap token lifetime afterwards. It is for Atlassian administrators and identity teams running an NHI inventory or responding to a credential exposure. For the wider Cloud picture (admin roles, OAuth apps, audit logs) see the Atlassian API Tokens Security Guide and the Atlassian Cloud Security Guide.

Key takeaways

• The token types differ by deployment: Cloud uses Atlassian account API tokens (classic or scoped) and service account credentials; Jira and Confluence Data Center use personal access tokens; Bitbucket Data Center uses HTTP access tokens at user, project and repository level.
• Data Center allows eternal tokens by default: atlassian.pats.eternal.tokens.enabled defaults to true, and the maximum lifetime property only applies to tokens created after you set it.
• Cloud tokens now expire, but within a year: Atlassian states that API tokens created after 15 December 2024 expire one year after creation by default, with a choice of 1 to 365 days, so a token can still live for twelve months.
• Central views need the right licence: the Cloud API token activity view requires Atlassian Guard Standard, and the Data Center admin token pages require a Data Center licence.
• Find the owner before you revoke: revocation is permanent in both Cloud and Data Center, so confirm what the token feeds and plan a replacement first.

When you need this

• NHI inventory or access review: tokens are machine credentials that inherit a human's permissions, so they belong in the same review as service accounts. See the OWASP NHI Top 10 NHI7 Long-Lived Secrets Guide.
• Leaver or role change: a token created by a user keeps that user's access for as long as the account is active.
• Infostealer or endpoint compromise: in the Schneider Electric Jira breach, the attacker claimed access to a Jira server using exposed credentials, and Hudson Rock linked them to an infostealer-infected employee machine that also held credentials for accounts named like migration accounts. Any token stored on a compromised machine should be found and revoked.
• Third-party integration breach: in the Docker Hub breach, a database holding the Bitbucket and GitHub tokens used for automated builds was accessed and Docker revoked them. When a supplier that holds your tokens is breached, you need to know which tokens they hold.
• Atlassian deprecations: Atlassian describes Bitbucket Cloud API tokens as the long-term replacement for app passwords, which is a good moment to inventory what still uses the old mechanism.

Before you start

• Roles: organisation admin in Atlassian Administration for Cloud; Jira and Confluence system administrator; Bitbucket system admin, plus project or repository admin for scoped tokens.
• Licences: confirm Atlassian Guard Standard for the Cloud API token activity view and Data Center licensing for the Jira and Confluence admin pages and Bitbucket project and repository tokens.
• Versions: Data Center personal access tokens exist from Jira Core and Jira Software 8.14, Jira Service Management 4.15 and Confluence 7.9. Older versions have no PATs, but scripts will be using passwords instead, which is its own finding.
• Startup properties: get read access to the JVM arguments (for example setenv.sh or the service definition) so you can see which atlassian.pats.* values are set.
• A findings register: one row per token with product, owner account, name, created, expiry, last used, permissions, consumer and decision.

Step-by-step

1. Know which token types to look for

2. Atlassian Cloud: list user API tokens

1. In Atlassian Administration, select the organisation, then Insights > API token activity. This shows user API tokens created by managed accounts in the organisation from one place.
2. Export or record each token with its owner, creation date, expiry and activity. For repeatable audits, Atlassian provides a Get API tokens API so the same list can be pulled on a schedule.
3. Flag tokens owned by accounts that are suspended, have left, or belong to shared mailboxes being used as integration accounts.
4. Flag classic tokens. Atlassian recommends scoped tokens and says a classic token, which has no scopes, should be used only when the app does not support scoped tokens.
5. Remember the gap: accounts outside your managed domains are not in this view. Users can see their own tokens at id.atlassian.com/manage-profile/security/api-tokens.

3. Atlassian Cloud: review service account credentials

Go to Directory > Service accounts, open the more actions menu for each account and choose View API tokens. Record expiry for each active token and confirm the service account still has an owner. Service accounts are the right home for integrations, so tokens found on human accounts in step 2 are candidates to move here. Atlassian states that deleting a service account also deletes its credentials.

4. Jira and Confluence Data Center: read the PAT settings

Check the JVM startup arguments for these properties. Absent means the default applies.

5. Jira and Confluence Data Center: list every token

1. Open Administering personal access tokens (Jira: cog > System; Confluence: cog > Users & Security).
2. Filter by expiration date to find tokens with no expiry or expiry more than your policy allows.
3. Filter by last use to find tokens that have not authenticated recently. Unused tokens are the easiest to remove.
4. Filter by author to group tokens per person and spot shared or integration accounts holding many tokens.
5. Repeat on every instance you run (separate Jira and Confluence sites, staging copies that were cloned from production with their token tables).

6. Bitbucket Data Center: check HTTP access tokens

1. Go to cog > Keys and tokens and record whether Automatic expiry is on and the HTTP access token expiry (in days) value. By default users can choose whether personal tokens expire.
2. For each user of interest, open Users > user > HTTP access tokens to see their personal tokens and expiry dates.
3. For each project and repository, open Project settings or Repository settings > HTTP access tokens. Project and repository tokens authenticate with the username x-token-auth or as a bearer token, so they will not appear in a per-user review.
4. Record permissions: read, write or admin at project or repository level. Write or admin tokens on build-critical repositories are the priority.

7. Triage

• Revoke now: owner gone, no use in your idle period, or found in a leak or on a compromised machine.
• Replace: no expiry or expiry beyond policy but in active use. Create a new token with an expiry (or a service account credential), switch the consumer, then revoke the old one.
• Reduce: classic Cloud tokens where scoped tokens are supported; Bitbucket tokens with admin where write or read is enough.
• Accept with exception: documented owner, purpose, review date and compensating monitoring.

Verify it worked

After the change window, confirm the consumers still work and repeat the filters. On Data Center, check that the new startup properties are actually in effect after the restart, for example by creating a test token and confirming the expiry choices offered.

Rollback and common errors

• Revocation cannot be undone: Atlassian states that revoking a Cloud user API token permanently deletes it, and an expired Data Center PAT cannot be reactivated. Rollback is issuing a new token and updating the consumer, so line up the replacement first.
• Assuming the cap fixed existing tokens: atlassian.pats.max.tokens.expiry.days applies only to new tokens. Old eternal tokens remain until you revoke them.
• Breaking integrations with a global switch: setting atlassian.pats.enabled to false disables every PAT. Use expiry limits and targeted revocation instead unless PATs are genuinely unused.
• Missing project and repository tokens: Bitbucket project and repository tokens are not tied to a user, so a people-based review misses them.
• Forgetting the per-user cap: the default of ten tokens per user counts expired tokens, and users who hit it may start sharing tokens. Pruning of expired tokens is controlled by atlassian.pats.pruning.delay.days (default 30).
• Bitbucket expiry dates are fixed: an expiry date cannot be changed after creation, so tightening policy means replacing tokens, not editing them.

Hardening afterwards

• Cap lifetime on Data Center: set atlassian.pats.eternal.tokens.enabled=false and a atlassian.pats.max.tokens.expiry.days value that matches your policy, then restart and replace old tokens.
• Turn on Bitbucket automatic expiry: and, from Bitbucket 8.8, use Restrict changes to repository settings so project admins control repository token creation.
• Move integrations to service accounts in Cloud: with scoped tokens or OAuth 2.0 credentials, owned by a named team.
• Schedule the export: pull the Cloud token list through the Get API tokens API and review the Data Center admin pages monthly.
• Feed revocation into offboarding: see the NHI Offboarding and Decommissioning Guide.

Practitioner checklist

• Map every Atlassian deployment you run and the token types each one supports.
• Export Cloud user API tokens from Insights > API token activity and service account tokens from Directory > Service accounts.
• Record the atlassian.pats.* startup properties on every Jira and Confluence Data Center instance.
• Filter Data Center PATs by expiry, last use and author and log every never-expiring token.
• Review Bitbucket personal, project and repository HTTP access tokens and their permissions.
• Revoke orphaned and idle tokens; replace eternal tokens with expiring ones after the consumer is switched.
• Disable eternal PATs, cap expiry and enable Bitbucket automatic expiry.
• Move integrations from human accounts to Cloud service accounts with scoped credentials.

Standards and references

• Atlassian: Using personal access tokens (Data Center)
• Atlassian: View API token activity
• Atlassian: Revoke user API tokens
• Atlassian: Manage API tokens for your Atlassian account
• Atlassian: Understand service accounts
• Atlassian: Bitbucket Data Center HTTP access tokens
• Atlassian: Managing HTTP access tokens
• NIST: SP 800-53 Rev 5 Security and Privacy Controls

Related NHI Mgmt Group resources: Atlassian API Tokens Security Guide · Atlassian Cloud Security Guide · OWASP NHI Top 10 NHI7 Long-Lived Secrets Guide · How to audit Jenkins credentials and secrets