Best Ways to Store Private Keys: Crypto, SSH, TLS, and Business Keys

There is no single best place to store every private key. The right choice depends on what the key does, whether software must use it continuously, whether it can remain non-exportable, and whether losing it would be worse than creating another backup copy.

As a general rule, keep an online service’s key inside a hardware-backed HSM or suitable KMS whenever the service can sign or decrypt without receiving the raw key. Use a hardware security key for a person’s high-value authentication key, a platform keystore for mobile applications, an encrypted PKCS#8 file inside a secrets-management system when export is unavoidable, and durable offline backups for cryptocurrency recovery phrases and other cold-storage secrets.

#	Preview	Product	Price
1		Yubico - Security Key C NFC - Basic Compatibility - Multi-Factor authentication (MFA) Security Key...	$29.00	Buy on Amazon
2		Yubico - YubiKey 5 NFC - Multi-Factor authentication (MFA) Security Key and passkey, Connect via...	$58.00	Buy on Amazon
3		Yubico - Security Key NFC - Basic Compatibility - Multi-Factor Authentication (MFA) Key, Connect via...	$29.00	Buy on Amazon
4		FIDO2 U2F Security Key Passkey Two-Factor Authentication (2FA) USB Key PIN+Touch (Non-Biometric)...	$18.00	Buy on Amazon
5		Symantec VIP Hardware Authenticator - K10S - Two Factor Authentication Security Key - Fits USB-A -...	$18.50	Buy on Amazon

Quick answer: choose storage by key type

Storage is not merely a question of keeping a secret out of sight. Good key management must protect confidentiality, integrity, and availability at the same time. NIST SP 800-57 recommends protecting stored key information from disclosure and modification, keeping it correctly associated with its application, and planning for recovery when long-term availability matters.

First identify what kind of key you have

“Private key” describes the secret part of an asymmetric cryptographic key pair, but the storage decision changes substantially depending on its purpose.

#1 Best Overall

Yubico - Security Key C NFC - Basic Compatibility - Multi-Factor authentication (MFA) Security Key and passkey, Connect via USB-C or NFC, FIDO Certified

• POWERFUL SECURITY KEY: The Security Key C NFC is the essential physical passkey for protecting your digital life from phishing attacks. It ensures only you can access your accounts.
• WORKS WITH 1000+ ACCOUNTS: Compatible with Google, Microsoft, and Apple. A single Security Key C NFC secures 100 of your favorite accounts, including email, password managers, and more.
• FAST & CONVENIENT LOGIN: Plug in your Security Key C NFC via USB-C and tap it, or tap it against your phone (NFC) to authenticate. No batteries, no internet connection, and no extra fees required.
• TRUSTED PASSKEY TECHNOLOGY: Uses the latest passkey standards (FIDO2/WebAuthn & FIDO U2F) but does not support One-Time Passwords. For complex needs, check out the YubiKey 5 Series.
• BUILT TO LAST: Made from tough, waterproof, and crush-resistant materials. Manufactured in Sweden and programmed in the USA with the highest security standards.

$29.00

Buy on Amazon

• Cryptocurrency wallet key or recovery phrase: controls the ability to authorize transactions. A recovery phrase is usually a human-readable backup representation from which wallet keys can be derived; it is not necessarily the raw private key.
• SSH key: authenticates a person or automated process to a server. It may be stored in a hardware authenticator or as an encrypted file.
• TLS certificate private key: is used with a certificate to authenticate a server and sign parts of a secure connection. The certificate itself is not secret; the private key is.
• Code-signing key: signs software or updates. Confidentiality and strict authorization matter because a stolen key may allow fraudulent software to appear authentic.
• PGP or S/MIME key: may sign messages, decrypt messages, or both. Backup requirements differ depending on whether the key is used for signatures or encryption.
• Application or database encryption key: protects data or wraps other keys. Losing it can make data permanently unrecoverable, so controlled backup is often essential.
• Mobile-device key: may be created and used inside Android Keystore or Apple’s Secure Enclave and may never be exportable.
• Root, recovery, or disaster-recovery key: is intentionally used rarely and needs carefully documented offline storage and recovery procedures.

Do not confuse these related terms

Public key

The distributable half of an asymmetric pair. It is normally safe to publish, although its association with an identity still needs to be verified.

