Forge vs Connect: A 2026 Security Guide for Jira App Buyers

Atlassian Connect routes your Jira data through external vendor servers. Atlassian Forge runs the app inside Atlassian's own cloud with zero data egress by default. Since September 17, 2025, only Forge apps can be submitted to the Marketplace — but the installed base still has thousands of Connect apps, so buyers evaluating Jira apps today need to know the difference. Here's what it means for your compliance posture.

Since September 17, 2025, new apps on the Atlassian Marketplace must be Forge-native — Connect-framework app submissions are closed, though updates to installed Connect apps continue (Atlassian Developer, 2025). Major Connect incumbents — including Structure by Tempo and BigPicture by Appfire — remain on the Connect framework as of April 2026, with no public Forge migration plan announced.

What is Atlassian Forge?

Atlassian Forge is a serverless app platform that runs third-party code inside Atlassian's own cloud. When a developer publishes a Forge app to the Marketplace and a Jira admin installs it, Atlassian provisions a dedicated runtime environment for that installation — serverless functions, a Forge SQL database, a Forge KVS key-value store, and an event subscription pipeline — all hosted on Atlassian infrastructure in the region assigned to the tenant. The vendor writes the code and ships it to Atlassian; Atlassian runs it.

The security implications are structural. Because the code runs inside Atlassian's boundary, a Forge app inherits the platform's network isolation, encryption, and rate-limit enforcement automatically. Its outbound network access is controlled by an explicit manifest permission (external.fetch) that the Jira admin reviews at install time. Its database and key-value storage are per-tenant by default. And the app cannot see any data outside its declared scopes, because Forge issues short-lived per-request tokens that the vendor's code never sees or stores.

What is Atlassian Connect?

Atlassian Connect is the older app framework, introduced around 2013 and still serving the majority of installed Jira Cloud apps as of 2026. Under Connect, the vendor operates its own server infrastructure — typically AWS, GCP, or a colocation facility — and hosts the app's UI, business logic, and databases there. Atlassian's cloud sends webhook events to the vendor's server; the vendor's server makes Jira REST API calls back into the tenant, authenticated by JWT or OAuth 2.0.

Connect apps work, and many of them are built by mature vendors with serious security programs. But the architecture puts the vendor in the data path. Every Jira page that includes a Connect app panel loads an iframe served from the vendor's domain. Every API call the app makes runs through the vendor's servers. Every row of cached data lives on the vendor's storage. That means your security review has to cover the vendor's hosting, sub-processors, incident response, key management, and availability — on top of Atlassian's. For buyers under tight compliance boundaries, that's additional review surface the Forge model eliminates.

What's the key security difference?

Data egress. A Connect app, by definition, moves Jira data out of Atlassian's cloud and into the vendor's. A Forge app, by default, keeps Jira data inside Atlassian's cloud — the vendor's code runs there, the data stays there, and nothing leaves unless the app explicitly requests and the admin approves an external.fetch permission for a specific domain.

This single difference reshapes the rest of the review. In a Connect posture, the vendor is a data processor under the GDPR and must be included in your sub-processor inventory, your DPA, your breach-notification matrix, and your annual vendor review. In a Forge posture with no external.fetch, the vendor's code processes data but never receives it on vendor-controlled infrastructure — the data plane stays entirely within Atlassian. Whether that reduces the vendor to a sub-processor or removes them from the inventory depends on your legal interpretation, but the technical reality is less hand-off, fewer trust hops, and a smaller blast radius.

What did Atlassian change on September 17, 2025?

Atlassian closed Connect-framework submissions to the Marketplace on September 17, 2025. From that date, any brand-new app submitted for Marketplace listing must be built on Forge — Connect submissions are rejected at intake. Updates to apps that were already listed on Connect before the deadline continue through the normal Marketplace review process; Connect is not being force-migrated.

Atlassian described the move as the completion of a multi-year platform transition. Forge is the platform Atlassian plans to invest in going forward — Rovo AI actions, Forge SQL, Forge Realtime, and new runtime capabilities all ship to Forge first and may never come to Connect. For buyers, the practical effect is that new PPM apps, new automation apps, new AI apps entering the Marketplace in 2026 and beyond are Forge-native by mandate, while the installed base of Connect apps — including several Marketplace top-20 incumbents — will continue operating on the older framework until each vendor chooses to rewrite. See the Atlassian Community announcement and the official migration guide for the exact timeline and technical implications.

