Forge Development

The Atlassian Marketplace Approval Process: What Forge Developers Should Expect in 2026

Matthias Rauer
#Forge#Marketplace#Security#Compliance
Server rack with security graphic.

Your Forge app is built, tested, and ready to solve customer problems. But before your team can ship it on the Atlassian Marketplace, one last critical step stands in the way: Atlassian’s approval review. What used to be a fairly straightforward functional test a few years ago has become, in 2026, a multi-stage process combining functional testing, security scanning, and identity verification.

Know the process, and you can move through it noticeably faster. Overlook key parts of it, and your team risks weeks of delay right before the planned launch.

The process at a glance

After submission, an app goes through several checkpoints at Atlassian: a functional test, a security review, and — new since 2025/2026 — an additional security workflow that applies to all new apps and new versions alike.

The official “App approval guidelines” state a target of 10 to 15 business days, noting that actual duration shifts depending on current volume and the Marketplace team’s availability.

So if you’re planning a launch date, build in those full two to three weeks — not the shorter one-week figure that appears elsewhere in Atlassian’s own documentation, on the page for listing Forge apps. The two official pages simply contradict each other here, and the approval guidelines, with their more detailed and more current description of the process, are the more reliable source.

What submission requires

The functional test is the part most developers expect: Atlassian checks whether the app works as described. The more interesting part is the second one, which is about transparency into your app’s architecture. At submission, your team has to disclose:

  • Which API scopes does the app request, and why are they necessary for its core function?
  • Which external hostnames or IP addresses does the app send data to?
  • What data flows there, and for what purpose?

This is where a “Runs on Atlassian” architecture pays off: an app with no data egress simply has less to explain in this part of the review, and less surface area for follow-up questions. If you still call out to remote backends, make sure this list is cleanly documented before submission — improvised, last-minute answers reliably extend the review significantly.

The new security workflow

Since the 2025 overhaul of the security policies, there’s a dedicated, automated review step that applies both to new apps and to new versions of existing apps. Answers to the security questionnaires are automatically scored and flagged with warning or fail signals. A fail signal blocks listing entirely until the issue is resolved — at that point, a fix is mandatory.

This is complemented by a partner security review, which — independent of any individual app — covers security practices, infrastructure, development processes, and vulnerability management.

In June 2026, Atlassian noticeably simplified this part of the process: all security questionnaires — both partner-level and app-specific — were consolidated into a single Forge app, accessible directly from the Marketplace app approval request. There you can also view the results of the automated vulnerability scan and find a designated point of contact for app-specific questions. For partners with multiple apps in their portfolio, this is a meaningful improvement over the previously separate, partly redundant forms.

Identity verification: KYC and KYB

Atlassian has contracted a third-party vendor to carry out Know-Your-Customer and Know-Your-Business verification. This check is now mandatory for every partner onboarding a new app — regardless of how long they’ve already been active on the Marketplace.

If you’re a new entrant, or submitting under a new legal entity, don’t underestimate the time this step takes: it requires identity documents and business paperwork, and processing runs through a separate ticket in the Developer and Marketplace Support project.

A word on stricter PAT requirements

If your app still collects, transmits, or stores personal access tokens (PATs), check this urgently before submitting: new apps that do this are categorically not approved during the security review. Existing apps had until the end of Q2 2026 to migrate away from this practice. Where a required API capability was only available via PATs, this deadline could be extended on a case-by-case basis.

Teams that instead rely on Forge-native mechanisms like storage.setSecret and Forge authentication, requesting only the minimum necessary scopes, sidestep this problem from the start.

The economic backdrop

That Atlassian is tightening the review while simultaneously simplifying it fits the clear prioritization of Forge over Connect. The standard revenue share for Forge apps rose from 15% to 16% on April 1, 2026, and climbs further to 17% on October 1. For Connect apps, the same step is markedly steeper: from 15% to 20% in April, then to 25% in October. Teams still building on Connect are paying a price not just in egress overhead and review duration, but increasingly in revenue too.

On top of that comes a direct migration incentive: since January 1, 2026, partners pay 0% revenue share on their first $1 million in lifetime Forge revenue. Moving from Connect to Forge saves you not just review time and egress overhead, but — for a good stretch — real revenue as well.

Practical recommendations

So what should your team actually do to enter the review well-prepared and move through it as fast as possible?

  • Keep scopes minimal and documented. For every scope you request, there should be a one-sentence, clear reason why it’s needed.
  • Prepare your egress list: before submitting, your team should have a clear breakdown of what data flows where.
  • Plan KYC/KYB early: the external partner verification for new partners or new legal entities runs in parallel and can take some time.
  • Stop using PATs: your team needs to move to Forge-native mechanisms before submitting a new app version.
  • Build in a realistic buffer: realistically, your team should set the launch date two to three weeks after submission.

The approval process has become stricter, but also more predictable: teams that know the requirements and prepare their app accordingly — ideally with no egress, clearly justified scopes, and no PAT dependencies — generally get through quickly.

Incomplete preparation, on the other hand, can turn the review into an unwelcome bottleneck right before launch.

Want your team to navigate scopes, egress documentation, and the security workflow confidently on your own? Our Forge Developer Trainings cover exactly that. Would you rather have your app built review-ready from the start? Our Atlassian development team is here to help.

← Back to Blog