Atlassian App Passwords to API Tokens: Migrate Bitbucket Automation to Scoped Tokens

Bitbucket Cloud app passwords were long-lived, user-bound credentials hidden in scripts, CI variables and Git remotes, and Atlassian originally scheduled them to stop working on 9 June 2026, later replaced by brownouts from that date and final removal on 28 July 2026. Their replacements, scoped Atlassian API tokens and repository, project or workspace access tokens, expire, carry explicit scopes and can be tied to a repository instead of a person. This guide is the migration runbook: the official dates and current status, what breaks, how to inventory the app passwords and the automation that used them, how to choose the right replacement token, how to test and roll back, and what remains risky afterwards. It is for platform, DevOps and security teams running Bitbucket Cloud. For the wider Bitbucket control set, see the Bitbucket Security Guide; for Atlassian token governance across Jira and Confluence, see the Atlassian API Tokens Security 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

• The announced end date has passed. Atlassian announced on 9 June 2025 that app passwords would cease to function on 9 June 2026, after new creation stopped on 9 September 2025. A later Atlassian Community deprecation notice replaced the hard cut-off with brownouts from 9 June to 27 July 2026 and final removal on 28 July 2026; we could not find an Atlassian statement confirming the removal took place, so treat any app password as broken or about to break.
• Not every app password should become an API token. Automation that touches one repository is better served by a repository access token, which is tied to the repository rather than a user account and cannot log in to bitbucket.org.
• Scopes are mandatory for Bitbucket. Atlassian states API tokens used for Bitbucket APIs or Git commands must have scopes, for example read:repository:bitbucket to clone and write:repository:bitbucket to push.
• Expiry is now a design input. Atlassian API tokens last from 1 to 365 days, so every migrated integration needs an owner, a stored expiry date and a rotation path before it fails again.
• Usernames change too. Git over HTTPS uses your Bitbucket username or the static x-bitbucket-api-token-auth for API tokens, and x-token-auth for repository access tokens; the REST API takes the Atlassian account email with Basic auth, or a Bearer token.

What is changing and why

An app password was a per-user credential with selected permissions, used in place of the account password for Git over HTTPS and the Bitbucket REST API. Because it was bound to a person, it inherited that person's repository access, stayed valid until revoked, and continued to work after the person changed role. Atlassian describes API tokens as "the long term replacement for App passwords."

Official timeline and current status

Dates are from Atlassian's announcement on the Bitbucket blog, published 9 June 2025, checked on 8 November 2026.

Atlassian's Community brownout notice (https://community.atlassian.com/forums/Bitbucket-articles/Deprecation-notice-Bitbucket-Cloud-app-password-brownout/bc-p/3251570) gives 28 July 2026 as the final removal date. The changelog's most recent related entry, dated 18 August 2026, added Bearer authentication for API tokens and states Bitbucket Cloud continues to support both Basic and Bearer authentication for them. Treat 28 July 2026 as the latest announced removal date and confirm current status with Atlassian if you see app passwords still authenticating.

A related Atlassian change affects API tokens themselves: per Atlassian's account documentation, new tokens default to a one-year expiry, and tokens created before 15 December 2024 were set to expire between 14 March and 12 May 2026. Integrations migrated early in 2025 with unscoped tokens may therefore have broken a second time.

Who and what is affected

• CI/CD systems outside Bitbucket Pipelines that clone, tag or push with an app password stored as a secret or credential.
• Scripts and bots calling the Bitbucket REST API: release tooling, pull request automation, repository provisioning and reporting jobs.
• Bitbucket Pipelines steps that call the API or push to other repositories using an app password held in a repository or workspace variable.
• Developer machines where Git credential helpers cached an app password for HTTPS remotes, and remote URLs with the password embedded.
• Third-party tools (IDEs, deployment, dependency update and code quality services) configured with a username and app password rather than OAuth.
• Shared "service users": ordinary Bitbucket accounts created only to own app passwords for automation, often with broad workspace access and no human owner.

Finding affected systems and identities

With app passwords no longer creatable and past their announced end, discovery has two goals: find integrations that are now failing or about to be rebuilt, and make sure no copy of an old app password is left in a place where it could be mistaken for a working secret or reused elsewhere.

1. Failure signals: search CI logs, job histories and monitoring for HTTP 401 responses from api.bitbucket.org and Git "Authentication failed" errors against bitbucket.org since June 2026. Each one is an unmigrated integration.
2. Secret stores and CI variables: list credentials whose names or descriptions mention Bitbucket, app password or BB_ (CI secret stores, vaults, Pipelines repository and workspace variables). Record owner, consumer and the Bitbucket account they belong to.
3. Code and configuration: run secret scanning across repositories for Bitbucket credentials and for remote URLs of the form https://user:[email protected]. See the Git Secret Scanning Guide.
4. Accounts: list workspace members that are service users rather than people, and the repositories and groups they can reach. These become candidates for repository access tokens or Atlassian service accounts.
5. Existing API tokens: find tokens without scopes or with long remaining expiry, using the approach in How to find long-lived personal access tokens across Atlassian.

