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 Jul 13, 2026

Atlassian Enterprise Certified Program

The Atlassian Enterprise Certified (AEC) program recognizes Marketplace apps that meet rigorous enterprise standards for security, reliability, privacy, accessibility, and responsible AI use — going beyond the baseline security requirements required of all Marketplace cloud apps. The Atlassian Enterprise Certified program gives customers a clear, Atlassian-verified signal that an app is ready for their most business-critical needs.

The Atlassian Enterprise Certified program is open to all Forge cloud apps.

The Atlassian Enterprise Certified program will begin onboarding apps in Q3 CY2026. At the time of program onboarding, we will stop accepting new submissions for the Cloud Fortified Apps Program. Cloud Fortified will be phased out by the end of CY2026.

We will share more details via a Changelog on how to apply for the program once it is open.

Requirements

An app must meet the following requirements to be eligible for the Atlassian Enterprise Certified program. Each requirement lists the validation steps Atlassian carries out to confirm compliance.

1.0 Security

ID

Requirement

Validation

1.1

Evidence that a current annual penetration test has been completed. This could be the report behind NDA on your trust center or an attestation letter from your CREST accredited pen test provider.

  • App has a penetration test report from our Bugcrowd penetration test program in the past year

  • OR app has a penetration test from an approved CREST vendor, and the partner has submitted for approval via the [Ecosystem help desk](https://ecosystem.atlassian.net/servicedesk/customer/portal/34/group/109/create/4625) in the past year.

1.2

Public (or in the process of becoming public) security vulnerability reporting using Atlassian's Bug Bounty program.

  • App has a public (or in the process of becoming public) bug bounty program without any major violations (for example, unpaid submissions)

1.3

If the app processes or stores data outside of Atlassian's infrastructure, an architecture, data flow or network diagram should be publicly available (ideally on your trust center). Note: This can be protected by an NDA or a password.

  • Partner supplies a link or indicates that this is available on their trust center.

1.4

The app does not use any Connect modules.

  • Ecoscanner does not detect Connect module definitions in the Forge manifest.

1.5

The app does not collect or store credentials belonging to Atlassian user accounts, such as user passwords or personal API tokens, unless the app has an approved PAT usage exemption documented via an ADDON ticket. Note: OAuth and other short-lived access tokens must only be cached in memory with a TTL no longer than the token's expires_in value and must not be stored beyond their lifetime. Alternatively, store them in Forge Secret Storage, with a TTL that does not exceed the expires_in value.

  • Ecoscanner does not detect any Personal API Token collection or usage logic in the app code. It will do this by checking:

    • The frontend UI code contains no forms or prompts that request user PATs.

    • The backend code does not store any user PATs.

    • The backend code does not call any Atlassian APIs using a PAT token in the Authorization header.

1.6

Any Atlassian end user data stored outside the Atlassian apps or users' browsers must use full disk encryption at rest (including any app logs).

  • Your public trust center must explicitly list data encryption at rest for customer data.

1.7

The app only requests access to the data it needs (least privileged access).

  • Ecoscanner does not find any excessive permissions being requested that are not utilized in the code.

1.8

The app logs must not include personal data or credentials. Note: "personal data" is defined as information about an identified or identifiable natural person, or which otherwise constitutes "personal data", "personal information", "personally identifiable information" or similar terms as defined in Applicable Data Protection Law.

  • If you are using Forge logs:

    • We will continuously monitor app logging behavior for any patterns of personal data logging and flag them to developers via an Ecoscanner vulnerability.

    • Note: These scans are not exhaustive. You remain responsible for verifying that personal data is not recorded.

  • If you are using remote logging:

    • We will rely on the new requirement "The app must publicly document (ideally on your trust center) what data is stored in the app logs and the retention period of these logs." for this.

1.9

The app must publicly document (ideally on your trust center) what data is stored in the app logs and the retention period of these logs. Note: This can be protected by an NDA or a password.

  • Partner supplies a link or indicates that this is available on their trust center.

1.10

Any Atlassian End User Data accessed by an application or a service should be authenticated and authorized appropriately.

  • Ecoscanner does not detect any unauthenticated web triggers or REST APIs exposed on the Forge app.

  • Ecoscanner does not detect unauthenticated & unauthorized remote hosts defined in the Forge manifest remote list.

1.11

The app must not use end-of-life NodeJS runtimes.

  • Ecoscanner does not detect any EOL NodeJS runtime versions in the Forge app manifest runtime.

1.12

The app must be transparent about all data egress. Notes:

  • All "first hop" outbound (egress) domains must be explicitly listed in the Forge Manifest to prevent unrestricted network access.

  • Any additional egress (for example, where the customer chooses which domains they egress to) must be under the customer's control.

  • The app must also publicly disclose all third-party integrations and subprocessors that may receive egressed data.

  • Ecoscanner does not detect any broad wildcards in the Forge app manifest (subdomain wildcards *.domain.com are acceptable; full * or *.com TLD wildcards are not).

  • All default egress domains are explicitly listed in the Forge Manifest.

  • Partner provides details on their trust center (NDA or password-protected is acceptable) of all subprocessors/third-party integrations that may receive egressed data.

1.13

Vulnerability Scanning.

  • The app must include CI/CD checks to prevent introducing common security vulnerabilities, such as Secrets or Forge security misconfigurations, and npm vulnerabilities.

  • App owners must patch any reported vulnerability Critical/High tickets before onboarding.

  • After onboarding, participating apps must maintain a net introduction rate below the median for detectable SAST vulnerabilities that can be caught by vulnerability-scanning gating.

1.14

App must default to asUser() when performing an action on behalf of the user.

  • Ecoscanner does not detect usage of privilege escalation without validating user permissions for the action.

  • When a user initiates an action that uses asApp(), the app first confirms that the user has the required permissions to access the target resource before executing the request.

1.15

App developers must ensure that any external services their app calls are only accessible over HTTPS with TLS 1.2+ (or higher). Note: Forge-managed egress already enforces this, so this requirement applies to any additional outbound connections or infrastructure the partner controls.

  • Ecoscanner will validate HTTPS, and newer TLS versions are supported by external egress points defined in the Forge manifest.

1.16

Apps must not use third-party dependencies or packages with known Critical and High severity vulnerabilities, and must prioritize patching when new vulnerabilities are disclosed.

  • There are no open Atlassian Marketplace Security (AMS) tickets of High/Critical severity at onboarding, and you continuously fix vulnerabilities within the Marketplace bug fix policy timeline without violations.

2.0 Reliability

ID

Requirement

Validation

2.1

Publicly documented incident management process, including a public Statuspage.

  • Partner has provided an active Statuspage or similar tool for tracking system health and for proactive customer communications during incidents.

  • Partner has a well-documented incident management process, including the following elements:

    • Incident detection, triaging and classification.

    • Incident resolution timelines.

    • Post-incident analysis and prevention.

2.2

Participation in a collaborative incident response program with Atlassian.

  • Partner has provided a 24/5 email mailbox and emergency phone security contact for security alerts. Contact must preferably be a security professional or third-party Security Operations Center. Alternatively, the technical lead of the app.

  • Partner collaborates with Atlassian during security incidents following the Atlassian-defined incident response process and communications channel.

  • Partner must respond to alerts within 8 hours.

    • Atlassian will conduct random test security incident notifications to validate partners have the correct contacts and are responding within SLA during business hours.

  • Notifies Atlassian of any security incidents impacting customers.

    • Atlassian will utilize customer escalations and breach monitoring services to identify undisclosed security incidents.

2.3

Partner must respond within 1 day (24 hours) to critical customer support issues, 5 days a week, in the Marketplace Partner's local timezone.

  • Atlassian will conduct random support request tests to validate that partners have the correct support contacts in place and are responding within SLA.

3.0 Privacy & Compliance

ID

Requirement

Validation

3.1

Public trust center available.

  • Ecoscanner has identified that the Trust Center link included in the app listing is accessible to the public and originates from a supported third-party provider.

    • List of supported providers: Vanta, Safebase, Drata, Sprinto, TrustShare, Comp AI, Conveyor, Delve, Scrut Automation, SecureFrame, TrustCloud, UpGuard, AuditBoard, OneTrust, Thoropass, Whistic.

    • Trust centers not currently supported can request a manual review by Atlassian for exceptions. These must meet the feature parity of other vendors, for example:

      • The site is public, not requiring a password or personal information to view.

      • Certifications are visible as badges, and certificates can be viewed.

      • Audit reports can be requested and viewed by customers.

3.2

SOC 2 Type II or ISO 27001 compliance.

  • Ecoscanner checks for compliance frameworks that are explicitly mentioned on the public trust center.

    • SOC 2 Type II or ISO 27001 badges are listed under Compliance Certifications.

    • SOC 2 Type II or ISO 27001 report is available under Resources on the trust center. Audit reports can be protected by NDA or passwords.

3.3

If an app stores data remotely, it should support Data Residency (pinning and migration). Note:

  • There is no mandatory requirement to support any specific regions.

  • The app should support at least 2 regions.

  • Apps that only store data within the host product (such as Jira or Confluence) meet this requirement.

  • For Runs on Atlassian:

    • The app uses only Forge storage modules, meaning Data Residency pinning and migration support is built in.

  • For Forge Remote:

    • The app's manifest contains:

      • region-specific URLs in baseUrl

      • use of the migration:dataResidency module

3.4

The app clearly discloses its data retention and deletion policies covering any data egressed from the app. Note: This can be protected by an NDA or a password.

  • Partner supplies a link or indicates that this is available on their trust center.

3.5

Publicly available privacy policy.

  • Privacy policy is shown on the app listing.

  • Atlassian will manually review the privacy policy during initial app onboarding, then continuously monitor for health.

  • Ecoscanner crawler detects a publicly available privacy policy page that doesn't return a 404.

  • The page contains privacy policy language.

  • Privacy policy is hosted on the same domain as the partner's main website.

4.0 Accessibility

ID

Requirement

Validation

4.1

The app has a Voluntary Product Accessibility Template (VPAT) publicly available. Notes:

  • Accessibility testing can be automated or performed manually.

  • No mandatory accessibility level is required.

  • Partner supplies a link or indicates that this is available on their trust center. Note: This can be protected by an NDA or a password.

5.0 AI & Responsible Use

ID

Requirement

Validation

5.1

If the app uses AI, there is a publicly available AI usage policy (ideally on the partner trust center).

  • Partner supplies a link or indicates that this is available on their trust center.

  • This can be protected by an NDA or a password.

Rate this page: