The Death of the Long-Lived Cloud Credential

May 25, 2026

Mat Evans

In 2014, AWS shipped OIDC federation for STS. That was the moment the long-lived cloud access key became legacy.

It didn’t die then, of course. Legacy doesn’t work that way. The first production systems to migrate were the CI runners — by around 2021, GitHub Actions shipped native OIDC federation and it became embarrassing to paste an access key into a pipeline. Kubernetes followed, via IRSA on EKS, Workload Identity on GKE, and the equivalent on AKS. Cloud-provider-internal services — Lambda, Cloud Run, App Service — had never needed long-lived keys in the first place.

That left one stubborn holdout. The developer laptop.

This post is about why the long-lived access key is dying, what’s replacing it, and why the last place it survives — the developer workstation — is the next domino.

A brief history of cloud credentials

The AWS access key was born in 2006 with S3 and EC2. It was, at the time, a reasonable design. You had one key, you put it in a config file, you called the API. There was no identity federation. There was no OIDC. There was no workload identity. There was barely a cloud, and there definitely weren’t SOC 2 auditors pointing at your IAM console with disapproval.

For roughly the first decade of cloud, the long-lived access key was how everything worked. Every service, every pipeline, every developer workstation. The story of cloud credential management from 2006 to about 2018 is “how do we encrypt, rotate, and detect the theft of long-lived keys” — a set of defensive patches on a design that predated the right answer.

The right answer arrived gradually:

2014 — AWS STS OIDC federation. AssumeRoleWithWebIdentity landed with OIDC 1.0 support. Any service producing a signed JWT from a trusted issuer could exchange it for short-lived credentials. Nobody noticed for years.
2019 — EKS IRSA. Kubernetes pods got native AWS credentials without managing access keys. First widely-deployed OIDC federation in the wild.
2021 — GitHub Actions OIDC. CI runners stopped being the worst-offender category overnight. Within 18 months, every serious infra-as-code pipeline had migrated.
2022 — AWS IAM Roles Anywhere. The explicit “we acknowledge you have workloads outside AWS” product. Uses X.509 certificates, but the shape is the same: no long-lived access keys.
2023–2024 — Azure Federated Identity Credentials, GCP Workload Identity Federation cross-cloud. The remaining big clouds shipped equivalent primitives. They all accept the same OIDC token format.

By 2024, any greenfield production workload authenticating to a cloud provider with a long-lived access key was doing it wrong on purpose. The tools existed. The primitives existed. The cross-cloud standards existed. What remained was migration and muscle memory.

Why the developer laptop survived

The developer laptop is a harder problem than the CI runner, for three reasons.

There’s no platform root of trust. A Kubernetes pod runs in a cluster whose service account is signed by a known issuer. A GitHub Actions job runs in a runner whose token is signed by GitHub. There’s a platform that vouches for the workload. A laptop doesn’t have one. If a developer says “give me AWS credentials,” there’s no clean answer to “on whose authority?”

The human is in the loop. A CI runner can get a fresh JWT every 15 minutes and nobody cares. A developer wants to run aws s3 ls and get credentials, not do a browser dance. Friction that’s invisible for services is a showstopper for people.

The old pattern works. ~/.aws/credentials still works. The AWS SDK still reads it. aws configure still writes to it. Every tutorial in existence tells you to paste your access key into it. Incremental improvement is available — aws-vault, Granted, AWS SSO — but the baseline pattern refuses to die.

Each of these has an answer arriving now.

What’s replacing it

The replacement isn’t one thing. It’s a stack.

1. Hardware as the laptop’s root of trust

Every Mac since 2016 has a Secure Enclave — a dedicated chip that generates keys and refuses to export them. Windows 11 ships with TPM 2.0. Modern Linux laptops have TPM 2.0. The hardware already exists on every developer’s machine.

The shift is in how it’s used. Until recently, these chips were used for Touch ID, BitLocker, and FileVault — consumer features. What’s changing is that the signing primitive (sign a JWT with a non-extractable hardware key) is being wired up to workload identity protocols. Once a laptop can produce a signed JWT from a hardware-bound key, it looks to AWS/GCP/Azure like any other federated workload.

This is the piece credctl exists to fill. Not novel cryptography — novel plumbing.

2. OIDC federation as the universal verb

The fact that AWS, GCP, and Azure all landed on OIDC federation is one of those quiet miracles of interop. Same JWT format. Same claims structure. Same JWKS discovery. The identity provider can be a laptop, a CI runner, a cluster, or an enterprise IdP — the cloud doesn’t care, as long as the issuer is trusted and the token validates.

This is what makes “one identity, all clouds” a real architecture and not a marketing line. A Secure Enclave key on a laptop can federate to AWS, GCP, and Azure from a single issuer. The plumbing is boring. The plumbing being boring is the win.

