credctl | Blog

Why credctl federates via OIDC instead of IAM Roles Anywhere

Mon, 13 Jul 2026 00:00:00 GMT

Both AWS OIDC federation and IAM Roles Anywhere can give a workload outside AWS short-lived AWS credentials. It’s the most common design question about credctl’s architecture — and the reasons to pick one over the other aren’t widely written up.

Here’s what credctl settled on, why — and importantly, when you’d actually pick Roles Anywhere instead. (For the reference-style comparison of how each mechanism works, see the OIDC vs Roles Anywhere guide — this post is the decision narrative.)

The two paths in plain terms

OIDC federation (sts:AssumeRoleWithWebIdentity). Your workload produces a signed JWT containing its identity. The signature is verifiable against a JWKS endpoint you host. AWS IAM trusts a specific OIDC provider (identified by JWKS URL + issuer + audience). When the workload calls STS with the JWT, STS fetches the JWKS, validates the signature, checks the claims against the role’s trust policy, and returns temporary credentials. This is the path GitHub Actions, Kubernetes (via IRSA), and most modern CI/CD systems use to authenticate to AWS without long-lived access keys.

IAM Roles Anywhere. Your workload presents an X.509 client certificate signed by a CA. AWS Roles Anywhere has a “trust anchor” pointing at that CA, plus a “profile” describing which IAM roles the cert is allowed to assume. The workload calls Roles Anywhere’s CreateSession endpoint with the cert and a signed challenge, gets temporary credentials back, and uses those against AWS. Roles Anywhere validates the cert chain against the trust anchor and the profile policies before issuing.

Both deliver the same end state: short-lived AWS credentials issued to a non-AWS workload, without anyone holding a long-lived access key. The difference is in what proves identity — a JWT signed by a key, or an X.509 cert.

credctl’s specific constraints

credctl is a CLI that runs on a developer’s laptop and authenticates to AWS using a hardware-bound key — Secure Enclave on macOS, TPM 2.0 on Linux. The key never leaves the chip. The key signs something that AWS validates, and AWS returns STS credentials.

That “something” is the question. It can be:

A JWT signed by the hardware key (OIDC path)
An X.509 challenge signed by the hardware key (Roles Anywhere path)

Both are technically achievable. Secure Enclave and TPM 2.0 both hold ECDSA P-256 keys and produce ECDSA signatures over arbitrary payloads.

But credctl had two other constraints that mattered for the choice:

We want the same auth flow to work across AWS, GCP, and Azure. A developer’s laptop should authenticate to whichever cloud their workload runs in — without per-cloud cert lifecycle management. The same hardware key, the same identity, three clouds.
We want zero customer-side infrastructure beyond the IAM trust setup. No CA to operate. No cert rotation. No revocation list to keep current.

Both push hard toward OIDC.

Why OIDC won for credctl

Multi-cloud portability. AWS OIDC federation, GCP Workload Identity Federation, and Azure Federated Identity Credentials all accept the same JWT format — signed with ES256, standard iss/sub/aud/exp/iat claims, JWKS discoverable via /.well-known/openid-configuration. Different endpoints (AssumeRoleWithWebIdentity on AWS, the WIF token exchange on GCP, FIC on Azure), but the underlying protocol is interoperable. One identity, three clouds. Roles Anywhere is AWS-only — for the same workload identity on GCP we’d need WIF anyway, so we’d be operating two parallel systems.

No customer-side PKI. Roles Anywhere requires the customer to operate a CA that issues client certs to their workloads. Even with public CAs and ACM Private CA, this is a real ongoing operational burden: cert rotation, revocation lists (CRLs or OCSP), CA renewal. For credctl’s “install the CLI and federate” experience, asking customers to run a CA before they can authenticate is a non-starter. OIDC requires hosting a JWKS file (a few hundred bytes of JSON behind a CDN) and registering the OIDC provider in IAM once. That’s it.

Mature ecosystem. OIDC is the cloud auth lingua franca for non-cloud workloads. GitHub Actions, Kubernetes service accounts, CI/CD runners, and SPIFFE all federate via OIDC. We can lean on documented patterns, well-tested IAM examples, and developer familiarity. Roles Anywhere is younger and the ecosystem of examples — especially for “laptop CLI” rather than “server workload” — is thinner.

Richer claims structure. JWTs carry arbitrary claims. credctl can put device identifiers, attestation data, or future attributes into the sub and standard claims without changing the underlying protocol. X.509 cert SANs and extensions can do something similar but less flexibly, and modifications usually mean cert re-issuance.

Existing audit story. AWS CloudTrail records the JWT’s sub claim on every AssumeRoleWithWebIdentity call. Roles Anywhere logs a CreateSession event with the cert’s subject — slightly different audit shape, an extra event in the chain, and a different correlation story between issuance and use.

The trade-off we accepted

OIDC’s main cost is that you have to host a JWKS endpoint that the cloud provider can reach over HTTPS. This is a customer-side trust dependency: AWS STS does an HTTP GET against the URL you registered in the OIDC provider, and trusts whatever JWKS comes back.

For credctl this is fine. The JWKS is small, immutable per device-key, and served from S3 + CloudFront in v1 (and the team broker in v2). It’s not on the credential path latency-wise — STS caches the JWKS aggressively. Outages of the JWKS host don’t break in-progress STS calls; they only prevent new federations against fresh JWTs that reference keys STS hasn’t seen before.

Roles Anywhere doesn’t have this requirement — AWS hosts the entire validation flow. If you genuinely cannot or will not host a publicly-reachable JWKS endpoint (some air-gapped environments, some regulated industries), this is a real point in Roles Anywhere’s favour.

When you’d actually pick Roles Anywhere

There are cases where Roles Anywhere is the better answer:

You already have a corporate PKI that issues device certs as part of MDM (Jamf, Intune). Reusing those certs for AWS auth means zero new identity issuance — the device cert it already has becomes the AWS credential. OIDC would require generating new credctl-shaped keys and hosting a parallel JWKS.
You can’t host a public JWKS endpoint. Air-gapped environments. Regulated environments where any public-internet trust dependency is unacceptable. Environments where the JWKS hosting is itself an audit boundary you don’t want to own.
You’re AWS-only with no plans to authenticate the same identity to GCP or Azure. The multi-cloud portability argument falls away.
You don’t want the JWT TTL revocation window and prefer cert-revocation semantics via CRLs or OCSP — even with the operational cost of that infrastructure.

For credctl’s target users — developers running CLIs on their own laptops, often across multiple clouds, often without enterprise MDM — none of these apply strongly enough to overcome OIDC’s portability and ergonomics.

The honest summary

OIDC won for credctl because we want one identity that works across three clouds, with zero customer-side PKI, with a mature ecosystem of examples to lean on.

Roles Anywhere wins if you have an existing PKI you want to reuse, if you can’t host a public JWKS endpoint, or if you’re committed to AWS-only.

For a workload that looks like credctl’s — a CLI tool, a CI/CD runner, a service mesh, a Kubernetes federation — OIDC is almost always the right call. Roles Anywhere is the right call when the constraints push you that direction explicitly. The default should be OIDC.

Stay up to date

Get notified about new credctl releases, security best practices, and hardware identity insights.

Designing credctl's team broker (v1 RFC)

Tue, 07 Jul 2026 00:00:00 GMT

Every team broker in the credential management space sits between the developer and the cloud. credctl’s team broker, in its v1 design, deliberately doesn’t.

This post explains why we made that call, walks through the v1 architecture, and points at the parts we’re least sure about. The full RFC is published as a GitHub Discussion — this is the narrative version. If you’re going to push back on the design (and we’d like you to), the RFC is where the architectural detail lives.

The most-requested feature, narrowed down

Since the credctl CLI shipped, the most consistent demand signal has been a team broker. The pain breaks into three shapes, in roughly this order of frequency:

Policy — “only senior engineers can assume the production role”
Audit — “who assumed what role when, across the org, in one place”
Device fleet management — onboarding, off-boarding, lost laptops

These are real problems. But they aren’t all the same shape of problem, and that mattered for what v1 should be.

When we looked closely at each one:

Policy at the “X can assume role Y” level is already expressible in AWS IAM trust policies. The hard part is managing which user maps to which role at scale, not enforcing it at issuance time.
Audit of role assumptions is already in CloudTrail. The hard part is mapping the cryptographic identity (the JWT sub claim) back to a person, and aggregating cleanly across clouds.
Device fleet management is mostly a question of which public keys are currently trusted, and revoking the ones that aren’t.

All three shapes are addressable by a registry — a system that knows who’s on the team, which devices they have, and which roles they can assume, and that publishes this information to the cloud’s existing trust machinery. None of them require the broker to actually issue credentials.