Certificate

A signed statement binding an identity to a public key. It does not replace or contain the usable private key.

Secret or symmetric key

A shared key used by multiple parties or systems for encryption, authentication, or other cryptographic operations.

Key-encryption key

A key used to encrypt or “wrap” other keys. Separating it from the data and keys it protects can limit the impact of a storage breach.

Password or passphrase

Human-provided information used to unlock a container or derive a key. It is not automatically the cryptographic key itself.

Google’s Cloud KMS documentation similarly distinguishes the public and private portions of an asymmetric key pair and identifies the private portion as sensitive because it is needed for signing or decryption.

The decision tree

1. Must the key be used continuously by software?
   If yes, an offline backup cannot be the operational copy. Look first for an HSM, KMS, platform keystore, or hardware-backed signing service.
2. Can the software call a cryptographic operation without receiving the raw key?
   If yes, prefer that design. A sign, decrypt, or wrap/unwrap API reduces exposure from files, source control, backups, and accidental logging.
3. Must the key be exportable or portable?
   If export is unavoidable, use an encrypted PKCS#8 or vendor-specific protected container and place it in a dedicated secrets-management system.
4. What does the key do?
   Signing keys, authentication keys, encryption keys, and ephemeral key-agreement keys have different backup and replacement requirements.
5. Can it be regenerated?
   A device identity key may be recreated through re-enrollment. A wallet recovery phrase or encryption key may be irreplaceable.
6. What is the availability requirement?
   An online payment service may need high availability. A cryptocurrency savings wallet or offline root key may intentionally remain inaccessible most of the time.
7. Is human approval or dual control required?
   For valuable organizational signing, certificate-authority, treasury, or recovery operations, consider multiple-person approval, split knowledge, or threshold custody.

Storage methods compared

1. HSM or managed KMS: best for online business systems

An HSM is specialized hardware designed to generate, protect, and use cryptographic keys. A KMS provides key lifecycle and access-control functions through an API; depending on the service and protection level, it may use software protection, an HSM, a dedicated HSM, or an external key manager.

For a high-value online system, the preferred architecture is usually:

1. Generate the key inside the HSM or KMS where possible.
2. Keep the private key non-exportable.
3. Give the application permission to request only the required operation, such as signing or decryption.
4. Do not return the private key to the application, deployment server, or administrator workstation.
5. Log administrative actions and cryptographic operations.

AWS states that asymmetric KMS private keys are created in AWS KMS and do not leave the service unencrypted, while plaintext key material remains inside the HSM security boundary. AWS’s asymmetric-key documentation and its data-protection documentation describe those service-specific controls.

Protection levels differ between providers. Google Cloud documents software, multi-tenant HSM, single-tenant HSM, and external-key protection levels in its KMS protection-level guidance. Azure describes HSM-protected keys as remaining within the HSM boundary and not being exportable as plaintext in its HSM-protected BYOK documentation. These are provider- and key-type-specific statements, not a guarantee that every product called “KMS” or “HSM” offers identical protection.

Controls that matter more than the product name

• Use the narrowest permitted operation: signing-only, decrypt-only, or wrap/unwrap-only.
• Separate key administrators from key users.
• Require phishing-resistant MFA for administrators and, for critical operations, more than one authorized person.
• Use aliases or version identifiers rather than embedding key material in application configuration.
• Monitor unusual signing volume, decryption volume, locations, and callers.
• Test key disabling, rotation, failover, re-enrollment, and recovery before production.
• Document what happens if the cloud account, region, provider, network, or external key manager becomes unavailable.

An HSM or KMS does not make a system invulnerable. An attacker who compromises an authorized workload may still request signatures or decrypt data. An administrator may accidentally disable or destroy a key. External-key designs can create additional availability and latency dependencies; Google discusses those risks in its external key-management architecture guidance.

FIPS qualification is precise, not a marketing label

If a contract or regulation requires FIPS validation, verify the exact cryptographic module, certificate number, security policy, algorithm coverage, and operating mode in the NIST CMVP validated-modules database. A product is not FIPS-validated merely because it uses approved algorithms or offers a setting called “FIPS mode.” FIPS 140-3 is a validation standard for cryptographic modules, not a universal ranking of security products.

