One of the most impactful updates to the Atlassian Cloud platform in recent months just arrived - and it solves a problem many admins have quietly dealt with for years.
Atlassian has introduced Service Accounts for Cloud, and while the feature seems technical at first glance, it directly addresses a critical compliance issue buried deep in the fine print of the Atlassian Customer Agreement.
⚠️ The Problem: Shared Credentials Are Prohibited
According to the agreement (Section 2.1):
“User accounts are granted to individual, named persons and may not be shared.”
“You must ensure that all Authorized Users keep their user IDs and passwords [...] strictly confidential.”
Despite this, many teams have historically:
- Used “bot” accounts for automation
- Shared passwords or API tokens across team members
- Scripted REST API actions (e.g. ticket creation, page updates) using credentials from a human user
While convenient, these patterns violated Atlassian’s terms and created governance blind spots - until now.
✅ The Solution: Atlassian Service Accounts
With the launch of Atlassian Service Accounts, you can now create dedicated, non-human technical identities - designed specifically for automation, scripting, and system-level integrations.
What makes a service account different?
- 🔐 Not tied to a person - it's a separate identity with no human user
- 📧 Distinct email format: xyz@serviceaccount.atlassian.com
- ⚙️ UI-based API token generation for secure REST access
- 📋 Assignable product access (e.g. Jira, Confluence) - just like normal users
- 🧾 Compliant with Atlassian’s license terms and audit policies
⚙️ Use Cases: Where Service Accounts Shine
Scenario | Old Way (Problematic) | New Way (Compliant) |
|---|---|---|
Scripted Jira ticket creation | Shared personal token | Service account with API token |
CI/CD integration with Confluence | Fake user with SSO bypass | Bot user with scoped product access |
Automation rules in Forge | Human user context | Dedicated service identity |
Data sync with external DBs | Generic “admin” login | Named service account, full audit trail |
🔄 Familiar for Data Center Users
If you're migrating from Atlassian Data Center, you're likely used to managing service accounts locally. Atlassian Cloud lacked an official equivalent - forcing workarounds with fake users. Now, you can implement the same best practices in Cloud, with tighter controls and better UI.
🧠 Key Benefits
- Security: No more shared credentials or tokens floating around
- Governance: Know exactly which automation is doing what, and when
- Clarity: Separate bot actions from real user activity in audit logs
- Simplicity: Configure and generate tokens directly from the Atlassian Admin UI
🚀 How to Get Started
- Go to Atlassian Admin → Directory → Service Accounts
- Create a new account and give it a clear name (e.g. jira-automation)
- Choose which product(s) it should access (Jira, Confluence, etc.)
- Generate a personal access token from the UI
- Use the token in your scripts, integrations, or automation tools
🔒 You can revoke tokens, deactivate accounts, or manage scopes just like any other user - but with full control and isolation.
🧩 ONETEEM Recommendation
We strongly recommend auditing your current automation and integration setups:
- Are you using shared user credentials?
- Do any bots or scripts authenticate using real user accounts?
- Are you assigning licenses to fake human identities?
If yes - now is the time to switch. Atlassian Service Accounts are secure, compliant, and purpose-built for modern teams.
Need help restructuring your automation setup?
ONETEEM supports teams transitioning to Atlassian Cloud with secure user management, automation best practices, and Forge-based custom integrations.
📩 Contact us today to streamline your platform while staying compliant.