So v1 doesn’t.

The architectural decision

In v1, the credctl team broker is not in the credential issuance path. The auth flow is unchanged from single-developer credctl:

Laptop signs a JWT with the hardware-bound key (Secure Enclave or TPM 2.0)
Laptop calls sts:AssumeRoleWithWebIdentity directly against AWS
AWS STS fetches JWKS from the broker-hosted endpoint (cached at CloudFront)
AWS STS validates the JWT against the JWKS and returns temporary credentials

The broker’s only role at runtime is hosting the JWKS. Its only role at design time is being the source of truth for the team’s roster, and emitting Terraform that keeps IAM trust policies aligned with that roster.

This is the smallest possible team broker compatible with credctl’s flow.

It also means the broker can be down for minutes without breaking developer auth — JWKS is served from CloudFront with aggressive TTLs, so STS hits the cache, not the broker. Broker compromise doesn’t directly compromise customer credentials: an attacker who pwned the broker could publish a malicious manifest, but the customer’s terraform plan would surface the diff before anything was applied. Broker availability is not on the critical path of credential issuance.

That’s the bet. Smallest blast radius, smallest surface area, smallest operational footprint compatible with solving the registry-shaped pain.

It is also very different from how every other broker in this space is designed. Vault, CyberArk Conjur, Venafi, Keyfactor — even SPIFFE in many deployments — all sit in the credential path. We think the cost of being in-path isn’t justified by the marginal capability it buys for v1.

What v1 ships

In scope:

A SaaS-hosted registry of users, devices, and per-org role bindings, with GitHub OAuth as the v1 identity provider
Per-org JWKS hosting, served via CloudFront
An open-source Terraform module (credctl/terraform-credctl-aws, published to the HashiCorp Terraform Registry) that consumes a manifest from the broker and produces IAM trust policy resources
A minimal admin web dashboard
A broker-side audit log of admin actions in Postgres — complementary to CloudTrail, which remains the system of record for STS calls

Explicitly out:

Real-time revocation. JWT expiry (~1 hour by default, tunable down to 15 minutes) is the only revocation mechanism — structural to the out-of-path design.
Policy beyond membership. “Alice can assume role X” — yes. Time-of-day, IP allowlists, posture, attribute-based conditions — no, not in v1.
Approval workflows. (Planned for Phase 4 of the roadmap.)
SSO beyond GitHub. (Planned for Phase 5.)
Self-hosted deployment.
GCP and Azure role mapping. The data model accommodates them; the per-cloud Terraform modules ship later.

The “explicitly out” list is doing real work in the design. Each item is something some adopter will ask about, and the answer for v1 is “not yet.” Whether any of these eventually flips to “yes” depends on what the next section asks for.

What we’re uncertain about

The RFC names three open questions. The most important is:

When does registry-only stop being enough?

We have candidate Phase 2 drivers — sub-minute revocation, per-request approval, cross-cloud policy, attribute-based conditions, business-context audit. But candidate scenarios aren’t the same as real ones. If your team is somewhere in the space where credctl might be a fit, the single most useful thing you can do is describe the specific scenario where v1 wouldn’t solve your problem.

We’d rather hear three concrete scenarios than a hundred abstract opinions.

The other two open questions are smaller but not trivial:

GitHub orgs/teams as source of truth for membership, or independent of GitHub? We’re defaulting to independent — membership lives in the broker’s database, decoupled from GitHub’s data model. Teams already running their access boundaries via GitHub orgs might prefer derived membership. The RFC asks for the concrete case.

Is the sub claim format right? We’re proposing user:<user-id>/device:<device-id> because it lets IAM trust policies match on the user via StringLike while keeping per-device fidelity in CloudTrail. It’s a one-way door once customers depend on it. The RFC asks whether you’d push back before the Terraform module ships v1.0.

What to do next

If you’d consider adopting a team broker like this, read the full RFC in the GitHub Discussion. It has the data model, JWKS layout, Terraform module shape, and revocation behaviour in detail. Then push back on the parts you’d hit first.

Channels for response:

The RFC discussion on GitHub
Direct: rfc@credctl.com

Comment window is ~2 weeks. Implementation begins once the architectural questions settle. The Phase 2 question can stay open longer — we’d rather gather real scenarios than design speculatively.

Stay up to date

Get notified about new credctl releases, security best practices, and hardware identity insights.

The Death of the Long-Lived Cloud Credential

Mon, 25 May 2026 00:00:00 GMT

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

Stay up to date

Get notified about new credctl releases, security best practices, and hardware identity insights.

credctl vs Granted: Workflow Ergonomics vs Hardware Identity

Mon, 18 May 2026 00:00:00 GMT

Granted is the tool I recommend to anyone juggling twelve AWS accounts through IAM Identity Center. Its browser-profile console UX is the best in the ecosystem — opening three production accounts in three isolated Chrome profiles at once, each with the correct colour-coded badge, is genuinely delightful.

credctl is doing something different. This post lays out the distinction honestly, including the cases where Granted is a better answer than anything credctl will offer.

What Granted is built for

Granted, built by Common Fate, is focused on the day-to-day ergonomics of working across multiple AWS roles and accounts.

The highlights:

granted console — opens the AWS console in a named browser profile so that signing into Role A doesn’t log you out of Role B. Each profile is visually distinct (colour, badge) to prevent “I clicked delete in the wrong account” accidents
granted exec — like aws-vault exec, runs a command with credentials for a given profile injected as environment variables
SSO / IAM Identity Center first-class support — discovery of available accounts and roles, session caching, device authorisation flows
Cross-account role discovery — pulls the list of available roles from your Identity Center directory
assume command — ergonomic role switching in the terminal
Team governance layer (Common Fate product, paid) — access requests, approvals, time-bound grants

The underlying credential mechanism is IAM access keys + STS role assumption, same as aws-vault. The Granted layer is the workflow around it: multi-account sanity, browser isolation, approval workflows.

What credctl is built for

credctl’s scope is smaller and deeper. It replaces the long-lived AWS credentials on a developer’s laptop with a hardware-bound identity backed by the macOS Secure Enclave.

The private key is generated in the Secure Enclave, never leaves the chip, and signs JWTs that AWS accepts via OIDC federation. Credentials are short-lived (1 hour) and require Touch ID per signing operation.

Granted asks “how do I make multi-account AWS access ergonomic?” credctl asks “why is there a long-lived credential on the laptop at all?”

Side-by-side

	Granted	credctl
Primary problem	Multi-account AWS workflow ergonomics	Eliminating long-lived creds on the laptop
Underlying AWS auth	IAM access keys or SSO + AssumeRole	OIDC federation via Secure Enclave JWT
Long-lived credentials on disk?	Encrypted in OS keychain	None
Root of trust	OS keychain / SSO session	Hardware (Secure Enclave)
Best feature	`granted console` (browser profiles)	Non-extractable signing key
IAM Identity Center support	First-class	Not applicable (different auth model)
Multi-account role switching	First-class	Possible but manual
Platform support	macOS, Linux, Windows	macOS today
Non-AWS clouds	AWS-focused	AWS and GCP today
Team governance	Yes (paid tier)	No (single user)

Where Granted clearly wins

Multi-account AWS console work. If a significant portion of your day is opening the AWS console across multiple accounts and roles, Granted’s browser profile UX is genuinely unmatched. There’s no equivalent in credctl because credctl isn’t trying to solve console access at all.

IAM Identity Center workflows. Granted is built around the Identity Center device authorisation flow, account/role discovery, and session caching. If your org standardised on Identity Center (a sensible choice for most enterprises), Granted fits that world natively. credctl uses a different auth model — direct OIDC federation — that’s orthogonal to Identity Center.

Linux and Windows. Granted works across all three platforms today. credctl’s Secure Enclave dependency means macOS-only until Linux TPM 2.0 support ships.

Team access governance. Common Fate’s paid tier adds just-in-time access, approval workflows, and time-bound role grants. This is a real problem for larger orgs, and nothing in credctl’s scope addresses it.

You already have credentials via SSO. If your company hands you access via Identity Center, you don’t have long-lived access keys — the SSO flow issues short-lived ones on each login. Granted makes that flow ergonomic. credctl’s “no long-lived keys” pitch is already satisfied.

Where credctl clearly wins

Your threat model includes endpoint compromise. Granted’s security model assumes the OS keychain and the SSO session cache are safe. An attacker with enough privilege on the machine can extract both. credctl’s signing key is in hardware — it can’t be stolen, only used while the Touch ID prompt is active.

You’re outside Identity Center. Small teams, solo developers, or orgs that use direct IAM federate without Identity Center don’t gain much from Granted’s SSO-centric features. credctl works for any AWS account where you can deploy the OIDC setup.

