How Should Crypto Wallet API Keys Be Stored and Rotated?

How should crypto wallet API keys be stored and rotated? For storage, keep keys out of code, config files, and images, and put them in a dedicated key management service or hardware security module that only authorized services can read at runtime. For rotation, replace keys on a regular schedule, and revoke and reissue them immediately when someone leaves, a server behaves abnormally, or a leak is suspected. Running old and new keys side by side for a short time lets you switch over without interrupting the business.

Where Should API Keys Not Be Stored?

Not in code or Git repositories, where they remain in the commit history even after being deleted. Not in container images or front-end code, where they are easy to extract once bundled. And not in plain text in server config files. Group chats, tickets, email, and shared documents are not places for keys either, since they lack strict access controls and are kept for a long time. These are exactly the most common channels through which API keys leak.

Where Should API Keys Be Stored?

A more reliable approach is to keep them in a dedicated key management service or hardware security module (HSM), where business services read them at runtime instead of having them hardcoded into any file. Access should be scoped to specific services and servers: engineers use only test-environment keys for day-to-day development, and production keys can be read only by production services. Every read should be logged, and keys should be filtered out of logs and error messages. Each key should also be registered with its purpose, permissions, and owner, so you know which systems will be affected when it is rotated or revoked.

How Often Should API Keys Be Rotated, and When Must They Be Rotated Immediately?

There is no single standard, but keys that can move funds should be rotated more often than read-only keys, and many businesses rotate them quarterly or every six months as part of their security policy. Event-driven rotation matters even more than the schedule. When an employee or contractor who had access to a key leaves, when a server or developer laptop behaves abnormally, when a key is found in code, logs, or chats, or when monitoring spots unusual calls, revoke and regenerate the key immediately rather than waiting to confirm a leak. Keys that are no longer used should be deactivated promptly.

How Can You Rotate API Keys Without Disrupting the Business?

The common approach is to run old and new keys side by side for a short time. Generate a new key with the same permissions, update it in the key management service, and let each service switch over gradually. Once you confirm the old key is no longer receiving calls, revoke it. If services read keys dynamically from the key management service, switching does not require redeploying code, and rotation becomes routine. Rotation itself should also be controlled: generating and revoking keys that can move funds should ideally require multi-party confirmation and leave a record. The key’s own permissions should still be backstopped by a policy engine, so that even if a key leaks before it is rotated, limits and approvals can still stop large transfers.

Conclusion

API keys should live in a key management service or HSM and be read dynamically by services, rotated regularly, revoked immediately when people change roles or something looks wrong, and switched over smoothly by running old and new keys side by side. Safeheron’s MPC Wallet-as-a-Service provides MPC key management and a policy engine for businesses.

Want to set up API key management standards for your team? Contact Safeheron’s Sales Team to Book a 1:1 Demo