Developer
News and Updates
Get Support
Sign in
Get Support
Sign in
DOCUMENTATION
Cloud
Data Center
Resources
Sign in
Sign in
DOCUMENTATION
Cloud
Data Center
Resources
Sign in
Last updated Apr 15, 2026

Marketplace Security Enforcement Policy

Security is a shared responsibility between Atlassian and our Marketplace partners. As the Marketplace ecosystem grows and the threat landscape evolves, Atlassian continues to raise the bar on the security posture we expect from partners and their apps. This page brings together the security compliance areas that apply across all Marketplace apps so that partners have a single place to understand what we look for, where each requirement is documented in more detail, and how Atlassian approaches non-compliance when it occurs.

This page is intended to complement, not replace, the Marketplace Partner Agreement, the Atlassian Developer Terms, and the detailed security documentation linked throughout. Where a specific requirement is documented elsewhere on developer.atlassian.com, that document remains the source of truth.

Table of contents

  1. Overview
  2. Vulnerability management and resolution timelines
  3. OAuth implementation
  4. Partner verification
  5. Bug bounty program
  6. Personal access tokens
  7. Incident response
  8. When compliance expectations are not met

Overview

Atlassian performs ongoing monitoring of the Marketplace to identify apps and partners that are out of alignment with our published security requirements. This includes automated security scanning of app artifacts, review of disclosures made through the Privacy and Security tab, review of incident reports, and auditing of partner identity and business information.

The areas covered on this page represent the key domains where Atlassian expects partners to demonstrate continuous compliance:

  • Vulnerability management: identifying and remediating security issues in your app within published timelines.
  • Authentication: implementing OAuth 2.0 and 3LO securely and following Atlassian's authentication guidance.
  • Partner verification: completing and maintaining the identity and business verification required of every Marketplace partner.
  • Bug bounty program: operating an active and effective bug bounty program if your app holds a security trust badge.
  • Personal access tokens: transitioning away from collecting, transmitting, or storing Atlassian user account API tokens in favour of scoped, OAuth-based alternatives.
  • Incident response: investigating, communicating, and remediating security incidents that involve your app.

Each section below outlines the expectation, where it is documented, and how to stay in good standing.


Vulnerability management and resolution timelines

Vulnerabilities discovered in Marketplace apps, whether identified by Atlassian's scanners, reported through the Marketplace Security Bug Bounty Program, or raised manually, are logged as tickets in the Atlassian Marketplace Security (AMS) Jira project and assigned to the security contact provided by the partner.

Each ticket is assigned a severity based on the probable impact of the vulnerability, and each severity has a published remediation timeframe that determines the ticket's due date.

Current remediation timeframes

SeverityMarketplace Cloud appsMarketplace Data Center apps
Critical10 days12 weeks (84 days)
High4 weeks (28 days)12 weeks (84 days)
Medium12 weeks (84 days)12 weeks (84 days)
Low25 weeks (175 days)25 weeks (175 days)

For the full policy, including CVSS-based severity definitions, the two-week triage window for Bug Bounty findings, and the limited conditions under which extensions may be granted, see the Security Bug Fix Policy for Marketplace apps.

What Atlassian expects

  • Partners should acknowledge and triage AMS tickets promptly after they are assigned.
  • Partners should remediate tickets within the published timeframe for their severity and hosting type.
  • Where a remediation is genuinely blocked, for example by an upstream dependency or a platform-owned change, partners should use the extension process rather than allowing the ticket to go overdue.
  • Partners should ensure their security contact has an active ecosystem.atlassian.net account so that AMS notifications are not missed.

Types of AMS vulnerability tickets

Ticket typeSource
Bug Bounty VulnerabilityReports from the partner's Bugcrowd bug bounty program. See the Marketplace Security Bug Bounty Program.
EcoScanner VulnerabilityAtlassian's continuous scanning platform. See EcoScanner and Security Initiatives for Data Center Apps.
Security VulnerabilityManually raised tickets from Atlassian's security team or from partner disclosures.

OAuth implementation

Marketplace apps that rely on OAuth 2.0 or Three-Legged OAuth (3LO) must implement these flows securely and in accordance with Atlassian's published guidance. Atlassian maintains automated and manual review mechanisms to validate OAuth implementations.

Start with the primary OAuth documentation:

