Hi @PhilipGrove ,
While I understand the situation with rate-limiting to some extent, it is also not clear what we should do. For example if during a space export by a user (or other app) our app gets called and rate limited, we have no option to reschedule our API requests. If we don’t respond within ~10 seconds, Confluence will just render an error.
It is unclear for me how an A4A app should respond.
That means if the rate-limiting is part of A4A, Atlassian should us also tell what to do.
Existing “Cloud Fortified“ largely reflects this, could be “Forge Fortified”.
Hi @PhilipGrove
Let me start by saying that I really appreciate the detailed engagement here. It makes me really happy to see that the program is starting out with eyes open and the apparent willingness to design the program around feedback received.
I thought that RoA was already designed to fulfill the WHERE criterion, so would this not mean that you are just looking for a good name to fill the HOW question?
There is still a definitional problem to be addressed first: the suggested scope of this program is too broad to be able to give it a concise name that reduces confusion.
If the program is intended to represent trust signals related to privacy and security, this is easy to name and easy to understand by customers. Call it the “Cloud Security Participant v.2” or “Cloud Fortified v.2” or whatever. I also like the “Forge Fortified” and “Atlassian Trust Certified” ideas. Or mix it up and call it “Forge Security Fortified”. Tell customers that these apps meet the best-in-class security and trust posture suggested by Atlassian. All of these names are better than “Architected for Atlassian” because they are evocative of trust.
It gets harder to name this when a bunch of other things are thrown in that are not related (or are tenuously related) to trust, or you want app architecture also reflected, and you still want them reflected in the name. “Cloud Kitchen Sink Participant” does not really roll off the tongue.
Most of the proposed requirements are clearly trust-related, which is great. Pointing out a few that are not:
1- not using Connect modules
2- not using private Atlassian endpoints
3- respects rate-limit headers
4- consumes APIs efficiently
5- as-of-yet undefined performance requirements
6- automated migration path, migration documentation
7- accessibility (VPAT)
The first three have arguably very little relationship to trust, and the last four have none. I certainly understand what you wrote here:
and here:
…but for me, these do not fit into the trust paradigm.
Maybe you need three signals:
The past confusion around multiple badges presumably stems not from the fact that there was more than one badge, but because you had multiple badges in the same domain (like having both CSP and Cloud Fortified for trust).
If you have three badges that are all orthogonal and well-defined in scope, it is much easier to make names that are clear. Something like: Runs on Atlassian (WHERE: app runs on Atlassian infra), Forge Security Fortified (HOW: meets best-in-class trust practices), and something like Atlassian Resilient Architecture (WHAT: meets your architectural design requirements).
The idea above of having metal tiers for the trust badge is also great. I agree that this would be instantly understood by customers, without muddying the waters with different badge names.
Hey @AaronMorris1, thanks for your feedback.
I am 110% in favor of improving the trust signals in the Marketplace.
It’s great to hear we are heading in the right direction
My advice is to go with “clear” over “clever”.
This is some great feedback! Thank you.
Customers understand tiers.
In principle, I completely agree, and this was the approach we initially took. However, during customer interviews, we tested the idea of a tiered trust program, and most customers said they would only fully trust the highest tier.
Instead of tiers, many said they would prefer a single badge, along with individual trust signals displayed in the app listing, which would help them better identify trust areas specific to their needs. This got us to where we are today.
My concern with a tiered program, based on this customer feedback, is that apps in lower tiers would be disregarded by customers, even though partners have made significant investments to move “up the ladder” towards the highest tier.
For example, we also tested a bunch of UI concepts around how to show a tiered program… things like a signal strength indicator (like a Wi-Fi-strength icon), metalled icons (similar to the silver, gold and platinum badges we have today for the Marketplace Partner Program, although this caused confusion for customers trying to understand the difference between the two programs), and various other UI treatments.
In the majority of cases, when testing these UI concepts, customers tended to disregard apps in the lower tiers of the program over apps that weren’t in the program at all… a lower “signal strength” badge was perceived as worse than no badge at all.
The badge requirements should be as objective as possible, and all the other genuinely good ideas belong in a policy, an agreement, or something similar.
Again, great feedback and something for us to consider when we are building out the verification process.
Hey @scott.dudley,
Let me start by saying that I really appreciate the detailed engagement here. It makes me really happy to see that the program is starting out with eyes open and the apparent willingness to design the program around feedback received.
No worries, we really wanted to ensure this program was built in collaboration with our partner community. At the end of the day, the goal of this program is to help streamline our customers’ procurement process, making it easier for them to buy apps… This should be a win-win for both your business and Atlassian 
I thought that RoA was already designed to fulfill the WHERE criterion, so would this not mean that you are just looking for a good name to fill the HOW question?
You’re right, good catch!
“Cloud Kitchen Sink Participant” does not really roll off the tongue.
I don’t think this would get past brand marketing 
Maybe you need three signals:
- WHERE (RoA)
- HOW (the trust component of this A4A proposal)
- WHAT (is it a well-architected app according to whatever criteria you want)
This is good feedback, and I will take it back to the team to discuss.
The idea above of having metal tiers for the trust badge is also great. I agree that this would be instantly understood by customers, without muddying the waters with different badge names.
Check out my response to @AaronMorris1 above. When we tested a tiered trust program with customers, especially when using metal tiers, they got confused about the distinction between the new trust program badge and the Marketplace Partner Program badge.
I did like Aaron’s “clear” over “clever” feedback, though, when it comes to how we name things.
Thanks again for all your feedback.
Hey @tbinna, @andreas1, @Chris_at_DigitalRose, I just wanted to follow up to let you know that we haven’t forgotten you. I am just waiting for some internal answers to come back so I can address your feedback properly. Cheers, Phil.
Hey @tbinna, thanks a lot for your comments. It’s great to hear you are interested in our pen testing program.
To answer your OAuth flow question:
Would exceptions on certain requirements with reasonable justification be accepted?
Would this use case be covered by customer-managed egress, where the IT admin defines the OAuth domain? If so, because the egress domain is under the customers’ full control, these apps would be eligible for A4A.
If I have misunderstood the use case, please let me know.
Hey @PhilipGrove, thanks for following up on this.
Unfortunately, customer-managed egress won’t help. We know the domain we want to call and we could declare it in the manifest. Unfortunately, declaring it also alters the behavior of Forge APIs such as Forge router.open in a way that makes a secure OAuth flow implementation tricky.
The core problem is that the Forge platform aims to improve security by disabling certain browser features, but this comes at the cost of blocking industry-standard implementations. Adding the “Allow for popups from frames” permissions reinstates the “standard” browser behavior.
If we are not allowed to use this feature for A4A, we will find workarounds, but it will come at the cost of user experience.
I do not deny that the Forge platform behavior can help to improve security in the common case. But it comes at the cost of disabling other viable scenarios, and I feel there should be room for justified exceptions for these. By using the “Allow for popups from frames” we are opening the door for some attack vectors. But I’d argue that if we try to fit into A4A and work around the Forge platform’s restrictions, we will do as well.
Hi @marc,
In situations where your app is called as part of a larger operation process by the host app (e.g. Confluence space export invoking macros or Jira workflow execution invoking validators) and there is a time limit in which you must respond, I’d recommend a two-fold approach:
(1) optimising your API requests as much as possible to avoid the risk of rate limiting; and
(2) failing gracefully when rate limiting means you can not respond in the prescribed time
In the case of macro export, if you’re rate limited and the RetryAfter value means you will exceed the timeout, I’d recommend rendering a message that the macro could not render correctly due to rate limiting, and (potentially) request the user to try again during a less busy period. The reference to the rate limiting requirement in the A4A proposal doesn’t mean your app has to work flawlessly when rate limited, only that rate limit headers are followed and that the experience degrades gracefully rather than blowing up with an opaque error.
If you wanted to go further, you could also potentially introduce a macro content cache that the user can explicitly pre-warm prior to performing an export (e.g. a “Prepare Space for Export” step accessible to space admins) though the complexity of building something like this will vary based on your use-case.
Hope this helps!
cheers,
Tim
Hi @PhilipGrove,
Thank you for posting this detailed RFC. I would like to question the point about requiring bug bounty programs to be public. I see that you address this elsewhere in the post, but noise is becoming an increasing problem in bug bounty programs because of LLM-generated content by bot farmers. This is a very real concern of ours facing a public bug bounty program.
Daniel Stenberg, the maintainer of cURL, has been frustrated with LLM-generated bug reports and issues since people started using them to auto-report issues. They been drowned with so much slop that they recently decided to close their public bug bounty:
[Daniel's week] January 16, 2026.
I am worried that we marketplace partners will expose our bug bounty programs to the same slop machine, and will spend a lot more time filtering out B. S. bug reports that should be spent actually improving the quality and security of our applications. Currently, I cannot see a positive cost/benefit trade-off of potentially getting a few more high-quality submissions at the expense of having to deal with a large volume of noisy bot farmer submissions.
With a private bug bounty program and annual pen-testing as well as SAST/DAST and SCA, you could instead ask partners to publish some more information about confirmed issues as a case by case exercise. For example a short notice / security advisory for approved AMS tickets / bugcrowd issues with a certain severity level. These in sum should give plenty of trust signals.
Thank you for the detailed RFC and all the outlined changes.
Here are my thoughts/concerns on this.
1.1 pen testing => is not the bug bounty program with bug crowd enough testing? This will introduce yearly costs per app that are very high. Smaller apps will no longer be able to uphold cloud security programs with such high costs.
1.12 We need user defined egress - e.g. admins allowing domains via UI. Otherwise some apps including one of our own will not be able to achieve the new cloud security badges.
2.1 efficency is a really hard thing to implement when there are sometimes limits of 50 items per page
via REST API and no optimal query endpoints available (depending on what the app needs to achieve)
3.1 performance: Also already hard to achieve. Forge seems a bit slow in comparison to the old connect.
For us same as 2.1 - can be hard to achieve when you need e.g. three REST API calls for one user interaction.
5.1 accessibility tested: This seems unecassary in terms of a secure app. For us this is just another hurdle which introduces more costs.
6.1 automated migration path: This really irritates me the most. For our apps there is no automated migration path,
because Atlassian does not offer the needed mechanisms.
Example app1: No mapping of customfield context ids from DC to cloud => no way of migrating our app data automatically. Open Bugs about this for many years.
Example app2: No automated conversion of DC Confluence macro storage format to cloud storage format. Open Bugs for years.
=> I vote to leave the while point 6.1 out of the security badge, because this is mostly out of an App Vendors scope to achieve even if he wants to. And it has nothing to do with cloud security.
The other mentioned changes are ok for us so far. Even though we would like to not see public bug bounty and mandatory pen tests. And please leave app migrations (6.1) out of the picture.
In general, it is a good initiative to define the A4A requirements and a badge for apps that have implemented best practices and recommendations already discussed and suggested in previous years. And just a limited number of the best apps should qualify for it, as otherwise, such a badge will have no value if everyone has it.
But I have objections to some requirements. I will focus on the most critical ones not discussed so much by others:
1.7 The app logs must not include UGC content …
“UGC content” is defined as titles, descriptions, comments, attachments, search queries etc.
We log the user request URLs and some POST request parameters, and they might include some user-generated content (like titles or search queries). We log exceptions that might contain UGC as well. The purpose of logs is to investigate and debug errors, performance problems, or security issues. Only the recent logs are kept and afterwards discarded. I do not see anywhere in Data Processing Addendum | Atlassian where Atlassian would promise that you do not log any UGC (and I doubt that all Atlassian services do not log any UGC).
1.12 All outbound (egress) domains must be explicitly listed to prevent unrestricted network access.
In our case, customers can use custom REST API data imports from external domains that they specify, as well as using the authentication credentials that they specify. We cannot list all these domains.
4.2 The app supports Data Residency (pinning and migration)
I assume that there are no specific requirements for all data residency regions that should be supported?
5.1 The app has been accessibility tested, and a Voluntary Product Accessibility Template (VPAT) is publicly available
This is a totally new area of requirements, and I doubt that it should be mandatory for all apps. As I see even not all Atlassian products (for example, Atlassian Analytics that is in the similar area as eazyBI) have VPAT documents published. I think Atlassian should not make it mandatory for all apps that Atlassian is not making mandatory for themselves.
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.
Forge LLM is still in EAP, not available in production, does not provide REST API that remote modules could use, provides limited set of models, has no pricing information. In such state it cannot be added to requirements. We have been using LLM services for several years and have built custom integrations with them, as well as we publicly provide to customers detailed information how we use them and what information is shared with LLMs.
As Adam Moore commented, more appropriate requirements might be “Uses Forge LLMs or has publicly documented Responsible AI policies and controls" that they can link to”.
Kind regards,
Raimonds Simanovskis
eazyBI
Hi @tpettersen ,
Thank you very much for your reply. I understand the options your presented.
Option 1 (optimising API requests) is very sensible.
However option 2 is, I think, problematic for customers. Customers often use a space export as a “batch job” to have a kind of backup. Customers don’t view the space export immediately, and so won’t know if any macro has been rate limited. If the customer tries to import the space export e.g. several weeks later and then discovers the rate limiting, it is too late to recover.
My impression is that the rate limiting should go the other way: A user starts a space export, Confluence realizes it gets overwhelmed by API requests, and so slows the space export such that less API calls are done. Confluence is in control, and Confluence “knows” that its API is under strain. Unfortunately apps and macros can’t signal to Confluence that they are rate limited (by Confluence).
Hi @marc,
That’s a great point regarding backups, and I love the idea of enhancing the Confluence export process to better cater to rate limiting. That said, I suspect having Confluence automatically scale the backup process speed based on load would be quite complex, particularly given cloud’s distributed architecture and the potentially large number of different APIs and API consumers in play.
As a step towards that, what do you think of allowing a macro to explicitly signal that it is temporarily unable to render due to rate-limiting, and that the export process should retry after a period? Perhaps something along the lines of the retry handling supported by Forge trigger modules, which allow you to request a retry after a customisable delay. This would also allow you to gracefully handle temporary outages in any external dependencies.
cheers,
Tim
1.8 The app is not using private/undocumented Atlassian API endpoints
Hi @scott.dudley, we understand the need to use undocumented endpoints to meet specific app requirements. While we acknowledge justifications, please be advised that Atlassian does not provide support for issues arising from the use of undocumented APIs. These endpoints are considered unsupported and are subject to change or removal without notice, unlike public APIs which follow a standard deprecation practice.
To ensure stability and predictable migration paths, Atlassian manages the lifecycle of all public APIs through official channels, specifically the Developer Changelog and official documentation updates.
To help us prioritize support for any use cases involving undocumented endpoints or recommended stable alternatives, we encourage you to submit a request via the Atlassian Developer Support portal or to engage directly with your Atlassian Partner Manager.
We support the move to simplify and consolidate Marketplace trust programs to provide clearer, more meaningful signals to current and prospective customers. Reducing overlapping badges is a positive step toward making trust easier to understand and evaluate.
Clarity of intent
On first reading, however, the intent of the proposal was somewhat confusing. The RFC opens with goals of “simplifying trust signals” and “uplifting security requirements”, which suggests a primarily security-focused change. As the proposal unfolds, it becomes clear that A4A is significantly broader in scope, covering operational maturity, reliability, performance, platform alignment, and responsible AI — with security being an important component, but not the sole focus.
We’d strongly encourage future communication of A4A — to both partners and customers — to be explicit about its broader intent upfront, positioning it as a holistic app quality and operational excellence standard.
Verification and assessment of requirements
Many of the proposed A4A requirements are reasonable in intent but are currently described using vague or subjective language (for example, “consumes APIs efficiently”). For a program of this importance, requirements need to be precise, measurable, and consistently verifiable.
At this stage, it’s difficult to provide detailed feedback without clearer information on how requirements will be measured and assessed — whether through automated tooling, defined thresholds, or partner-provided evidence.
Timeline expectations
We understand that concrete timelines may not yet be available. However, some A4A requirements could require significant investment and lead time, depending on how expectations are ultimately defined (for example, SOC2 compliance or accessibility).
If possible, even a high-level indication of the expected timeframe for A4A to replace Cloud Fortified (e.g. months vs. years) would help partners prioritise work and plan investment more effectively.
New Penetration Testing Program — alignment with SOC2 evidence requirements
We’d appreciate some clarification on whether the requirements defined for the new Atlassian-provided penetration testing program are intended to be sufficient for use as evidence in SOC2 compliance assessments.
For partners maintaining SOC2 certification, penetration testing is a recurring compliance requirement. If the scope or outputs of this program do not meet auditor expectations, partners may still need to commission additional third-party testing, resulting in duplicated effort and increased cost with limited additional security benefit.
Requirement 1.14 — “Respects rate-limiting headers”
Partners are currently unable to meet this requirement due to known limitations in the Forge ecosystem. When calling Jira and Confluence APIs from the frontend, the headers required to detect rate-limiting and implement backoff behaviour are obfuscated, making compliance impractical.
This is tracked under FRGE-1923 (https://ecosystem.atlassian.net/browse/FRGE-1923). Until resolved, we recommend deferring enforcement of this requirement or clarifying acceptable interim behaviour.
Requirement 2.2 — “Publicly defined SLI/SLO reliability metrics”
This requirement is noted as being “partially required for the Cloud Fortified Apps program”. However, the Cloud Fortified reliability documentation also states that “we don’t yet have SLIs and SLOs defined for Forge Marketplace apps” (see cloud fortified docs).
Given that A4A is explicitly limited to Forge applications (see Requirement 1.3: “The app does not use any Connect modules”), this implies that there are currently no defined platform SLIs or SLOs for partners to build upon.
Until Forge Marketplace app SLIs and SLOs are clearly defined and documented, partners are left to make assumptions — or, at best, define metrics only for their remote services (where applicable), which may not reflect overall app reliability. We recommend deferring enforcement of this requirement until Forge-specific SLIs and SLOs are available.
Requirement 4.2 — “App supports Data Residency (pinning and migration)”
The requirement does not currently specify a minimum expectation for the number of realms that remote data stores must support.
As written, it’s unclear whether existing realm coverage is sufficient or whether additional regional investment is expected. Clear guidance on what constitutes adequate coverage at launch (and how this may evolve) would help partners assess gaps and plan investment with confidence.
Requirement 7.1 — “The app conforms to Atlassian’s Responsible Technology Principles”
There appears to be overlap between this requirement and Requirement 5.1 (Accessibility).
Requirement 5.1 requires accessibility testing and a publicly available VPAT, while Requirement 7.1 introduces additional accessibility expectations, including conformance with WCAG 2.2 AA. If these standards are required under A4A, they should be made explicit and consolidated, ideally by reflecting those targets directly in Requirement 5.1 to avoid ambiguity.
It’s also important to note that WCAG 2.2 AA conformance represents a significant upfront and ongoing investment, particularly for existing applications that were not originally designed with accessibility as a primary concern. Achieving compliance often requires substantial design, engineering, and testing effort, followed by continuous validation to ensure new features and changes do not introduce regressions. The amount of time and resources required to meet these expectations could make A4A alignment untenable for many partners, reducing participation in the program rather than increasing trust across the Marketplace.
Additionally, many partners rely heavily on Atlassian-provided libraries (such as UI Kit and the Atlassian Design System) to deliver a seamless and consistent user experience. If partners are expected to meet these accessibility standards, clarity on Atlassian’s ongoing support, ownership, and SLAs for addressing accessibility issues identified in these libraries would be important. Without this, partners may be held accountable for gaps outside their direct control.
Requirement 7.2 — “Uses Forge LLMs where practical”
As written, it’s unclear who determines what is considered practical, or what process will be used to assess or validate this.
Practicality in this context is inherently subjective and use-case dependent. For example, Forge LLMs may not currently be practical for partners who require robust analytics, observability, and quality monitoring to ensure AI-generated outputs meet internal standards and customer expectations.
Without clearer criteria or an explicit evaluation process, partners may be left uncertain as to whether their AI architecture choices will be considered compliant. Clarifying how “practical” will be defined, evaluated, and enforced — and whether there will be an exception or review mechanism — would help partners make informed decisions without risking retroactive non-compliance.
We support the direction of this proposal and appreciate the effort to simplify trust signals while raising the bar for Marketplace apps. The feedback above is intended to help ensure A4A is clear, achievable, and consistently applied, particularly given the investment some requirements may entail.
Hi @tpettersen ,
The retry handling would work potentially in Forge resolvers. We would likely use such a solution.
However there is also rate limiting for Forge macro PDF exports, and during PDF export macros can get rate limited, even if a macro does not use a resolver because PDF export also runs e.g. Custom UI code.
I think the rate-limiting should be looked at holistically. Atlassian chosen a distributed cloud architecture, and the rate-limiting needs to adopt to this. For example the rate-limits for frontend calls should be different than the rate limits for batch backend calls (which can be throttled easily). I think sorting this out is worthy of a separate RFC (and not touched upon in 2026 point-based rate limits )
Hey @andreas1, my apologies for the late reply. We totally understand that it may not make sense to redo a pen test if you already completed one in the past year. However, at this time, we will only be able to accept your pentest if it has been done by a CREST-certified vendor or through our managed Bugcrowd pentesting program.
However, bear in mind that the timeframe for launching the A4A program has not been set yet so you could consider moving to our managed Bugcrowd pentesting program (or a CREST-certified vendor) when your annual renewal is due.
Hey @Chris_at_DigitalRose, thank you for your thoughtful feedback, and my apologies for the delayed response.
Unfortunately this new requirement list is not security or architecture focused. Replacing Cloud Fortified with an ‘everything we think is a good idea’ list is disturbing.
As I mentioned to @scott.dudley above, the A4A program is intended to cover more than security; it’s designed to reflect our view of what a well‑architected app looks like.
A4A is being designed to ensure IT admins have confidence that the app has all the “boxes ticked” as they go into their procurement process.
Mixing in the Platinum badge requirements (e.g. SOC 2/ISO and a trust center) adds an artificial barrier and is redundant as already enforced by the platinum badge.
We have been discussing this internally, and our approach is to review all our Marketplace programs as part of building out A4A, and this may include moving requirements from one program to another (with plenty of advanced notice to our partners of course 
). In this case, we may consider moving the SOC 2/ISO27K requirement from the Marketplace Partner Program into A4A. I believe this could make sense when considering the A4A objective of streamlining the app procurement process for customers, as a partner may not yet meet the revenue bar for Platinum but still wants to highlight their investment in trust to prospective customers.
I called this out in a previous reply, but A4A is intentionally setting a high bar, and if that means we need to shift some requirements from one program to another, we will consider it.
Hey @raimonds.simanovskis, thanks for taking the time to reply to this RFC.
In general, it is a good initiative to define the A4A requirements and a badge for apps that have implemented best practices and recommendations already discussed and suggested in previous years.
Thank you, we appreciate this feedback.
And just a limited number of the best apps should qualify for it, as otherwise, such a badge will have no value if everyone has it.
100% agree.
In our case, customers can use custom REST API data imports from external domains that they specify, as well as using the authentication credentials that they specify. We cannot list all these domains.
Based on the feedback in this RFC, we are looking to update requirement 1.12 to read:
“All default outbound (egress) domains must be explicitly listed to prevent unrestricted network access. Any additional egress, e.g where the customer chooses which domains they egress to, must be under customer control and fully auditable.”
Does this better frame the requirement that apps that have customer-defined egress domains will still meet the requirement?
I assume that there are no specific requirements for all data residency regions that should be supported?
Correct, we will not be mandating which regions you support, but you should support data residency in the regions where your customers are and include data migration support between those regions.
As I see even not all Atlassian products (for example, Atlassian Analytics that is in the similar area as eazyBI) have VPAT documents published. I think Atlassian should not make it mandatory for all apps that Atlassian is not making mandatory for themselves.
This is good feedback, thank you.
As Adam Moore commented, more appropriate requirements might be “Uses Forge LLMs or has publicly documented Responsible AI policies and controls" that they can link to”.
I think this is a reasonable update to the requirement based on the timing of Forge LLMs.