You want multi-cloud from one identity. credctl targets AWS and GCP (Azure on roadmap) with a single Secure Enclave key. Granted is AWS-focused. If you’re moving between AWS and GCP daily, one hardware identity is simpler than two credential systems.

You want hardware attestation per signing, not per session. SSO sessions typically last hours. credctl prompts Touch ID on every request. Stronger attestation, more friction — right for high-trust roles, probably too much for day-to-day browsing.

You don’t want to depend on an identity provider being up. Granted’s SSO flow depends on Identity Center / IdP availability. credctl’s flow only depends on the cloud provider’s STS endpoint.

Can you use them together?

Yes, and it’s a reasonable pattern for larger orgs.

Granted for day-to-day SSO-backed account navigation. Console access, multi-account discovery, browser isolation.
credctl for high-trust direct role access. Production deploys, infra admin, audit log signing — anywhere the extra hardware-bound attestation is worth the ceremony.

The two tools don’t conflict. They produce the same thing at the end (AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY / AWS_SESSION_TOKEN) via different paths. A developer can use granted exec for a sandbox role and credctl auth --profile prod for a production role in the same terminal session.

The honest framing

These tools are not direct competitors. They solve overlapping but distinct problems:

Granted makes AWS workflow better
credctl makes AWS identity stronger

If your pain is “I keep deleting things in the wrong account,” that’s Granted. If your pain is “we audit a lot and someone keeps asking why engineers have 90-day access keys,” that’s credctl.

Most teams have some of both pains. Pick the one that hurts most first.

Where to go from here

credctl quickstart — 5 minutes from install to hardware-bound credentials
AWS setup guide — what credctl setup aws deploys
OIDC vs Roles Anywhere — why credctl uses the federation path
Granted — if multi-account ergonomics is your primary pain, start here

Stay up to date

Get notified about new credctl releases, security best practices, and hardware identity insights.

credctl vs HashiCorp Vault: Different Problems, Not a Replacement

Mon, 11 May 2026 00:00:00 GMT

Every few weeks I see someone on Hacker News say “just use Vault” in response to a post about credential management. It’s usually well-meaning and usually wrong — or at least, it conflates two different problems.

HashiCorp Vault is a centralised secrets management system. credctl replaces the long-lived AWS/GCP credentials on a developer’s laptop with hardware-bound, short-lived ones. Both care about secrets. They operate at different layers of the stack.

This post lays out what each tool is actually for, where they overlap, and why the right answer for many teams is “both.”

What Vault is for

Vault is a server you run (or buy as HCP Vault Cloud) that stores, rotates, and issues secrets for an entire organisation. Services authenticate to it, prove their identity, and request secrets with narrow scopes and short lifetimes.

The headline features:

Static secret storage — API keys, database passwords, certificates, SSH keys, encryption keys
Dynamic secrets — Vault generates ephemeral credentials on demand (database users, AWS IAM credentials via the AWS secrets engine, signed SSH certs) and revokes them when the lease expires
Policy engine — fine-grained HCL policies mapping identities to the secrets they can access
Audit log — every request is logged for compliance
Many auth methods — Kubernetes service accounts, AWS IAM, JWT/OIDC, LDAP, AppRole, cloud auth methods
PKI, transit encryption, KV stores, totp, SSH CA, and about 30 other backends

Vault is a platform. It’s what you reach for when your organisation has dozens of services and hundreds of secrets and needs a central control plane over all of it.

What credctl is for

credctl has a much narrower scope: replace the long-lived cloud credentials on a developer’s laptop.

The private key lives in the macOS Secure Enclave (hardware, non-extractable). credctl auth signs a JWT with that key and exchanges it for short-lived AWS STS or GCP Workload Identity Federation credentials via OIDC federation. No server, no agent, no SaaS.

credctl auth
# Touch ID prompt
export AWS_ACCESS_KEY_ID=ASIA...

There are no plaintext AWS keys anywhere. There’s no central server to run. There’s nothing to audit beyond what the cloud provider already logs (AssumeRoleWithWebIdentity shows up in CloudTrail with the device fingerprint as the subject).

Scope-wise: credctl manages one identity (your device), talks to one class of service (cloud providers that accept OIDC federation), and does one thing (sign a JWT and exchange it). It’s the laptop counterpart to what GitHub Actions gets from GitHub’s OIDC issuer.

Side-by-side

	HashiCorp Vault	credctl
Primary purpose	Organisation-wide secrets management	Developer-laptop cloud credential replacement
Deployment	Run a server (self-hosted) or buy HCP Vault Cloud	Install a CLI
Scope	Everything — DB creds, API keys, certs, cloud creds, SSH, PKI	AWS + GCP short-lived credentials
Auth root-of-trust	Whatever auth method you use to log in	Secure Enclave hardware key
Audit log	Central, built-in	CloudTrail / GCP audit logs
Multi-user	Yes, first-class	Single user, per-device
Requires infrastructure	Yes	No
Works offline	No	Yes (for cached credentials)
Platform support	Linux, macOS, Windows, many runtimes	macOS today

Where Vault clearly wins

Anything beyond cloud credentials. Database passwords, third-party API keys, Stripe webhook secrets, TLS certificates — credctl has nothing to say about these. Vault handles all of them.

Team and organisation-wide policy. If your security team needs to enforce “nobody can read the production database password without going through this policy,” that’s Vault. credctl has no policy surface.

Dynamic secrets. Vault’s AWS secrets engine can mint a fresh IAM user with a specific policy for each request, revoke it on lease expiry, and audit the whole cycle. credctl does something conceptually similar for STS AssumeRole, but Vault does it across dozens of systems beyond AWS.

Services, not just laptops. A Kubernetes pod that needs a database password is a Vault-shaped problem. credctl is specifically aimed at the human-on-a-laptop case.

Compliance evidence. Vault’s audit log is a well-understood artefact auditors recognise. credctl’s audit story is “look at CloudTrail,” which is honest but less complete.

Where credctl clearly wins

Zero infrastructure. A team can adopt credctl today with one brew install. Standing up Vault means servers, HA, storage backends, unseal ceremonies, upgrade plans, disaster recovery. For most of what developers actually do with cloud credentials — running terraform apply or aws s3 ls — that infrastructure is overkill.

Hardware-bound identity. Vault’s security model ultimately depends on the auth method you use to log in. If a developer authenticates to Vault with a username/password or a long-lived token stored in their shell history, Vault’s policy engine doesn’t help against endpoint compromise. credctl’s identity is in hardware — the device identity can’t be stolen, even with full local privileges.

Offline operation. When Vault is down, everything that depends on it is down. credctl’s cached short-lived credentials keep working until they expire, and a fresh credctl auth only needs the cloud provider’s STS endpoint to succeed.

Touch ID per signing. Every credctl auth requires a Touch ID confirmation. Vault logins are typically cached for hours or days. Different tradeoff — more friction, more attestation.

Using them together

The cleanest mental model: Vault for everything except developer-to-cloud authentication, credctl for that last mile.

Concrete patterns:

Developer laptop → cloud. credctl. Hardware-bound, no server, minimal setup.
Service → database. Vault. Dynamic credentials, audit log, policy.
Service → third-party API. Vault. Static secret storage, rotation.
Service → cloud. Cloud-native workload identity (EKS IRSA, GKE Workload Identity, App Role for Azure). Skip both tools — the platform does it.
Developer → Vault (to fetch team secrets). Authenticate to Vault using OIDC federation from credctl’s JWT. The Secure Enclave key becomes the root of trust for Vault access too. Vault supports this via its JWT/OIDC auth method.

That last pattern is worth calling out: you can chain them. credctl produces a signed JWT, Vault’s JWT auth method validates it, and Vault issues a token with the appropriate policy. Now your Vault identity is anchored in hardware you can’t extract from.

When to not bother with Vault

Small teams with only cloud credential needs often don’t need Vault at all. If your secrets are:

AWS credentials (credctl)
GCP credentials (credctl)
GitHub Actions cloud deploys (built-in OIDC)
Kubernetes service accounts (platform-native)
Database passwords managed by your cloud provider (RDS IAM auth, Cloud SQL IAM)

…you can get away without running a secrets manager at all. Vault is excellent, but it’s also operationally significant. Don’t take it on unless you’ve identified a class of secret that the platform-native options don’t handle.

When to absolutely use Vault

If your organisation has any of these, Vault earns its weight:

Dozens of services each needing their own distinct secrets
Compliance requirements that mandate a central audit log for secret access
A need for dynamic secrets at scale (per-request database credentials)
Secrets that must live on-prem or in an air-gapped environment
A policy engine requirement that the cloud-native options can’t satisfy

Where to go from here

credctl’s scope is narrow and intentional. For the developer-laptop-to-cloud path, hardware-bound + no infrastructure is a strong combination. Vault is the right answer for most of the problems credctl doesn’t touch.

credctl quickstart — 5 minutes from install to working credentials
AWS setup guide — what happens during credctl setup aws
Secure Enclave deep dive — the hardware identity model
HashiCorp Vault — if you’re at the scale where you need it, you probably already know

Stay up to date

Get notified about new credctl releases, security best practices, and hardware identity insights.

credctl vs aws-vault: When to Use Each

Mon, 04 May 2026 00:00:00 GMT

aws-vault is one of the most loved tools in the AWS ecosystem for a reason. It solved a real problem — plaintext AWS keys in ~/.aws/credentials — back when no one else was solving it, and it solved it well. If you’re using aws-vault today, you’re already ahead of 80% of developers on credential hygiene.

credctl takes a different approach to the same underlying problem. This post compares the two fairly, and flags the cases where each is the better fit.

What both tools are trying to fix

A default AWS setup leaves long-lived access keys sitting in ~/.aws/credentials:

[default]
aws_access_key_id = AKIAIOSFODNN7EXAMPLE
aws_secret_access_key = wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

Plaintext. Never expires. Usable from any machine once copied. Readable by any process running as your user. This is the root problem both tools address.

How aws-vault solves it

aws-vault encrypts your long-lived AWS keys at rest in the OS keychain (macOS Keychain, gnome-keyring on Linux, Windows Credential Manager). When you run a command, it asks the keychain for the key, calls sts:GetSessionToken or sts:AssumeRole, and injects the resulting short-lived credentials into the process environment.

aws-vault exec my-profile -- aws s3 ls

The long-lived keys are in the keychain, not on disk. Short-lived session credentials never touch disk at all — they’re passed via environment variables to a single process and discarded when it exits. MFA via TOTP is supported. Role assumption chains work. It integrates cleanly with AWS IAM Identity Center (SSO).

This is genuinely good security. It materially raises the bar for an attacker.

How credctl solves it

credctl eliminates the long-lived AWS keys entirely.

Your Mac’s Secure Enclave generates an ECDSA P-256 key pair. The private key lives in hardware and cannot be exported — not by malware, not by root, not by forensic disk imaging. AWS is configured to trust a static OIDC issuer backed by your public key. When you need credentials, credctl signs a JWT with the hardware key and exchanges it for short-lived STS credentials via AssumeRoleWithWebIdentity:

credctl auth
# Touch ID prompt
export AWS_ACCESS_KEY_ID=ASIA...
export AWS_SECRET_ACCESS_KEY=...
export AWS_SESSION_TOKEN=...

There are no long-lived AWS credentials involved. The only long-lived thing in the system is the Secure Enclave key, and that can’t be stolen.

See the quickstart or the Secure Enclave deep dive for how the OIDC federation is wired up.

Side-by-side

	aws-vault	credctl
Long-lived AWS keys on the machine?	Yes (encrypted in keychain)	No
Root of trust	OS keychain (software)	Secure Enclave (hardware)
Can the root-of-trust key be extracted?	Yes, with keychain + system compromise	No, non-extractable by hardware
Per-use attestation	TOTP MFA (optional)	Touch ID (every signing operation)
AWS integration	IAM access keys + AssumeRole / SSO	OIDC federation + AssumeRoleWithWebIdentity
Other clouds	AWS only	AWS and GCP today, Azure on roadmap
Platform support	macOS, Linux, Windows	macOS only today (Linux TPM planned)
Setup	Use existing AWS keys	Deploys OIDC infrastructure on first run
Ecosystem maturity	10+ years, huge community	New, smaller

When aws-vault is the better choice

You’re on Linux or Windows. credctl relies on the macOS Secure Enclave; Linux TPM 2.0 support is on the roadmap but not yet shipped. aws-vault works everywhere.

You need AWS IAM Identity Center (SSO). aws-vault has first-class support for IAM Identity Center flows with the browser redirect, device authorisation, and session caching. credctl’s model is different — it’s OIDC federation against a custom issuer, not SSO.

You already have working AWS keys in a mature workflow. If your team’s CI, scripts, and tooling all assume aws-vault, there’s real switching cost. aws-vault is a strict improvement over plaintext keys in ~/.aws/credentials, and staying on it is a reasonable choice.

You don’t control your AWS account. credctl needs to deploy an OIDC identity provider, IAM role, and CloudFormation stack the first time you run credctl setup aws. If you’re in an org where you can’t make those changes, aws-vault is a drop-in improvement that doesn’t need account-level config.

Your threat model is stolen disk images and dotfile repos, not targeted malware. aws-vault’s keychain encryption covers the common cases. Hardware attestation is overkill if the risk you’re managing is “I synced my ~/.aws directory to a public GitHub repo.”

When credctl is the better choice

Your threat model includes compromised endpoints. The CircleCI and LastPass breaches both started with malware on developer machines. Keychain-encrypted keys are still decryptable by a sufficiently privileged attacker with a running session. A Secure Enclave signing key is not. If you’re a target — SOC 2 auditor, crypto team, infra engineer at a high-profile company — this difference matters.

You want no long-lived cloud credentials on the machine at all. Even encrypted keychain storage means there’s a long-lived secret that can, under some conditions, become plaintext. credctl’s only long-lived material is a non-extractable hardware key.

You’re multi-cloud. One credctl init produces a single hardware identity that works with both AWS and GCP today. aws-vault is, by design, AWS-only. If you’re juggling AWS access keys and GCP service account JSON files, credctl collapses both into one hardware-rooted identity.

You want per-use attestation, not per-session. aws-vault’s MFA is typically once per session (typical session: hours). credctl prompts Touch ID on every signing operation. That’s stronger attestation but also more friction — decide based on your role.

You’re setting up a new project and can deploy OIDC federation cleanly. credctl setup aws handles the CloudFormation, IAM, and OIDC wiring automatically. If you’re starting fresh, there’s no reason to provision long-lived keys at all.

Can you use them together?

Yes, and it’s sometimes the right answer.

aws-vault and credctl both produce the same thing at the end: AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY / AWS_SESSION_TOKEN environment variables. Any tool that reads those will work with either.

Practical hybrid setups:

Migrate gradually. Keep aws-vault for existing profiles while standing up credctl for new projects or new cloud accounts. Both work side by side.
credctl for direct role access, aws-vault for SSO. If your org uses IAM Identity Center for most access but you want hardware-bound creds for a specific high-trust role (production deploys, infra admin), you can do both.
Different threat models for different accounts. Dev sandbox via aws-vault, prod via credctl. Entirely reasonable.

Choosing based on threat model

The honest framing: aws-vault and credctl represent two different answers to “how much should I trust software?”

aws-vault trusts the OS keychain. If the keychain is honest and the process reading it is honest, the keys stay protected. This is true the vast majority of the time.
credctl doesn’t require that trust. The signing key is in hardware that refuses to cooperate with software trying to extract it. Malware with full user privileges still can’t steal the key — it can only use it while the Touch ID prompt is active.

Both are defensible positions. The question is how much of your security budget you want to spend on reducing the “vast majority of the time” to “always.”

Where to go from here

Quickstart — from brew install to working AWS credentials in 5 minutes
AWS setup guide — what credctl setup aws does under the hood
Secure Enclave deep dive — how hardware-bound signing actually works
OIDC vs Roles Anywhere — why credctl uses one and not the other

If you’re already using aws-vault, you’ve done the hard part — you’ve accepted that plaintext keys are the enemy. Moving to credctl is a step in the same direction, not a change in philosophy.

Stay up to date

Get notified about new credctl releases, security best practices, and hardware identity insights.

Vercel, Context.ai, and the Case Against Bearer Secrets

Tue, 21 Apr 2026 00:00:00 GMT

On 19 April 2026, Vercel disclosed that an attacker had accessed a subset of internal systems and customer environment variables. The entry point wasn’t a Vercel product vulnerability. It was an OAuth grant.

Here’s the chain, as reported:

A Vercel employee had authorised Context.ai, a third-party AI tool, against their Google Workspace account — a normal OAuth integration with broad scopes.
Context.ai itself was breached.
The attacker used the existing OAuth grant to take over the Vercel employee’s Google account.
From there, they pivoted into Vercel’s internal systems and exfiltrated corporate credentials, ~580 employee PII records, and customer environment variables that weren’t flagged Sensitive.

Vercel’s guidance to affected customers: assume API keys, tokens, database credentials, and signing keys stored as non-Sensitive env vars have been compromised. Rotate them.

This is the part of the story that matters for anyone thinking about credential architecture.

The blast radius is the story