The identity angle: each app password was an unmanaged non-human credential attached to a human account. Migration is the chance to separate them: give automation its own identity (a repository, project or workspace access token, or an Atlassian service account with a scoped token), record an owner and expiry in your NHI inventory, and stop personal accounts carrying production automation. See the CI/CD Pipeline Identity Security Guide.

Migration options

Atlassian publishes no mapping from old app password permissions to new scopes. Map by what the job does, not by what the old password allowed: most app passwords were created with broad checkboxes, so start from the smallest scope set (read:repository:bitbucket) and add write, pull request, pipeline or webhook scopes only when a test fails for a documented reason. Each level (repository, project, workspace) allows a maximum of 25 access tokens, which cannot be increased, so design one token per consuming system, not per job.

Decision guidance: on Standard plans, use repository access tokens for single-repository automation and scoped API tokens on a dedicated account only where cross-repository access is unavoidable. On Premium, prefer project access tokens over workspace tokens. Small teams can migrate by hand; large estates should first build the inventory, then migrate by consuming system so one change window updates every secret that system holds. Where the consumer runs in a cloud with workload identity, store the token in a secrets manager rather than CI variables. See the Secrets Management Guide.

Testing and rollback

1. Create with intent: in Atlassian account settings, Security, Create and manage API tokens, choose Create API token with scopes, set an expiry date, select Bitbucket and pick scopes; or create an access token in repository, project or workspace settings. Copy it once into your secrets manager.
2. Update the consumer: change username and secret together (x-token-auth or x-bitbucket-api-token-auth for Git; email plus token or Bearer for the API). Avoid embedding the token in remote URLs; Atlassian advises against storing it permanently there.
3. Test the least-privilege set: run the job in a branch or staging pipeline and confirm every call succeeds; a 403 indicates a missing scope, a 401 a wrong username or token.
4. Cut over and record: switch production, then record the token's owner, consumer, scopes and expiry date in your inventory with an alert at least 30 days before expiry.
5. Rollback: there is no rollback to app passwords. Rollback means reverting the consumer to the previous working token while you correct scopes, so keep the old token valid until the new one has passed a full run, then revoke it.
6. Clean up: delete stale CI variables, cached Git credentials and secrets that held app passwords, so retired values cannot be confused with live ones.

Risks of doing nothing

• Broken delivery: builds, releases and bots that still rely on app passwords stop working, often discovered during an urgent release.
• Rushed over-scoping: teams fixing breakage under pressure create workspace tokens or admin-scoped API tokens with a one-year expiry, recreating the old risk with a new name (ATT&CK T1528 Steal Application Access Token).
• Secrets left in place: old app passwords left in files and variables train people to ignore secret scanning alerts; credentials in files remain a classic discovery path (ATT&CK T1552.001 Credentials In Files).
• Silent second expiry: migrated tokens expire within a year; without an owner and alert, the integration fails again.
• Human-bound automation: scoped tokens on personal accounts still break when the person leaves, and still carry that person's access.

Framework mapping

Practitioner checklist

• Search CI and monitoring logs for 401s from api.bitbucket.org and Git authentication failures since June 2026.
• Inventory every secret, variable and remote URL that held an app password, with owner and consumer.
• Replace single-repository automation with repository access tokens using x-token-auth.
• Use project access tokens before workspace tokens where Premium is available.
• Create API tokens only with scopes, the shortest workable expiry and a named owner.
• Move automation off personal accounts to access tokens or Atlassian service accounts.
• Store tokens in a secrets manager and alert 30 days before expiry.
• Delete retired app password values from variables, vaults, credential helpers and code.

Standards and references

• Atlassian: Bitbucket Cloud transitions to API tokens (app password deprecation)
• Atlassian Support: Using API tokens with Bitbucket Cloud
• Atlassian Support: Bitbucket API token permissions
• Atlassian Support: Bitbucket access tokens
• Atlassian Support: Using repository access tokens
• Atlassian Support: Manage API tokens for your Atlassian account
• Atlassian Developer: Bitbucket Cloud changelog
• NIST: SP 800-53 Rev 5 Security and Privacy Controls

Related NHI Mgmt Group resources: Bitbucket Security Guide · Atlassian API Tokens Security Guide · How to set expiry policies on personal access tokens · CI/CD Pipeline Identity Security Guide