For organizations subject to U.S. or Canadian federal validation requirements, NIST’s CMVP status information says FIPS 140-2 validations remain on the active list through September 21, 2026, and move to the Historical list after September 22, 2026, while FIPS 140-3 remains the current validation path. That transition does not make FIPS a universal requirement for personal or commercial users.

2. Hardware security keys and smart cards for people

A hardware security key is often the best choice for a human administrator who needs SSH, PIV, OpenPGP, S/MIME, or manual code-signing authentication. The device can keep the private component inside its protected hardware and require a PIN, touch, or other user action.

FIDO-backed SSH

OpenSSH supports FIDO authenticator-backed key types including ed25519-sk and ecdsa-sk. The file on the computer contains information associated with the credential, but the device-specific private component is not exportable from the authenticator. On a compatible system and security key:

ssh-keygen -t ed25519-sk -C '[email protected]'

If the authenticator does not support that algorithm:

ssh-keygen -t ecdsa-sk -C '[email protected]'

GitHub’s hardware-security-key SSH instructions document this approach. The exact behavior depends on the OpenSSH version, operating system, authenticator, and whether the credential is resident or non-resident.

• A non-resident credential generally requires the original authenticator and its key-handle file.
• A resident or discoverable credential can be loaded from the authenticator, but storing more credential information on the device may increase the consequences of device theft.
• A key generated inside a token is generally non-exportable. Losing the token may therefore mean losing the private key.
• Enroll at least one replacement authenticator before the first device fails. For critical access, keep the replacement under separate control rather than beside the primary device.
• Do not assume a FIDO login credential is a general-purpose backup container. PIV, OpenPGP, and FIDO applications have different import, backup, and algorithm rules.

Yubico’s PIV key-generation guidance explains the important distinction between generating a key directly on a YubiKey, which makes it non-exportable, and importing a key, which can be appropriate when a controlled backup is required.

Encrypted SSH keys on disk

If a hardware authenticator is not practical, use an encrypted Ed25519 SSH key with a strong passphrase. Load it only when needed:

Rank #2

Yubico - YubiKey 5 NFC - Multi-Factor authentication (MFA) Security Key and passkey, Connect via USB-A or NFC, FIDO Certified - Protect Your Online Accounts

• POWERFUL SECURITY KEY: The YubiKey 5 NFC is the most versatile physical passkey, protecting your digital life from phishing attacks. It ensures only you can access your accounts
• WORKS WITH 1000+ ACCOUNTS: Compatible with popular accounts like Google, Microsoft, and Apple. A single YubiKey 5 NFC secures 100+ of your favorite accounts, including email, password managers, and more
• FAST & CONVENIENT LOGIN: Plug in your YubiKey 5 NFC via USB and tap it, or tap it against your phone (NFC), to authenticate. No batteries, no internet connection, and no extra fees required
• MOST SECURE PASSKEY: Supports FIDO2/WebAuthn, FIDO U2F, Yubico OTP, OATH-TOTP/HOTP, Smart card (PIV), and OpenPGP. That means it’s versatile, working almost anywhere you need it
• PRIMARY & SPARE KEYS: Just like having a spare house key, we recommend buying two YubiKeys - one for daily use and one as a spare. That way you’ll never get locked out of your accounts

$58.00

Buy on Amazon

ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519
eval "$(ssh-agent -s)"
ssh-add -t 1h ~/.ssh/id_ed25519

Store the file in the user’s protected SSH directory and restrict access. An agent reduces repeated exposure of the encrypted file, but it is not an HSM. The agent socket is accessible to the current user and may be abused by root or another process running as that user. Agent forwarding also deserves careful threat modeling because a remote host may be able to request signatures through the forwarded agent. The OpenSSH agent documentation describes these behaviors.

Maintain a separate SSH recovery plan: record which servers trust the key, keep a second authentication method, and know how to remove the old public key from authorized_keys if the private key is exposed.

3. Android Keystore and Apple Secure Enclave for mobile apps

Mobile applications should not store private keys in ordinary application files, preferences, source code, or bundled resources when the platform offers a secure keystore.

Android Keystore keeps key material non-exportable after insertion and can apply restrictions such as permitted uses and user authentication. Where supported by the device, keys can be bound to secure hardware such as a Trusted Execution Environment or Secure Element.

