credctl vs aws-vault: When to Use Each

May 4, 2026

Mat Evans

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.