Secrets Management Best Practices for Crypto Companies

By Owen Thurm Published November 6, 2026 6 min read

Quick answer. Centralize secrets in one vault or cloud secrets manager. Give each service only what it needs, prefer short-lived credentials, and rotate and audit everything. Keep signing keys in an HSM, KMS or MPC system, never a secret store.

Watch: Secrets Management Best Practices for Crypto Companies 1:37

Video transcript

In crypto, one leaked credential can lead to a key that moves funds. Centralize, scope and rotate secrets, and keep signing keys out of secret stores.

Guardian's review of a Synthetix keeper found an RPC key committed in plaintext, a private key returned as a raw string, and a role that could read every secret.

CI leaks too. After a GitHub Action was compromised in March 2025, CISA said to rotate all identified secrets immediately.

OWASP says to centralize secrets, and that engineers should not see every secret. Apps fetch credentials at runtime instead of hardcoding them.

A cloud secrets manager suits teams mostly in one cloud. Vault fits teams needing dynamic credentials, revocation by prefix, or one audit trail across environments.

The safest secret expires before anyone can use it. Vault issues expiring per-service database logins, and GitHub Actions can get a cloud token for one job.

Rotate on a schedule and automate it. After a leak, revoke first. Audit every read, scan before you ship, and rotate what a departing engineer could read.

Signing keys are different. Once a private key reaches app memory, whoever controls that process can copy it. Keep them in an HSM, KMS or MPC system.

Guardian's infrastructure pentest checks who can read your secrets and whether a compromised pipeline can ship or sign. Read the full article, or talk to Guardian.

A crypto company runs on secrets: cloud credentials, database passwords, exchange API keys, RPC keys, webhook secrets and deploy tokens.

Most start life in a .env file. Then they spread into CI variables, laptops, chat threads and container images.

The stakes are higher than in most software, because one leaked credential can lead to a key that moves funds. If a key has already leaked, see what to do in the first hour.

The Secrets Sprawl Problem

Guardian's public reports show how secrets leak in crypto backends. Its review of a Synthetix LP vault keeper found:

M-07: an Alchemy RPC key and a secret's ARN committed in plaintext.
M-08: the keeper's private key returned as a raw string that code could log.
Remediation M-03: the keeper's role could read every secret in the account.

CI pipelines leak too. In March 2025, the compromised tj-actions/changed-files GitHub Action exposed access keys, GitHub tokens, npm tokens and private RSA keys, per CISA.

CISA's advice to affected teams: "Rotate all identified secrets immediately as they should be considered compromised."

Centralize Secrets in a Vault

OWASP's Secrets Management Cheat Sheet says teams "must standardize and centralize the secrets management solution." One system gives you one place to grant, rotate, revoke and audit.

Access inside it should be narrow. OWASP adds that "engineers should not have access to all secrets in the secrets management system."

AWS describes the shift well: you "replace hard-coded credentials with a runtime call" that fetches them when needed.

Vault vs Cloud Secrets Managers

Five common choices, with what stands out in each vendor's own docs:

Tool	What stands out
HashiCorp Vault	Dynamic credentials with leases, revocation by prefix, audit log of every request
AWS Secrets Manager	KMS encryption, managed or Lambda rotation as often as every four hours, CloudTrail
Google Cloud Secret Manager	Versions, IAM conditions, customer-managed keys, rotation notices via Pub/Sub
Doppler	CLI injects secrets; rotated secrets (Team, Enterprise); dynamic secrets (Enterprise)
1Password	Service accounts limited to chosen vaults, for CI/CD and apps

Which to choose

A cloud secrets manager fits teams that run mostly in one cloud. It plugs into that cloud's IAM, logging and key management.

Vault fits when you need dynamic credentials for databases and other systems, revocation by prefix, or one audit trail across environments.

Doppler and 1Password suit teams that want one place for developer, CI and production secrets. Check the plan tier for the features you need.

One difference to plan for: Google's Secret Manager sends a rotation notice but does not change the value itself. You "must configure a Pub/Sub subscriber to receive and act on" it.

Short-Lived Credentials

The safest secret expires before anyone can use it. OWASP: "Dynamic secrets should be used where possible."

Vault's database engine "generates database credentials dynamically based on configured roles." Each service gets its own login, so access traces back to one service.