Apple’s Secure Enclave can create and use certain private keys without the application handling the plaintext key. Secure Enclave keys are device-specific and support a limited set of operations, including signatures and elliptic-curve Diffie-Hellman.

Before choosing a device-bound key, developers should answer:

• Can the key be regenerated through account re-enrollment?
• Does a user need to approve every operation, or only unlock the device?
• Is the key allowed to leave the device?
• What happens after uninstall, factory reset, device migration, or hardware replacement?
• Is it used for authentication, signing, encryption, or local data protection?
• Does the application still have permission to request harmful operations if the application itself is compromised?

Secure hardware improves extraction resistance, but it does not automatically solve availability. Build replacement and re-enrollment into the product before deploying a non-exportable key.

4. Encrypted PKCS#8 files when export is unavoidable

Some web servers, SSH clients, certificate tools, PGP applications, and smaller deployments require a private-key file. In that case, use an encrypted PKCS#8 EncryptedPrivateKeyInfo container rather than an unencrypted PEM file.

For example, OpenSSL documents openssl pkcs8 for encrypted PKCS#8 output. This example uses scrypt-based protection and restrictive file permissions:

umask 077

openssl pkcs8 
  -topk8 
  -scrypt 
  -in private-key.pem 
  -out private-key.p8

chmod 600 private-key.p8

Check that the encrypted key can be opened and validated:

openssl pkey -in private-key.p8 -check -noout

Extract only the public key when a tool needs it:

openssl pkey 
  -in private-key.p8 
  -pubout 
  -out public-key.pem

See the OpenSSL PKCS#8 documentation for the format and options. Use an interactive passphrase prompt rather than placing the passphrase in shell history or a command-line argument.

Rules for encrypted key files

• Keep the encrypted key in a dedicated secrets manager or protected file store, not in source control.
• Store the passphrase or key-encryption key through a separate control path. A ciphertext file and its unlocking secret in the same directory are not a meaningful backup separation.
• Restrict ownership and permissions. On Unix-like systems, a key file commonly needs to be readable only by the service account that uses it.
• Do not log the key, passphrase, decrypted output, or command-line arguments.
• Do not place the key in an image layer, deployment artifact, public bucket, shared drive, or broad-access backup.
• Test restoration on a clean, isolated system and verify the recovered public-key fingerprint.
• If either the plaintext key or its passphrase may have been exposed, replace the key rather than relying on re-encryption alone.

Encryption protects the file only while the unlocking secret remains protected. OWASP’s cryptographic-storage guidance warns against hard-coded keys and discusses key separation, configuration-file exposure, and the limitations of environment variables. Environment variables can leak through process inspection, /proc, crash reports, child processes, container inspection, CI logs, or diagnostic output.

5. Secrets managers and password managers are not the same as HSMs

Secrets manager

A secrets manager is usually the right place to control delivery of exportable application secrets. It can provide centralized permissions, versioning, audit logs, rotation workflows, and runtime retrieval or injection.

Rank #3

Yubico - Security Key NFC - Basic Compatibility - Multi-Factor Authentication (MFA) Key, Connect via USB-A or NFC, FIDO Certified

• POWERFUL SECURITY KEY: The Security Key NFC is the essential physical passkey for protecting your digital life from phishing attacks. It ensures only you can access your accounts.
• WORKS WITH 1000+ ACCOUNTS: Compatible with Google, Microsoft, and Apple. A single Security Key NFC secures 100 of your favorite accounts, including email, password managers, and more.
• FAST & CONVENIENT LOGIN: Plug in your Security Key NFC via USB-A and tap it, or tap it against your phone (NFC) to authenticate. No batteries, no internet connection, and no extra fees required.
• TRUSTED PASSKEY TECHNOLOGY: Uses the latest passkey standards (FIDO2/WebAuthn & FIDO U2F) but does not support One-Time Passwords. For complex needs, check out the YubiKey 5 Series.
• BUILT TO LAST: Made from tough, waterproof, and crush-resistant materials. Manufactured in Sweden and programmed in the USA with the highest security standards.

$29.00

Buy on Amazon

