credctl vs HashiCorp Vault: Different Problems, Not a Replacement

May 11, 2026

Mat Evans

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