# What are short-lived credentials?

> Short-lived credentials expire on their own, in minutes or hours, so a stolen copy soon stops working. How they compare with long-lived keys, and their limits.

URL: https://crunu.com/learn/ephemeral-credentials
Language: en
Updated: 2026-10-30

Short-lived credentials are access tokens or keys issued for a limited time, typically minutes to a few hours, that stop working on their own when the time runs out, as opposed to long-lived credentials such as API keys and access keys that stay valid until someone revokes them.

## The difference in practice

AWS describes its temporary credentials this way: they "can be configured to last for anywhere from a few minutes to several hours", and after they expire "AWS no longer recognizes them or allows any kind of access" ([AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html)). They are "generated dynamically and provided to the user when requested" rather than stored. AWS even marks the two kinds in the key itself: access key IDs beginning with `AKIA` are long-term keys, those beginning with `ASIA` are temporary ([AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/security-creds-programmatic-access.html)).

|                    | Long-lived                           | Short-lived                                        |
| ------------------ | ------------------------------------ | -------------------------------------------------- |
| Valid until        | someone revokes it                   | it expires                                         |
| Stored             | in CI settings, `.env` files, config | usually nowhere; requested when needed             |
| A leaked copy      | works until you notice and reissue   | works until expiry                                 |
| Needs to be issued | once                                 | every time, by something that trusts the requester |

## What they don't solve

Short lifetimes shrink the window, not the access. A token valid for one hour can still do a lot of damage in that hour if it carries broad permissions. And a short-lived credential has to come from somewhere: something must decide that the requester deserves one. That decision usually rests on another identity, such as a CI provider's signed token or a cloud instance's role, which moves the question rather than removing it. See [secret zero](https://crunu.com/learn/secret-zero).

Many credentials can't be short-lived at all. A third-party API key, a webhook signing secret or a database password set by hand is long-lived by nature. For those, the levers are narrow scope, separate keys per consumer and a practiced [reissue](https://crunu.com/learn/credential-reissue).

## Common mistakes

- **Short-lived tokens, long-lived fallback.** An old access key kept in CI "just in case" means the pipeline still has a long-lived credential.
- **Long expiry by default.** "Short-lived" set to seven days is a long-lived credential with a reminder.
- **Printing tokens in logs.** They are credentials until they expire.

## How Crunu fits

Crunu doesn't generate short-lived credentials for your providers: it has no [dynamic secrets](https://crunu.com/learn/dynamic-secrets), by design, because that would require the server to hold decryption keys. The values it stores are as long-lived as their providers make them.

What Crunu does is limit the lifetime and use of its *own* access credentials:

- **Service tokens** for CI stop working after a lease of inactivity, from 1 hour to 30 days, can have a usage limit from 1 to 1,000,000 sign-ins, and can be restricted to networks. With a CI binding, each sign-in also needs a fresh JWT that the CI provider issues to the running job, and each JWT is accepted once.
- **Machines** hold a lease, 24 hours by default, that the agent renews while it can reach the server.
- **Enrollment codes** last 15 minutes by default and can be used once.
- **Share links** can expire and have a view limit.

To get short-lived cloud credentials into a pipeline, use your cloud's federation; [CI/CD secrets with OIDC](https://crunu.com/guides/ci-cd-secrets-with-oidc) covers AWS, Google Cloud and Azure.

## Sources

- [AWS IAM: Temporary security credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html), checked October 30, 2026.
- [AWS IAM: Programmatic access with AWS security credentials](https://docs.aws.amazon.com/IAM/latest/UserGuide/security-creds-programmatic-access.html), checked October 30, 2026.