Atlassian Cloud Security Guide: Jira, Confluence and API Tokens

Atlassian Cloud security starts from an uncomfortable fact: Jira, Confluence and Bitbucket hold an organisation's plans, architecture diagrams, incident notes, source code and, too often, the credentials people paste into tickets and pages, yet access to them is usually governed by permission schemes nobody has reviewed since the site was set up. Atlassian secures the cloud platform; the customer decides who can see what, which tokens and apps can act on the data, and what leaves the tenant. This guide covers Atlassian admin through Atlassian Administration and Atlassian Guard, Jira permission schemes, Confluence space permissions and anonymous access, API tokens and offboarding, Bitbucket credentials, Marketplace and Forge apps, the Atlassian Rovo MCP server, and data residency and backups. It is for Atlassian administrators, SaaS security teams and identity teams that run Atlassian Cloud.

Key takeaways

• Atlassian Cloud is not Data Center. Exploited Confluence flaws such as CVE-2023-22515 hit self-managed Data Center and Server; in Cloud, the main risks are permissions, tokens, apps and accounts.
• API tokens are the quiet back door. A user API token works with the account email over basic authentication, survives SCIM deactivation while site access remains, and before 15 December 2024 could be created without any expiry.
• Public and anonymous access is all or nothing. A Jira space with Browse set to Public, or a Confluence space open to anonymous users, exposes everything in it, and Confluence warns such content "will show up in Google searches".
• Apps and AI clients act with real permissions. Marketplace apps, Forge apps and MCP clients inherit what an admin approved or what the user can see, so govern them like users.
• Guard tier decides what you can see. Enforced SSO, token expiry policy and session controls need Atlassian Guard Standard; in-app activity logging and threat detection need Guard Premium or Cloud Enterprise.

Shared responsibility in Atlassian Cloud

The Data Center distinction matters for incident triage. CISA's advisory on CVE-2023-22515, a broken access control flaw used to create "unauthorized Confluence administrator accounts", applied to Confluence Data Center and Server 8.0.0 to 8.5.1 and stated that Atlassian Cloud sites on atlassian.net were not affected. If you run both, patch and monitor the self-managed estate separately. For the wider SaaS picture see the SaaS Security Guide.

Atlassian Administration and Atlassian Guard

Atlassian Administration (admin.atlassian.com) is where an organisation verifies domains, manages accounts, sets authentication policies, reviews connected apps and reads the audit log. Atlassian Guard is the security subscription layered on top. Atlassian announced in May 2024 that "Atlassian Guard unifies existing Access and Beacon beta capabilities", so Guard Standard carries the former Atlassian Access features (SSO, user provisioning, user API token management) and Guard Premium adds data classification, sensitive data detection, threat detection and extended audit logs.

• Separate policies by population: SSO enforcement locks out anyone not in the identity provider, so put external collaborators and service accounts in their own policy rather than weakening the main one.
• Provision with SCIM: drive group membership from the identity provider so Jira and Confluence access follows role changes. See the SCIM Provisioning Guide.
• Keep admins few: organisation admins can change every policy and revoke every token. Treat them as privileged accounts with phishing-resistant MFA at the identity provider.

Jira permissions and permission schemes

Jira security rests on permissions, and Atlassian's current Jira Cloud documentation calls projects "spaces". Access is controlled at two levels: global permissions, which "define what users can do across your entire site", and permission schemes, which define what users can do within a space. A scheme "can be shared with other spaces, but any changes will be applied to all that use it", which is efficient and dangerous in equal measure.

• Grant to roles, not people: build schemes on space roles and groups so one scheme serves many spaces "without granting unwanted access", and space admins manage membership without Jira admin rights.
• Find public spaces: setting Browse spaces to Public lets "anyone" view the space and its work items without Jira access. Audit every scheme for Public grants, and remember that Browse can "reveal the details of spaces in the directory and in search" even to users who cannot open items.
• Use issue security for sensitive work: security incidents, HR cases and vulnerability tickets need work item security schemes so only a named group sees them. These are not available on Free sites.
• Jira Service Management: customer portals deliberately expose a request surface to people outside the organisation. Restrict who can raise requests, keep agent permissions separate from customer access, and do not let customers browse other customers' requests.
• Jira access review: security in Jira depends on knowing who holds each grant, so each quarter export scheme grants, group memberships and space role holders for spaces tagged sensitive and have owners certify them. See the Access Reviews Guide.

Confluence space permissions and anonymous access

Confluence security depends on how Confluence permissions combine: a site-level anonymous access setting, space permissions and page restrictions. Anonymous access is the highest-impact setting: enabling it globally means "Anyone on the internet will be able to find and access your Confluence instance", and a space opened to anonymous users gives them "access to all content within the space". New spaces start with no anonymous access.

