Atlassian is continually updating its products to use safer authentication methods, and the latest changes focus on Bitbucket Cloud. Earlier this year, Atlassian announced plans to phase out the old “app password” authentication method in Bitbucket Cloud. Now that initiative has reached a major milestone: as of September 9, 2025, Bitbucket Cloud has entered Phase Two of its app password deprecation process. This brings immediate changes for users and signals that the final phase is on the horizon. Let’s break down what’s happening, why Atlassian is making this change, and how you can prepare.
Phase Two of the transition imposes some new restrictions and requirements on Bitbucket Cloud users. In summary, here are the key changes now in effect:
No more new app passwords: As of September 9, 2025, Bitbucket Cloud no longer allows the creation of new app passwords. If you try to generate a new app password now, the option is disabled. Going forward, this legacy method of authentication is effectively turned off for new setups.
Existing app passwords still work (for now): Any app passwords you already have will continue working throughout Phase Two, so your current integrations and scripts won’t break immediately. Bitbucket isn’t cutting off existing credentials yet, ensuring no sudden disruption to your workflows at this stage.
New integrations must use API tokens: For any new integration, script, or tool you set up from now on, you must use an API token (with appropriate scopes) instead of an app password. Bitbucket’s interface will direct you to create an API token when credentials are needed for something new. In other words, API tokens are now the standard for any new connection to Bitbucket Cloud’s API.
Laying a secure foundation: By enforcing tokens for new setups while keeping old passwords temporarily valid, Atlassian is ensuring all new integrations are built on a modern, secure foundation right away, while giving you time to transition existing setups. You have a grace period during Phase Two to update older integrations before app passwords are fully retired in the final phase.
Why is Atlassian making this change? In short, API tokens are a more secure and flexible way to authenticate, offering several advantages over app passwords:
Stronger security with expiration: API tokens come with built-in expiration control. Unlike app passwords which stay valid indefinitely until you manually revoke them an API token can be set to expire automatically after a defined period. This greatly reduces the risk of long-term exposure. For example, if an API token were ever accidentally leaked or left unused, it would eventually time out and become unusable. Short-lived tokens mean a smaller window of opportunity for bad actors and better overall security hygiene.
Centralized management and oversight: API tokens are created and managed through your Atlassian account’s centralized security settings. This makes it much easier to keep track of all active tokens. You can see all the tokens you’ve issued in one place and revoke any that are no longer needed. Importantly, organizations get more control, too. If your users’ Atlassian accounts are managed by your company, your Org Admins can now gain visibility into API token usage across the team. Admins have the power to monitor tokens and revoke them if necessary. This level of administrative oversight simply wasn’t possible with the old app passwords, which were often invisible to org admins.
Granular permission scopes: API tokens support a modern set of permission scopes that are more fine-grained and secure. App passwords used a limited set of “classic” scopes that were fairly broad. In contrast, when you create an API token you can specify exactly what that token can do. For example, you might create a token that can only read repository content but not write to it, or one that has access to issue tracking data but not repository admin settings. By granting exactly the permissions needed and nothing more, you minimize potential damage if a token were ever compromised. The flexibility of these new scopes means you can tailor tokens to each integration’s needs, improving security across the board.
Transitioning to API tokens ensures a more secure and consistent authentication experience for all Bitbucket Cloud users. Atlassian is making this move now so that the entire ecosystem benefits from tighter security and better management features.
Depending on how you currently use Bitbucket Cloud, the impact of Phase Two will differ. Here’s what the changes mean for a few common scenarios:
If you rely on existing app passwords: Your current app passwords will continue to work throughout Phase Two (until the final cutoff on June 9, 2026). However, don’t wait too long to act. It’s strongly recommended to start updating your integrations to API tokens sooner rather than later. Migrating early will ensure you’re not caught off guard by the time Phase Three arrives. Take this opportunity to identify where you’re using app passwords and plan to replace them with API tokens well before the deadline.
If you’re creating new integrations: Starting now, any new tool or integration that needs to connect to Bitbucket Cloud must use an API token. Be prepared to generate API tokens for new projects and use those tokens when configuring access. This might involve updating your team’s documentation or informing developers about the new process. The important point is that “create app password” is no longer an option for new setups tokens have fully taken over that role. Make sure everyone on your team who interacts with Bitbucket is aware of this change so they can obtain and use API tokens for new connections.
If you’re an admin: Now is the time to encourage and assist your team in migrating to API tokens. As an administrator or team lead, you might want to audit your projects for any usage of app passwords. Get an inventory of which integrations are still using app passwords, and prioritize transitioning them. By starting the migration early, you’ll avoid last-minute scrambles when Phase Three arrives. Also remember that you have new tools at your disposal: with the centralized token management in Atlassian accounts, you can monitor all the API tokens your users have created. Keep an eye on token usage and revoke any tokens that look suspicious or are no longer needed. Providing guidance and oversight now will save headaches later, and it will ensure your team isn’t locked out of any critical systems when the old method is finally turned off.
Phase Two is a transitional period, but it’s not the end of the journey. Atlassian has already announced that Phase Three will be the final step, coming on June 9, 2026. On that date, all remaining app passwords will stop working permanently. In other words, any Bitbucket integration still using an app password at that time will cease to authenticate successfully once Phase Three kicks in. Only API tokens will be accepted for Bitbucket Cloud after that point. This final cutoff may seem far off at the moment, but it will arrive quicker than you think. If you have a habit of “if it ain’t broke, don’t fix it,” keep in mind that waiting until the last minute could lead to service interruptions. It’s best to use the generous lead time Atlassian has provided to update everything well before next June. Phase Three will mark the complete end of app passwords, so make sure you’re fully prepared for a tokens-only world by then.
By now, you might be wondering how to actually create and use an API token in place of an app password. The good news is that Atlassian has made this process straightforward. You can start using API tokens for scripting, CI/CD pipelines, or any application that connects to Bitbucket. Follow these steps to create a Bitbucket API token:
Open your Atlassian account security settings: Log in to Bitbucket Cloud and click your account avatar. From the menu, go to your Account settings. This will take you to your Atlassian account management page. Once there, find and select the Security section.
Go to the API token management page: In the Security settings, look for an option to manage API tokens. Click on “Create and manage API tokens.” Then, initiate the process by clicking the button to create a new API token.
Name your token and set an expiry: A dialog or form will prompt you to configure the new token. Give the token a descriptive name so you remember its purpose. You will also be asked to set an expiration date. Choose an expiry duration that makes sense for your use case you might set a token to last a few months or a year, depending on how often you’re willing to rotate it. Also, if prompted, specify that this token is for Bitbucket Cloud usage.
Select the necessary scopes/permissions: Next, you’ll need to select which permissions to grant to this token. Only grant the minimum access that the integration requires. For instance, if the token will be used by a read-only reporting tool, you might only select “read” scopes on repositories or projects. On the other hand, a token for a CI/CD pipeline that needs to push code might require read and write scopes on repositories. Take a moment to check the scopes that are available and choose the ones that match the actions the token will need to perform. Atlassian’s documentation provides details on each Bitbucket API token scope if you need guidance on what to select.
Create and copy the token: After setting name, expiry, and scopes, finalize the process by clicking the button to create the token. Bitbucket will now generate the token a long string of characters and display it on your screen. Important: that token value will only be shown once, at the moment it’s created. Be sure to copy the token string now and store it in a secure place. You will need to paste this token into your application or script to replace the old password. If you lose the token or forget to copy it, you’d have to generate a new one, since for security reasons Atlassian won’t show it to you again after this point.
Once you’ve copied the token, you can update your integration to use it. For example, if you were using an app password in a Git command or in your code, replace that password value with the new token. In most cases, an API token can be used exactly like an app password was used for HTTP basic authentication, you use your Atlassian account username and the token as the password. After completing the steps above, your new API token is ready to go, and your integration should authenticate with Bitbucket Cloud using the token.
If you need more detailed guidance or run into any issues, Atlassian’s support documentation and community forums have additional instructions on creating and using API tokens. But for most users, the process is quick and similar to how you might have managed app passwords in the past.
Atlassian is rolling out this deprecation in phases specifically to give everyone plenty of time to adapt. They will continue to provide reminders, documentation updates, and community support as the transition progresses. You can expect periodic communications from Atlassian leading up to the final phase, including prompts in the Bitbucket Cloud UI or emails reminding you of the upcoming changes. Make use of the resources available: the official Atlassian Community forums are a great place to ask questions if you’re unsure about anything or run into a challenge. There, you can get answers from Atlassian staff and other developers who are also migrating away from app passwords.
Keep in mind that you don’t have to tackle this change alone. Atlas Bench, as an Atlassian Solution Partner, is here to help organizations navigate changes like this smoothly. We’ve been following this app password deprecation plan closely from the beginning. Our team has experience assisting clients in updating their Bitbucket authentication, and we can share best practices to ensure a seamless transition for your projects. Whether you need advice on how to audit your current usage or hands-on help implementing API tokens across dozens of scripts and tools, we’re available to support your team through the process.
The important thing is to stay proactive. Phase Two is the ideal time to start cleaning house: review where your Bitbucket integrations stand, educate your developers about API tokens, and put a transition plan in motion. By doing so, you’ll be well-prepared long before June 2026, and the final switch-over will be a non-event for your organization. Remember, these authentication changes are ultimately about keeping your code and data safe with modern security standards it’s a positive step that will benefit you in the long run.