Client secret protection

  • Do not hardcode client_secret values in source code, configuration files, or any client-side artifact that can be inspected by an end user.
  • Store OAuth client secrets and tokens using encrypted secret stores or a managed key management system. If your app is built on Forge, use Forge secret storage rather than rolling your own secret management.
  • Enable and exercise secret rotation on a regular cadence, consistent with your organization's key management practices. Rotate immediately if exposure is suspected.

Redirect URI security

  • Maintain strict control over every registered redirect URI. Each should resolve to a domain your organization actively owns and operates.
  • Keep registration records for redirect URI domains current. Renew domain registrations well before expiry.
  • Immediately remove any redirect URI that points to an expired domain, a transferred domain, or a domain at risk of subdomain takeover. Domain expiry or subdomain takeover of a registered redirect URI constitutes a critical security vulnerability.
  • Monitor your redirect URIs continuously rather than only at registration time.

OAuth scope management

  • Apply the principle of least privilege: request only the minimum scopes required for your app's core functionality. This aligns with the security requirements for cloud apps.
  • Avoid broad or unused scopes that expose unnecessary data or capabilities.
  • Audit scope usage periodically to confirm it still matches what your app actually does. Remove scopes that are no longer needed in a planned, customer-communicated manner.

Partner verification

Every partner listing apps on the Atlassian Marketplace must complete Atlassian's identity and business verification process. This process validates partner legitimacy, establishes a durable business relationship, and satisfies regulatory obligations that apply to Atlassian as the Marketplace operator.

For a full walkthrough of what the verification process involves and how to complete it, see Due Diligence Business and Identity Verification for Marketplace Partners.

How it applies

Partners are encouraged to engage with Atlassian early if any part of the verification process is unclear or if additional information is required.

What Atlassian expects

  • Complete the Partner Verification ticket within the timeframe indicated on the ticket.
  • Respond to requests for additional information in a timely manner.
  • Notify Atlassian via ECOHELP of any change to the verified entity, such as an acquisition, change of control, or change of legal name.

Bug bounty program

Participation in the Marketplace Security Bug Bounty Program is a requirement for partners in the Marketplace Partner Program and for apps carrying a security trust signal such as Cloud Fortified. A healthy bug bounty program gives external security researchers a reliable channel to disclose vulnerabilities and demonstrates a sustained commitment to security improvement.

Where bug bounty is mandated

The Marketplace Partner Program ties bug bounty participation to each partner tier, with the scope widening as the tier advances:

  • Silver Marketplace Partner: the paid cloud Marketplace app with the most installs must meet Marketplace Bug Bounty Program standards.
  • Gold Marketplace Partner: all paid cloud Marketplace apps with 100 or more installations must meet Marketplace Bug Bounty Program standards.
  • Platinum Marketplace Partner: every paid cloud Marketplace app in the partner's portfolio must meet Marketplace Bug Bounty Program standards.

Participation in the Marketplace Security Bug Bounty Program is also a prerequisite for Cloud Fortified approval.

Key documents:

What Atlassian expects

  • Public by default: All Marketplace-managed bug bounty programs must be public, or actively scheduled to go public with Bugcrowd, by June 30, 2026. See Making your Bug Bounty Program Public for the full timeline, prerequisites, and migration instructions.
  • Healthy and active: Programs should be adequately funded, triage researcher submissions in a timely manner, and meet the published reward and operational requirements.
  • Responsive to researchers: Partners should engage with researchers promptly and issue valid rewards without delay.

As noted in the public transition guide, Atlassian is entitled to pause or deactivate bug bounty programs that are not in the process of going public by the compliance deadline, or that are consistently dormant or unhealthy.


Personal access tokens

As previously communicated to partners (CHANGE-2449 and the security requirements FAQ), Marketplace apps must not collect, transmit, or store Atlassian user account API tokens (personal access tokens, or PATs). This requirement supports customer data security and aligns with Atlassian's authentication modernization toward OAuth-based flows.

Why this matters

Personal access tokens used as a general app authentication mechanism introduce several categories of risk:

  • Broad scope access. A PAT typically inherits the user's full set of product permissions, far more than most apps actually need.
  • Long-lived credentials. PATs can remain valid for extended periods without an enforced rotation lifecycle.
  • User impersonation. Any API call made with a PAT appears as the user themselves, with limited visibility to the customer over what the app is doing on their behalf.
  • Centralized exposure risk. Apps that store PATs concentrate the blast radius of any future application compromise across every customer who shared a token.

