Service acccounts now available across all Atlassian Data Center products

[#1]

We’re excited to share that service accounts are now available across all supported Atlassian Data Center products:

• Jira Data Center 11.1
• Jira Service Management Data Center 11.2
• Confluence Data Center 10.1
• Crowd Data Center 7.1
• Bitbucket Data Center 10.1
• Bamboo Data Center 12.0

Service accounts are dedicated, non-human identities designed for automating tasks, running scripts, and integrating with external systems. They authenticate using OAuth 2.0, have tightly controlled permissions, and give admins full visibility and lifecycle control — without relying on individual user credentials.

Key benefits from service accounts in Data Center

Service accounts in Atlassian Data Center are built to help admins manage non-human access in a more secure and scalable way:

• Stronger security and separation from human users
  Use purpose-built, non-human identities instead of shared admin logins or long-lived personal tokens. Service accounts have tightly scoped permissions, no interactive login, and aren’t tied to a person’s credentials or email address.
• Standards-based API access with OAuth 2.0
  Each service account gets its own OAuth 2.0 Client ID and Client Secret. Use OAuth 2.0 client credentials for REST API access instead of basic auth or personal access tokens, with support for secure credential rotation and expiry.
• Centralized lifecycle management
  Create, view, edit, and delete service accounts directly from each product’s administration panel. Service accounts are managed locally per product instance.
• Auditability, governance, and compliance
  Actions performed by service accounts are visible in product audit logs and attributable to specific service accounts. Admins can track usage, see when a service account was last used, and centrally rotate or revoke credentials to meet internal and external compliance requirements.
• Resource restrictions
  When creating a service account, admins can define which actions (scopes) it can perform and which resources (for example, specific projects or spaces) it can access.
• Consistent experience across products
  Service accounts are available across Jira, Confluence, Crowd, Bitbucket, and Bamboo Data Center, as well as in Atlassian Cloud, providing a unified way to manage non-human access across environments.
• No additional license cost
  Service accounts don't count against your licensed user seats and are included in your Data Center deployment.
• Alignment with Atlassian Cloud
  Service accounts functionality is also available in Atlassian Cloud, helping you build patterns that work across both Data Center and Cloud and easing future migrations. 

Read more about the service account functionality

How Data Center and Cloud service accounts compare

Both Atlassian Data Center and Atlassian Cloud now support service accounts, but the operational models differ.

What’s consistent across platforms

• Non-human identities with distinct credentials, not tied to individual users
• OAuth 2.0-first authorization and standardized handling of secrets
• Clear audit trails and the ability to enforce least-privilege access

Key differences

Operational layer

• Data Center: service accounts are administered per product (for example, Jira Data Center, Confluence Data Center).
• Cloud: service accounts are administered at the organization level via Admin Hub, with centralized visibility and policy control.

Scope depth

• Data Center: scopes are aligned to read/write API categories, with permissions enforced using each product’s native permission model.
• Cloud: typically offers more fine-grained scopes with additional organization-wide guardrails and governance controls.

Provisioning model

• Data Center: integrates with your existing infrastructure and access patterns.
• Cloud: centralizes policies and governance through platform features in Admin Hub.

How customers are using service accounts — examples

Customers typically use service accounts to:

• Run automation scripts and scheduled jobs
• Power custom tools and business-critical internal applications
• Extract data for reporting and analytics
• Integrate Jira, Confluence, and other tools with external systems via APIs

We’d love your feedback

If you’re using (or planning to use) service accounts in your Data Center environment, we’d like to hear from you:

• What use cases are you enabling with service accounts?
• What’s working well so far?
• Where do you still see gaps (permissions, observability, identity provider integration, migration, etc.)?

Please share your experiences and questions in the comments so we can continue to improve this capability.

[Pawel Wysocki]

Hi,

This is good news, but I’d like some clarification around migration from Data Center to Cloud. Right now we use standard accounts that act like service accounts. If we convert those into the new “service account” type, how does that help with migration?

For example, let's say we currently have 10 service-style accounts in Jira DC. During migration to Cloud, will those be transferred and recognized as service accounts as well, or not?

Cheers

[Olga Springer]

Hello! There’s no automatic “DC service account → Cloud service account” conversion yet, but using DC service accounts can still help you prepare for Cloud:

• You move away from “fake human” accounts and shared logins.
• You start using OAuth 2.0, scopes, which is very similar to how Cloud service accounts work.
• You get a cleaner, auditable list of non-human access that you can then map to Cloud service accounts during migration.

For teams close to migration, there are two realistic paths:

1. If security and hygiene are your priority right now, convert your current “service-style” users on DC into proper service accounts and secure them (least privilege, OAuth 2.0, no interactive login). Later, when you migrate, you recreate equivalents as service accounts in Cloud and point your integrations at the new Cloud endpoints/credentials.

2. If you want to minimize rework before a near-term migration, keep your “service-style” accounts as standard users on DC for now. When you migrate, they’ll come over as regular cloud user accounts. You can then gradually replace them with cloud service accounts and retire the old ones.

Both paths are valid; which one is better depends mostly on your migration timeline and security/compliance requirements.