As announced on the Developer Community, we're making several shared changes to all the Atlassian Data Center products. We expect all of these changes to land into the following product versions:
Here are the estimated release dates for the first EAPs containing these changes:
| Product | Version number | EAP date | GA date | Download link |
|---|---|---|---|---|
| Jira Software | 11.0 | 16 July 2025 | August 2025 | https://www.atlassian.com/software/jira/download-eap |
| Jira Service Management | 11.0 | 16 July 2025 | August 2025 | https://www.atlassian.com/software/jira/download-eap |
| Confluence | 10.0 | 16 July 2025 | August 2025 | https://www.atlassian.com/software/confluence/download-eap |
| Bitbucket | 10.0 | 3 July 2025 | September 2025 | Bitbucket Data Center 10.0 Early Access Program (EAP) release |
| Bamboo | 12.0 | Q3 2025 | September 2025 | |
| Crowd | 7.0 | 19 June 2025 | August 2025 | https://www.atlassian.com/software/crowd/download-eap |
Check out the public announcements we've made so far about the upcoming updates:
While there might be differences in details and implementation timelines between the products (which you can learn more about from product-specific documentation), here's a general overview of the planned changes.
To maintain high security standards and keep dependencies supported and up to date, we're updating Spring to the 6.x line. Spring 6 is no longer compatible with the currently used Jakarta 8, requiring us to also update the Jakarta version to EE Platform 10, specifically:
We're also updating all the other libraries that depend on Spring and Jakarta.
We won't be making any changes to the Atlassian API unless they're necessary because of the updates to the Jakarta API. There are also several API changes in Jakarta that may impact apps.
We're upgrading to jQuery 3 to align on jQuery versions across all Data Center products. This means a significant jQuery version uplift for products containing older versions of jQuery that will make developing cross-product apps easier.
We're removing some outdated AUI 10 components with design and accessibility issues. Make sure to move to their new versions or migrate to Atlaskit:
We're also upgrading some outdated dependencies:
We're also deprecating or removing the following:
<input> placeholder.Other changes include the Node 22 engine requirement. This will only affect using AUI via NPM, not through the running product.
To enhance the security, performance, and overall developer experience, we're deprecating both the LESS web-resource transformer and the LESS Maven plugin.
We're updating Look and Feel to use CSS variables, and all styles will either be CSS or compiled to CSS at build-time. We're also removing LESS compilation from Java build and runtime. You can continue to use LESS or any other CSS pre-processor at build-time.
We recommend you replace the runtime transformation of LESS files with build-time compilation or move to native CSS altogether where applicable.
We're removing Trusted apps to reduce the number of insecure entry points into the products. We've replaced this way of exchanging information between Atlassian products with more secure solutions that follow industry best practices, like the OAuth 2.0 protocol.
With the new light and dark themes that brought accessibility and usability improvements, we're removing the original theme from all products.
We're adding support for the following databases:
We're also removing support for:
These versions of the products will only run on Java 21.
We’re implementing a global serialization filter that relies on a central blocklist for Java deserialization, Velocity, Struts, and XStream. This filter is designed to block specific classes and patterns that are recognized as vulnerable to Remote Code Execution (RCE) through publicly known gadget chains.
We’ll update this page with the full list of blocked classes and patterns.
As we communicated in February, in 2025 we’re rolling out app signing. In these releases, app signing is enabled by default. This feature enables better security and increases customer trust in what they install on their local instances.
If you upload your apps to Atlassian Marketplace, we’ve got you covered. Once Marketplace validates and approves your app, Atlassian will sign and trust all your apps by default; no additional action is needed. App signing affects only new app installations, previously installed apps will not undergo verification.
For details on private builds, check this CDAC post.
We’re working on introducing service accounts to Data Center products. Service accounts are specialized, non-user accounts created for secure and efficient management of automated processes and external integrations. With service accounts, you can securely access REST APIs using the OAuth 2.0 authentication method to execute scripts and run tasks while maintaining full control of permissions.
Until we introduce the UI for this feature, you can use the new API in Embedded Crowd to create service accounts.
We’ve introduced @ScopesAllowed to improve security and control over REST endpoints.
Add the @ScopesAllowed annotation to your endpoints to make them accessible using an OAuth 2.0 Client Credentials token (2LO).
For example, this annotation requires that the access token has the WRITE scope before providing access to this endpoint:
1 2@POST @ScopesAllowed(requiredScope = "WRITE") public void createEntity(...) {}
Supported scopes are documented here:
Confluence: OAuth 2.0 scopes for incoming links
Bitbucket: OAuth 2.0 scopes for incoming links
Crowd: Configuring an incoming link
We're implementing several important changes to our OAuth 2.0 authentication process to enhance security and efficiency.
Enforced global maximum time on access tokens: Access tokens will now have a maximum validity period of 1 hour. This change is designed to improve security by ensuring tokens are refreshed more frequently. You can change the value by setting the atlassian.oauth2.provider.access.token.expiration.seconds system property.
Maximum lifetime of client ID and secret: The lifetime of client IDs and secrets is now restricted to a maximum of 730 days. However, this period can be reduced as needed, with a default setting of 90 days. This change aims to encourage regular rotation of credentials. You can change the value by setting the atlassian.oauth2.provider.client.credentials.expiration.seconds system property.
Rotation of client credentials: Regular rotation of client credentials (both client ID and secret) is now encouraged to enhance security. Implementing a rotation policy can help mitigate risks associated with compromised credentials.
Revocation of rotated client credentials: Once client credentials (client ID and secret) are rotated, the previous credentials can be revoked. This ensures that only the most recent credentials remain active, reducing the risk of unauthorized access.
Revocation of user's refresh tokens: We now provide the ability to revoke all refresh tokens associated with a specific user. Additionally, administrators have the authority to revoke all refresh tokens for users within the system. This capability allows for greater control over session management and security.
Maximum number of refresh tokens: The maximum number of refresh tokens allowed per client ID and user is limited to 25. This limitation helps manage resource usage and ensures that token proliferation is kept in check. You can change the value by setting the atlassian.oauth2.provider.refresh.token.limit.per.client.user system property.
The changes listed on this page apply to common elements shared across multiple Atlassian Data Center products. Each product's feature release may in turn have additional changes. Refer to product-specific release notes for more information on those changes:
Rate this page: