Non-Human Identity Management in Atlassian Cloud

Ask a security team how many employees they have and they will answer instantly. Ask how many non-human identities they have, and the room goes quiet.

Non-human identities (NHIs) are the identities that applications, services and automation use to act in a system. Service accounts, automation users and bot logins are identities, while API tokens, keys and certificates are the credentials they authenticate with, and teams have to govern both. These identities run deployments, sync data, post notifications and generate reports, usually without anyone watching.

In most organizations nobody knows the exact count, and these identities are governed far less carefully than people.

Atlassian environments are no exception. Jira and Confluence sit in the middle of engineering and business workflows, so they attract a dense web of integrations. This article looks at what NHI management means in that context, what the Atlassian cloud platform provides, where gaps remain and how self-managed Jira users can approach the same problem.

Why Non-Human Identities Are a Security Problem

Human accounts have natural safeguards. People get onboarded and offboarded. They use multi-factor authentication. They notice when something odd happens to their account.

Machine credentials have none of that. A token is created once, pasted into a configuration file and forgotten. Several properties make these identities risky:

• No owner of record. The person who created the token may have moved teams or left the company.
• Long or unlimited lifespans. Without an expiry, a credential stays valid indefinitely.
• Over-privilege. Convenience tends to win, so credentials often carry far more access than their job requires.
• No interactive protections. A token cannot answer a prompt or respond to a suspicious-login warning.

Attackers know this. A leaked token in a repository, a ticket or a chat log can give quiet, persistent access that bypasses the controls built around people.

The OWASP Non-Human Identities Top 10 names the same patterns. It ranks improper offboarding first, defined as failing to deactivate service accounts and access keys when they are no longer needed. It ranks long-lived secrets seventh, meaning tokens whose expiry dates are too far out or that never expire at all.

The Core Principles of NHI Management

Good NHI governance is built on a few simple ideas, whatever platform you use.

• Inventory. You cannot manage what you cannot see. Know every non-human credential, who owns it and what it touches.
• Ownership. Every identity maps to an accountable person or team.
• Least privilege. Grant only the access the automation needs.
• Lifecycle. Credentials are created, reviewed, rotated or replaced, and retired on purpose.
• Expiry by default. Short lifetimes limit the damage from leaks.
• Visibility into use. Last-used timestamps and usage counts reveal what is dead and what is unexpectedly active.
• Fast revocation. When something goes wrong, removing one credential should be quick and should not take anything else down.

Keep these in mind as we look at what Atlassian Cloud offers.

What Atlassian Cloud Gives You

Atlassian's cloud platform has been moving steadily toward better NHI controls, and several features are worth knowing.

Personal API tokens

An Atlassian account API token, usually called a Jira Cloud API token when it is used with Jira, is created by a user from their Atlassian account security settings and used with their account email in place of a password, in standard Basic authentication. This is the entry-level mechanism, and the one most teams start with.

Its weakness is that the credential belongs to a person, so it inherits that person's access and disappears from the picture when they leave.

Expiry limits

According to Atlassian's documentation, tokens created after December 15, 2024 expire in one year by default, and creators can choose a lifespan from one day to one year. Atlassian also set tokens created before that date to expire, between March 14 and May 12, 2026, so older tokens no longer run indefinitely.

Admins on Atlassian Guard Standard can change this in an authentication policy, setting expiry anywhere from 1 to 365 days or allowing tokens that never expire. Check what your own policy says, because the default is a starting point rather than a ceiling.

Service accounts

For shared automation, the better option is a service account: a non-human identity with its own credentials, created by an organization admin in Atlassian administration. A Jira service account API token belongs to that account, so it survives staff changes.

Atlassian describes these accounts as built for script authentication, they cannot be used for interactive login, and their tokens last between 1 and 365 days. Five service accounts are free per organization, and additional ones require an Atlassian Guard subscription: Standard supports up to 250 and Enterprise up to 1,000.

Scopes

