A stolen token works until it expires or someone revokes it. For a long-lived token that can be months or longer. For a short-lived token from an identity exchange it can be minutes. Token lifetime is one of the cheapest levers for limiting damage after a credential theft.
Lifetimes in practice
The documentation from several services shows the range.
| Credential | Lifetime | Source of the statement |
|---|---|---|
| PyPI API token (traditional) | Long-lived, until revoked | PyPI documentation |
| PyPI token from trusted publishing | 15 minutes | PyPI documentation |
| Cloud token from GitHub OpenID Connect | Valid for a single job | GitHub documentation |
| npm granular access token | Configurable expiry, at least one day ahead | npm documentation |
PyPI explains that an attacker who compromises a package's long-lived release token can use it until its legitimate user notices and manually revokes it. Trusted publishing avoids that because the minted tokens expire automatically.
What an attacker needs to do in that window
With a 15 minute token, the attacker must act inside the same short window and from a place the issuer accepts. With a token valid for a year, they can wait, test and choose their moment. Long lifetimes also let a theft stay hidden: the real owner keeps working, nothing breaks and nobody looks.
Settings to change
- Replace stored publishing tokens with trusted publishing where your registry supports it. npm and PyPI both describe it as exchanging short-lived identity tokens from CI.
- For tokens you must keep, set an expiry. npm lets you choose how long a granular token is valid.
- Scope each token narrowly: specific packages, specific permissions, and IP ranges where supported. npm's documentation says granular tokens can limit access by package, scope and organization, and can restrict by IP address range.
- Use cloud identity federation instead of stored cloud keys. GitHub describes OpenID Connect as giving tokens that expire automatically after a single job.
- Revoke on departure. Remove tokens tied to people who leave.
Know your inventory
You cannot shorten what you cannot list. Make a table of every long-lived token: where it is stored, what it can do, who created it and when it was last used. Delete unused ones. Set a calendar reminder to review the table.
When a token leaks
Revoke it first. Then check what it was used for in the window since the leak. Registries and CI systems often have audit logs for token use, so look at recent publishes and pushes. Rotate related secrets that the same job could read.
Where Safeguard fits
Safeguard's compliance and evidence automation can help you record who holds release rights and when they were last reviewed. Issuing and expiring tokens is done in your registry and CI platform.
Quick check
Is a short-lived token safe if the workflow is compromised?
Not fully. An attacker running inside the workflow can use the token during its life, so protect the workflow too.
What is a good expiry for a token I must keep?
There is no single answer. Choose the shortest period you can manage to rotate reliably, and automate the rotation.
Sources
- PyPI Docs: Trusted Publishers
- GitHub Docs: OpenID Connect
- npm Docs: About access tokens
- npm Docs: Trusted publishing
Last reviewed: 19 October 2026.