• Lock the site setting: if you never need public spaces, use "Enforce site-level control" so spaces cannot turn anonymous access on. Atlassian notes this "can't be undone", so decide deliberately.
• Confluence space permissions: grant view and edit to groups, keep space admin to a few people per space, and review spaces whose permissions include broad groups such as all licensed users.
• Page restrictions inherit: view restrictions on a parent page pass to child pages, which suits sensitive sections inside an otherwise open space.
• Treat Confluence as an attacker's library: MITRE ATT&CK T1213.001 (Data from Information Repositories: Confluence) notes that Confluence may hold "network and architecture diagrams" and "testing or development credentials". Its detection guidance is programmatic and excessive access, including API scraping.

Atlassian API tokens, service accounts and offboarding

An Atlassian API token lets a script "replace your password with the token", sent with the account email over HTTP basic authentication. Many teams call a Jira API token a Jira API key; they act with the full permissions of the user who created them unless they are scoped. The API Key Management Guide covers the general lifecycle; the Atlassian specifics are below.

• Admin visibility: organisation admins can see each user API token's expiry and last use and "revoke one or more tokens from a centralized location", on any plan.
• Jira integration hygiene: automation rules with web request actions, CI jobs and reporting scripts often run on a person's token. Move them to service accounts with scoped tokens so a leaver does not break them, or keep them alive.
• Jira offboarding: Atlassian states that when a user "is deactivated or unsynced via SCIM, that does not automatically remove their site or product access", and "their user API tokens remain usable". Offboarding must remove site and product access or suspend the account, and revoke tokens. See the Joiner-Mover-Leaver Guide.

Bitbucket Cloud credentials

Bitbucket stores source code and pipeline configuration, so its credentials reach production. Atlassian stopped the creation of new app passwords on 9 September 2025 and announced that "Integrations with app passwords will stop working entirely on June 9, 2026"; the replacement is API tokens with scopes and an expiry date. Rebuild any integration that broke on a scoped token owned by a service account, not on a personal unscoped one. Keep pipeline secrets in secured repository or workspace variables rather than in bitbucket-pipelines.yml, and review which tokens and SSH keys can push to protected branches. The CI/CD pipeline exploitation demonstration showed how an exposed .git directory and a Bitbucket pipeline led to server takeover. See the CI/CD Pipeline Identity Security Guide.

Atlassian Marketplace apps and Forge

"Every Marketplace cloud app must adhere to Atlassian's mandatory app security requirements", and Atlassian scans listed cloud apps, but "Marketplace partners are independent businesses" and Atlassian "is not directly responsible for third-party products or services".

• Review before install: read each listing's Privacy & Security tab for permissions, certifications and data handling, and approve requested permissions knowingly.
• Restrict scope: admins can restrict app access to specific spaces or projects, or block apps from them, which suits apps needed by one team only.
• Prefer apps that keep data in Atlassian: the "Runs on Atlassian" badge marks Atlassian Forge apps that "exclusively use Atlassian-hosted compute and storage", match the host's data residency, let customers control egress and egress nothing except analytics. Atlassian is clear that these controls "do not prevent misuse of access granted to the app during installation".
• Track badge changes: Atlassian is sunsetting the Cloud Fortified badge on 31 December 2026, so do not build procurement rules on it.
• Review installed apps: use the Connected apps view in Atlassian Administration to remove unused apps quarterly. See the SaaS and OAuth App Governance Guide.

The Atlassian Rovo MCP server

Atlassian made its Rovo MCP server, an Atlassian-hosted remote Model Context Protocol server for Jira and Confluence, generally available on 4 February 2026; admin settings list it as the Atlassian MCP server. It is Atlassian's own route for AI assistants and coding agents that need a Jira MCP server or Confluence MCP server.

• Permissions: tool calls are "subject to their normal Atlassian app permissions", so an agent can reach everything its user can. Over-shared spaces become over-shared agent context.
• Authentication: users connect with OAuth 2.1 by default. API token authentication is optional and admins can turn it off.
• Allowed domains: admins control which AI tool domains may connect; this blocking "applies only to OAuth 2.1 tools", so API token use is not covered by it.
• IP allowlists: the organisation's IP allowlist applies to MCP requests whether they use OAuth or an API token.
• Logging: Atlassian provides MCP usage logs; review them for bulk reads by agents.

See the MCP Security Guide and the AI Coding Agents Security Guide.

Secrets in tickets, data residency and resilience

• Secrets in tickets and pages: engineers paste keys, passwords and connection strings into Jira comments and Confluence runbooks. Guard Premium sensitive data detection can find them; without it, run periodic scans through the API, rotate anything found and give people a vault link instead. See the Secrets Management Guide.
• Data residency: available for Jira, Jira Service Management, Jira Product Discovery, Confluence and Loom on Standard, Premium and Enterprise plans, with locations including the EU, Germany, the UK and the USA. "User account information data is considered out-of-scope", as are logs and audit log events.
• Jira data resilience: Backup Manager creates a site backup, but with attachments "you'll need to allow 48 hours between backups", and from 22 January 2026 it limits restores to backups 30 days old or less. Keep your own retained copies for longer recovery needs and test restores into a sandbox. See the Backup Security and Immutable Backup Guide.