When a lease expires, Vault revokes it. After an intrusion, operators can revoke every secret under a lease prefix at once.

Doppler's dynamic secrets default to a 30-minute TTL and are an Enterprise feature.

CI without stored cloud keys

GitHub Actions can use OpenID Connect to get a cloud token "that is only valid for a single job, and then automatically expires."

That means you "won't need to duplicate your cloud credentials as long-lived GitHub secrets." Treat every third-party action as code that can read your secrets.

Delivering Secrets to Apps and Bots

Fetch secrets at runtime with an identity the platform gives the workload, not a key copied in.

Cloud workloads: call the secrets manager with the workload's own IAM role.
Vault: Vault Agent authenticates, renders secrets into templates and renews leases.
Doppler: doppler run injects secrets; production service tokens reach one config only.
1Password: service accounts reach chosen vaults, not a person's account.

Environment variables are convenient but leaky. OWASP notes they "may be included in logs or system dumps," and recommends them only when other methods are not possible.

Bots and keepers need the tightest scope. Each should read only its own secrets, unlike the wildcard role above.

Rotation, Revocation and Auditing

Rotate on a schedule. Automate it, as OWASP advises. AWS can rotate as often as every four hours.
Rotate without downtime. Doppler keeps two credentials and swaps them halfway through each interval.
Revoke first after a leak. OWASP: exposed keys "should undergo immediate revocation," then rotation.
Audit every read. Vault logs every request and response; AWS logs Secrets Manager calls to CloudTrail.
Protect the audit trail. Vault refuses a request if no audit device can record it.
Scan for leaks. Check commits, CI logs and images before they ship.
Offboard fast. Rotate every secret a departing engineer could read.

Signing Keys Are Different

A secrets manager hands the secret to your application. For a database password, that is the point. For a key that signs transactions, it is the risk.

Once a private key reaches application memory, whoever controls that process can copy it. A stolen signing key can move funds before any rotation runs.

AWS points the same way. Its Secrets Manager guide recommends AWS KMS for encryption keys, and in KMS the private key "never leaves AWS KMS unencrypted."

KMS supports secp256k1, which AWS says is "commonly used for cryptocurrencies." Vault's Transit engine offers cryptography as a service, but its key types do not include secp256k1.

So keep signing keys in an HSM, a KMS or an MPC system, and let apps request signatures, never keys. For the keeper key (M-08), Guardian recommended a KMS-wrapped signer.

A KMS still signs whatever an authorized caller sends, so limit who can call it. Our HSM vs KMS guide compares the options and approval policies.

Private key management for digital asset platforms covers tiers, limits and ceremonies.

Signing roles need least privilege too. In Guardian's Synthetix withdrawal flow review (H-14), one key held three roles, though the deployment config expected a 2-of-3 watcher quorum.

How Guardian Helps

Guardian's infrastructure pentest covers secrets handling: where keys and tokens live, who can read them, rotation, and what survives an employee leaving.

It also tests CI/CD runner permissions, and whether a compromised pipeline can ship or sign. Scope a whole cloud account, or narrow it to IAM and key management.

The OpSec audit maps keys, signers, privileged roles and the people around them.

With Managed Security, Sentry watches your cloud and code host, and new disclosures are matched against your stack as they land.

Frequently Asked Questions

What are secrets management best practices?

Centralize secrets in one system and give each service only what it needs. Prefer short-lived credentials, rotate on a schedule, revoke at once after a leak and audit every read. Keep signing keys in an HSM, KMS or MPC.

Should I use HashiCorp Vault or AWS Secrets Manager?

AWS Secrets Manager suits teams mostly on AWS: it uses IAM, KMS and CloudTrail and rotates on a schedule. Vault suits teams that need dynamic credentials, revocation by prefix or one audit trail across environments.

Should private keys go in a secrets manager?

Not keys that sign transactions. A secrets manager returns the key to your app, where it can be copied. Use an HSM, KMS or MPC system so apps request signatures and never hold the key.

Are .env files safe for secrets?

Only for local development with non-production values. Committed .env files leak, and OWASP notes environment variables can end up in logs or system dumps. Production secrets belong in a secrets manager, fetched at runtime.

Sources

Find out who can read your secrets

Guardian traces every key and token from laptop to production, and shows which ones lead to something that signs.

Talk to Guardian Explore Managed Security