What the badge means for customers, what it requires from developers, and why investing in enterprise-grade app security pays off.
Updated August 2026
When evaluating an app on the Atlassian Marketplace, customers can compare its functionality, pricing, reviews and number of installations. They may also see different trust badges and security indicators.
These badges are more than visual labels. They help administrators, security teams and procurement departments understand how an app is built, where its data is processed and whether the vendor follows additional security, reliability and support practices.
Two of the most prominent trust signals for cloud apps are Runs on Atlassian and Cloud Fortified. They are related to trust, but they answer different questions and should not be understood as two levels of the same certification.
Important 2026 update: Atlassian has announced that Cloud Fortified will be replaced by the new Atlassian Enterprise Certified program. Onboarding is planned to begin in Q3 2026, and Cloud Fortified is expected to be phased out by the end of 2026. Nevertheless, the security, reliability and support practices behind Cloud Fortified remain highly relevant and provide a strong foundation for the new certification. (Atlassian Enterprise Certified Program)
The Runs on Atlassian badge focuses primarily on the app’s architecture and data handling.
It is automatically applied to eligible Forge apps that:
exclusively use Atlassian-hosted compute and storage,
support data residency that matches the host Atlassian product, and
allow customers to control permitted external data egress, such as analytics and logs.
In simplified terms, Runs on Atlassian answers the question:
Does the app operate within the Atlassian platform, and can the customer control whether its data leaves that environment?
The badge is particularly valuable to organizations with strict data residency and data processing requirements. However, it is not applicable to every app architecture. For example, an integration whose core purpose is to communicate with an external business system may need external connections by design.
That does not automatically make the app less secure. It simply means that Runs on Atlassian describes a specific architectural model rather than serving as a universal security rating. (Runs on Atlassian)
The Cloud Fortified badge has a broader focus. It was introduced for Marketplace apps intended to support larger organizations, regulated industries and business-critical processes.
Cloud Fortified evaluates the app and its vendor across three areas:
Area | Main Cloud Fortified expectations |
|---|---|
Security | Participation in the Marketplace Security Bug Bounty Program and a fully completed Privacy & Security tab |
Reliability | Defined service-level objectives, production readiness, core capability testing and incident management |
Support | A maintained support contact and a response to critical, high-severity requests within 24 hours, five working days per week |
Has the vendor established the security, operational and support processes expected from an enterprise application provider?
Atlassian states that the program is designed to make it easier for enterprise customers to evaluate Marketplace apps and to give eligible apps greater visibility among customers with business-critical requirements. (Cloud Fortified Apps Program)
For an Atlassian administrator, procurement team or information security department, Cloud Fortified provides a valuable initial trust signal.
It indicates that the app vendor has gone beyond the baseline security requirements applicable to Marketplace cloud apps and has established processes for:
publishing structured privacy and security information,
exposing the app to independent security researchers,
evaluating and remediating reported vulnerabilities,
monitoring reliability and responding to production incidents, and
supporting customers within a defined response time.
However, Cloud Fortified is not a guarantee that an app is free of vulnerabilities. It is also not a regulatory certification and does not remove the customer’s responsibility to assess whether an app is suitable for its environment.
Before installing any Marketplace app, customers should still review:
requested app permissions,
data accessed and processed by the app,
data storage and data residency,
external data transfers,
retention and deletion rules,
subprocessors and external services,
vulnerability and incident management,
support contacts and response commitments, and
the vendor’s privacy and security documentation.
The badge is a strong starting point for due diligence, but the information behind the badge remains just as important as the badge itself.
From a developer’s perspective, Cloud Fortified is not simply an application form or a one-time technical review.
The vendor needs to introduce and maintain processes around security documentation, vulnerability management, application monitoring, incident response, production readiness and enterprise support.
The security requirements include:
Completing all relevant questions in the app’s Marketplace Privacy & Security tab.
Enrolling the app in the Atlassian Marketplace Security Bug Bounty Program.
Giving external researchers sufficient access and time to test the app.
Reviewing submitted findings within the required time.
Remediating critical and high-severity vulnerabilities in accordance with Atlassian’s security timelines.
The reliability requirements add further work. Developers must assess the app’s scalability and performance, establish a documented service restoration plan, implement incident management processes and test core app functionality against Atlassian’s pre-release environment.
Cloud Fortified vendors must also provide a support contact and respond to critical requests within 24 hours, five working days per week in the partner’s local time zone. (Cloud Fortified requirements)
In practice, the reliability and support requirements can be just as demanding as security: incident response, SLO monitoring, and enterprise support commitments require ongoing operational ownership, not just a security workflow.
Participation in the Atlassian Marketplace Security Bug Bounty Program is one of the central Cloud Fortified requirements.
The program is operated through Bugcrowd, a platform that connects organizations with independent security researchers. Unlike an internal test performed by the development team, the bug bounty exposes the application to specialists who may approach its permissions, APIs, user roles and data flows in unexpected ways.
The typical process is:
The Marketplace Partner defines which applications and environments are in scope.
The partner prepares instructions, test accounts and setup information for researchers.
Bugcrowd invites researchers to the program.
Researchers test the app within the defined scope.
Potential vulnerabilities are submitted through Bugcrowd with reproduction details.
Bugcrowd’s Application Security Engineering team checks whether a report is reproducible and within scope.
A corresponding ticket is opened in Atlassian Marketplace Security (AMS).
The app developer accepts or rejects the triaged report within two weeks.
If accepted, the developer implements a fix, tests the remediation, and rewards the researcher based on severity.
To be shown as participating in the program on the Marketplace, an eligible app must currently be in scope for at least four weeks and at least 100 security researchers must have been invited. Going further, Atlassian now requires Marketplace bug bounty programs to be public, or actively scheduled to go public, by 30 June 2026. Programs preparing for public launch typically need at least 250 invited researchers for at least two weeks, along with other readiness checks such as a funded reward pool and a manageable queue of open critical findings.
Partners must accept or reject reports within two weeks after Bugcrowd has triaged them. Critical and high-severity findings must be remediated within Atlassian’s applicable security timelines. (Marketplace Security Bug Bounty Program)
Atlassian covers the Bugcrowd platform costs for Marketplace Partners. The app developer does not pay for access to the Bugcrowd platform and its services.
The Marketplace Partner is responsible for the rewards paid to researchers for valid findings.
At the time of writing, Atlassian specifies the following minimum payout structure:
Vulnerability severity | Minimum reward |
|---|---|
P1 – Critical | USD 1,500 |
P2 – High | USD 900 |
P3 – Medium | USD 300 |
P4 – Low | USD 100 |
P5 – No appreciable security impact | USD 0 |
Partners are requested to fund an initial Bugcrowd reward pool of at least USD 5,000. This is a pre-funded balance rather than an automatic fee. Rewards are paid from the pool for valid findings, and an unused balance can be returned if the program is closed. Partners may need to top up the pool as valid findings are paid out; underfunded programs can be paused.
Duplicate submissions generally do not require an additional payment, as the reward is normally paid only for the first valid report of a vulnerability. (Bug bounty program costs)
The financial cost is only one part of the investment. The vendor also needs to allocate engineering capacity to:
define and maintain the testing scope,
prepare test environments and documentation,
communicate with Bugcrowd and researchers,
reproduce and evaluate submitted findings,
implement and test fixes,
update dependencies or architecture where necessary, and
document the resolution.
The exact workload depends on the app’s complexity and the number and severity of reported findings. It should therefore be viewed as an ongoing engineering responsibility rather than a fixed one-time project.
A valid vulnerability report should not be understood merely as an additional cost. It is an opportunity to identify and resolve a weakness before it is discovered during a customer audit or exploited in a real customer environment.
“From a developer’s perspective, Cloud Fortified is not a one-off checklist. The initial work includes preparing a safe test environment, defining scope, documenting setup for researchers, and wiring Bugcrowd submissions into our normal development process. The recurring effort matters even more: each valid finding must be reproduced, assessed, fixed, tested, and documented – often while balancing remediation timelines for higher-severity issues. In practice, we don’t wait for the AMS ticket to appear before investigating; once Bugcrowd has triaged a report, we can already reproduce it and often prepare a fix. AMS then provides the formal tracking and compliance workflow with Atlassian. That takes real engineering capacity, but it provides continuous external feedback and a much clearer view of the app’s security than internal testing alone.”
Martin Fischer, Chief Developer at Sykora IT
The ongoing Bugcrowd bug bounty required for Cloud Fortified should not be confused with a traditional penetration test.
A bug bounty program runs continuously. Different researchers can examine the application over time and report vulnerabilities whenever they discover them.
A penetration test is a structured assessment with a defined scope, methodology and testing period. It is intended to provide systematic coverage of the application at a particular point in time.
Atlassian operates a separate Marketplace Penetration Testing Program, also through Bugcrowd. Vetted security researchers conduct grey-box testing against the production version of an app installed directly from the Marketplace.
According to Atlassian, most apps require approximately two to five testing days. The current cost is USD 1,000 per testing day and per app. Atlassian recommends annual or biannual testing, particularly after major releases or significant architectural changes. (Marketplace Penetration Testing Program)
The two approaches complement each other:
a penetration test offers systematic coverage during a defined period,
a bug bounty provides continuous exposure to a wider community of researchers.
For an enterprise application, external security testing should also be supported by secure development practices, dependency scanning, code review, access control testing and internal quality assurance.
Cloud Fortified does not make an application compliant with DORA, NIS2, ISO/IEC 27001 or any other regulation or standard. None of these frameworks specifically requires customers to use Cloud Fortified apps.
The program can, however, provide useful and verifiable evidence during supplier security assessments.
DORA requires financial entities to manage ICT third-party risk as part of their overall ICT risk framework. NIS2 includes requirements relating to supply-chain security, incident handling and vulnerability handling. ISO/IEC 27001 uses a risk-based information security management approach, while the ISO/IEC 27036 series addresses information security in supplier relationships more specifically. (DORA, NIS2, ISO/IEC 27001, ISO/IEC 27036-2)
Cloud Fortified can support these assessments by providing evidence of:
transparent security and data handling information,
independent vulnerability testing,
defined vulnerability remediation processes,
documented incident management,
reliability practices, and
established support responsibilities.
This can reduce the amount of uncertainty during an audit. It does not replace the customer’s own risk assessment, contractual review or compliance obligations.
At Sykora IT, we completed the Cloud Fortified process for Azure Sync for Jira Assets, our Forge-based app for synchronizing Microsoft Azure resources and Microsoft Entra ID objects into Jira Assets.
The app’s Marketplace listing displays the Cloud Fortified trust signal and confirms its participation in the Marketplace Security Bug Bounty Program.
For enterprise customers, general statements such as “our application is secure” are rarely sufficient. Their security and compliance teams typically require documented answers about app permissions, data flows, storage, external services, vulnerability testing, incident handling and responsibilities.
The Cloud Fortified process gives the vendor a structured basis for providing this evidence.
“Cloud Fortified has a clear business value for us. It enables us to sell Azure Sync for Jira Assets to enterprise customers with stronger and verifiable security evidence. It helps us successfully pass customer security and compliance reviews, while also giving us greater confidence that we are delivering a product whose security is continuously challenged and improved.”
Petr Sýkora, CEO of Sykora IT
For a small experimental app intended primarily for individual teams, the financial and operational investment may initially appear disproportionate.
For a commercial Marketplace application targeting enterprise customers, our conclusion is clear:
Yes, investing in Cloud Fortified-level security and operational maturity is worth it.
The investment brings several benefits:
earlier identification of security vulnerabilities,
independent testing beyond the internal development team,
clearer vulnerability management and remediation processes,
improved visibility into the app’s actual security posture,
stronger evidence for customer audits,
greater trust from enterprise customers, and
less friction during procurement and security reviews.
Cloud Fortified does not guarantee that an enterprise customer will purchase the app. However, a lack of verifiable security controls can prevent an app from passing the customer’s initial supplier assessment at all.
The badge is the visible result. The more important benefit is the security and operational maturity developed while earning and maintaining it.
Atlassian has announced that the Cloud Fortified program will be phased out by the end of 2026 and replaced by Atlassian Enterprise Certified.
The new program raises the enterprise standard further. Its published requirements include, among other things:
evidence of a current annual penetration test,
a public bug bounty program, or one in the process of becoming public,
documented architecture and data flows where data leaves Atlassian,
vulnerability scanning in the development pipeline,
a public trust center,
SOC 2 Type II or ISO/IEC 27001,
a documented incident management process and public status information,
accessibility documentation, and
a responsible AI policy for apps that use AI.
Atlassian states that onboarding is planned to begin in Q3 2026. When onboarding begins, Atlassian will stop accepting new Cloud Fortified applications, and the existing program will subsequently be phased out. (Atlassian Enterprise Certified requirements)
This transition does not make the investment in Cloud Fortified obsolete. The processes established for Cloud Fortified—including external vulnerability testing, security transparency, incident management and enterprise support—create an important foundation for the new program.
Developers beginning this journey in 2026 should therefore focus not only on obtaining a particular badge, but on building sustainable enterprise-grade security and operational capabilities.
When selecting apps for business-critical or regulated environments, we recommend prioritizing apps that provide strong trust signals such as Cloud Fortified and, once available, Atlassian Enterprise Certified.
Administrators should also review the evidence behind the badge:
What information and permissions does the app require?
Where is customer data processed and stored?
Does any data leave the Atlassian environment?
Which subprocessors or external platforms are involved?
Does the vendor operate a bug bounty program?
Has the application undergone a recent penetration test?
How are vulnerabilities and security incidents handled?
Is there a dedicated security and support contact?
Are retention and deletion rules clearly documented?
A badge makes initial selection easier, but responsible app governance still requires examining the underlying security information.
For developers targeting enterprise customers, we recommend investing in the controls and processes represented by Cloud Fortified and its successor, Atlassian Enterprise Certified.
This investment can provide access to more security-conscious and business-critical customers. Just as importantly, it gives the development organization greater visibility into and control over the security of its own application.
Based on our experience with Azure Sync for Jira Assets, Sykora IT can support Marketplace developers with:
Forge app architecture and security reviews,
preparation of Marketplace privacy and security documentation,
Bugcrowd program preparation and scope definition,
evaluation and remediation of reported vulnerabilities,
reliability and incident management processes,
enterprise customer security questionnaires, and
preparation for Atlassian Enterprise Certified requirements.
The final badge matters. The security maturity developed while working towards it is even more valuable.
We would like to share our experience connecting USM (USU Service Management) with Jira. Introduction USU Service Management (USM) is an IT Service Management (ITSM) software solution developed by the German company USU. It supports ITSM processes, Service Desk operations, and more. The platform is highly customizable and can handle
Migrating to Jira Service Management: Challenges and Best Practices Why Migrating to Jira Service Management Is More Than a Data Import Organizations modernizing their IT Service Management (ITSM) landscape increasingly choose Jira Service Management (JSM) as their strategic platform. Whether the source system is USU Service Management (USM), Redmine, ServiceNow, Matrix42,
OCR Rovo Capabilities: From Smart Chat to Full Automation When working with Rovo and AI capabilities in Atlassian tools, image understanding plays a key role in how efficiently teams can extract and use information. Today, we’re looking at the differences between how Rovo and our app AI Screenshot Insights for Jira