Implementation roadmap

1. Claim and verify domains so all company accounts become managed, then inventory admins, groups and products.
2. Enforce SSO and two-step verification through a main authentication policy, with separate policies for contractors and service accounts. Pilot on the IT team before the whole organisation.
3. Close public exposure: list Public Browse grants in every Jira scheme and anonymous access in every Confluence space, confirm each with its owner and remove the rest.
4. Clean up tokens: export user API tokens with last-use dates, revoke unused ones, move integrations to service accounts with scoped tokens and set token expiry in policy.
5. Rationalise apps: remove unused Marketplace apps and restrict the rest to the spaces that need them.
6. Govern AI access: set allowed MCP domains, decide whether API token authentication is needed and apply IP allowlists.
7. Monitor: stream the audit log to your SIEM and add Guard Premium detections where licensed.

Testing and rollback: new authentication policies can be applied to a small group first, and members can be moved back to the previous policy. Token blocking takes up to 10 minutes to apply, so announce a window and keep a list of revoked integrations with owners to restore with scoped replacements.

Decision guidance

• Guard Standard or Premium: Standard is the baseline for any organisation with an identity provider. Premium earns its cost where Jira and Confluence hold regulated or highly sensitive data and you need in-app activity logs and exfiltration detection.
• Personal or service account tokens: personal tokens are acceptable for short-lived individual scripts; anything shared, scheduled or business-critical belongs to a service account with a scoped token and a named owner.
• Public spaces: if a knowledge base or service desk must be public, run it in a dedicated space or site with nothing else in it, rather than opening an internal space.
• Small organisations can rely on SSO, two-step verification, scheme hygiene and quarterly token review. Large organisations need multiple authentication policies, delegated space administration with certification, app governance and SIEM integration.

Detection and measurement

• Token hygiene: active user API tokens unused for 90 days, and share of integrations on scoped tokens.
• Public footprint: number of Jira spaces with Public Browse and Confluence spaces with anonymous access, each with an approved owner.
• Leaver closure: leavers whose site access and tokens were removed within one working day.
• App footprint: installed apps with no use in 90 days, and apps restricted to specific spaces.
• Review completion: percentage of sensitive spaces certified in the last quarter.

Common failure patterns

• Stolen credentials, no SSO: in the Schneider Electric Jira breach, infostealer credentials led to 40GB of project data being stolen. Enforced SSO with strong MFA and token controls removes password-only paths.
• Tokens outliving people: SCIM deactivation assumed to end access while tokens keep working.
• Integration tokens stored elsewhere: third-party services that hold Bitbucket tokens become a target, as the Docker Hub breach showed with GitHub and Bitbucket tokens for 190,000 accounts.
• One shared scheme opened for one space: a Public grant added for a single space applies to every space using that scheme.
• Credentials in runbooks: passwords in Confluence pages give any reader, app or agent with access a ready-made foothold.

Framework mapping

Practitioner checklist

• Verify domains, enforce SSO and two-step verification, and keep organisation admins to a small, protected group.
• Create separate authentication policies for contractors and service accounts.
• Remove Public Browse grants and anonymous Confluence access that lack an approved owner.
• Use work item security for incident, HR and vulnerability tickets.
• Replace personal and unscoped API tokens in integrations with scoped service account tokens and set expiry in policy.
• Remove site and product access and revoke tokens at offboarding, not just SCIM deactivation.
• Migrate remaining Bitbucket app passwords to scoped API tokens and keep pipeline secrets in secured variables.
• Restrict Marketplace apps to the spaces that need them and remove unused apps quarterly.
• Set allowed MCP domains, decide on API token access and apply IP allowlists.
• Stream the audit log to your SIEM and test a Jira restore from backup.

Standards and references

• Atlassian: Manage API tokens for your Atlassian account
• Atlassian: Authentication policy settings for your organizations
• Atlassian: Understand Atlassian Guard
• Atlassian: Control whether spaces can turn on anonymous access
• Atlassian: Control Atlassian Rovo MCP server settings
• Atlassian: Marketplace trust and security
• CISA: Threat Actors Exploit Atlassian Confluence CVE-2023-22515 for Initial Access to Networks
• MITRE ATT&CK: T1213.001 Data from Information Repositories: Confluence

Related NHI Mgmt Group resources: SaaS Security Guide · API Key Management Guide · MCP Security Guide · Collaboration Tool Security Guide · Joiner-Mover-Leaver Guide