Atlassian API Token Expiry: Living With Mandatory Token Lifetimes

Every Atlassian Cloud API token now has an expiry date, and an integration that was built around a token that never expired will stop authenticating on the day its token runs out. Atlassian set new tokens to expire after one year by default from 15 December 2024 (lifetimes of 1 to 365 days are allowed), and after 13 March 2025 it set tokens created before 15 December 2024 to expire in one year, between 14 March and 12 May 2026. This guide covers what changed, the dated timeline from Atlassian's own documentation, how to find the scripts, pipelines and connectors that depend on user tokens, the options for moving them to scoped tokens and service accounts, and how to test the switch without an outage. It is written for Atlassian organisation admins, platform engineers and the owners of integrations that call Jira or Confluence REST APIs. For the full credential model and admin controls, see the Atlassian API Tokens Security Guide; this page stays on expiry and the work it creates.

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

• No token lives longer than a year. User and service account API tokens take an expiry of 1 to 365 days, with one year as the default, so renewal is now a recurring operational task.
• The legacy deadline has passed. Tokens created before 15 December 2024 expired between 14 March and 12 May 2026; any integration still failing since then is probably using one of them.
• Renewal means replacement. Atlassian's documentation describes no way to extend a token: you create a new one, switch the integration, then revoke the old one.
• Use the change to fix ownership. Integrations running on a person's classic token move cleanly to a service account with a scoped token, which removes the dependency on one employee.
• Track expiry dates like certificates. Record each token's expiry in an inventory, alert well before it, and keep the token in a secrets manager so the swap is a configuration change, not a code change.

What is changing and why

Atlassian Cloud API tokens are used for HTTP basic authentication against the REST APIs: the account email is the username and the token takes the place of the password. Atlassian's developer documentation for Jira Cloud states that password authentication for the REST API is deprecated, so tokens are the standard credential for scripts. Users who sign in with two-step verification must also use a token for scripted access.

Before the change a token stayed valid until someone revoked it. A token created for a quick report in 2019 could still be running nightly jobs years later, long after anyone remembered it. Mandatory lifetimes cap that exposure: a token that leaks in a repository, a CI log or an infostealer dump stops working on a known date even if nobody notices the leak. The cost moves to operations, because every token now needs a renewal plan.

Three credential types sit in scope of the expiry rules, and they differ in how they are created and who owns them.

Service accounts can also hold OAuth 2.0 client credentials, which issue short lived access tokens. Those follow a different pattern (the client fetches a new access token as needed) and are an alternative to token renewal, covered under migration options below.

Official timeline and current status

The dates below come from Atlassian's support page Manage API tokens for your Atlassian account, checked on 8 November 2026. Atlassian does not publish per-token dates for the legacy group, so treat the window as a range.

The practical consequence is that expiry is no longer a single event. Every token created since 15 December 2024 carries its own date, so failures will arrive one integration at a time for as long as tokens are in use. Atlassian's page also notes that the default lifetime applies to current and new tokens. Related changes on Bitbucket Cloud, where app passwords are being replaced by API tokens, are covered in Atlassian App Passwords to API Tokens.

Who and what is affected

• Scripts and scheduled jobs: reporting scripts, bulk update jobs and data exports that call /rest/api/3/ or /wiki/rest/api/ with basic authentication.
• CI/CD pipelines: build steps that transition Jira issues, publish release notes to Confluence or post deployment records, usually with a token held as a pipeline variable.
• Third-party connectors: BI and SQL connectors, test management tools, time tracking exports and chat integrations where a user pasted a token into the vendor's settings page. These fail silently from the Atlassian side; the vendor's tool shows the error.
• Personal tokens doing shared work: the highest risk group. If the token belongs to someone who has left, nobody can sign in to create its replacement, and the integration's access depended on that person's permissions.
• Internal tools and bots: service desks, chatbots and automation services that read or create issues on behalf of a team.

Marketplace apps built on Forge or Connect generally authenticate as apps rather than with a user's pasted API token; confirm with each app's documentation before ruling it out of scope. Atlassian's documentation notes that when a scoped token request triggers a Forge app (for example through a JQL function), the app acts under its own approved permissions.

Finding affected systems and identities

Inventory comes from two sides: the tokens Atlassian knows about, and the systems that hold them. Neither is complete on its own.

From the Atlassian side

1. User tokens across the organisation: in Atlassian Administration, select the organisation, then Insights, API token activity. This view needs Atlassian Guard Standard and an organisation admin role, and covers tokens created by managed accounts. The Get API tokens API in Atlassian's developer documentation automates the same view, which suits a scheduled export.
2. Service account tokens: in Directory, Service accounts, open the account's more actions menu and choose View API tokens. Atlassian documents that this shows the active token count, creation date, expiration date and last used date for each token.
3. Your own tokens: each user can see their tokens on the API tokens page of their Atlassian account. Ask integration owners to check theirs and record the expiry dates.

From the consuming side