Vercel did a lot of things right in the disclosure. Fast IOC publication, law-enforcement engagement, coordination with GitHub/Microsoft/npm/Socket, and a product change making Sensitive the default for new environment variables going forward.

But the cleanup cost — the thing landing on thousands of engineering teams right now — is a direct consequence of what the stolen data was: static, long-lived, extractable bearer secrets sitting in plaintext in a platform database.

Bearer secrets have a defining property. They work from anywhere. An attacker who reads the secret can replay it from their own infrastructure, at their own pace, against any service that accepts it. There’s nothing about an AWS access key, a Stripe secret, a Postgres URI, or a signing key that cares who is holding it.

That’s what makes “rotate everything” the only safe response. The team doing the rotation has no way to prove which specific secrets have been used maliciously and which haven’t, because a stolen bearer secret leaves no fingerprint that distinguishes legitimate use from attacker use.

Why env vars still look like the right answer

Environment variables are a 2010s secret-storage pattern that survived into 2026 for one reason: nothing more ergonomic replaced them for the “my web app needs an API key” case.

The tooling around env vars is genuinely excellent. Vercel’s platform exposes them cleanly at build and runtime, pulls them into local dev, integrates with secret managers, and now defaults to encrypted storage with restricted access. The ergonomics are close to unbeatable.

The problem is architectural, not tooling. Encryption at rest with platform-held keys is a software mitigation. A sufficiently privileged internal account — or a successful intrusion on the platform itself — can still read the plaintext. The Vercel incident is a reminder that this is not a theoretical risk.

And the failure mode compounds. Context.ai → Google Workspace → Vercel → N customers → downstream cloud providers, databases, signing infrastructure, third-party APIs. One OAuth breach exposed the entire upstream credential surface of everyone using the affected platform. The secrets don’t care that they’re on the attacker’s laptop instead of Vercel’s servers.

What breaks the chain

The alternative pattern — already deployed for production workloads in most clouds — is to stop storing bearer secrets altogether.

There are two flavours of this, and they address different environments.

In the cloud, the root of trust is the platform itself. A Kubernetes pod gets a projected service account token signed by the cluster. A GitHub Actions runner gets a JWT signed by GitHub’s OIDC issuer. The cloud provider trusts the issuer, validates the JWT, and returns short-lived credentials via AWS STS, GCP Workload Identity Federation, or Azure Federated Identity Credentials. No signing key on the workload — the platform vouches for it. Stolen short-lived credentials expire in minutes, and there’s nothing long-lived to steal in the first place.

Off the cloud — developer workstations, on-prem services, edge devices — there’s no platform to vouch. The signing key has to live somewhere. The answer is hardware: TPM 2.0 on Linux and Windows, Secure Enclave on macOS, dedicated HSMs for higher-assurance workloads. The key is generated in the chip, never leaves it, and can’t be exported by malware or disk imaging. The device becomes its own root of trust, and the same federation protocols issue the same short-lived credentials on top.

None of this is new. Production services should have been authenticating this way for years.

For the Vercel case, the hardware-bound version of the same architecture would have broken the chain at two points:

Employee side. The OAuth session that enabled the initial takeover was itself a long-lived bearer secret on the employee’s device. A hardware-bound session — gated by device attestation and a non-extractable key — couldn’t be silently exfiltrated by compromising a connected SaaS app. The attacker would need the physical device.
Customer side. If customer workloads authenticated to AWS/GCP/Stripe/Postgres via federated, short-lived credentials rather than long-lived env-var secrets, the stolen env vars wouldn’t be usable off the issuing workload. There would be nothing to “rotate” because there would be nothing static to steal.

The rotation burn-down that Vercel customers are running this week is the direct cost of the architecture. Hardware-bound, short-lived credentials don’t eliminate incidents — they eliminate the catastrophic replay phase that turns an incident into a cleanup project.

Where credctl fits

credctl is the developer-workstation version of this pattern. Your Mac’s Secure Enclave generates a non-extractable signing key. credctl auth signs a JWT with that hardware-bound key and exchanges it for short-lived AWS or GCP credentials via OIDC federation. Credentials last one hour. The signing key can’t leave the chip.

It doesn’t solve the whole Vercel problem. Production workloads still need their own identity. Platform vendors still need to rotate their internal OAuth hygiene. SaaS integrations still need scoped, auditable grants.

But it removes one class of long-lived, extractable credential from the developer’s laptop entirely — the class that shows up in the first line of nearly every postmortem: “the attacker exfiltrated credentials from a developer machine.”

The next time a platform has a rough week, the teams running hardware-bound credentials will be reading the postmortem with interest rather than with a panicked grep -r secret.

Sources

Stay up to date

Get notified about new credctl releases, security best practices, and hardware identity insights.

credctl Now Supports GCP: One Hardware Identity, Two Clouds

Mon, 23 Mar 2026 00:00:00 GMT

When we launched credctl, the pitch was simple: replace the plaintext AWS keys on your laptop with hardware-bound credentials using the Secure Enclave. No keys on disk. Ever.

Today, we’re extending that to GCP.

credctl auth --provider gcp exchanges the same hardware-bound JWT for short-lived GCP access tokens via Workload Identity Federation. Same Secure Enclave key. Same OIDC provider. No new infrastructure. No GCP SDK dependency.

Why This Matters

If you work across AWS and GCP — and an increasing number of teams do — you now have a single device identity that works with both clouds. One credctl init, one OIDC provider, two clouds.

The security model is identical to AWS:

Private key lives in the Secure Enclave. Can’t be exported.
Credentials are short-lived (1 hour).
Touch ID required for every signing operation.
Nothing on disk to steal.

The difference is in the exchange mechanism. AWS uses a single AssumeRoleWithWebIdentity call. GCP uses a two-step exchange:

sequenceDiagram
    participant CLI as credctl CLI
    participant SE as Secure Enclave
    participant STS as GCP STS
    participant IAM as GCP IAM Credentials

    CLI->>SE: Sign JWT (Touch ID)
    SE-->>CLI: Signed JWT
    CLI->>STS: ExchangeToken (JWT)
    STS-->>CLI: Federated access token
    CLI->>IAM: GenerateAccessToken
    IAM-->>CLI: OAuth2 access token (1h)

The CLI signs a JWT with the Secure Enclave key (same as AWS, but with GCP’s Workload Identity Provider URI as the audience).
GCP STS validates the JWT against the OIDC provider and returns a federated access token.
The CLI exchanges the federated token for a service account access token via the IAM Credentials API.

The result: a standard GCP OAuth2 access token, usable with gcloud, Terraform, and all GCP client libraries.

Setup: Five Minutes

Prerequisites

You need credctl installed and initialised (credctl init), and AWS OIDC infrastructure deployed (credctl setup aws). GCP reuses the same OIDC provider — the CloudFront-hosted discovery documents that AWS validates are the same ones GCP validates.

You also need a GCP service account with the roles you want credctl to assume.

Step 1: Set up GCP federation

credctl setup gcp --service-account credctl@my-project.iam.gserviceaccount.com

This single command handles everything: OIDC hosting on GCS, Workload Identity Pool, OIDC Provider, service account binding, and generating the credential config file at ~/.credctl/gcp-credentials.json.

Step 2: Use it

export GOOGLE_APPLICATION_CREDENTIALS=~/.credctl/gcp-credentials.json
gcloud storage ls

Or authenticate gcloud directly:

gcloud auth login --cred-file=~/.credctl/gcp-credentials.json

That’s it. Every GCP API call now uses hardware-bound, short-lived credentials.

Terraform for Teams

If your team prefers infrastructure-as-code over CLI setup, there’s a Terraform module at deploy/terraform-gcp/:

module "credctl_gcp" {
  source = "github.com/credctl/credctl//deploy/terraform-gcp"

  project_id         = "my-project"
  device_fingerprint = "SHA256:oKz3i9Tg..."
  issuer_url         = "https://d1234.cloudfront.net"

  service_account_roles = [
    "roles/storage.objectViewer",
    "roles/bigquery.dataViewer",
  ]
}

This creates the same resources as credctl setup gcp — Workload Identity Pool, OIDC Provider, Service Account, and IAM bindings — but version-controlled and repeatable.

No GCP SDK

One design decision worth highlighting: credctl has zero GCP SDK dependency. The GCP STS token exchange and IAM Credentials API calls are implemented with Go’s net/http stdlib. This keeps the binary small, the dependency tree minimal, and the attack surface narrow.

The same is true for AWS — credctl’s only external Go dependency is spf13/cobra for CLI argument parsing.

How the OIDC Architecture Made This Easy

When we chose OIDC federation over AWS Roles Anywhere (see the technical deep dive), cross-cloud portability was a key reason. OIDC is a standard. AWS, GCP, and Azure all accept OIDC tokens for credential exchange. By building on OIDC, adding GCP support meant implementing the GCP-specific exchange protocol — not rebuilding identity infrastructure.