What partners should do instead

Timelines

  • Existing apps: Partners are expected to complete migration away from PAT collection, transmission, and storage by the end of Q2 2026. Where a required API capability is only available via PAT today, partners can engage with Atlassian through ECOHELP so we can prioritize the platform work needed to unblock migration. While that platform work is in progress, your migration window will be extended accordingly.
  • New apps: Any new app submitted to the Marketplace must be fully compliant. Apps that collect, transmit, or store Atlassian user account API tokens will not be approved during the security questionnaire review.

See the related guidance:


Incident response

Security incident response is a shared responsibility between Atlassian and our Marketplace partners. As set out in the Forge shared responsibility model, Atlassian operates the underlying platform while partners are responsible for the security of their own app code, data handling, and customer-facing communications. Incident response sits squarely in that partner column: every Marketplace partner is responsible for preparing for, detecting, and responding to security incidents that affect their app, and for collaborating with Atlassian throughout the lifecycle of an incident. What varies across partners is the depth of Atlassian's involvement, not the underlying obligation.

Incident response process

All Marketplace partners are expected to maintain a documented security incident response process covering:

  • Prompt investigation of any suspected or confirmed security incident.
  • Immediate containment of customer impact.
  • Active collaboration with Atlassian throughout remediation, including sharing relevant technical details, root cause analysis, and remediation status.

Atlassian scales its direct engagement to the risk profile of the partner and the app. Platinum Marketplace Partners and partners whose apps are used by Enterprise customers can expect closer, more hands-on collaboration from Atlassian's security team during an incident, reflecting the broader customer exposure of those apps. Partners at other tiers are still expected to follow the same core process, with Atlassian engaging commensurate with the risk.

For a walkthrough of what to prepare in advance, see Preparing for a security incident.

Notification requirements

Partners must notify Atlassian of any security incident impacting a Marketplace app by raising a P1 incident ticket within 24 hours of becoming aware of the incident, and must provide:

  • timely status updates as the investigation progresses,
  • a detailed remediation plan, and
  • a comprehensive post-incident review.

See the App security incident management guidelines for the end-to-end process.

Customer communication

Partners should notify affected customers transparently and promptly. Use the App security incident communication template as a starting point and adapt it to the specifics of the incident.

Emergency actions

Where customer data or systems are being actively exploited through a Marketplace app, Atlassian reserves the right to immediately suspend the app to protect the broader customer base, pending partner remediation and security verification. This is an existing emergency capability and is used only where the risk to customers would not be addressed in time through normal remediation channels.


When compliance expectations are not met

Atlassian's strong preference is to resolve compliance issues collaboratively with partners. In the vast majority of cases, partners respond to AMS tickets, ECOHELP tickets, and direct outreach, remediate the underlying issue, and the app remains in good standing.

Where a compliance expectation is not met and remediation does not occur through normal channels, Atlassian has a range of remediation actions available, including:

  • Warning and remediation window: Atlassian notifies the partner of the issue and provides a window (typically 30 days) to remediate.
  • Revoke security badges: where an app no longer meets the requirements for a security trust signal (for example Cloud Fortified), Atlassian may revoke the badge until the requirements are met again. See Cloud Fortified Apps Program security requirements.
  • Hide the app from the Marketplace: the app is hidden from search and browse results so no new customers can discover or purchase it. Existing installs continue to function. This mechanism is documented as part of the Security Bug Fix Policy for vulnerability SLO breaches and is used in similar contexts for other severe or unresolved security compliance issues.
  • Pause the app: for severe, unresolved security issues where continued operation would put customers at risk, Atlassian may pause the app so that it is no longer operational for customers.
  • Temporary suspension: the partner's Marketplace presence is temporarily suspended while the issue is resolved.
  • Termination of the Marketplace Partner Agreement: reserved for severe or repeated non-compliance, fraud, or cases where Atlassian has lost confidence in the partner's ability to meet ongoing security obligations. Termination follows Atlassian's internal review process and includes customer migration windows where feasible.

In situations involving actual or imminent material harm to customers, clear evidence of malicious activity, or legal or regulatory obligations, Atlassian may act more quickly than the standard remediation flow would otherwise allow.


Where to go next

If you have questions about any of the areas on this page or need help planning a migration, please raise an ECOHELP ticket.

Rate this page: