Introducing Atlassian Enterprise Certified (AEC)

Announcements
, ,
1

We’re thrilled to announce the launch of Atlassian Enterprise Certified (AEC), which highlights Marketplace apps that meet common enterprise needs for compliance, security, reliability, privacy, accessibility, and responsible AI use.

For customers, the AEC badge serves as an Atlassian-verified trust signal. It empowers enterprise buyers and procurement teams to confidently discover, evaluate, and adopt apps built for their most critical business requirements.

For Marketplace partners, AEC turns the traditional procurement back-and-forth into a repeatable, scalable process. Instead of fielding bespoke questionnaires for every deal, partners can publish standardized trust evidence and artifacts upfront to accelerate enterprise reviews.

Where will customers see AEC across the Marketplace?

  • Dedicated AEC trust filter: Customers can apply the filter to instantly surface AEC apps.

  • AEC badge displayed on app tiles: The AEC badge is prominently featured on app tiles across search and category pages.

  • AEC badge displayed on app listings: The AEC badge is prominently featured on app listings alongside other trust signals e.g. Runs on Atlassian.

Thank you to the Partner community

AEC is the direct result of extensive collaboration, feedback, and open dialogue with our Marketplace partners, developers, and enterprise customers.

A heartfelt thank you to everyone who shared insights, challenged assumptions, and contributed to our RFCs:

Your feedback directly influenced several pivotal updates:

  • Clear, enterprise-focused positioning: Aligning the program name and badge directly with enterprise buyer and procurement expectations (and concluding the legendary naming debate!).

  • Refined & pragmatic requirements: Removing subjective criteria and deferring requirements dependent on future platform capabilities.

  • Validation transparency: Clarifying exact evidence, artifact, and trust-center expectations.

  • Architectural clarity: Providing concrete guidance around data handling, logging, subprocessors, and residency.

RFCs succeed when they drive meaningful outcomes, and your constructive engagement made AEC substantially stronger.

Transitioning from Cloud Fortified (CFA)

As a reminder, AEC is replacing the Cloud Fortified Apps program as Atlassian’s primary trust designation for Marketplace apps. To support the transition:

  • Cloud Fortified is no longer accepting new submissions.

  • Existing Cloud Fortified badges will remain active and visible on the Marketplace through December 31, 2026.

  • Partners should use the transition period to review the AEC requirements, prepare their apps and submit an application to the program.

  • All CFA badges will be extended until the end of December 2026, and there is no requirement to complete an annual review.

If your app currently has a Cloud Fortified badge, we encourage you to review the AEC requirements and plan your transition early.

Get started now

AEC is now open to eligible Forge cloud apps. Check out the documentation on how to apply to join the AEC program.

We will continue sharing updates, FAQs, and enablement resources across the Atlassian Developer Community, developer changelog, and partner webinars.

Thank you for your continued partnership as we shape the future of enterprise trust across the Atlassian Marketplace together!

2

$2–5k pentesting per app per year to qualify for AEC badge. Is that fair?

Screenshot 2026-10-02 at 9.30.15 am
Screenshot 2026-10-02 at 9.30.15 am1066×292 26 KB

AI agents already perform autonomous testing, exploit validation and reporting. Given that agents are finding vast numbers of previously unknown exploits suggest their capabilities already exceed human experts. And the models are advancing exponentially with new frontier releases every ~11 days.

Apr 7th: https://www.anthropic.com/research/mythos-preview

Engineers at Anthropic with no formal security training have asked Mythos Preview to find remote code execution vulnerabilities overnight, and woken up the following morning to a complete, working exploit. In other cases, we’ve had researchers develop scaffolds that allow Mythos Preview to turn vulnerabilities into exploits without any human intervention.

Sep 1st: https://openai.com/index/path-to-astra/

We now believe Astra meets the Critical cybersecurity capability threshold under our Preparedness Framework, meaning that with the right tools and access, it can find previously unknown security flaws and develop ways to exploit them across many well-protected systems without a person guiding each step.

Why lock in a Bugcrowd/CREST requirement that gives accredited providers an incentive to retain high prices while automating the work themselves? I’ve audited their offerings and they still charge thousands for agentic pentesting.

This financial barrier risks excluding smaller apps regardless of their security. Cloud Fortified did not impose this pentesting expense. Given that the badges are now only engineering-determined RoA and accreditation-determined AEC, the logical incentive for any app which can’t justify $2-5k/yr is to opt-out of all the prior security requirements of Cloud Fortified. You’ll have made the marketplace less secure.

