RFCs are a way for Atlassian to share what we’re working on with our valued developer community.
It’s a document for building shared understanding of a topic. It expresses a technical solution, but can also communicate how it should be built or even document standards. The most important aspect of an RFC is that a written specification facilitates feedback and drives consensus. It is not a tool for approving or committing to ideas, but more so a collaborative practice to shape an idea and to find serious flaws early.
Please respect our community guidelines: keep it welcoming and safe by commenting on the idea not the people (especially the author); keep it tidy by keeping on topic; empower the community by keeping comments constructive. Thanks!
Project Summary
Atlassian is looking to evolve its Ecosystem Trust program, simplifying and streamlining the process for customers to discover and procure cloud apps from the Marketplace.
By simplifying trust programs, uplifting security requirements, and surfacing more transparent, verified trust signals, we will help streamline the app procurement for customers and Marketplace partners.
Note: The solutions set out below apply only to cloud apps. DC apps are out of scope (unless specifically stated).
Following extensive customer research and collaborative discussions with our partners, we have decided to:
- Retire our legacy trust programs—Cloud Fortified and Cloud Security Participant—while continuing to recognize partner investments in these initiatives, including Bug Bounty by surfacing these trust signals on the cloud app listing pages.
- Launch a new, app-focused trust program: Architected for Atlassian (A4A). This program will be available to apps that meet rigorous standards for security, reliability, performance, privacy, and compliance.
- Implement the Runs on Atlassian (RoA) and A4A programs independently of each other. The A4A program will be available to RoA apps, apps that egress data (beyond what is allowed under RoA), or apps that require integrations with remote services.
In addition, we plan to:
- Enhance trust signals by making them clearer, more visible on the app listing, filterable and backed by increased verification and transparency.
- Continue to encourage partners to adopt industry standards and showcase these investments via third-party trust centers (e.g. Vanta, Safebase, Drata).
As part of this RFC, we would greatly appreciate your feedback on the following:
- The proposed list of A4A requirements
- The proposed list of trust signals to be surfaced on the app listing
- The proposed list of trust filters to be made available on the Marketplace
Publish: 15 Jan 2026
Discuss: 28 Jan 2026
Resolve: 3 Feb 2026
Problem
We have identified several opportunities to strengthen and elevate our approach to trust, enabling us to better serve our shared customers while more effectively highlighting partner investments in trust and security. Through conversations with a range of customers, we have uncovered a few common themes:
- Customers often don’t understand what our trust signal badges mean or what requirements are needed to obtain them. However, they know they “represent” trust, so they put a lot of faith in them when making choices.
“So, if your app’s not in Cloud Fortified, it’s not being discussed."
- The specifics of the badges on the Marketplace are unclear; it is not immediately obvious what additional security, reliability, and support they offer.
“Cloud Fortified’? No idea what it means.
- Customers are confused by multiple overlapping trust signals (Runs on Atlassian, Cloud Fortified App, Cloud Security Participant, etc.).
“I’m not sure what the difference between ‘Cloud Security Participant’ versus ‘Cloud Fortified’ would be.”
- Enterprise customers want more transparency, assurance, and actual verification from Atlassian, not just partner attestation.
“We take [the Privacy & Security tab] as verified and accurate”
Proposed Solution
1. Simplify trust programs
Simplifying the number of trust programs we have will eliminate the current confusion caused by overlapping and unclear trust signals. This will enable customers to confidently evaluate apps and streamline the procurement process.
We will reduce the number of trust programs on the Marketplace to two. These will highlight the most critical trust signals that customers are looking for.
As part of this simplification, we will be retiring the Cloud Fortified App (CFA) and Cloud Security Participant (CSP) badges.
However, the investment partners have made as part of these programs will continue to be highlighted as part of the trust signals shown on the app listing and filters, including the Bug Bounty program.
How will the two trust programs work together?
We’ll use two different lenses:
-
WHERE does the app process and store my data?
- For apps running on Atlassian’s infrastructure, with only the limited data egress allowed by ROA .
- Program: Runs on Atlassian (RoA): Existing
-
HOW is the app built and run in a secure, reliable and performant way?
- For apps that meet rigorous standards for security, reliability, performance, privacy, and compliance.
- New program: Architected for Atlassian (A4A): New
| Trust Program | Trust signal | Description |
|---|---|---|
| App is not part of any trust program | Neither WHERE nor HOW | Standard Marketplace app, customers use their normal vendor risk review process. Criteria:
|
| App is part of the RoA Program | WHERE‑only | Customer data doesn’t leave Atlassian infrastructure (except as allowed under RoA), but the app hasn’t yet met all the requirements for A4A. Criteria:
|
| App is part of A4A Program | HOW‑only | Customer data may be processed and stored outside Atlassian’s infrastructure, but the app has met the requirements for A4A Criteria:
|
| App is part of RoA and A4A programs | Both WHERE and HOW | Customer data doesn’t leave Atlassian infrastructure (except as allowed under RoA), and the app has met the requirements for A4A Criteria:
|
Proposed requirements for Architected for Atlassian (A4A)
The Architected for Atlassian (A4A) program should highlight to customers that a cloud app has been architected to be secure, reliable, and performant.
We believe the following requirements will ensure that customers are assured the app is built and run in a well-architected manner.
The list below is not exhaustive and is being used to gather your feedback.
| Req. # | Requirements | New/existing requirement? |
|---|---|---|
| 1.0 | Security | |
| 1.1 | Annual penetration testing report available (see more details about our new penetration testing program below)* * Penetration tests must be carried out by a CREST-accredited company |
New |
| 1.2 | Public security vulnerability reporting using Atlassian’s Bug Bounty program. | Current requirement for:
|
| 1.3 | The app does not use any Connect modules | Current requirement for:
|
| 1.4 | The app does not collect or store credentials belonging to Atlassian user accounts, such as user passwords or user API tokens. | Part of the current security requirements for Cloud Apps |
| 1.5 | All data at rest must be encrypted | Part of the current security requirements for Cloud Apps |
| 1.6 | The app only requests access to the data it needs (least privileged access) | Part of the current security requirements for Cloud Apps |
| 1.7 | The app logs must not include UGC content*, personal data**, or credentials. * “UGC content” is defined as titles, descriptions, comments, attachments, search queries etc. ** “Personal Data” is defined as information about an identified or identifiable natural person, or which otherwise constitutes “personal data”, “personal information”, “personally identifiable information” or similar terms as defined in Applicable Data Protection Law. Read more: Data Processing Addendum |
New |
| 1.8 | The app is not using private/undocumented Atlassian API endpoints | New |
| 1.9 | Any Atlassian end user data stored outside the Atlassian product or users’ browsers must use full disk encryption at rest | Part of the current security requirements for Cloud Apps |
| 1.10 | Any Atlassian End User Data accessed by an application or a service should be authenticated and authorised appropriately | Part of the current security requirements for Cloud Apps |
| 1.11 | The app must not use unmaintained/deprecated libraries or end-of-life NodeJS runtimes | Part of the current security requirements for Cloud Apps |
| 1.12 | All outbound (egress) domains must be explicitly listed to prevent unrestricted network access. Note: subdomain wildcards (.domain.com) are acceptable, while full wildcard () entries are not. |
New |
| 1.13 | Vulnerability Scanning | Part of the current security requirements for Cloud Apps. Read more about our ecoscanners. |
| 1.14 | Respects rate-limiting headers | New |
| 1.15 | App must default to asUser() when performing an action on behalf of the user | Part of the current security requirements for Cloud Apps |
| 2.0 | Reliability | |
| 2.1 | The app consumes APIs efficiently (utilising bulk APIs, field expansion & limiting parameters where appropriate) and scales to enterprise data volumes and activity thresholds. User experiences degrade gracefully with appropriate user and admin messaging when rate limits are exceeded. |
New |
| 2.2 | Publicly defined SLI/SLO reliability metrics | Partially required for:
|
| 2.3 | Publicly documented incident management process, including a public Statuspage | Partially required for:
|
| 2.4 | Participation in a collaborative incident response program with Atlassian | Partially required for:
|
| 3.0 | Performance | |
| 3.1 | Performance requirements are still being considered. An RFC on this topic is expected to be released in the coming months. |
New |
| 4.0 | Privacy & Compliance | |
| 4.1 | SOC 2 Type 2 or ISO27001 Read more about how we are supporting our partners in obtaining SOC 2 or ISO27001 with our partnership with Vanta. Note: the linked document focuses on Silver partners, but please reach out if you are interested in this program, regardless of your partner status. |
Current requirement for
|
| 4.2 | The app supports Data Residency (pinning and migration) | New |
| 4.3 | The app clearly discloses all third-party integrations, along with data retention and deletion policies, for any data egressed from the app | New |
| 4.4 | Public trust center available | Current requirement for:
|
| 4.5 | Publicly available Privacy policy | Current requirement for:
|
| 5.0 | Accessibility | |
| 5.1 | The app has been accessibility tested, and a Voluntary Product Accessibility Template (VPAT) is publicly available | New |
| 6.0 | Migration (if the app has a DC equivalent) | |
| 6.1 | The app has an automated migration path from Data Center to cloud | New |
| 6.2 | Migration documentation is publicly available | New |
| 6.3 | Feature parity documentation is publicly available | New |
| 7.0 | AI & Responsible Use (if the app uses AI) | |
| 7.1 | The app conforms to Atlassian’s Responsible Technology Principles | New |
| 7.2 | The app uses Forge LLMs where practical, and may only use external AI services for scenarios that Forge LLMs don’t support. For example, when a use case requires a custom‑trained model or a modality that Forge LLMs don’t provide. |
New |
Updates to the A4A program and its requirements
The requirements for A4A may change over time as Atlassian and the trust/security landscape evolve. New requirements may be added, or obsolete requirements removed. Sufficient advance notice will be given when requirements change.
A4A review cadence
We expect the A4A program to follow a similar review cadence to the Cloud Fortified Apps program, with annual reviews to ensure an app continues to meet the A4A requirements.
How would we retire the CFA and CSP badges?
We are conscious that the retirement of the CFA and CSP badges will have an impact on our partners and customers. To ensure a smooth transition, we propose the following rollout plan (note: this is subject to change):
| Milestone | Proposed date |
|---|---|
| Announce to the developer community the new trust program changes, including the retirement of CFA and CSP | This RFC, as well as at Atlas Camp (9 Feb, 2026) |
| Ensure CSP trust signals are displayed on the app listing page | End-March, 2026 |
| Retire the CSP badge | End-March, 2026 |
| Begin to add more trust signals (see below) on the app listing page, including those that are part of the CFA program. | May - June, 2026 |
| Implement more trust filters on the Marketplace | May - June, 2026 |
| Retire the CFA program and launch A4A* | TBD |
* We propose retiring the CFA program as we launch the new A4A program to customers. This will ensure customers continue to have a trust badge they are familiar with until we introduce the new A4A program.
2. Implement more trust signals on the app listing
We propose highlighting trust signals more clearly on the app listing. These trust signals should be used in conjunction with and complement our trust programs.
We propose to surface the following trust signals (as they become relevant):
- 24/7 support (this could be via a premium/paid support package)
- Industry standards:
- SOC 2
- ISO27001
- Annual penetration testing report available
- Public security vulnerability reporting (Bug Bounty)
- Public Trust Center
- Supports Data Residency
- Option to use Standard Legal Agreement
3. Add more trust signal filters to the Marketplace homepage
Different customers have different trust requirements. We should allow customers to filter apps based on the trust requirements that are important to them.
We propose adding the following filters (as they become relevant):
- Trust programs:
- RoA
- A4A
- Industry standards:
- SOC2
- ISO27k
- Annual penetration testing report available
- 24/7 support (this could be a premium/paid support package)
- Public security vulnerability reporting (Bug Bounty)
- Public Trust Center
4. Uplift our security requirements
Requirement for Bug Bounty Programs to be public by default
To strengthen security assurances for customers, we will be requiring all bug bounty programs be public by June 30th, 2026, and should be in progress by March 1st, 2026.
Public programs are easier for researchers to find and participate in, providing a clear, incentivized way to report vulnerabilities. Our analysis of the last four years of bug bounty data shows that public programs see higher-quality engagement and more meaningful findings, which directly improves security outcomes for customers and partners.
We understand you may have concerns regarding the financial impact, noise, and distraction caused by this increased traffic. The migration process will be a gradual, managed rollout, not an overnight switch. Before a program goes public, Atlassian and Bugcrowd will work with you to tighten scopes and targets, invite additional researchers to ramp-up, and set strict expectations to minimize low‑value reports. You can expect an increase in submissions, but our goal is for that increase to be high-signal and manageable, not overwhelming.
Read more: Making your Bug Bounty Program Public
New Penetration Testing Program
We’re opening up early access to a penetration testing program through our partnership with BugCrowd, offering pre-negotiated competitive pricing for Marketplace Partners to test their cloud apps. Discovered findings are reported through the AMS Jira project, and pentest reports and attestations are provided for you to share with customers.
Note: For partners locked into existing contracts for penetration testing, Atlassian will support reporting these findings to earn similar trust signals, provided they are on the CREST-approved PenTester list and are remediated within the Marketplace Bug Fix timelines.
Read more: https://developer.atlassian.com/platform/marketplace/marketplace-penetration-testing-program/
5. Continue to encourage partners to invest in industry standards and external Trust Centers
Customers rely heavily on industry standards (e.g. SOC 2, ISO27k etc.). They also rely on external trust centers for gathering documentation.
We believe these changes will lead to improved:
-
User Experience:
Customers will see clearer and more meaningful trust signals on app listings, with the ability to filter apps by trust criteria relevant to their organization. -
Developer Experience:
Partners will have a streamlined path to achieving trust recognition, with clear requirements and guidance in place. Retiring legacy badges will reduce confusion and administrative overhead, while displaying trust signals directly on listings will better highlight and reward ongoing investments in security and compliance. -
Trust Experience:
Trust signals will be based on verification rather than partner attestation, with a focus on industry standards and publicly available evidence.
What the solution won’t address
Even though customers use our trust signals as a decision-making filter when discovering apps, based on our research, we believe the following won’t be addressed by our trust programs and signals:
- The solution will not eliminate the need for customers to send partners security questionnaires: both customers and partners have confirmed that, despite vendor-specific trust programs and compliance certifications, security questionnaires will remain necessary. However, the program will help partners obtain the necessary information to complete the questionnaires more quickly and efficiently.
- The solution will not eliminate the need for compliance certifications; we will continue to recommend and mandate partners pursue SOC 2 or ISO 27001. These industry standards help security and risk teams expedite procurement processes.
Additional asks
While we would appreciate any reactions you have to this RFC (even if it’s simply giving it a supportive “Agree, no serious flaws”), we’re especially interested in learning more about:
- For the new Architected for Atlassian program, do you agree, in principle, with the requirements detailed above?
- Are there any requirements you think shouldn’t be included?
- Are there any requirements missing?
- What tooling or platform support would you expect from Atlassian to successfully participate in the A4A program?
- Do you believe the timeframe for retiring the Cloud Security Participant badge (end of March, 2026) is reasonable?
- Are there any other trust signals from the Cloud Fortified Apps program that should be surfaced on the app listing once we retire this badge, beyond participation in the Bug Bounty program and providing critical support within one day, five working days a week?
- Are there any trust signals that we should surface on the app listing that are not mentioned above? Are there any we should consider omitting, and if so, why?
- Are there any trust filters that we should surface on the Marketplace that are not mentioned above? Are there any we should consider omitting, and if so, why?
- Are there any trust or procurement challenges that the proposed changes don’t address?
- What ongoing pain points do you experience with our current trust programs, and how could we address these?
- Should we allow users to report inaccurate P&S tab information? How would you see this process working?
- Are you interested in the new penetration testing program?
- Do you already conduct penetration testing?
- If so, where do you usually publish your pen testing reports?
If you would like to provide feedback in a 1:1 conversation, please use this RFC: Partner Feedback form.