What compliance does a Forge app inherit by default?

Because a Forge app runs on Atlassian infrastructure and uses Atlassian-managed storage, it inherits the compliance posture Atlassian has built and audits at the platform layer. “Inheritance” is not marketing language here — it's the direct consequence of the app running inside the audited boundary. The headline inheritances are SOC 2 Type II (Atlassian's annual audit across security, availability, processing integrity, confidentiality, and privacy), ISO 27001 and ISO 27018 (information security management and cloud PII), PCI-DSS (for the payment flows Atlassian handles on behalf of Marketplace vendors), and GDPR processor commitments documented in Atlassian's standard DPA.

Data residency is enforced by the platform: if your Jira tenant is pinned to the EU, Australia, US, or another supported region, the Forge app's SQL database, KVS, and function execution environment are all provisioned in that same region. The Atlassian data residency page lists the full set of regions Atlassian supports. What a Forge app does not automatically inherit is the vendor's own operational controls — how the vendor writes code, manages source control, does incident response, or handles support access. Enterprise buyers should ask each vendor for a letter of attestation that maps the vendor's own controls onto the Atlassian scope, plus evidence of the vendor's SDLC.

What is Cloud Fortified and does it apply here?

Cloud Fortified is Atlassian's highest Marketplace app-trust tier, introduced in 2021 and expanded through 2026. To earn the badge an app must meet enhanced requirements across reliability, security, support, and customer success — a published availability SLO, a documented incident-response SLA, a public security program, and a 24/5 support commitment. Apps that pass Cloud Fortified review get a visible badge on their Marketplace listing and are surfaced preferentially in enterprise buying flows.

Forge apps have a structurally easier path to Cloud Fortified than Connect apps because several of the program's requirements — data residency, encryption at rest, zero-egress runtime, scope enforcement, mandatory permission grants — are enforced at the Forge platform layer rather than the vendor layer. A Connect vendor has to build those controls themselves and document them in the audit. A Forge vendor has to confirm them and attest that the platform enforces them. The remaining Cloud Fortified work — SLOs, support commitments, internal incident response — still falls on the vendor. See the Cloud Fortified program page for the current criteria.

What scopes and permissions does a Jira app need?

Every app — Forge or Connect — declares the Jira API scopes it needs to do its job. The honest breakdown for a typical PPM app: it needs to read issues and projects (read:jira-work), read user profiles (read:jira-user) to render assignee pickers, and write to issues (write:jira-work) for inline editing. An app with Gantt or timeline features may also request access to sprint and version data. An app with admin features (project templates, workflow automation) may request manage:jira-project. None of these are unusual or suspicious on their own.

What deserves scrutiny is scope breadth versus feature need. An app requesting admin:jira-project when it doesn't ship project-admin features is a yellow flag; an app requesting read:jira-user with no people-related UI is worth asking about. Forge apps publish their full scope set in the manifest, which any Jira admin can read post-install. Connect apps declare their scopes in the app descriptor but present them as a grouped grant to the admin at install time. In both cases, the admin can revoke the app by uninstalling it; neither framework supports per-scope toggling after install. That's a platform limit, not a vendor choice.

How does data residency work for Forge apps?

A Forge app's data follows the Jira tenant's residency setting automatically. When an admin pins their Jira Cloud site to a specific region — EU, Australia, US, UK, Germany, Japan, Korea, Canada, Switzerland, or any other Atlassian-supported region — the Forge platform provisions that app's storage environment (Forge SQL, Forge KVS, scheduled job state, event queues) in the same region. The vendor has no configuration knob for this, and no code path can bypass it: the Forge runtime enforces the boundary.

For buyers under GDPR, data-sovereignty, or state-secrets-style regulations, this is a meaningful difference from Connect. A Connect vendor can choose where its servers run, and that choice is a negotiation point in enterprise contracts. A Forge app cannot choose — it stores data wherever the tenant is pinned. For the EU customer, that's a Frankfurt or Dublin region run by Atlassian, audited under Atlassian's GDPR processor commitments. No separate vendor data-residency review is needed because the app is not the entity making the decision.