But a secrets manager often decrypts the secret and returns it to the application. A KMS or HSM may instead perform the signature or decryption operation without returning the private key. The distinction is:

• Secret storage: protects a value at rest and releases it to an authorized consumer.
• Non-exportable key operation: lets an authorized consumer ask for signing, decryption, or key wrapping while the raw key remains inside the protected module.

OWASP’s secrets-management guidance notes that server-side encryption protects a secret at rest but generally decrypts it before sharing it with its intended consumer. Client-side encryption can keep it encrypted until the consumer decrypts it, but that consumer still needs access to the decryption capability.

For each secret, record its purpose, owner, consumers, creation date, rotation history, identifier, expiration, dependencies, and emergency contact. OWASP recommends this kind of secret inventory and operational documentation.

Password manager

A password manager can be reasonable for a low- or medium-risk exportable private key when the vault is strongly encrypted, the account uses phishing-resistant MFA, the key is not the sole recovery copy, and the export or recovery process has been tested.

It is not equivalent to an HSM. An authorized user or a compromised endpoint with access to the vault may be able to retrieve the plaintext key. Avoid automatically syncing especially sensitive keys to every personal device, and do not treat a password manager as the only backup for an irreplaceable recovery secret.

6. TLS and certificate private keys

For an ordinary small website, an encrypted private-key file with restrictive permissions may be workable if the web server requires a file. For a high-value service, certificate authority, payment system, identity provider, or large-scale TLS termination platform, prefer an HSM or managed private-key operation when the software supports it.

Keep the certificate chain, key identifier, renewal instructions, DNS or load-balancer dependencies, and emergency replacement procedure with the operational documentation. The certificate is public, but the private key must receive stronger protection.

When a server requires a file, use encrypted PKCS#8, a restricted mount path, a dedicated service account, and a secrets manager or controlled deployment process. Remember that the server generally decrypts the key during startup or operation, so host compromise can still expose it in memory or abuse its signing capability.

For certificate renewal, test the complete process before the existing certificate expires. If a private key is exposed, revoke or replace the certificate where applicable, generate a new key, update every dependent system, and review logs for unauthorized use.

7. Code-signing, PGP, and S/MIME keys

Code-signing keys deserve stronger controls than ordinary deployment secrets because a stolen key can make malicious software appear to come from a trusted publisher. Prefer a non-exportable HSM, hardware token, or controlled signing service. Separate build systems from signing authorization, require approval for production releases, log every signing operation, and restrict what identity or artifact can be signed.

Where possible, use short-lived or delegated signing identities rather than exposing a long-lived root signing key to a CI/CD runner. A reproducible build and independent signature verification process can reduce the damage from a compromised build host, but neither replaces protection of the signing key.

PGP and S/MIME keys often need portability, so an encrypted portable container and a carefully controlled backup may be necessary. Separate keys used for signing from keys used for decryption where the software and policy allow it. Losing an encryption key may make historical messages unreadable; losing a signing key may be preferable to backing up many copies if preserving non-repudiation is the priority.

8. Cryptocurrency wallets and recovery phrases

For substantial cryptocurrency holdings, use a reputable hardware wallet or dedicated signing device, keep the recovery phrase offline, and verify transaction details on the device’s trusted display. A hardware wallet is generally strong against remote theft in a self-custody setup, but it is not the universally best storage method for TLS, SSH, mobile, or enterprise keys.

Rank #4

FIDO2 U2F Security Key Passkey Two-Factor Authentication (2FA) USB Key PIN+Touch (Non-Biometric) USB-A Type TrustKey T110

• Security Key : Protect your online accounts against unauthorized access by using FIDO2 and U2F authentication with T110. It's the world's most protective security key that works with windows, Mac OS, Linux as well as Chrome, Firefox, Edge and many other major browsers.
• Certified with the new FIDO2 standard, T110 provides the benefit of fast login and strong protection against phishing, account takeover as well as many other online attactks.
• Works with : Bank of America, Github, Google, Microsoft, DUO, Twitter, Facebook, Dropbox, Apple, ebay, BINANCE, mor and more.
• Fits USB-A port : Insert the T110 security key into the USB-A port of each service and log in conveniently with one touch
• For the driver download and user guide, please visit TrustKey Solutions Home support page.

$18.00

Buy on Amazon

Recommended cold-storage process

