credctl vs Granted: Workflow Ergonomics vs Hardware Identity

May 18, 2026

Mat Evans

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