What about GDPR and data subject requests?

Under the GDPR, a Jira tenant's admin is the data controller; Atlassian is a processor for Jira Cloud; a third-party app vendor is a sub-processor. For a Forge app with no external.fetch, the sub-processor relationship is narrow: the vendor's code processes data inside Atlassian's boundary, but the vendor never receives the data on vendor-controlled infrastructure. For a Connect app, the vendor is a full sub-processor whose hosting, sub-processors, and data handling you must review and document.

Data subject requests (access, rectification, erasure) are served through Jira's standard user-deletion flow. When a Jira admin deletes a user, Jira fires a product event that propagates to all installed apps — a well-built Forge app subscribes to avi:jira:deleted:user- and avi:jira:deleted:issue-style events and clears the corresponding cached rows automatically. Atlassian publishes its full GDPR resource center with DPA templates, sub-processor lists, and SCC guidance. Ask each Jira app vendor — Forge or Connect — to confirm they handle these events and meet the 30-day DSR fulfillment window.

How do Connect apps handle this today?

Established Connect vendors — Tempo, Appfire, Adaptavist, K15t, and the other large Marketplace partners — publish their own security programs: SOC 2 reports (independently audited), ISO 27001 certifications, DPAs, sub-processor lists, incident-response procedures, and in many cases Cloud Fortified badges earned under the Connect framework. Trust in a Connect vendor is vendor-by-vendor — you evaluate the vendor's own program, not just the platform's.

This is workable. It's how enterprises have bought SaaS for two decades. But it does mean that when you evaluate a Connect app, you are doing two reviews: Atlassian's platform posture and the vendor's hosting posture. Each vendor's program has strengths and gaps. When you evaluate a Forge app with no external.fetch, you are doing one review: Atlassian's platform posture, plus a narrower check on the vendor's SDLC and operational practices. For enterprises with dozens of installed apps, the Forge model compounds into meaningfully less review overhead over time.

What to ask a Jira app vendor in 2026

The 8-question security evaluation below is what we recommend enterprise IT and security teams use when reviewing any Jira Cloud app. It works for Forge and Connect apps alike; several of the questions resolve quickly for Forge apps because the platform enforces the answer.

Is the app Forge-native, Connect, or hybrid? Ask the vendor directly and verify on the Marketplace listing. Forge-only is the cleanest posture; a hybrid app that runs some workloads in Forge and others in a Connect-style external service should disclose the split.
What scopes does the app request, and why each one? Get the Forge manifest (or the Connect descriptor). Every scope should map to a real feature. A PPM app requesting write:jira-work is reasonable; one requesting admin:jira-project without a clear reason is a yellow flag.
Does the app declare external.fetch? If so, to which domains? For Forge apps, the external.fetch block is the egress inventory. If it is empty, the app cannot exfiltrate data, period. If it is populated, verify each domain is the vendor’s own or a legitimate integration (e.g., a ticketing system). Block unknown third-party domains.
Where does the app’s data live? For Forge apps, data follows your Jira tenant’s residency. For Connect apps, ask the vendor for their hosting region, sub-processor list, and redundancy posture. If you have a regulatory boundary (EU, Australia, US Federal), confirm the vendor’s hosting matches.
What is the vendor’s own SOC 2 / ISO 27001 status? Forge apps inherit the platform certifications but not the vendor’s SDLC. Request the vendor’s own audit reports, or a letter of attestation that maps the vendor’s controls onto the Atlassian scope. Accept that early-stage Forge vendors may not have independent audits yet.
How does the app handle data subject requests and deletion? Per GDPR and similar regimes, you must be able to delete a user’s data on request. For Forge apps, the Jira deletion event propagates to the app’s cache automatically; confirm the vendor handles the event. For Connect apps, ask for the vendor’s DSR process and SLA.
Is the app Cloud Fortified? Not required, but a strong positive signal — Cloud Fortified adds published SLOs, incident-response SLAs, and support commitments. If the app is not Cloud Fortified, ask whether it is on the program roadmap and when the vendor expects to achieve the badge.
What happens when the app is uninstalled? Forge apps fire an uninstall lifecycle event that clears installation-scoped storage; the environment is torn down within 90 days. Connect apps should document their data-deletion SLA and confirm whether any backups or logs retain customer data after uninstall. Get this in writing.