• Secrets stores and pipeline variables: search for variables named like JIRA_TOKEN, ATLASSIAN_API_TOKEN or CONFLUENCE_TOKEN, and for basic authentication headers aimed at atlassian.net or api.atlassian.com.
• Code repositories: secret scanning catches tokens committed to code; treat any hit as compromised and replace it, not just renew it.
• Error logs: since the legacy window closed, look for spikes of authentication failures from integrations calling Atlassian. Jira's basic authentication documentation notes that repeated failed logins can trigger a CAPTCHA, after which the REST API cannot authenticate until it is cleared; an X-Seraph-LoginReason: AUTHENTICATION_DENIED response header is the usual sign. A retry loop on an expired token can therefore lock the account for interactive users too.
• Vendor admin pages: list every SaaS tool with an Atlassian connection and check whether it uses a token, OAuth or an app install.

Record each token in a single inventory: owner, consuming system, account (person or service account), token type, scopes, created date, expiry date and last used date. The Service Account Inventory Template provides a structure, and How to find long-lived personal access tokens across Atlassian covers the Data Center and Bitbucket side of the estate.

Migration options

Expiry is a prompt to decide, per integration, which credential it should be using. The table sets out the choices.

Practical points for a service account move

• Cloud ID: scoped and service account calls need the site's Cloud ID, the string after /s/ in the Atlassian Administration URL. Atlassian warns that using the organisation ID instead causes errors such as 404 Not Found.
• App roles: service account access is the intersection of its app roles and the token scopes, so give the account only the projects and spaces the integration touches.
• Licensing: Atlassian states that service accounts with Jira or Confluence access do not count toward the user limit.
• Naming: the description field should name the owning team and the consuming system; Atlassian recommends recording who or what uses the account.
• Lifecycle: service accounts cannot be provisioned from your identity provider, so add them to your joiner, mover and leaver review by hand.

Choosing a lifetime

Shorter is safer, longer is quieter. A lifetime of 90 to 180 days balances the two for most integrations, provided renewal is scheduled. Choose 365 days only when renewal is automated or the integration is low impact, and short lifetimes (under 30 days) for one-off migrations and tests. Whatever the choice, put the expiry date in the inventory and in a calendar or ticketing reminder the day the token is created. The Secrets Rotation Runbook Template gives a reusable renewal procedure.

Testing and rollback

1. Create the new credential first. Issue the replacement token (or service account and token) while the old one still works. Set a short expiry for any token used only for testing.
2. Test in a sandbox or with read-only scopes. Point a non-production copy of the integration at the new credential and endpoint. Confirm reads, then writes, against a test project or space.
3. Check the base URL change. Moving to scoped or service account tokens moves calls from the site URL to the api.atlassian.com gateway. Most breakage after a migration is an unchanged base URL or a missing scope, not a bad token.
4. Switch production in the secrets store. Update the secret, restart or redeploy the consumer, and watch its next scheduled run.
5. Keep the old token for a short overlap. Rollback is reverting the secret to the previous token while it remains valid. Once the new path has run cleanly for an agreed period (one or two job cycles), revoke the old token. Revocation of a user token takes effect immediately; Atlassian notes service account token revocation can take up to 10 minutes.
6. Record the result. Update the inventory with the new token's expiry date and the date the old one was revoked.

A revoked token cannot be restored, so revoke only after the new path is proven. If the old token has already expired, there is no rollback: the only path forward is the new credential, which is why testing should start weeks before an expiry date.

Risks of doing nothing

• Unplanned outages: pipelines stop updating issues, release notes stop publishing and reports go blank, often noticed days later.
• Emergency workarounds: under pressure, people paste a new personal classic token with full access into a shared tool, which is worse than the credential it replaced.
• Account lockouts: retry loops on an expired token can trigger CAPTCHA on the owning account and block that person's interactive sign-in.
• Orphaned access: integrations owned by leavers cannot be renewed and must be rebuilt in a hurry, usually without knowing what access they needed.
• Lost visibility: without an inventory, a team cannot tell an expired token from a revoked or compromised one when an integration fails.

Framework mapping

Practitioner checklist

• Export user token activity from Insights and service account tokens from Directory, and merge them with the secrets and pipeline variables that hold Atlassian tokens.
• Record owner, consumer, token type, scopes and expiry date for every token in one inventory.
• Alert at 30 and 7 days before each expiry date, routed to the owning team, not the individual alone.
• Move every shared integration off personal tokens onto a service account with a scoped token or OAuth 2.0 client credentials.
• Store every token in a secrets manager so renewal is a secret update, not a code change.
• Pick a lifetime per integration (90 to 180 days is a sensible default) and document why longer lifetimes were chosen.
• Test replacements against the api.atlassian.com gateway and the correct Cloud ID before production.
• Revoke the old token only after one or two clean runs, and record the date.
• Add backoff to integration retry logic so an expired token does not trigger CAPTCHA lockouts.
• Review service accounts in the quarterly access review, since they are not provisioned from the identity provider.

Standards and references

• Atlassian Support: Manage API tokens for your Atlassian account
• Atlassian Support: Manage API tokens for service accounts
• Atlassian Support: Understand service accounts
• Atlassian Support: View user API tokens
• Atlassian Developer: Basic auth for REST APIs
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls
• NIST: Cybersecurity Framework 2.0

Related NHI Mgmt Group resources: Atlassian API Tokens Security Guide, Atlassian Cloud Security Guide, Service Account Security Guide, Secrets Rotation Runbook Template.