1. Initialize the wallet on the device itself and follow its recovery procedure.
2. Write the recovery phrase accurately on durable material. Do not photograph, scan, email, text, or place it in cloud notes.
3. Store carefully controlled copies in separate physical locations. A second location improves survival after fire, flood, or theft at the first location, but each additional copy is another opportunity for unauthorized viewing.
4. Verify the receiving address and transaction details on the wallet’s trusted display before approving a transaction.
5. Perform a small recovery test before depositing significant value. Verify the derived addresses, not merely that a device accepts the words.
6. Document how a trusted person could recover the wallet without placing the phrase in an online document.
7. For very high values, consider multisignature custody or threshold backup rather than one phrase in one location.

Ethereum.org’s security guidance describes a recovery phrase as the master key to a wallet, warns that screenshots can synchronize to cloud storage, and recommends hardware wallets for offline private-key protection. Bitcoin.org’s wallet-security guidance also recommends offline wallets for savings and emphasizes backups and encryption.

BIP-39 phrases and optional passphrases

BIP-39 defines mnemonic sentences generated from 128 to 256 bits of entropy and derives a 512-bit seed using PBKDF2-HMAC-SHA512 with 2,048 iterations. It also supports an optional passphrase.

Do not assume every blockchain or wallet uses BIP-39. A phrase may generate many accounts, so exposing it may compromise more than the address currently visible. The optional passphrase is not a replacement for the recovery phrase: every different passphrase creates a different derived wallet. A forgotten or mistyped passphrase can produce a valid but apparently empty wallet. Use one only if it can be documented and recovered reliably.

Never type a recovery phrase into a website, “wallet sync” page, support form, or internet-connected computer merely to verify it. Recovery should happen through a trusted wallet or an appropriately isolated recovery environment, followed by address and balance verification.

Paper, metal, Shamir, and multisignature choices

Paper can be adequate for a modest-risk backup if it is protected from viewing, duplicated accurately, and replaced when damaged. Metal is preferable when resistance to fire, water, and long-term deterioration matters. Neither medium protects against a person who sees or photographs the words; they solve durability, not secrecy.

SLIP-39 describes a Shamir secret-sharing scheme in which a threshold number of shares is needed to reconstruct a secret. It is not automatically compatible with BIP-39 and requires compatible tools. Before using it, decide who holds each share, what happens if a custodian dies, how shares will be verified, what software will reconstruct them years later, and whether the threshold is too low for collusion or too high for recovery failure.

Shamir-style backup splits one recovery secret. Multisignature custody is different: it requires multiple independent signing keys to authorize an on-chain transaction. Either can be useful, but additional complexity is safe only when the recovery process has been practiced.

Backup is not automatically correct for every private key

The right backup policy depends on the key’s purpose. NIST’s key-management guidance distinguishes among key types:

• Private signature keys: backup is generally discouraged because additional recoverable copies can undermine non-repudiation. A certificate-authority signing key can be an important exception.
• Private authentication keys: backup may be appropriate when timely replacement is difficult, provided the backup is strongly protected.
• Data-encryption keys: backup is usually important because losing them can make protected data permanently unrecoverable.
• Ephemeral key-agreement keys: generally should not be backed up; generate new material instead.
• Metadata and recovery information: preserve key identifiers, owners, algorithms, dependencies, certificates, and recovery instructions for as long as they are needed.

Do not confuse an operational copy with a recovery copy. The operational key may be available to a live service, while the recovery copy should be under a separate control path. Storing an encryption key beside the data it protects defeats much of the benefit of separating them. Use envelope encryption, a separate key-encryption key, or an HSM/KMS; see OWASP’s key-separation guidance.

Rotation does not erase the past

Rotating a key limits future use, but it does not undo transactions, invalidate every artifact already signed, or automatically re-encrypt data protected by an older key. Some encrypted data still needs an older key version for decryption. Google’s CMEK best practices and key-destruction guidance warn that destroying a required key version can make associated data permanently undecryptable.

Before disabling or destroying a key, identify every dependent certificate, backup, database, archive, application, and recovery procedure. Preserve old encryption keys when policy requires continued access; do not preserve compromised signing keys merely for convenience.

Recovery testing: the step most people skip