If the vendor cannot answer all eight questions in writing within a few business days, treat that as signal. Established vendors publish most of this on a trust page; newer vendors should be willing to send it directly. A vendor that bristles at scope-level questions is not ready for an enterprise deployment, regardless of framework. Frame the questions against a standard like NIST SP 800-171 or the OWASP SaaS security cheat sheet if your compliance framework requires it.

How to migrate from Connect to Forge apps

For most enterprises, the migration is incremental. Start by inventorying the Connect apps currently installed on your Jira tenant — the admin Apps page shows every installed app with its framework label. For each Connect app, check the Marketplace for a Forge-native alternative in the same category: in the PPM category alone, Forge-native entrants now cover most of what the Connect incumbents ship. Not every Connect app has a Forge replacement yet, and some never will; that's fine, the goal is reducing Connect surface, not eliminating it overnight.

Next, plan a parallel-run migration. Install the Forge replacement alongside the Connect incumbent, import the existing data (many Forge apps ship migration tooling for exactly this), validate a representative workload for 2–4 weeks, and cut over when the team is comfortable. Decommission the Connect app on your own schedule once the new app is proven. This avoids the “rip and replace” risk and gives your security team a documented parallel period to confirm the Forge app's behavior matches the Connect incumbent's. When you uninstall the Connect app, confirm with the vendor that their data-deletion SLA matches their contract. See Foundation's migration tools for an example of how a Forge app can ingest a Connect app's data directly.

How I researched this guide

This guide draws on Atlassian's own platform documentation, the Forge security model published by the Atlassian developer team, the Marketplace security requirements for vendors, and Atlassian's Trust Center. The Forge vs Connect architectural distinctions are reproduced from the Forge security docs and the Forge runtime reference; the September 17, 2025 Connect submission deadline is from Atlassian's own announcement. Compliance inheritance claims come from the Atlassian Trust Center, which publishes the current audit reports under NDA. Cloud Fortified criteria are from Atlassian's public Cloud Fortified program page. The 8-question evaluation checklist is drawn from real enterprise procurement reviews the Foundation team has participated in during 2025–2026 and mapped against NIST SP 800-171 control families. This guide will be revisited quarterly; corrections welcome to [email protected].

Frequently asked questions

Is Forge more secure than Connect?

In the default case, yes — because Forge moves the trust boundary inward. A Connect app runs the vendor’s own code on the vendor’s own servers and makes Jira API calls back into your tenant; the vendor is an independent data processor and you need to review their hosting, incident response, sub-processors, and key management. A Forge app runs inside Atlassian’s cloud on Atlassian-operated infrastructure, stores its data in Forge SQL and Forge KVS in your tenant’s region, and cannot call out to external services unless it explicitly requests an external.fetch permission the admin approves at install. That doesn’t make every Forge app perfectly safe — a Forge app with sloppy scopes, permissive external.fetch, or a bad SQL design can still cause harm — but the baseline is materially higher and the review surface is narrower.

Can I trust a Connect app in 2026?

Many Connect apps are run by mature vendors with serious security programs — Tempo, Appfire, and the other large Marketplace partners publish SOC 2 reports, maintain dedicated security teams, and have years of incident history you can review. The question isn’t whether you can trust them; it’s whether you want your security review to cover an external hosting environment on top of Atlassian’s. If your compliance framework (HIPAA, FedRAMP Moderate, financial-services regulators) requires that covered data stay inside a specific boundary, Forge’s zero-egress default is structurally easier to sign off on than Connect’s vendor-hosted model. For lower-sensitivity workloads, a well-run Connect app remains a reasonable choice.

What happens to existing Connect apps after September 17, 2025?

They keep running. Atlassian’s September 17, 2025 deadline stopped new Connect-framework app submissions to the Marketplace — the frameworks themselves are still supported and installed Connect apps continue to work. Existing Connect apps can ship updates under the Connect model for the foreseeable future. What changed is the strategic direction: the Marketplace is Forge-first for new apps, and vendors have been told Connect will sunset eventually. Buyers should expect major incumbents to stay on Connect through at least 2027, at which point an accelerating share of Marketplace search results and Atlassian-promoted apps will be Forge-native.