Atlassian's service account documentation also refers to API tokens with scopes, which are limited by the permissions of the service account itself. The practical lesson is to give each service account only the access its job needs, because its token can never exceed it.

Visibility and revocation

Users can revoke their own tokens from their Atlassian profile settings, and service account tokens are managed by admins in Atlassian administration.

Organization admins also get a central view. Under Insights, then API token activity, they can see how many active tokens managed accounts hold, when each was created and when it expires and was last used, and they can revoke tokens from the same place. Atlassian lists the feature as available on any plan.

Taken together, these features cover a lot of the principles above: expiry by default, central visibility, scoping for least privilege and independent identities for shared work.

A Practical NHI Program for Atlassian Cloud

Here is a sequence that works for most teams.

Step #1 –Discover

Start with the credentials you can find. Review service accounts and the API token activity page in Atlassian administration, ask each team which integrations they run and search for places where tokens might be stored.

Step #2 – Assign owners

Every token and service account gets a named team. Record this somewhere durable.

Step #3 – Move shared work to service accounts

Replace personal tokens in production automation with a Jira service account API token for each integration, each used for one job. Separate credentials make revocation precise.

Step #4 – Apply least privilege

Review the permissions and scopes of each identity. Remove anything the job does not need, and confirm the service account only has the project and space roles it requires.

Step #5 – Set expiry deliberately

Choose lifetimes appropriate to the risk, and create a calendar or ticket process for renewal so lapses do not cause outages.

Step #6 – Store secrets properly

Keep tokens in a secret manager or CI secret store. Treat any token found in a page or ticket as compromised, revoke it and reissue.

Run the whole sequence once as a project, then repeat steps 1, 2 and 4 every quarter as a short review.

Self-Managed Jira Needs a Different Answer

Everything above describes Atlassian's cloud platform. Many organizations still run self-managed Jira on Data Center, often for regulatory, residency or customization reasons. The NHI story there is different, and Jira API tokens work differently too.

In a self-managed instance, scripts commonly authenticate to the REST API with a username and password. That means a real person's login ends up inside automation. Changing the password breaks every job that uses it, and leaving it alone leaves a powerful credential scattered across systems. From an NHI perspective, this is the worst case: a human identity pressed into service as a machine identity, with no label, no expiry and no usage record.

For admins asking about API tokens Jira Data Center can enforce, this is the gap that API tokens for Jira, a Wombats Corp app listed on the Atlassian Marketplace for Jira Data Center and Server, is designed to close. Users create labelled tokens from their Jira profile, copy the secret once and use it as the password in standard Basic Authentication. The app stores a hash rather than the readable secret. Tokens can be given an expiry, revoked individually and inspected for creation date, last access and usage count.

On the administrator side, a central page lists tokens across the whole instance with owner, owner status, label, usage and expiry, and supports filtering and bulk deletion. Administrators can also set policy: block new token creation, require expiry, set recommended and maximum lifetimes, cap tokens per user and switch on a token-only mode that rejects password-based Basic Auth on the covered endpoints.

Measured against the principles earlier in this article, it maps well onto inventory, ownership, lifecycle, expiry, usage visibility and revocation. It is equally important to be clear about its limits. A token acts as its owning user and carries that user's Jira permissions, so it does not provide per-token scopes. It does not rotate itself, send expiry reminders or replace an identity provider. For true least privilege in self-managed Jira, pair tokens with a dedicated, minimally permissioned Jira user for each integration, and treat that user as your service identity.

Final Thoughts

Non-human identities are becoming an increasingly important part of the identity landscape, and Atlassian environments are full of them. The cloud platform has made real progress with default expiry, central token visibility and service accounts, and teams should take full advantage. Self-managed Jira needs its own approach, built around labeled, expiring, revocable credentials and a central view of what exists.

The principles stay constant everywhere: know what you have, give it an owner, limit what it can do, give it an end date and make removal easy. Do that consistently, and the invisible workforce of machine credentials stops being a hidden risk and becomes something your team can actually govern.