RFC-133: Evolving the Marketplace Trust Program (follow up to RFC-124) - Trust program requirement updates and validation steps

General Request for Comments (RFC)
, , , ,
21

Here’s how it will play out:

  1. Let’s say 5% of apps marketplace-wide can justify the hoops and $2-5k/yr/app.
  2. Only these 5% will be badged as “Enterprise-Ready”.
  3. Thus 95% of apps are signalled to customers as not enterprise-ready.
  4. Thus the longtail of installs marketplace-wide will drop substantially.
  5. Thus revenues marketplace-wide will drop substantially.

You know “enterprise” in this industry simply means business-use right?

You’d very literally be signalling that 95% of apps on the marketplace are not fit for business-use.

Just because Atlassian uses the term in a sizing context doesn’t mean it copies across into a marketing context. The typical customer installing apps on the Atlassian Marketplace reads “enterprise” as business-use and not “enterprise means 100k+ seats”.

How would Atlassian like it if we partners started saying that Confluence was “Enterprise-Ready” but Jira was not? That’d be bad right? Nobody would want to use Jira regardless of their seat size. Can you see the parallels here? Run it by marketing, fellas.

And if the marketing team are bizarrely fine with this decision you’d still literally be signalling to those 100k+ seat customers that only 5% of the marketplace apps are fit for their use.

That will directly result in a substantial decrease in cumulative installs and revenues marketplace-wide.

22

If we stack on the additional requirement that only platinum vendors who have SOC/ISO certification can build “Enterprise Ready” apps as well, the 5% may be too optimistic.

23

Hi @ZacharyEchouafni ,