How do I check if an app is Forge-native before I install it?

Open the app’s Marketplace listing and look at the Hosting Options or technical details block: Atlassian labels apps "Cloud" or "Cloud — Forge" in the system requirements. During the install flow, Forge apps show a permission screen that lists Forge scopes (read:jira-work, storage:app, etc.) and any requested external.fetch domains; Connect apps show a simpler permission grant that references the vendor’s hosted URL. As a third check, an admin can open the Apps section of Jira Cloud admin, pick the installed app, and verify whether it shows Forge-style permission and manifest details. If you are pre-install and can’t tell from the listing, email the vendor and ask — any honest vendor will tell you without hesitation.

Does a Forge app automatically inherit Atlassian’s SOC 2 report?

A Forge app inherits the runtime, storage, and infrastructure controls that Atlassian audits under SOC 2 Type II, because the app runs on that exact infrastructure. What it does not inherit is the vendor’s own operational controls — how the vendor writes code, manages source control, handles support access, or responds to incidents. Enterprise buyers who need a full SOC 2 assessment of a Jira app should ask for a letter of attestation that maps the vendor’s controls onto the Atlassian scope, plus evidence of the vendor’s own SDLC, secret-management, and incident-response practices. Most Forge vendors are still building these programs; expect variance across the Marketplace.

What’s the performance impact of Forge vs Connect?

Historically Connect apps had a latency advantage for compute-heavy operations because vendors could run dedicated infrastructure sized to their workload. Forge’s serverless model has cold-start and cross-region hop overheads that some Connect apps avoid. In practice, the gap has narrowed through 2025–2026 as Atlassian invested in Forge runtime performance and added Forge SQL (which removes round-trips to vendor-hosted databases). For most interactive workflows — UI rendering, inline editing, short JQL queries — the difference is imperceptible. For heavy batch processing (large-scale JQL imports, cross-project reports over 50K issues), well-architected Forge apps use async events and Forge SQL to match or beat Connect performance.

Can Forge apps call external APIs?

Yes, but only with explicit admin consent. A Forge app declares external.fetch permissions in its manifest listing the exact domains it wants to reach; at install time the admin sees that list and must approve it. The Forge runtime then enforces that restriction — a call to any other domain fails at the platform layer, not in the app’s code. This is a meaningful contrast with Connect, where the vendor’s server-side code can call any URL it likes and the admin has no runtime enforcement. For buyers this means the external.fetch list in a Forge manifest is the definitive egress inventory — there is nothing else to audit.

What data stays inside Atlassian when I use a Forge app?

By default, all of it. A Forge app’s database (Forge SQL), key-value store (Forge KVS), scheduled-job state, and event-handler invocations live in Atlassian’s cloud in the region Atlassian assigned to your tenant. Jira issues, users, permissions, and the app’s own cached data never leave that boundary unless the app explicitly requests external.fetch and the admin approves it. A Forge app that declares no external.fetch is, by platform construction, a zero-egress app. That is the claim the Forge runtime enforces — it’s not a vendor promise.

Is Cloud Fortified required for enterprise Jira app purchases?

Not strictly required, but it’s become a standard line item in enterprise security reviews. Cloud Fortified is Atlassian’s highest Marketplace app-trust tier — apps must meet enhanced reliability, security, and support standards on top of the baseline Marketplace requirements. Many enterprise procurement teams will only sign off on apps with the Cloud Fortified badge for critical workflows. Forge apps have a structurally easier path to Cloud Fortified because several of the underlying requirements (data residency, encryption, scope enforcement, incident reporting) are inherited from the Forge platform itself.

Where can I audit a Marketplace app’s scopes and data handling?

Three places. First, the Marketplace listing’s Privacy & Security tab, which Atlassian standardized across listings — it shows the vendor’s data-handling claims, certifications, and DPA availability. Second, the install-flow permission screen, which lists the Forge scopes or Connect permissions that must be granted. Third, after install, the Jira admin Apps page shows the active permissions, storage usage, and for Forge apps, the full manifest including any external.fetch domains. Enterprise buyers should request a written security pack from the vendor that covers the app’s threat model, data-flow diagram, DPA, and, for Forge apps, a copy of the manifest.