For apps running entirely within Forge, Atlassian should offer autonomous pentesting on its own infrastructure, charging partners a transparent fee based on actual token execution costs. That could enable testing on every deployment at a fraction of the cost of an annual engagement.

Will Atlassian provide this path, or accept equivalent agent-led assessments based on demonstrated quality rather than provider accreditation?

3

We ran the AEC Scorecard on a Custom UI-only Forge app (no functions, triggers, remotes or storage) and found several places where the scanner doesn’t match the published requirements:

  1. Frontend-only apps. 1.5, 1.7, 1.10, 1.11, 1.13 and 1.14 all return “Review required: The app bundle contains no analyzable source files” (FSRT). There’s no backend to analyse, and 1.11 is documented as a manifest check (ours declares nodejs24.x). Is “Request exception” the intended path for these apps, or will the scanner handle them?
  2. 5.1 is conditional, but the scanner isn’t. The requirement starts “If the app uses AI”. Ours doesn’t use AI, and 5.1 still fails. Should apps without AI publish an “AI Usage Policy” saying so, or request an exception?
  3. 2.1 checks something the requirement doesn’t mention. Edit: found it, the Marketplace listing has a status-page URL field, which the scanner reads. Worth mentioning in the 2.1 requirement.
  4. Links vs uploaded files. Edit: answered by a rescan: Vanta link resources (including #section anchors into a public page) pass 1.9 and 3.4. No uploaded file is needed.
  5. App keys in titles. Edit: a rescan confirmed that app keys in the entry’s description are not recognised, so 1.3 and 4.1 need the key in the title. For vendor-wide documents covering many apps (ours covers ten), that makes titles long. Would Atlassian consider matching keys in the description, or accepting a vendor-wide document for all of a partner’s apps?

More specific remediation in the scanner would help too. The documentation failures all say only “Review the AEC Required Documentation naming conventions”, without naming the expected title pattern or listing the trust-centre documents the scanner found. That would make it clear whether a document is missing, misnamed or just not recognised.

4

For a “runs-on-atlassian” app, penetration testing should be simpler and priced accordingly. But price quotes are based on number of modules as far as I see. We have received higher cost offers for “runs-on-atlassian” apps than an app with heavy webtrigger user (NOT runs-on-atlassian) app.

5

I tried the scanner and have a couple of questions about the process and usability.

After the first scan, I could submit an exception request, which I did for one criterion (5.1). Since then, I cannot submit any other exception requests. Is this expected? I also cannot see that an exception request is pending.
[Edit] I just noticed that a new ECOHELP ticket was created for the exception request. But the original assessment request doesn’t reference it, and I still cannot create new exception requests on the assessment.

Using file-name patterns to detect certain documents in the trust center is an interesting idea, but I don’t like it because it’s a customer-facing surface we would prefer not to clutter with app keys. The requirements page mentions that providing a link is an option, but I don’t see any way to do this in the application/scanner results.

For 1.3, I tried a couple of different names and rescanned, but it keeps failing. The documentation is not precise. Could you provide exact naming conventions and the exact Regex describing what the scanner is looking for (including the app key where required)? For example, 1.3 reads:

An architecture document matching “… Architecture Diagram …”
Both a “Dataflow/Data Flow” document and a “Network Diagram/Network Flow” document
Must indicate applicable app key

“Dataflow/Data Flow” is unclear, and I am almost certain the scanner isn’t looking for the same name written in different ways. I assume it’s something like “Dataflow” or “Data Flow” (it’s unclear whether additions are allowed, and where the app key goes).

6

Partners should use the transition period to review the AEC requirements, prepare their apps and submit an application to the program.

Just curious how apps that were previously Cloud Fortified are expected to achieve this if there are blockers to migrate away from Connect still impacting vendors (See RFC-149 https://community.developer.atlassian.com/t/rfc-149-forge-user-impersonation-fui-addressing-connect-parity-gaps-edge-cases )?

1.4 The app does not use any Connect modules.

Are Connect scopes under permissions counted towards connect usage?

  • If not, how exactly does a connect module performing remote calls vs a forge module invoking remote calls differ, when the authentication uses the old Connect permissions?
  • If yes, without a Connect EOS fix timeline for the disparity between Connect and Forge, how exactly are vendors blocked by this expected to comply to AEC when Atlassian does not provide the ability to do so in Forge?