Personal access tokens end up running automation that nobody owns, and a token with no expiry date stays valid for as long as the account behind it does. Every major developer platform now lets administrators cap token lifetime, but the settings live in different places, apply to different token types, and behave very differently towards tokens that already exist: some block them, some revoke them, some leave them alone. This guide shows where the lifetime controls are in GitHub, GitLab, Azure DevOps and Atlassian, what each does to existing tokens, how to pick a maximum lifetime, and how to roll a cap out without breaking pipelines. It is for platform owners and identity teams. For the background on why long-lived secrets are a risk see the OWASP NHI Top 10 NHI7 Long-Lived Secrets Guide.
Key takeaways
- Existing tokens are treated differently by each platform: GitHub blocks non-compliant tokens from the organisation without revoking them, GitLab revokes tokens with no expiry or a longer lifetime, Azure DevOps leaves existing PATs valid for the rest of their lifespan, and Atlassian Data Center applies its cap only to new tokens.
- GitHub classic tokens have no expiry requirement by default: GitHub documents a default 366-day maximum for fine-grained tokens, while classic tokens need an explicit lifetime policy or an outright restriction.
- Inventory before you enforce: a cap that revokes or blocks tokens in use will stop builds, so find long-lived tokens, owners and consumers first.
- A cap is not rotation: shorter lifetimes need a replacement path, ideally service accounts, GitHub Apps or workload federation instead of personal tokens.
- Admin exemptions are a known gap: GitHub's enterprise policy offers an Exempt administrators option for SCIM and unmigrated automation; record and review every exemption.
When you need this
- Audit or policy finding: a credential policy that requires expiry for machine credentials has no technical enforcement on the developer platforms.
- Leaked token that still worked: in the Home Depot token exposure, a GitHub access token reportedly published in early 2024 was confirmed still working in November 2025, with read and write access to private repositories. A lifetime cap bounds that window.
- After an incident clean-up: once you have revoked tokens, a cap keeps the population from growing back. See How to revoke a leaked GitHub personal access token and check what it touched.
- Platform migration: moving automation to service accounts or federation is the moment to make personal tokens short-lived.
Before you start
- Roles: GitHub organisation or enterprise owner; GitLab administrator (instance settings); Azure DevOps Administrator for tenant policies and Project Collection Administrator for the organisation policy; Atlassian organisation admin or Data Center system administrator.
- Licensing and offering: GitLab's maximum allowable lifetime setting is documented for the Ultimate tier on GitLab Self-Managed and Dedicated, while the Require expiration date setting is available on all tiers and on GitLab.com. Azure DevOps policies need an organisation backed by Microsoft Entra ID.
- An inventory: token owner, creation date, expiry, last use and consumer for each platform. For GitHub fine-grained tokens, owners can see them under Personal access tokens > Active tokens; for Atlassian see How to find long-lived personal access tokens across Atlassian.
- A target lifetime and an exception process: agreed with platform teams, with a named approver.
- A communication plan: users learn about GitHub's policy only when API calls are rejected, so tell them first.
Step-by-step
1. Compare the controls
| Platform | Setting and location | Default | Effect on existing tokens |
|---|---|---|---|
| GitHub organisation | Organisation settings > Personal access tokens > Fine-grained tokens or Tokens (classic) tab > Set maximum lifetimes for personal access tokens | Fine-grained: expire within 366 days. Classic: no expiration requirement | Non-compliant tokens of organisation members are blocked from the organisation, not revoked or disabled |
| GitHub enterprise | Enterprise > Policies > Personal access tokens > Set maximum lifetimes; optional Exempt administrators | As above | As above; organisations can tighten but not exceed or disable the enterprise policy |
| GitLab instance | Admin > Settings > General > Account and limit > Maximum allowable lifetime for access tokens (days) | 365 days | After about three hours GitLab revokes tokens with no expiry or a longer lifetime |
| GitLab instance | Same page > Require expiration date | Enabled by default from GitLab 17.3 | New personal, group, project and impersonation tokens must have an expiry within the allowed lifetime |
| Azure DevOps tenant | Organization settings > Microsoft Entra > Enforce maximum personal access token lifespan | Off | Existing PATs remain valid for the rest of their lifespan; renewal must comply |
| Atlassian Cloud | Set per token at creation | Tokens created after 15 December 2024 expire after one year by default, choice of 1 to 365 days | Older tokens keep their lifetime until revoked |
| Atlassian Data Center | JVM properties atlassian.pats.eternal.tokens.enabled and atlassian.pats.max.tokens.expiry.days | Eternal tokens allowed; 365-day maximum | Cap applies only to tokens created after it is set |
The Atlassian rows summarise the live Atlassian API Tokens Security Guide and the Atlassian audit guide linked above, which carry the detail and sources.
2. Choose the maximum lifetime
| Token use | Suggested ceiling | Reasoning |
|---|---|---|
| Interactive developer use (CLI, local scripts) | 30 to 90 days | Renewal is cheap for a person; exposure through laptops and infostealers is the main risk |
| Automation still on personal tokens | 90 days, with a migration date | Forces an owner to touch it regularly while you move it to a service account, GitHub App or federation |
| Automation that cannot move yet | Exception, platform maximum, named owner and review date | Visible, time-bound risk instead of a silent one |
| Break-glass or recovery tokens | Shortest the process allows, stored in a vault | Used rarely, so short life costs little |
These ceilings are a starting point, not a standard. Small organisations with few pipelines can usually go straight to 90 days or less; large estates should stage the reduction (for example 366, then 180, then 90 days) so each step surfaces a manageable number of broken consumers.
3. GitHub: set the policy
- Read-only first: in Personal access tokens > Active tokens, filter fine-grained tokens by expiry and list those beyond your target. For classic tokens on Enterprise Cloud with SAML SSO, use the SAML credential authorisations list, which includes token expiry.
- Decide on classic tokens. GitHub documents that only fine-grained tokens are subject to approval and that any classic token can access organisation resources unless classic tokens are restricted. The strongest option is Restrict access via personal access tokens on the Tokens (classic) tab; otherwise set a classic maximum lifetime.
- On the Fine-grained tokens and Tokens (classic) tabs, set Set maximum lifetimes for personal access tokens and click Save. At enterprise level, set the same under Policies > Personal access tokens and decide on Exempt administrators.
- Keep Require administrator approval for fine-grained tokens, which GitHub sets by default, so new tokens get a review.
- Expect enforcement at use: GitHub states that classic token limits are enforced when the token is used and when SSO authorisation is attempted, and users are prompted to regenerate a compliant token.
4. GitLab: set the policy
- Read-only first: list tokens with no expiry or with an expiry beyond your target, including group, project and service account tokens, and contact their owners.
- Confirm Require expiration date is selected (Admin > Settings > General > Account and limit).
- Destructive: set Maximum allowable lifetime for access tokens (days). GitLab documents that it then revokes old tokens with no expiry or a longer lifetime after three hours, so replacements must be in place first.
- Service account personal tokens are governed by the separate
service_access_tokens_expiration_enforcedapplication setting; review it in the same change. - The same page has Maximum allowable lifetime for SSH keys (days); GitLab states that keys with no expiry or a longer lifetime become invalid immediately, so treat it as a separate, planned change.
5. Azure DevOps: set the policies
- In Organization settings > Microsoft Entra, turn on Enforce maximum personal access token lifespan and enter the number of days.
- In the same place, consider Restrict global personal access token creation (new PATs must be tied to specific organisations) and Restrict full-scoped personal access token creation (new PATs need a custom set of scopes). Confirm Automatically revoke leaked personal access tokens is on; Microsoft documents it as on by default.
- Add exceptions through each policy's allowlist, using Entra groups rather than named users as Microsoft advises. Each policy has its own allowlist.
- Because existing PATs remain valid for their lifespan, run a separate clean-up of long-lived PATs. Microsoft recommends Microsoft Entra tokens over PATs where possible. See the Azure DevOps Security Guide.
6. Atlassian: close the eternal token gap
On Data Center, set atlassian.pats.eternal.tokens.enabled=false and a value for atlassian.pats.max.tokens.expiry.days, restart, then replace old tokens, because the cap does not touch existing ones. In Bitbucket Data Center, turn on automatic expiry for HTTP access tokens. In Cloud, the one-year default bounds new tokens; revoke older tokens without an expiry through the audit described in the Atlassian guide.
Verify it worked
| Metric | Source | Target |
|---|---|---|
| Tokens with no expiry | Platform token lists (GitHub Active tokens and SSO authorisations, GitLab token lists, Atlassian admin pages) | Zero, or each covered by an exception |
| Median remaining lifetime of active tokens | Same sources | Falling towards the policy ceiling |
| Tokens blocked or revoked by policy that broke a consumer | Incident and ticket records | Falling after each stage |
| Active exceptions and admin exemptions | Allowlists, Exempt administrators setting | Each with an owner and a review date |
| Automation moved off personal tokens | Migration tracker | Rising each quarter |
Test each policy by creating a token as a normal user and confirming the expiry choices offered, then try a GitHub classic token with a longer lifetime against the organisation and confirm it is rejected.
Rollback and common errors
- GitLab revocation is final: raising the lifetime setting again does not restore revoked tokens; owners must create new ones. Stage the cap well above your target first.
- GitHub blocks rather than revokes: raising or removing the policy lets blocked tokens back in, which is a usable rollback, but it also means the long-lived tokens still exist and need revoking.
- Assuming Azure DevOps fixed existing PATs: it does not; long-lived PATs created before the policy keep working until they expire.
- Forgetting classic or service tokens: GitHub classic tokens have no default expiry requirement, and GitLab service account tokens use a separate setting.
- Exemptions that never end: GitHub's Exempt administrators option and Azure DevOps allowlists are easy to set and forget; review them with the exceptions register.
- Shorter tokens pasted into more places: without a renewal path, users store tokens in shared files to save time. Pair caps with a vault and with token-free alternatives.
Hardening afterwards
- Replace personal tokens for automation: GitHub Apps, platform service accounts and OIDC federation remove the need for long-lived personal credentials. See the Workload Identity Federation Guide.
- Restrict token types: restrict GitHub classic tokens and Azure DevOps global and full-scoped PATs once consumers have moved.
- Monitor for leaks: keep Azure DevOps automatic leaked PAT revocation on and run secret scanning on repositories.
- Feed offboarding: revoke tokens of leavers as part of the leaver process. See the NHI Offboarding and Decommissioning Guide.
- Review quarterly: lower the ceiling as migrations complete.
| Framework | Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-01, PR.AA-05 | Credentials managed; access reviewed for least privilege |
| NIST SP 800-53 Rev 5 | IA-5, AC-2, AC-2(3) | Authenticator lifetime and management, account review, disabling unused access |
| CIS Controls v8.1 | Controls 5 and 6 | Account and access control management |
| MITRE ATT&CK v20 | T1528 Steal Application Access Token; T1552.001 Credentials In Files | Stolen or exposed tokens remain useful until they expire |
Practitioner checklist
- Inventory personal tokens on every platform with owner, expiry, last use and consumer.
- Agree a maximum lifetime per use case and an exception process with a named approver.
- GitHub: set fine-grained and classic maximum lifetimes, or restrict classic tokens; review Exempt administrators.
- GitLab: keep Require expiration date on and set the maximum lifetime only after replacements are ready.
- Azure DevOps: enforce maximum lifespan, restrict global and full-scoped PATs, keep leaked PAT revocation on.
- Atlassian Data Center: disable eternal tokens and replace existing ones.
- Stage the ceiling down, measure breakage at each step and communicate before every change.
- Move automation to service accounts, GitHub Apps or federation and review exceptions quarterly.
Standards and references
- GitHub Docs: Setting a personal access token policy for your organization
- GitHub Docs: Enforcing policies for personal access tokens in your enterprise
- GitHub Docs: Reviewing and revoking personal access tokens in your organization
- GitLab Docs: Account and limit settings
- Microsoft Learn: Manage personal access tokens using policies
- OWASP: Non-Human Identities Top 10
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
Related NHI Mgmt Group resources: GitHub Personal Access Tokens Security Guide, GitLab Tokens Security Guide, Atlassian API Tokens Security Guide, How to audit GitHub Apps and OAuth apps in an organisation.