The only code change to the shared JWT package was making the audience claim configurable. AWS uses sts.amazonaws.com. GCP uses the Workload Identity Provider URI. Same key, same signature, different audience.

What’s Next

Azure Federated Identity Credentials — the third major cloud. Same OIDC architecture, Azure-specific exchange.
Linux TPM 2.0 — the same multi-cloud identity on Linux workstations.
Credential caching daemon — avoid redundant STS calls and Touch ID prompts within the credential TTL. (This is already available as an experimental feature: credctl daemon start.)

Try It

Update to the latest credctl:

brew upgrade credctl/tap/credctl

GCP setup guide: credctl.com/guides/gcp-setup
GitHub: github.com/credctl/credctl
Quickstart: credctl.com/quickstart

If you’re using credctl with both AWS and GCP, we’d love to hear about your experience. Open an issue or start a discussion on GitHub.

Stay up to date

Get notified about new credctl releases, security best practices, and hardware identity insights.

credctl: Eliminating Plaintext Cloud Keys with the Secure Enclave

Sat, 07 Mar 2026 00:00:00 GMT

The Problem Nobody Talks About

Here’s a number that should keep you up at night: 86% of breaches involve stolen credentials. In 2025 alone, infostealer malware exfiltrated 1.8 billion credentials from 5.8 million devices — an 800% surge over recent years.

And where are your cloud credentials right now?

If you’re like most developers, the answer is ~/.aws/credentials. A plaintext file. On your laptop. Readable by any process running as your user.

[default]
aws_access_key_id = AKIAIOSFODNN7EXAMPLE
aws_secret_access_key = wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

That file is the single most common credential pattern in cloud computing. It never expires. It works from any machine. And it can be stolen by any malware with file access, copied from disk images, committed to dotfile repos, or extracted from a stolen laptop.

Think about what that means in practice. You install a VS Code extension, a Homebrew package, or a Python library — any of them could read ~/.aws/credentials silently. You back up your disk, and those keys are in the backup. You sell your old laptop and don’t wipe it properly, and those keys go with it. You share your dotfiles on GitHub and accidentally include your credentials directory.

The breach data tells the same story, over and over:

CircleCI (2023): Malware on a developer laptop exfiltrated a session cookie. The attacker accessed production systems and forced all customers to rotate their secrets.
LastPass (2022): A developer workstation was compromised. Credentials from the first breach were used to access cloud storage containing customer vault backups. The result was one of the most catastrophic data breaches in password manager history.
Okta (2023): A stolen service account credential, stored in a personal Google account synced from a company device, gave attackers access to every customer’s support case files.
Uber (2022): Stolen contractor credentials combined with MFA fatigue bombing compromised internal systems. The former CISO was criminally convicted.
Codecov (2021): A modified CI script exfiltrated environment variables — including credentials — from thousands of downstream customers.

Every one of these traces back to the same pattern: long-lived credentials accessible on a developer machine. The attackers aren’t breaking encryption or exploiting zero-days. They’re reading files.

The Gap That Shouldn’t Exist

Here’s what’s strange. Your Mac has had a Secure Enclave since 2016. It’s a hardware security module — a dedicated chip that generates cryptographic keys, stores them in hardware, and never allows them to be exported. The private key physically cannot leave the chip. Not by malware, not by root access, not by forensic disk imaging.

Your Mac uses the Secure Enclave for Touch ID, Apple Pay, and FileVault. Banks use it. Governments use it. Apple’s corecrypto module is FIPS 140-2 validated.

Meanwhile, AWS has supported OIDC federation since 2014. Any service that can produce a signed JWT can exchange it for short-lived STS credentials via AssumeRoleWithWebIdentity. No long-lived keys required.

The Secure Enclave can sign JWTs. AWS can accept them. Nothing connected the two.

That’s the gap credctl fills.

What credctl Does

credctl uses your Mac’s Secure Enclave to replace long-lived cloud access keys with short-lived, hardware-bound credentials. It works with both AWS and GCP today, with Azure on the roadmap.

The private key lives in the Secure Enclave — it can never be exported, copied, or stolen. When you need AWS credentials, credctl signs a JWT with that hardware-bound key and exchanges it for short-lived STS credentials via OIDC federation. The credentials last one hour. There’s nothing on disk to steal.

$ credctl init
✓ Generated ECDSA P-256 key pair in Secure Enclave
✓ Exported public key to ~/.credctl/device.pub
✓ Device ID: SHA256:oKz3i9Tg...

$ credctl setup aws --policy-arn arn:aws:iam::123456789012:policy/DevAccess
✓ Deployed CloudFormation stack (S3, CloudFront, OIDC provider, IAM role)
✓ OIDC issuer URL: https://d1234.cloudfront.net