Again Atlassian partners are asked to ship apps without vulnerabilities, while we have to use Atlassian dependencies riddled with security vulnerabilities and outdated software (e.g. see https://community.developer.atlassian.com/t/raising-the-bar-on-marketplace-cloud-app-security-together/98750/4 and Action Required for Marketplace App Developers - Axios npm Supply Chain Compromise - #2 by marc ).

When is that going to change?

24

Thank you all for the thoughtful feedback on the program naming. This is clearly the topic currently generating the most discussion.

Let me address the alternative suggestions, because you’ve collectively proposed some good ones:

  • “Atlassian Trust Certified”: suggested by @AaronMorris1
  • “Enterprise Certified”: suggested by @scott.dudley
  • “Atlassian Security Verified” and “Atlassian Verified”: suggested by @PrinceNyeche

Here’s the challenge I’d like to put back to the community: no matter what we call the program, apps without the badge will carry an implied negative.

If we named the program “Atlassian Trust Certified”, does that mean an app without the badge is not trusted by Atlassian? As @scott.dudley noted:

“the absence of a particular badge implies that an app that does not have the badge does not have the attribute”.

Unfortunately, that problem doesn’t go away with a different name; It feels like “Atlassian Trust Certified” would create a bigger risk for apps without the badge than “Enterprise Ready.”

If it’s “Atlassian Security Verified”, does an app without the badge mean it’s unverified, or insecure? Not necessarily. An unverified app isn’t automatically insecure, it just hasn’t been through the validation process.

I take @remie’s point, the badge represents Atlassian’s defined set of requirements, not a universal definition. But that same caveat applies to any name we chose. This is the inherent tension with any badging program; it isn’t unique to the “Enterprise Ready” naming.

Please don’t get me wrong, I am not criticising the proposed names at all, I just want you to know that, internally, we have wrestled with all the same issues you are raising.

@nathanwaters raised a pointed concern:

“The language choice here literally signals to potential customers that any app without this badge is not fit for enterprise-use.”

This is why the badge is not the only trust signal we’re investing in. As outlined in RFC-124, we’re adding granular trust signals and filters directly into the Marketplace, things like: compliance status, pen testing report, bug bounty participation, and data residency. We will make these visible in every app listing, regardless of badge status. The Enterprise Ready badge is meant to be the top tier for apps that meet the full set of requirements, which will be clearly documented for customers. Our goal is that no customer ever feels an app is untrustworthy simply because it doesn’t hold the top-tier badge.

@PrinceNyeche makes an important point:

“Different organisations define ‘enterprise’ very differently, for some it’s security and compliance, for others it’s scalability, governance, or data residency.”

Completely agree! When we talk about “Enterprise” here, we are referring to Atlassian’s definition of Enterprise in the Cloud and not necessarily any other industry defined term. Atlassian’s Cloud Enterprise customers are the focus for this new trust program. When we ran these requirements past one highly regulated enterprise customer in the financial services industry who is currently migrating to Cloud, they told us.:

I can see this massively helping to reduce the onboarding time for us.

While we don’t claim to have addressed every enterprise need for all customers, we are focusing on the critical requirements of the Atlassian Cloud enterprise customers we have collaborated with. I am sure we will hear feedback from other customers saying things like “well, we consider X or Y to be critical for an app to be enterprise ready”, and we will take this feedback on board and refine the program over time.

We will be very transparent with customers about Atlassian’s definition of “Enterprise Ready” by publicly documenting the eligibility requirements. We will also welcome customer feedback on these requirements. Again, looking at the proposed names here, whatever we call the program would require us to be very transparent in our documentation, explaining what the badge actually means in practice.

@Stavros_EasyApps says,

“it needs to have clear and understandable value for customers”.

“Enterprise Ready” resonates with the enterprise procurement audience we’re targeting; it speaks their language. But we hear you, and we’ll continue to pressure-test the name with enterprise customers and procurement teams and we’ll use that data to inform how we communicate the badge, not just what we call it.

I think we can all agree that naming is genuinely hard. Every option creates implications for apps that don’t have the badge. We’re trying to find the name that creates the right signal for the right audience.

Cheers, Phil.

25

Hey all, thanks for your engagement so far on this RFC. Hopefully, I have addressed the naming debate in my reply above, so I’d like to steer the conversation back to the original feedback requests for this RFC.

The intent of this RFC is to capture feedback on the requirements of the new trust program and the validation steps to assess them, and I would like to thank the partners who have provided constructive feedback on this so far. However, this is not the forum to debate whether we should introduce this new trust program or not.

We have undertaken extensive customer research and validation ahead of proposing these changes and we want to assure you that these updates are not something we have taken lightly.

For clarity, when we talk about “Enterprise” here, we are referring to Atlassian’s definition of Enterprise in the Cloud and not necessarily any other industry defined term. Atlassian’s Cloud Enterprise customers are the focus for this new trust program.

I’m not dismissing the concerns you’ve raised about program impact, but we have clear signals from our customers that they want to see a higher trust bar across our Marketplace, and we believe that this new program, along with surfacing more granular trust signals and filters on the Marketplace will achieve this.

So, to reiterate, the asks for this RFC are:

  • Clarity & objectivity: Are there any requirements where the wording or the validation method feels vague, subjective, or open to inconsistent interpretation? Please provide suggestions on how this could be improved.
  • Evidence expectations: For requirements that rely on your trust center or documentation (e.g. logging, architecture diagrams, subprocessors), is it clear exactly what you’d need to publish?
  • Gaps: Are there any critical enterprise trust expectations you believe should be in the Enterprise‑Ready program but are currently deferred or missing?

If you would like to talk further about the implications this trust program may have on your business, I would be more than happy to discuss this in a 1:1 setting. Please feel free to reach out to me via DM.

Cheers, Phil.

26

Hi Philip,

I have a question about the scope of “data retention and deletion policies” in this requirement.

Interpretation A: The app must disclose (1) all third-party integrations and subprocessors, and (2) the app vendor’s own retention and deletion policies for egressed data.

Interpretation B: The app must disclose all third-party integrations and subprocessors together with each subprocessor’s own retention and deletion policies.

Could you clarify which interpretation is correct, or whether both are expected?

27

Don’t use words then. Just use checkmark icons on app listings.

You can still name the program something benign like “Atlassian Verified” but only show that on hover. “Unverified” is a fact about whether an app has been through Atlassian’s security checklist. “Not ready” is a verdict on the app itself which literally signals “not suitable for business-use” (catastrophic decision).

Plenty of precedent:

Every platform that’s solved this converged on the same shape: neutral glyph on the listing, attribution-clear name in the tooltip.

You then have the option to do tiers based on colours (eg blue and gold in X) and/or use multiple icons which would make the program fairer because you can split each requirement and partners can collect them all like Pokemon (eg pentested icon, SOC2 icon, …).

28

plus

With all due respect, it is a bit unfair to pose a challenge and then discourage a response. But I’ll respect your wishes and disengage.

29

As someone who studied philosophy of language, I absolutely love this nihilistic approach to language. But unfortunately it is obviously not true.

I’m really trying not to be rude here, but I hope Atlassian will forgive me if I value the opinion of those who’s livelyhood may depend on the naming of this program more than whether or not the naming feels right for Atlassian staff.

Yes, it does mean exactly that, and that is OK. Because by naming it “Atlassian X” it conveys the message that it is validated by the very subjective opinion of Atlassian. It steers clear from making universal claims using ambiguous words and offers a very specific opinionated viewpoint. It will entice customers to check what the Atlassian opinion is and whether they agree with it.

The problem is: Atlassian is wrestling with two different goals. Because Atlassian also wants a shiny marketing name. But this is not a subject that should be used for marketing. There is a reason why we are not calling it “Certified Secure” but “ISO27001 certified” or “SOC2 certified”. These names are not sexy, but they convey the fact that an opinionated party approved it based on their requirements.

But that’s not clear now, is it? Nobody knows this nuance when they look at a badge that says “Enterprise Ready”. Because it is ambiguous, they will project their own interpretation to it. It would even be better if it would be called “Atlassian Enterprise Ready”. Somewhere in the naming, Atlassian should make it unambiguously clear that this is an Atlassian opinionated badge.

Again, Atlassian is playing with people’s livelihood here. I urge Atlassian to take this matter very very very serious and only continue with the name when it is approved not only by customers but also by partners. Put it to a vote in the Marketplace Partner Advisory Council if you must.

30

Since RFC-124 this has evolved and is forming shape, @PhilipGrove what is the high level indicative thoughts for timing for introduction of this trust program (once all the points have been ironed out) ?

31

One more thing!

There is an extremely large bias in the data points that Atlassian is collecting here. Atlassian is talking to customers that will always validate the viewpoint. Approaching Enterprise customers and asking them if they agree with their “Enterprise” label… well… I mean… in Dutch we would refer to a very popular ad which Toilet Duck once ran, that actually made it to Wikipedia:

Screenshot 2026-04-28 at 16.13.01
Screenshot 2026-04-28 at 16.13.011962×298 93 KB

Atlassian is targeting Enterprise customer that fall within her definition of Enterprise customers, asking them if they identify as Enterprise customers and whether or not an Enterprise specific badge resonates with them.

As mentioned before, the problem lies with the fact that smaller companies will also identify as Enterprise. Point in case: the Dutch Railways (Nederlandse spoorwegen), an Atlassian customer with ~3000 users will never be considered Enterprise by Atlassian. However, for Dutch standards, they are one of the larger companies in our country and absolutely considered an enterprise. They will also consider themselves an Enterprise.

I’m really sorry, but I have zero faith in Atlassian research as up until now this has always been used to validate existing ideas. For some reason, Atlassian customers always agree with Atlassian.

32

@PhilipGrove by your own logic the badge needs a word like ‘validation’.

“Enterprise Ready” resonates with the enterprise procurement audience we’re targeting

I can’t understand how ‘Ready’ is reasonably clear to them. ‘Ready’ is everything and nothing at the same time, corporate speak.

Why was ‘Cloud Fortified’ as a name a failure. ‘Enterprise Ready’ is to me another ‘Cloud Fortified’. Great in theory, but a low risk lowest common denominator in a big corporation, gets approval because nobody hates it. Legal says zero risk. A no risk, no reward name to me. Like with Cloud Fortified millions in marketing didn’t solve the problem.

I can understand why using the term Atlassian is redundant. I think these are clear, not perfect, but with Ready you have to explain and if have to explain right away then it is a bad name, marketing 101:

  • Enterprise Certified
  • Enterprise Verified

It sounds like you have already decided on ‘Enterprise Ready’.

33

This thread is now mostly about the naming of this program / badge. Maybe it would be a good idea to create a poll and invite partners only to vote? Atlassian can still discard the result, but it would give better data on what partners prefer.

I am really concerned about Forge platform readiness rather than the program naming. Unfortunately, that part is not discussed at all. It feels like this initiative is coming from the compliance / solution engineering side at Atlassian rather than the Forge platform team (I have no insights, just guessing).

34

Yes! 100%

But unfortunately, nothing in this RFC relates to Forge platform readiness.

This RFC is about a new program that impacts the Marketplace. That makes this effectively a marketing program rather than a technical program. And anyone who has spent more than a day in real-world marketing knows that an effective headline is 80% of the battle.

That means the program name is literally the most important part of this RFC. (Even if Atlassian insists it’s not in scope of the RFC.)

35

Hi @PhilipGrove

I will take that challenge. :face_with_tongue:

In an environment where some apps are badged and some are not, yes, there has to be a difference between the groups. The distinction depends on what the implied negative is: is it that the app does not have a quality, or is it that an app is not certified as having a certain quality? There is a difference, and it is very important.

As Stavros and Remie mentioned above, the key to this is really having “certified” or “verified” or “certification” or some version thereof in the name (or really any other qualifier that defines the badge as a certification, rather than a core app capability).

I would be happy with that name too. This just means that the trust was not certified by Atlassian. It even seems fair, because that is exactly what the program is actually doing.

For comparison:

  • “Enterprise Ready” vs “Enterprise Certified”. The app is not enterprise ready (arguably not true), or the app doesn’t have the enterprise certification (could mean a bunch of things)
  • “Trusted App” vs “Trust Certified”. The app is not trusted, or it does not have the trust certification.

Having a negative implication is normal, but the negative should again relate to the certification and not the core quality.

I disagree: the caveat does not imply to any name you choose, at least not if that name indicates that the certification is, in fact, a certification.

“Atlassian Trust Certified” is still better than “Enterprise Ready” for me and I think it does make most of the problem go away.

As you pointed out, “Security Verified” is a bad choice is because “not security verified” is ambiguous. Why is it ambiguous? I believe it is because “verified” is being used here in the context of something the customer already understands (“security”), and “not verified” can imply the absence of that known thing.

So while “Atlassian Security Verified” does not work for the reasons you mentioned, “Atlassian High-Tier Enterprise Verified” probably does work (because we are coining words and the customer has no preconceived notion of what a verification for a High-Tier Enterprise might be). The name is admittedly awkward, but it is clear.

Instead of throwing up our hands and just giving up, we can also bypass all of that by calling it the “Atlassian Security Certification”. The name is still not sexy, but you can dress it up for marketing purposes (“Atlassian Enterprise Security Certification” or whatever). Again, its absence implies would be a lack of certification, not lack of security, which is exactly the point.

To the challenge, I argue that you can slap “certification” onto the end of almost anything and it fixes the problem immediately. For example, “Enterprise-Ready Certification” or “Architected for Atlassian Certification” would be far better than the previous two names of this program (even if not perfect).

36

Hi all,

I will not hook into the naming discussion, you all got that covered already :smiley:

I am very happy that the Migration requirement has been removed!

But the "3.1 - Public trust centre available" introduces another 4K of costs when used from e.g. Vanta. So for “smaller” vendors, would it be possible to use a trust center e.g. generated by a static site generator and hosted publicly? Could you for example simply define an XML or any other form of machine readable requirement one can fulfill.

That would be great. Otherwise we would have very high costs just for the trust center.

For our Vanta I think the costs are around:

  • 10K per year for Vanta itself including SOC 2 Type II and Audit
  • 3K per year for 1 App PenTesting in BugCrowd
  • 4K per year for the public Vanta Trust Center alone.

I am not a big fan of the throwing additional 4K at Vanta just so customers can download some PDF documents. (And yes there is also other stuff available, but the NDA-protected download functionality for example can also be implemented with Jira Service Management).

Thanks

37

Seems inevitable that the AI hyperscalers will soon eat these margins with an inexpensive security offering that provides 24/7 autonomous SOC necessary for this agentic era. That will render the certification racket as legacy and redundant.

This RFC should have that situational awareness baked in but I guess we’ll have to wait for a reactionary response in 6-12 months time.

38

As always, thank you for your honest and candid feedback — I genuinely appreciate the perspectives and concerns you’ve shared.

I also want to acknowledge that my earlier response about the naming, and my follow-up asking to bring the RFC back on track, were poorly timed. My intent was not to shut down the discussion on naming, but rather to ensure that the feedback on this RFC ultimately helps us improve the program’s requirements and validation steps.

Based on your input, we’ve reopened our internal discussions to work toward a more aligned and balanced outcome for the program name.

We recognise how important it is to strike the right balance: clearly defining the purpose and audience for this badge, while also being mindful of any unintended signals that not having the badge might send to customers. I hear your feedback and your concerns, and we’ll take these directly into our internal conversations.

In the meantime, we want to reaffirm a key point: regardless of the final badge name, we will clearly communicate that any app receiving it has been validated against the specific set of requirements defined in this RFC. We will also continue to reinforce that all Marketplace apps meet Atlassian’s baseline cloud security standards.

We’ll keep you updated as this progresses.

Cheers, Phil.

39

Thank you for the update, Phil. Some great improvements on the original RFC, which will make this programme more accessible to a larger group of vendors.

I will refrain from commenting on the name, 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.

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.

40

“Verified by Spotify” badge.

LA Times, May 2, 2026

Spotify is adding a new level of verification to artists profiles, in an effort to reassure subscribers worried about Al-generated music. Starting Friday, a “Verified by Spotify” badge will begin to appear on artist profiles across the platform. As AI avatars and music continue to break through on social media and streaming platforms, the marker is meant to be a more reliable signal that an artist is human.

“Our goal is to make it easier for you to trust and understand the human artistry behind the music you listen to on Spotify, and develop long-term, meaningful connections with the artists and music you love,” Spotify said in a statement.

@PhilipGrove if Spotify can use the word ‘Verified’ than any lawyer claiming it is not possible now has some explaining to do.

  • Verified by Atlassian
  • Enterprise Verified

Should be on the table.