3. Short-lived everything

The quiet cultural shift is that “short-lived” has become the default expectation. Kubernetes service account tokens rotate. GitHub Actions JWTs expire in minutes. STS credentials last an hour. The entire mental model of “I have a credential” is being replaced with “I have an identity that can produce fresh credentials on demand.”

Once “fresh credentials on demand” is the default, long-lived access keys become weird. They’re the thing that doesn’t expire. They’re the thing that works from anywhere. They’re the thing that survives key rotation policies because the rotation window is longer than the attack cycle. They become the anomaly, not the norm.

The forces closing the last gap

Three things are ending the long-lived key on the laptop, all at once.

Breaches keep making the argument for us. CircleCI, LastPass, Uber, Codecov, Vercel — every year the list gets longer. The pattern is consistent: long-lived credentials on developer machines, stolen, replayed, catastrophic blast radius. Every incident is another data point in favour of “what if there was nothing to steal?”

Compliance is catching up. NIS2 Article 21(2)(j) explicitly calls out cryptographic controls for access management. SOC 2 CC6.1 is being interpreted more strictly. DORA pushes toward demonstrable key lifecycle controls. Auditors are starting to ask the question “why do developers have 90-day access keys?” — and “because we rotate them” is no longer a satisfying answer.

Platform defaults are changing. Vercel, after April 2026, made Sensitive the default for new environment variables. GitHub made OIDC federation the recommended path for cloud deploys. AWS’s own docs now lead with “use IAM Identity Center or federation” before mentioning access keys. When the defaults flip, the population follows.

None of these forces are decisive on their own. Together, they’re a ratchet. Every incremental step makes the next one easier and the reverse harder.

What “after” looks like

The world on the other side of this transition has a specific shape.

Every credential is short-lived. A human asks for AWS access and gets 60 minutes. A service gets a new JWT every 15 minutes. Long-lived material exists — but it’s a signing key, not a bearer credential, and it lives in hardware that refuses to export it.

Every identity has a hardware anchor. A workload’s identity is rooted in the platform that runs it (Kubernetes service account, cluster OIDC issuer, Lambda execution role). A human’s identity is rooted in the device they’re using, attested by the Secure Enclave or TPM. There’s no “credential file” category anymore — there’s identity, and there’s ephemeral proof of identity.

“Rotate all the secrets” becomes nonsense. The next Vercel-shaped incident still happens — platforms get breached, employees get phished, integrations get compromised. But the cleanup changes. When there are no long-lived bearer secrets to have been stolen, “rotate everything” doesn’t apply. You investigate, contain, fix. You don’t burn down N customer credential surfaces.

Auditors change their questions. “When did you last rotate your access keys?” becomes “show me the key-generation attestation.” That’s a better question. It doesn’t have “we rotate every 90 days” as an acceptable answer.

The plaintext credentials file stops being a default artefact. ~/.aws/credentials doesn’t disappear — it’ll linger for legacy scripts — but it stops being what new developers are taught to use. The thing that replaces it is credctl auth or its equivalent.

A specific prediction

Here’s the claim I’ll stake out: by 2030, provisioning a long-lived cloud access key for a human will be seen the way we now see chmod 777 on a config file.

Not impossible. Not blocked by the platform. Just evidence that someone didn’t know the better way, or skipped it out of expediency, and it’ll be the first thing a code review or audit flags.

The signs are already there. AWS buries access keys deeper in the console every year. GCP has made it progressively harder to generate long-lived service account keys. Azure has deprioritised the flow in its docs. The tooling is converging — aws-vault, Granted, credctl, the various SSO solutions — on “don’t have long-lived keys on the machine.” The only question is how long the tail is.

Where credctl fits

credctl is one tool in a broader movement. It’s specifically the answer for the macOS developer laptop talking to AWS or GCP — hardware-bound OIDC federation, no server to run, no long-lived keys anywhere. Linux TPM 2.0 support is on the roadmap. Azure FIC is on the roadmap. Team broker functionality is on the roadmap.

But credctl is not the whole answer. The whole answer is every platform and every tool converging on “short-lived credentials from a hardware-rooted identity.” Vault’s JWT auth method, Granted’s SSO integration, GitHub Actions OIDC, workload identity on every cluster — they’re all facets of the same shift.

The long-lived cloud access key had a good run. It survived the arrival of every better pattern for nearly two decades. But the combined weight of breach pressure, compliance, platform defaults, and now laptop-level hardware federation is breaking the last thing holding it up.

It’s going to take a few more years, and a few more breaches, and a few more auditor escalations. But it’s going.

Where to go from here

credctl quickstart — 5 minutes to hardware-bound AWS or GCP credentials
The Vercel breach analysis — why bearer secrets are the root cost
Secure Enclave deep dive — how hardware-bound signing works
Why I built credctl — the origin story