$ credctl auth
✓ Built JWT (iss=https://d1234.cloudfront.net, sub=SHA256:oKz3i9Tg...)
✓ Signed with Secure Enclave (Touch ID)
✓ Exchanged for STS credentials (expires in 1h)

export AWS_ACCESS_KEY_ID=ASIA...
export AWS_SECRET_ACCESS_KEY=...
export AWS_SESSION_TOKEN=...

That’s it. Five minutes from install to working credentials. No server infrastructure. No SSO portal. No browser redirects.

How It Works

The architecture is straightforward:

sequenceDiagram
    participant Dev as Developer
    participant CLI as credctl CLI
    participant SE as Secure Enclave
    participant STS as AWS STS
    participant OIDC as OIDC Provider<br/>(S3 + CloudFront)

    Dev->>CLI: credctl auth
    CLI->>CLI: Build JWT (iss, sub, aud)
    CLI->>SE: Sign JWT (ECDSA P-256 / ES256)
    SE-->>CLI: Signed JWT
    CLI->>STS: AssumeRoleWithWebIdentity
    STS->>OIDC: Fetch JWKS (public key)
    STS->>STS: Validate signature, assume role
    STS-->>CLI: Short-lived credentials (1h)
    CLI-->>Dev: AWS credentials

credctl init generates an ECDSA P-256 key pair inside the Secure Enclave. The private key never leaves the hardware. The public key is exported.
credctl setup aws creates an S3 bucket to host OIDC discovery documents, an IAM OIDC identity provider that trusts the issuer URL, an IAM role configured for web identity federation, and configures the AWS CLI profile — all in a single command.
credctl auth builds a JWT with your issuer URL, device ID, and sts.amazonaws.com as the audience. The Secure Enclave signs it (Touch ID prompt). The CLI sends it to STS via AssumeRoleWithWebIdentity. STS fetches your JWKS, validates the signature, and returns short-lived credentials.

The CLI is written in Go. The Secure Enclave integration uses cgo to call Apple’s Security framework directly (SecKeyCreateRandomKey, SecKeyCreateSignature). The STS call is a raw HTTP POST — no AWS SDK dependency. The only external dependency is spf13/cobra for CLI argument parsing.

Multi-Cloud: AWS and GCP Today

credctl’s OIDC architecture was designed for cross-cloud portability from the start. The same Secure Enclave key and OIDC provider work with both AWS and GCP.

GCP setup is just as simple:

$ credctl setup gcp --service-account credctl@my-project.iam.gserviceaccount.com
✓ Created Workload Identity Pool
✓ Created OIDC Provider (using existing issuer URL)
✓ Bound service account to device identity

$ credctl setup gcp-cred-file
✓ Wrote credential config to ~/.credctl/gcp-credentials.json

$ export GOOGLE_APPLICATION_CREDENTIALS=~/.credctl/gcp-credentials.json
$ gcloud storage ls

One hardware identity. Two clouds. No keys on disk for either.

What It Doesn’t Do (Yet)

To be clear about scope — credctl today is:

macOS only. Secure Enclave integration works on Apple Silicon (M1–M4) and Intel Macs with T2 chip. Linux TPM 2.0 support is planned but not yet implemented.
AWS and GCP. Azure Federated Identity Credentials are on the roadmap.
Individual use. Direct Mode means each developer manages their own OIDC endpoint. A team broker with policy enforcement, audit trails, and device fleet management is planned for a future phase.

credctl doesn’t replace HashiCorp Vault for secrets management. It replaces the plaintext cloud keys on your laptop. Different problem, different tool.

What’s Next

The roadmap expands in concentric circles:

Azure: Federated Identity Credentials, completing the three major clouds with one hardware identity.
Linux TPM 2.0: The same architecture using TPM 2.0 on Linux workstations. Windows 11 requires TPM 2.0, so the hardware is already there.
Credential broker for teams: A centralised broker that sits between developers and cloud providers. Policy enforcement (who can assume which roles, from which devices), approval workflows, and a full audit trail mapped to SOC 2, NIS2, DORA, and ISO 27001 controls.

Try It

credctl is open source (Apache 2.0).

GitHub: github.com/credctl/credctl
Quickstart: Read the quickstart guide — install to working credentials in under 5 minutes
Technical deep dive: How credctl Uses the macOS Secure Enclave for Cloud Credentials

Questions and feedback welcome in GitHub Discussions.

Stay up to date

Get notified about new credctl releases, security best practices, and hardware identity insights.

How credctl Uses the macOS Secure Enclave for Cloud Credentials

Sat, 07 Mar 2026 00:00:00 GMT

This post explains the architecture of credctl — a CLI tool that replaces long-lived AWS access keys with short-lived, hardware-bound credentials using the macOS Secure Enclave. For the problem statement and product overview, read Eliminating Plaintext Cloud Keys. This post is the “how.”

What the Secure Enclave Actually Is

The Secure Enclave is a hardware security subsystem isolated from the main processor. On Apple Silicon Macs (M1–M4), it’s a dedicated core within the SoC. On Intel Macs with T2, it’s a separate chip. Either way, it has its own boot process, its own encrypted memory, and its own secure storage.

What matters for credctl:

Key generation happens inside the hardware. When you ask the Secure Enclave to create a key pair, the private key is generated inside the chip and never leaves it. There is no API to export it. There is no memory region to read it from. The hardware enforces this — it’s not a software policy.
Signing happens inside the hardware. You send data to the Secure Enclave, it signs it with the private key, and returns the signature. The private key is never exposed to the application, the operating system, or the CPU.
User presence verification. The Secure Enclave gates key operations behind biometric (Touch ID) or passcode verification. Even with root access, a process cannot silently use a Secure Enclave key without the user’s explicit approval.
FIPS 140-2 validated. Apple’s corecrypto module, which underpins Secure Enclave operations, has FIPS 140-2 validation. This is the same level of certification used by government and financial systems.

The Secure Enclave supports ECDSA with the P-256 curve (also known as secp256r1 or prime256v1). This maps directly to the ES256 algorithm in JWTs — which is exactly what credctl needs.

credctl’s Architecture

credctl is a Go CLI that bridges the Secure Enclave’s cryptographic capabilities to cloud provider credential APIs. The architecture has five components:

graph TB
    subgraph "credctl CLI"
        CMD[Command Layer<br/>cobra]
        CFG[Config Manager<br/>~/.credctl/config.json]
        ENC[Enclave Interface<br/>cgo → Security.framework]
        JWT[JWT Builder<br/>ES256 tokens]
        STS_C[AWS STS Client<br/>AssumeRoleWithWebIdentity]
    end

    subgraph "Hardware"
        SE[Secure Enclave<br/>ECDSA P-256]
    end

    subgraph "AWS"
        STS[AWS STS]
        OIDC_P[OIDC Provider<br/>S3 + CloudFront]
    end

    CMD --> CFG
    CMD --> ENC
    CMD --> JWT
    CMD --> STS_C

    ENC --> SE
    JWT --> ENC
    STS_C --> STS
    STS --> OIDC_P

The Enclave Interface

This is the critical piece. The Secure Enclave is accessed through Apple’s Security framework, which is an Objective-C/C API. Go doesn’t call C APIs natively, so credctl uses cgo — Go’s foreign function interface for C code.

The Enclave interface abstracts hardware operations:

type Enclave interface {
    Available() bool
    GenerateKey(tag string) (*ecdsa.PublicKey, error)
    LoadKey(tag string) (*ecdsa.PublicKey, error)
    DeleteKey(tag string) error
    Sign(tag string, data []byte) ([]byte, error)
}

On macOS, the implementation calls Security framework functions via cgo:

GenerateKey calls SecKeyCreateRandomKey with kSecAttrTokenIDSecureEnclave to create an ECDSA P-256 key pair inside the Secure Enclave. The key is tagged with a unique identifier so it can be loaded later. The function returns the public key — the private key stays in hardware.
Sign calls SecKeyCreateSignature with the kSecKeyAlgorithmECDSASignatureMessageX962SHA256 algorithm. The Secure Enclave signs the data and returns the DER-encoded signature. By default (--biometric=any), this triggers a Touch ID prompt with passcode fallback. This behaviour is configurable via the --biometric flag at credctl init time.
LoadKey retrieves a previously generated key by its tag using SecItemCopyMatching.

Build tags dispatch the implementation:

darwin.go — the real Secure Enclave implementation via cgo
other.go — a stub that returns clear errors on unsupported platforms

This cgo dependency is a deliberate architectural choice. It means credctl can’t be cross-compiled with a simple go build — it needs Xcode and an Apple provisioning profile. That’s a trade-off: harder distribution in exchange for real hardware security. The binary is distributed as a code-signed, notarised macOS app bundle.

The OIDC Flow

This is where the Secure Enclave connects to AWS. The flow uses OIDC (OpenID Connect) federation — specifically, AWS STS AssumeRoleWithWebIdentity. Here’s how the pieces fit together:

Setup (one-time)

credctl init generates the key pair in the Secure Enclave. It exports the public key to ~/.credctl/device.pub and derives a device ID (SHA-256 fingerprint of the public key).
credctl setup aws deploys a CloudFormation stack that creates:
- An S3 bucket to host OIDC discovery documents
- A CloudFront distribution in front of S3 (AWS requires OIDC issuers to use HTTPS)
- An IAM OIDC identity provider that trusts the CloudFront URL as an OIDC issuer
- An IAM role with a trust policy that allows AssumeRoleWithWebIdentity from the OIDC provider
The command also generates and uploads the OIDC discovery documents (.well-known/openid-configuration and keys.json JWKS) automatically.

After setup, you have a self-hosted OIDC provider backed by your device’s hardware identity. AWS trusts this provider because it’s registered as an IAM OIDC identity provider.

Authentication (every time)

sequenceDiagram
    participant CLI as credctl CLI
    participant SE as Secure Enclave
    participant STS as AWS STS
    participant CF as CloudFront<br/>(OIDC Provider)

    CLI->>CLI: Build JWT claims:<br/>iss = CloudFront URL<br/>sub = device ID (SHA-256)<br/>aud = sts.amazonaws.com<br/>iat = now<br/>exp = now + 5min<br/>jti = random UUID
    CLI->>SE: Sign JWT (ES256)
    Note over SE: Touch ID prompt
    SE-->>CLI: Signature
    CLI->>CLI: Assemble signed JWT<br/>(header.payload.signature)
    CLI->>STS: AssumeRoleWithWebIdentity<br/>(JWT + role ARN)
    STS->>CF: GET /.well-known/openid-configuration
    CF-->>STS: Discovery document
    STS->>CF: GET /keys.json
    CF-->>STS: JWKS (device public key)
    STS->>STS: Verify JWT signature<br/>against JWKS public key
    STS->>STS: Validate claims<br/>(issuer, audience, expiry)
    STS->>STS: Assume IAM role
    STS-->>CLI: AccessKeyId +<br/>SecretAccessKey +<br/>SessionToken<br/>(valid 1 hour)

credctl auth builds a JWT with these claims:
- iss — the CloudFront URL (OIDC issuer)
- sub — the device ID (SHA-256 fingerprint of the public key)
- aud — sts.amazonaws.com
- iat — current timestamp
- exp — current timestamp + 5 minutes (short-lived token)
- jti — a random UUID (prevents replay)
The JWT header specifies alg: ES256 and includes a kid (key ID) matching the key in the JWKS.
The CLI sends the JWT payload to the Secure Enclave for signing. With the default biometric policy (--biometric=any), this triggers a Touch ID prompt with passcode fallback. The Secure Enclave returns an ECDSA signature.
The CLI assembles the complete JWT (header.payload.signature, base64url-encoded) and calls STS AssumeRoleWithWebIdentity with the JWT and the IAM role ARN.
STS fetches the OIDC discovery document from CloudFront, follows it to the JWKS endpoint, retrieves the device’s public key, and validates the JWT signature.
If validation passes and the role’s trust policy allows it, STS returns temporary credentials — an access key ID, secret access key, and session token valid for one hour (default, configurable up to 12 hours).

Why OIDC Over Roles Anywhere

AWS offers two X.509-based credential mechanisms: OIDC federation (via AssumeRoleWithWebIdentity) and IAM Roles Anywhere (via CreateSession). credctl uses OIDC federation. Here’s why:

Portability. OIDC is a cross-cloud standard. GCP’s Workload Identity Federation and Azure’s Federated Identity Credentials both accept OIDC tokens. By building on OIDC, credctl’s architecture extends to multi-cloud without fundamental changes. Roles Anywhere is AWS-specific.

Simplicity. OIDC federation requires hosting two static JSON files. Roles Anywhere requires managing X.509 certificates, certificate authorities, and certificate lifecycle. For a developer workstation tool, the OIDC approach is simpler.

JWT ecosystem. OIDC uses JWTs, which are well-understood, easy to debug (paste into jwt.io), and have mature library support. X.509 certificate handling is more complex and error-prone.

Existing infrastructure. The Secure Enclave supports ECDSA P-256 signing, which maps directly to ES256 JWTs. No certificate generation or CA infrastructure needed.

The trade-off: OIDC requires hosting a discovery endpoint (the S3 + CloudFront stack). Roles Anywhere doesn’t require any hosted infrastructure — it uses the X.509 certificate directly. For credctl’s use case, the simplicity and portability of OIDC outweigh the small infrastructure requirement.

Code Walkthrough: Key Generation to Credential Exchange

Here’s the flow through credctl’s code, step by step.

Step 1: Key Generation (`credctl init`)

The init command calls the Enclave interface to generate a key:

Enclave.GenerateKey(tag) → *ecdsa.PublicKey

Under the hood (on macOS), this calls SecKeyCreateRandomKey with attributes specifying:

Token: kSecAttrTokenIDSecureEnclave (create in Secure Enclave, not software)
Key type: kSecAttrKeyTypeECSECPrimeRandom (ECDSA)
Key size: 256 bits (P-256 curve)
Access control: determined by the --biometric flag (default: any)

The --biometric flag controls the Secure Enclave access control policy for signing:

`--biometric` value	Access control	Behaviour
`any` (default)	`kSecAccessControlPrivateKeyUsage` + `kSecAccessControlUserPresence`	Touch ID with passcode fallback
`fingerprint`	`kSecAccessControlPrivateKeyUsage` + `kSecAccessControlBiometryCurrentSet`	Touch ID only, no passcode fallback. Key is invalidated if fingerprints change.
`none`	`kSecAccessControlPrivateKeyUsage` only	No user verification. Signing happens silently when the device is unlocked.

The biometric policy is set at key creation time and cannot be changed afterward. To change it, reinitialise with credctl init --force --biometric=<policy>.

The public key is exported to ~/.credctl/device.pub in PEM format. The device ID is the SHA-256 fingerprint of the public key bytes. The config is written to ~/.credctl/config.json.

Step 2: JWT Construction (`credctl auth`)

The JWT builder constructs the token in three parts:

Header:

{
  "alg": "ES256",
  "typ": "JWT",
  "kid": "<key-id-matching-jwks>"
}

Payload:

{
  "iss": "https://d1234.cloudfront.net",
  "sub": "sha256:a1b2c3d4e5f6...",
  "aud": "sts.amazonaws.com",
  "iat": 1709800000,
  "exp": 1709800300,
  "jti": "550e8400-e29b-41d4-a716-446655440000"
}

The header and payload are base64url-encoded and concatenated with a dot: base64url(header).base64url(payload). This becomes the signing input.

Step 3: Hardware Signing

The signing input bytes are sent to the Secure Enclave:

Enclave.Sign(tag, signingInput) → []byte (DER-encoded signature)

The Secure Enclave computes the ECDSA-SHA256 signature and returns it. The DER-encoded signature is converted to the raw r || s format that JWTs expect, then base64url-encoded.

The final JWT: base64url(header).base64url(payload).base64url(signature)

Step 4: Credential Exchange

The CLI calls AWS STS AssumeRoleWithWebIdentity via a raw HTTP POST (no AWS SDK):

POST https://sts.amazonaws.com/
Content-Type: application/x-www-form-urlencoded

Action=AssumeRoleWithWebIdentity
&RoleArn=arn:aws:iam::123456789012:role/credctl-role
&RoleSessionName=credctl-session
&WebIdentityToken=<signed-jwt>
&Version=2011-06-15

STS validates the JWT by:

Fetching https://d1234.cloudfront.net/.well-known/openid-configuration
Following the jwks_uri to https://d1234.cloudfront.net/keys.json
Matching the kid in the JWT header to a key in the JWKS
Verifying the ES256 signature against the public key
Checking claims: issuer matches, audience is sts.amazonaws.com, token is not expired

If valid, STS assumes the IAM role and returns temporary credentials.

Security Properties

credctl’s architecture provides several security guarantees:

Private key never leaves hardware. The Secure Enclave enforces non-exportability at the hardware level. Even with root access, an attacker cannot read the private key. They would need physical possession of the specific device AND the user’s biometric (or passcode) to sign a JWT.

Short-lived credentials. The STS credentials returned by AssumeRoleWithWebIdentity are temporary — one hour by default, configurable up to 12 hours. There are no long-lived credentials on disk.

Replay protection. Each JWT includes a unique jti (JWT ID) and a short exp (5 minutes). Even if a JWT were intercepted, it would expire before it could be meaningfully reused.

User presence required (default). With the default biometric policy (--biometric=any), every signing operation requires Touch ID or passcode verification. Malware cannot silently use the Secure Enclave key to obtain credentials. This can be disabled with --biometric=none at credctl init time for headless environments, at the cost of losing user-presence protection.

Revocation via JWKS. To revoke a device’s access, remove its public key from the JWKS and delete the IAM OIDC identity provider trust. STS will no longer validate JWTs from that device.

No credential caching on disk. credctl does not cache STS credentials to disk in plaintext. The credentials are output to stdout or set as environment variables for the current session.

What This Doesn’t Protect Against

No security architecture is complete without stating its limitations:

A compromised device with the user present. If an attacker has remote access to a device and the user approves a Touch ID prompt (social engineering or confusion), the attacker gets valid short-lived credentials. The mitigation is that the credentials are short-lived and the attack window is narrow.
Credential misuse after issuance. Once STS credentials are issued, they’re standard AWS temporary credentials. If they’re logged, written to a file, or used in a shared terminal, they can be used by anyone until they expire.
OIDC provider compromise. If an attacker gains write access to the S3 bucket hosting the JWKS, they could add their own public key and sign JWTs that STS would accept. The CloudFormation stack configures bucket access controls, but the OIDC provider is a critical trust boundary. The brokered mode (planned) eliminates this risk by centralising OIDC management.

Comparison to Alternative Approaches

It’s worth comparing credctl’s security properties to common alternatives:

Approach	Key Storage	Exportable?	Credential Lifetime	Device Binding
`~/.aws/credentials`	Plaintext file	Yes	Permanent	None
1Password Shell Plugins	Encrypted software vault	Yes (if vault decrypted)	Permanent (stored key)	None
AWS Identity Center	Browser session cookie	Yes (cookie theft)	8–12 hours	None
credctl	Secure Enclave hardware	No (hardware-enforced)	1 hour (STS)	Hardware-bound

The fundamental difference is the transition from software-stored credentials (which can be copied) to hardware-bound credentials (which physically cannot be copied). This is not an incremental improvement — it’s an architectural change in where trust is anchored.

Performance

Credential issuance involves three operations:

JWT construction: Microseconds. String formatting and base64 encoding.
Secure Enclave signing: Typically 20–50ms for the cryptographic operation, plus Touch ID interaction time (user-dependent).
STS API call: 100–300ms depending on network latency.

Total time from credctl auth to credentials: under one second of compute, plus Touch ID interaction. This is faster than browser-based SSO flows, which typically require 5–15 seconds of page loads, redirects, and MFA prompts.

STS caches the OIDC discovery document and JWKS, so subsequent credential requests in the same session don’t require CloudFront fetches. The signing operation itself is constant-time — the Secure Enclave processes ECDSA signatures at the same speed regardless of the data being signed.

What’s Next

The architecture is designed to extend in two directions:

Platform expansion. The Enclave interface abstracts hardware operations, so adding Linux TPM 2.0 support means implementing the same interface against go-tpm instead of Apple’s Security framework. The JWT builder, OIDC generator, and STS client remain unchanged. The same applies to Windows TPM via a Windows-specific build.

Multi-cloud. The OIDC-based architecture was chosen specifically because GCP Workload Identity Federation and Azure Federated Identity Credentials accept OIDC tokens. Adding GCP support means implementing a GCP token exchange client; adding Azure means implementing an Azure AD token exchange client. The hardware identity, JWT construction, and OIDC provider infrastructure remain the same.

Brokered mode. For teams, the CLI will authenticate to a centralised credctl broker instead of directly to cloud providers. The broker verifies device identity, evaluates policy (who can assume which roles from which devices), brokers credentials from cloud providers, and logs everything for audit. The hardware identity foundation is the same — the broker trusts the device’s signed assertion because it has the device’s public key in its registry.