A backup that has never been restored is an assumption, not a recovery plan. Test on an isolated system or spare device and verify the expected public key, fingerprint, wallet address, or certificate identity.

Check for:

• The correct file format and algorithm
• The correct passphrase or key-encryption key
• Required certificate chains and metadata
• Compatible replacement hardware or software
• Correct wallet derivation path and addresses
• Permissions and service-account access
• Provider, account, region, and network dependencies
• The ability to revoke the old key and deploy the replacement

For an HSM/KMS key, recovery may mean restoring access to the account or a second protected module rather than exporting the key. For a non-exportable phone or security-key credential, recovery may mean re-enrolling a replacement device. For an encryption key, recovery may require preserving the exact old version rather than simply generating a new one.

Best Value

Symantec VIP Hardware Authenticator - K10S - Two Factor Authentication Security Key - Fits USB-A - FIDO U2F Certified

• Standard OATH compliant HOTP (event-based). The HOTP function is to be used with Symantec VIP Access.
• Generates a 6-digit HOTP code with one tap of the touch button
• FIDO U2F support with Symantec VIP attestation certificate
• Zero footprint: no need for the end user to install any software
• Micro-sized, secure, sturdy, and long-life hardware design

$18.50

Buy on Amazon

What not to do

• Do not commit a private key to Git. Treat it as compromised even if the file is deleted in a later commit. Removing a file does not remove it from repository history or prevent exploitation. GitHub’s secret-scanning documentation and leaked-secret remediation guidance recommend rotating or revoking first, then cleaning the repository history.
• Do not store a key and the data it protects in the same place. A stolen disk, bucket, or backup may then contain both halves of the problem.
• Do not call ssh-agent a vault or HSM. It holds usable keys for the current user and can be abused by sufficiently privileged processes.
• Do not treat “offline” as automatically safest. Offline storage reduces remote attack exposure but adds physical loss, damage, transcription, and availability risks.
• Do not put a recovery phrase in a screenshot, cloud note, email, password-reset form, or support chat.
• Do not rely on environment variables by default. They can leak through process listings, crash reports, CI logs, child processes, and container inspection.
• Do not assume a cloud KMS cannot be misused. It protects key material, but an attacker with permission may still invoke permitted operations.
• Do not use “FIPS” as a synonym for secure. Verify the exact validated module and operating mode when that requirement applies.

What to do if a private key is exposed

Act quickly. If the plaintext key, recovery phrase, unencrypted backup, or unlocking passphrase may have been exposed, treat the key as compromised.

1. Revoke or disable it where the system supports revocation or immediate disablement.
2. Generate new key material using a trusted and preferably hardware-backed method.
3. Replace dependent credentials and identities: certificates, SSH authorized keys, signing identities, tokens, application configuration, and wallet destinations where applicable.
4. Re-encrypt or re-sign affected material when the key protected data or authenticated releases.
5. Review logs for unauthorized signatures, decryptions, logins, transactions, or administrative changes.
6. Search every copy in repositories, backups, build artifacts, CI logs, crash reports, email, cloud storage, deployment images, and personal devices.
7. Destroy obsolete copies after confirming that the replacement and recovery path work.
8. Record the incident in the key inventory and update the procedure that allowed the exposure.

NIST advises that when the confidentiality of an asymmetric key becomes suspect, the key pair should transition to a compromised state and entirely new keying material should be used. Rotation limits future harm; it cannot reverse signatures, transactions, or data already exposed.

Practical recommendations by reader type

Individual cryptocurrency holder

Use a hardware wallet for meaningful savings, keep the recovery phrase offline on durable material, store controlled copies in separate locations, and test recovery before depositing substantial value. Consider multisignature or threshold custody only if you can maintain the additional documentation and recovery complexity.

Developer or system administrator

Use a FIDO-backed SSH key for privileged human access when compatible. Otherwise use an encrypted Ed25519 key with a passphrase, a limited-duration agent load, a separate recovery method, and a documented revocation process. Never commit the key to source control.

Small business operating a website

Use the certificate provider’s protected key-generation or managed private-key option when available. If the web server requires a file, use encrypted PKCS#8, restrictive permissions, a secrets manager, tested renewal, and a separate emergency replacement procedure.

Cloud-native application

