I would agree with someone suggesting “Atlassian Trust Certified” being a better name.
Also, I’d like to come back to the purpose of this change. Is this to signal to enterprise orgs that the app supports all their safety requirements? Is there a chance, however, that this will at all reduce the amount of security questionnaire requests that vendors still get from these same enterprise orgs every day, or is it just another checkbox that we will be required to tick, and they are not going to look at anyway? Is it actually going to solve the problem? The approval and procurement process doesn’t seem to care what badges we have or what we have in the Trust Center with Vanta, because they ask the same questions anyway.
So perhaps could we go the other way and just have a unified way for apps to securely answer all of those without having to dig through the terminology of what each and every badge and term means? I assume they have a checklist of what they find acceptable or what they must report on, so why not just provide that, in a unified form for vendors instead of another hoop that we have to jump through but no one actually needs?
As I already mentioned, this rule can easily be circumvented. I understand the desire to prevent unrestricted network access and I don’t have a better idea to contribute. But maybe the rule should be dropped if it’s not possible to enforce anyway. Some apps also use wildcard egress to allow the usage of popups, which would become blocked with this rule, which might not be the intention of this rule.
To be clear, we wouldn’t be impacted by this rule, but I don’t think it fulfills the goal of having actual verification:
Since naming is still causing so much discussion, maybe the general approach of picking one name for a set of apps that fulfill a certain set of criteria should be reconsidered?
What if instead the Marketplace had a set of badges and/or filters for apps with:
a bug bounty program,
a compliance certification (SOC2, ISO),
a Trust Center (if that’s a concern),
that use the standard agreement.
For all of these, there should be a filter in the Marketplace so customers can easily find the ones that match their criteria. These badges/filters are objective and do not require a name to be invented.
For the remaining requirements, such as
app does not collect or store credentials
app does not use any Connect modules
app logs must not include personal data or credentials
publicly available privacy policy
app has a Voluntary Product Accessibility Template (VPAT) publicly available
which may not be a good fit for a badge/filter, there could still be a badge called “Atlassian reviewed” that attests that Atlassian has done some checks with the partner and verified that these criteria are met.
If marketing still requires a name like “Enterprise ready”, Atlassian could still associate a filter/badge set with that specific name, but at least it would be quite transparent which filters/badges/criteria apply to that particular name.
One more benefit, and maybe the most important one, is that this isn’t an all-or-nothing approach for partners and customers.
Hey @scottohara, we hear you. This new program is intentionally different. It’s based on multiple requirements, and a lapse in any one requirement won’t automatically remove the badge. We’re still finalising the operational details, but our intent is to have clear verification steps and appropriate grace periods before any badge state changes. We’ll share more specifics as they’re locked in.
Hi @AndreasReif. Great feedback. Your interpretation A is the intended scope: the requirement is that the app discloses the integrations/subprocessors it uses, and the vendor’s own data retention and deletion policies for any data egressed from the app. We’re not asking vendors to document each subprocessor’s retention/deletion policy.
Here is the proposed update to the requirement:
The app clearly discloses all third-party integrations and subprocessors, and provides app-level data retention and deletion policies covering any data egressed from the app.
This new trust program is one part of a larger effort to evolve how trust is represented on Marketplace. Beyond the program itself, we’re also working to surface more granular trust signals e.g., compliance, security programs (like pen tests), and data residency, and implement trust-based filtering so that customers can quickly identify apps that meet their specific procurement requirements. This is called out in RFC-124 as part of the broader vision.
Anastasiya, on your question around security questionnaires specifically, we want to be transparent here. As noted in RFC-124, this new trust program 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 most likely remain a thing. However, the program will help partners obtain the necessary information to complete the questionnaires more quickly and efficiently.
The goal here isn’t to add a hoop nobody looks at; it’s to create a shared, verifiable baseline that benefits both partners and customers.
but it would be great to understand the timelines for the new programme, or at least when we should expect the announcement. This would help vendors, who may have identified qualifying gaps, with prioritisation.
Once we close out this RFC, we will switch to execution mode and begin developing the processes and procedures for this new trust program.
We are keen to announce the new trust program to customers at Team EU in early-October.
We then propose to retire the Cloud Fortified Apps badge at the end of December 2026.
Between the announcement of the new trust program in early-October and the end of 2026, Cloud Fortified and the new trust program will coexist to ensure continuity for both partners and customers.
These dates are subject to change, but I hope this gives you an idea of our current thinking.
An additional point, though it’s all semantics, in a number of instances, e.g., 1.3, we talk about data being publicly available with the validation being that it can be a private document under NDA/password. Tightening the language in these cases will remove ambiguity and help vendors (and customers!) to better understand what is advisory and what is compulsory.
Good feedback, we will take this on board and ensure the wording is clear and unambiguous.
As someone who is considering entering the marketplace more deeply, I agree with this point.
If you wish for the largest possible agreement of an “objective naming convention” for the program you can’t really mark your own homework and then expect you’ll bring along all of the influential members of this community.
Hey @scott.dudley, apologies for the delay, been busy making this program happen in the background To answer your questions:
Wording change on the vulnerability requirement
Based on your suggestion, we’ll update the RFC text to align directly with the Cloud Security Policy. The revised requirement will read along the lines of:
Apps must not use third‑party dependencies or packages with known Critical and High severity vulnerabilities at onboarding, and must prioritise patching when new vulnerabilities are disclosed.
We’ll remove the “especially” phrasing and make sure the CSP linkage is explicit in the RFC. Another note is these are CVEs Atlassian detects with their scanners with a fix available, we don’t ticket open ended CVEs unless it’s a critically vulnerable EOL software issue.
Human-in-the-loop badge withdrawal
Badge removal will not be fully automated or based on a single failed check. Instead, we’ll use a compliance coverage model and a violation workflow:
Badges are based on overall compliance across requirements, not a strict binary pass/fail at any moment in time. A scorecard will be available to partners for live audits.
Temporary gaps (for example, a pen test that expires while a new test is being scheduled) are handled as tracked violations with SLOs and a remediation window, not instant badge loss.
If a violation persists beyond its SLO, it goes through an exception review. Only after that review, and with a human making the final call, would a badge be withdrawn. This would be different compared to Cloud Fortified today, where the scale of apps is much larger and badge turnaround is faster.
On the permission analysis requirement, we’re not walking it back from the RFC, but we are tightening how we describe enforcement and feature-flagged code:
The scanner validates whether scopes are actually called via an API or required in code, even when usage is behind a feature flag.
As long as Atlassian has at least one artifact containing usage of the code path (for example, in a code snapshot or build we analyze), the SAST scanner will treat that permission as used and will not flag it as “excessive”.
Enforcement will continue to be based on ample data, the same way we operate today. We won’t enforce on thin or noisy signals, especially where abstraction layers or remotes are involved. There’s some follow up work here for forge remotes analysis which we’ll be prioritizing.
For pre‑emptive permission requests and release tracks:
We recognize that apps often need to request scopes ahead of launch to avoid fragmenting versions or breaking existing installs.
We’ll work internally with Ecosystem Platform to prioritise support for this use case (including permission-change re‑prompts / re‑consent flows) before we tighten enforcement on unused scopes in the Enterprise program.
I may not have a clear answer on this today but expect a resolution by the time the scorecard and badging process is released. We’ll likely be validating this during EAP with design partners.
I am seeing these questions in the Security Questionnaire and I think this is an enterprise ready requirement to NOT use script src unsafe-inline, unsafe-eval, unsafe-hashes. Also style src unsafe-inline.
Currently we use Atlaskit Components with Emotion/Styled components and I think we can refactor everything to not use script unsafe-* stuff, but the style unsafe-inline needs to be allowed as long as atlas kit uses it.
Are there any plans to move to Vanilla Extract to not have runtime css-in-js logic with tags injected during runtime? The library looks promising.
Will style unsafe-inline be allowed in enterprise ready?
Hey everyone, as I close out this RFC, I would like to thank you all for your engagement. As always, I appreciate your honest and candid feedback.
On the program requirements and validation steps
Overall, it seems that the updates to the requirements (e.g. wording changes, deferrals, and removals) have been well received. There are still some open questions around specific requirements, and while we haven’t been able to respond to every comment, we’ve heard you and taken all feedback on board.
On the program name
This was clearly the topic that generated the most discussion, and your feedback has surfaced genuinely valuable perspectives. We’re continuing internal discussions to ensure the badge clearly signals who it’s for and what it represents, while being extra mindful of the implications of not having it. We will follow up with a Partner Portal update here when we have a new name, and also surface it in the monthly Partner Digest.
What happens next
We will now focus on operationalising the trust program rollout.
We plan to announce the new trust program to customers at Team EU in early October and retire the Cloud Fortified Apps badge by the end of December 2026.
Note: Between the announcement of the new trust program in early-October and the end of 2026, Cloud Fortified and the new trust program will coexist to ensure continuity for both partners and customers.
If there are any changes, we will provide updates on the existing QRG here.
To answer your questions: