What are short-lived credentials?

Short-lived credentials are access keys, tokens, or certificates that carry a built-in expiry. When the window closes, the credential stops working automatically. No manual revocation step is required. This shifts the security model from “someone must remember to clean this up” to “it will clean itself up by design.”

Why does credential lifetime matter so much?

Long-lived credentials are one of the most common root causes of cloud security incidents. An access key created for a quick integration test and never deleted. A CI/CD variable set two years ago when someone is long gone. A developer’s personal key checked into a dotfile. These credentials sit in systems for months or years, often with broad permissions, and most of the time nobody thinks about them until something goes wrong.

The problem is not carelessness. It is that revocation requires a deliberate action, and deliberate actions are easy to defer. Short-lived credentials remove the dependency on human memory. Expiry is guaranteed regardless of whether anyone follows up.

How does this work in AWS?

AWS Security Token Service issues temporary credentials on request. When an identity assumes an IAM role, STS returns three values: an access key ID, a secret access key, and a session token. These credentials are valid for a configured duration, anywhere from 15 minutes up to 12 hours depending on the role settings.

Once that window passes, any API call signed with those credentials returns an authentication error. The identity must assume the role again to get a fresh set. This re-assumption can be automatic, as it typically is for EC2 instances using instance profiles or Lambda using execution roles, or it can be triggered explicitly, as it is in JIT access workflows.

What about long-lived keys in practice?

AWS IAM user access keys, the kind generated in the console and downloaded as a CSV, do not expire unless you set a policy to rotate or deactivate them. These are the credentials that end up in .env files, shell histories, and CI/CD platform secrets. They work indefinitely, which means a key leaked in a git commit three years ago may still be valid today.

This is why the AWS security community broadly recommends against IAM user keys for anything automated. OIDC federation for CI/CD, instance profiles for compute, and role assumption for human access all produce short-lived credentials by default, and none of them require storing a secret anywhere.

How does this connect to JIT access?

Just-in-time access relies on short-lived credentials to close the loop. Granting temporary elevated access means nothing if the credentials for that access do not actually expire. STS makes the expiry enforceable at the AWS API level, not just at the policy level, so a JIT workflow that issues a one-hour role assumption produces credentials that genuinely stop working in one hour.

This is what distinguishes JIT from simply having a policy that says “this role should only be used temporarily.” Policy intent is not enforcement. Credential expiry is. The two together, a policy that grants narrow permissions and credentials that expire when the task ends, form the mechanical basis of most modern least-privilege access patterns.

Korvalis issues and tracks short-lived credentials as part of its JIT access flow, so teams get automatic expiry, a full audit trail of what happened during each session, and real-time guardrails on the API calls made with those credentials.