Use KMS or HSM-backed operations when the application can sign or decrypt through an API. If the application must receive a secret, use a secrets manager, narrow workload identity, audit logs, rotation, and a recovery plan. Do not assume a secret manager provides the same isolation as a non-exportable HSM key.

Software publisher or certificate authority

Keep the highest-value signing keys non-exportable where possible. Use approval workflows, separation of duties, protected audit logs, controlled ceremonies, and a carefully considered backup policy. NIST’s caution against routinely backing up signature keys is especially relevant, although a CA recovery design may justify an exception.

Personal-finance or security-conscious organization

Maintain an inventory containing each key’s owner, purpose, algorithm, identifier, creation date, expiration, dependencies, backup location, recovery instructions, and revocation method. Review who can use and administer the key, test recovery, and remove obsolete copies after successful rotation.

Frequently Asked Questions

Is a password manager safe for storing a private key?

It can be reasonable for a low- or medium-risk exportable key if the vault is strongly encrypted, protected with phishing-resistant MFA, and backed by a tested recovery process. It is not equivalent to an HSM: an authorized user or compromised endpoint may still retrieve the plaintext key. Do not use it as the only copy of an irreplaceable recovery phrase or high-value signing key.

Should a cryptocurrency recovery phrase be stored on paper or metal?

Paper can be adequate when protected from theft, moisture, fire, and unauthorized viewing. Metal offers better resistance to fire and water, but neither medium prevents theft or photography. The best choice is durable offline storage, carefully controlled physical access, separate locations where justified, and a tested recovery procedure.

Should every private key be backed up?

No. Data-encryption keys often need backup because losing them can make data unrecoverable. Authentication keys may need backup when replacement is difficult. Private signing keys are generally not backed up when doing so would undermine non-repudiation, although controlled exceptions such as certificate-authority keys exist. Ephemeral key-agreement keys generally should be regenerated instead.

What is the difference between a secrets manager and a KMS?

A secrets manager commonly stores an encrypted value and returns it to an authorized application. A KMS or HSM can often perform signing, decryption, or key-wrapping operations without returning the raw private key. A secrets manager is useful for exportable secrets; a non-exportable KMS or HSM key is usually stronger when the application supports cryptographic APIs.

What should I do if I accidentally committed a private key to Git?

Treat the key as compromised immediately. Revoke or disable it, generate a replacement, update every dependent system, and review logs. Only after replacement should you clean the repository history and search branches, forks, build artifacts, backups, and CI logs for copies. Deleting the latest file or adding it to .gitignore does not remove the old secret from history.

The Bottom Line

The best private-key storage method is the one that matches the key’s job and its recovery requirements. Keep active business keys non-exportable in an HSM or suitable KMS when possible; use hardware-backed authentication for people and platform keystores for mobile apps; use encrypted PKCS#8 plus controlled secret storage when portability is unavoidable; and keep cryptocurrency recovery phrases and offline roots in durable, offline, geographically considered backups. Always protect confidentiality, integrity, and availability separately—and test recovery before the key is needed.

Quick Recap

Bestseller No. 1

Yubico - Security Key C NFC - Basic Compatibility - Multi-Factor authentication (MFA) Security Key and passkey, Connect via USB-C or NFC, FIDO Certified

$29.00

Bestseller No. 2

Yubico - YubiKey 5 NFC - Multi-Factor authentication (MFA) Security Key and passkey, Connect via USB-A or NFC, FIDO Certified - Protect Your Online Accounts

$58.00

Bestseller No. 3

Yubico - Security Key NFC - Basic Compatibility - Multi-Factor Authentication (MFA) Key, Connect via USB-A or NFC, FIDO Certified

$29.00

Bestseller No. 4

FIDO2 U2F Security Key Passkey Two-Factor Authentication (2FA) USB Key PIN+Touch (Non-Biometric) USB-A Type TrustKey T110

For the driver download and user guide, please visit TrustKey Solutions Home support page.

$18.00

Bestseller No. 5

Symantec VIP Hardware Authenticator - K10S - Two Factor Authentication Security Key - Fits USB-A - FIDO U2F Certified

Generates a 6-digit HOTP code with one tap of the touch button; FIDO U2F support with Symantec VIP attestation certificate

$18.50

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.