Offline Storage for Signing Keys, Recovery Codes and Security Keys

Keep anything that nobody can reissue offline, in at least two physically separate places. That covers release and app signing keys, OpenPGP primary keys, recovery codes for code hosts and package registries, and a spare hardware security key for every account. Put the root key offline, do daily work with subkeys, and test the kit every year. Then a lost laptop or a dead phone costs you a day of work, not your project.

Some accounts and keys come back after a password reset. Others are gone for good, and the platforms say so in their own documentation. This post covers which is which and how to keep an offline copy that is safe and actually works, using NIST SP 800-57 Part 1 Rev. 5 (key management), NIST SP 800-63B-4 (authentication and recovery) and each platform's own docs.

Key takeaways

• Sort before you store. Separate what can be reissued (passwords, most tokens) from what cannot (self held app signing keys, pinned release roots, recovery codes).
• Root offline, subkeys online. The long lived key does almost nothing, so it can live on encrypted media in a drawer.
• Two of everything, in two places. NIST's archive guidance asks for multiple copies in physically separate locations. Platforms that support security keys either require two (Apple requires at least two) or warn that losing your only factor can lock you out permanently.
• Recovery codes are meant to be offline. SP 800-63B-4 describes saved recovery codes as something "maintained offline (e.g., printed or written down)".
• Private signing keys are a special case. SP 800-57 says private signature keys are generally not backed up, with exceptions such as a certificate authority's signing key. A release root key users pin behaves like that exception; a short lived subkey does not.
• Test without exposing. Sign a throwaway file on an offline machine and verify it, every year.
• Plan the rotation before you need it. Keep a revocation certificate with the root, know your platform's upload key reset path, and know which keys you cannot rotate at all.

Which keys and codes are unrecoverable if you lose them?

"Unrecoverable" has a precise meaning here: no support team, password reset or identity check can give it back. The platform either never held a copy by design, or holds one but has decided not to override two factor authentication on request.

Here is how the common items sort out, based on each platform's own documentation.

Passwords and most API tokens are missing on purpose: if you can still prove who you are, you can rotate them. The offline kit is only for things at the root of trust with no reset button.

What does SP 800-57 say about key backup and archival?

NIST SP 800-57 Part 1 Rev. 5, published in May 2020, is the general key management recommendation. Three parts of it shape everything else in this post.

Backup is for continuity, and not every key should be backed up

Section 8.2.2 frames backup as continuity of operations: keys get lost to hardware damage, corrupted files or configuration changes. It then adds an important counterweight. If you can keep operating without a backup, for example by issuing a new key, it "may be preferable not to save" the keying material, because every extra copy is another place it can leak.

Table 7 in Section 8.2.2.1 applies that idea to each key type. For a private signature key the answer is "No (in general)", because a backed up signing key weakens non repudiation: if copies exist, it is harder to argue that only the owner could have signed. The same row immediately allows an exception: backup "may be warranted in some cases, such as a CA's private signing key", and any backed up copy "shall be stored under the owner's control". Public signature verification keys are fine to back up, and private authentication keys are fine if an application needs it.

For a maintainer, your release root key is your project's private certificate authority, so back it up under your own control. Your daily signing subkey is the "in general, no" case: if you lose it, revoke it and make a new one from the root.

Archive means separate copies in separate places

Section 8.3.1 covers key archives, which keep key information for recovery beyond a key's cryptoperiod. NIST says archived key information shall be stored separately from operational data and that "multiple copies of archived key information should be provided in physically separate locations". It also says the archive must be maintained by a trusted party and protected with strong access control. Two encrypted USB drives in the same desk drawer do not meet the spirit of that sentence. One at home and one in a bank deposit box or a trusted colleague's safe does.

Cryptoperiods are finite

Section 5.3.6 recommends a maximum cryptoperiod of about one to three years for a private signature key and says it shall be destroyed at the end of that period. Long lived release roots often stretch this in practice. The practical lesson is to design for rotation from day one: subkeys that expire, a root you can retire, and a documented handover to the next key.

Key recovery needs a written plan

Section 9.5.2 lists the questions a key recovery plan must answer: what gets backed up, where, who protects it, who can request recovery, who is notified, and how you prove only authorized people got access. They work for a three person project as well as for an agency. Write the answers down and keep that page with the kit.

What is an offline root key and why do releases use subkeys?

An offline root key is a long lived private key that only ever touches a computer when you need to do something rare: create or revoke a subkey, extend an expiry date, add an identity, or sign another key. The rest of the time it sits encrypted on removable media, disconnected. Everyday signing uses subkeys or hardware bound keys whose loss is an inconvenience, not a crisis.

The Debian wiki's Subkeys page sets out the reasoning well. Subkeys let you sign and decrypt every day without touching the primary key, which is your main proof of identity. A subkey can be revoked on its own, so if your laptop is stolen you replace the subkey and keep the reputation and web of trust attached to the primary. The primary key is needed only for exceptional tasks. Debian recommends keeping the primary private key on encrypted USB drives, ideally at least two copies.

OpenPGP: certification only primary, expiring subkeys

GnuPG supports this layout directly: a certification only primary plus subkeys with their own usage and expiry, as the walkthrough below shows. On a machine without the primary secret, gpg --list-secret-keys shows sec# instead of sec.

GnuPG also stores pre generated revocation certificates in ~/.gnupg/openpgp-revocs.d/, one file per key fingerprint. The GnuPG manual recommends backing them up and moving them to external storage if the primary private key is not kept on disk, and it warns that anyone who can access these files can revoke the corresponding key. Store a copy apart from the key, so one loss does not take both.

Android: the upload key and the app signing key

The app signing key signs the APKs installed on users' devices. It never changes during the app's lifetime. With Play App Signing, Google holds and protects it, and you can upgrade it in Play Console if it is compromised or you want a stronger key; the new key then signs installs and updates on Android 13 and higher, while the older key continues to sign for earlier versions.

The upload key signs what you upload to Play. If you lose it, you create a new upload key and request a reset in Play Console. Because Google holds the app signing key, you can keep shipping updates to the original app.

Without Play App Signing, the situation is stark. If you lose your app signing key, you lose the ability to update the app; the docs say Google cannot retrieve it and you cannot regenerate a previously generated key. The page recommends a validity of 25 years or more (Google Play requires validity ending after 22 October 2033) and says to keep the keystore "in a safe, secure place". It does not spell out a backup procedure, so that part is on you.

SSH: hardware bound keys and what to keep offline

OpenSSH supports FIDO authenticator backed keys through the ecdsa-sk and ed25519-sk key types. According to the ssh-keygen manual, the private key file on disk holds only a key handle; the per device private key stays on the authenticator and cannot be exported. There is nothing secret to back up from the laptop, and a lost authenticator is a lost key, so enroll a second authenticator and add both public keys wherever you need access.

The -O resident option stores the key handle on the authenticator itself, so you can run ssh-keygen -K on a new machine to download the handles and start working. The manual notes the trade off: storing both parts on the device raises the risk if the device is stolen, and a PIN is usually required first. The -O verify-required option asks for a PIN on every signature, where the authenticator supports it.

For more on this, see our earlier post on hardware backed SSH keys and what ed25519-sk gives a developer. For the cloud and HSM side of release signing, see where to keep code signing keys.

How should recovery codes be stored, and how many copies?

Recovery codes are one time secrets a service hands you when you turn on two factor authentication. Each code works once. They exist for exactly one scenario: you have lost every other factor.

NIST SP 800-63B-4, finalized in July 2025, describes them in Section 4.2.1.1 as "saved recovery codes". It says a service should issue one at enrollment, that it must carry at least 64 bits from an approved random generator, and that saved recovery codes "are intended to be maintained offline (e.g., printed or written down)". It also requires the service to invalidate a code after use and issue a new one, and to send an account recovery notification when a replacement is issued. That last point matters: a well run service tells you when someone regenerates your codes.

Here is what the major developer platforms document:

GitHub and npm both suggest storing codes in a password manager. That is reasonable for convenience, but notice the circular dependency: if your password manager is locked behind the same phone you just lost, the codes are locked with it. Keep a paper copy outside the password manager as well.

Paper, encrypted USB or a safe?

Each medium fails differently, so the answer is usually a mix.

A practical pattern is two kits: kit A at home, kit B somewhere you can reach within a day or two that will not burn in the same fire. Each holds printed recovery codes and an encrypted drive with key material. Keep the drive passphrase out of the envelope that holds the drive.

For more on this, see maintainer account recovery codes and backups and MFA recovery codes and fallback without weakening MFA.

Why do vendors require or recommend two security keys?

A hardware security key is designed so that its private keys cannot be copied off it. That is the whole point, and it is also why one key is a single point of failure. There is no backup to restore from.

Apple is the clearest example. Its Security Keys for Apple Account support page says you must add and maintain at least two FIDO Certified security keys, and you can add up to six. Every device signed in to the account needs iOS 16.3, iPadOS 16.3 or macOS Ventura 13.2 or later (iCloud for Windows needs version 15 or later), and two factor authentication must already be on. The page warns that if you lose all your keys and trusted devices you could be permanently locked out, and it suggests keeping keys in separate places, such as one at home and one at work. Child accounts and Managed Apple Accounts are not supported.

NIST makes the same point in general terms. Section 4.1.2.1 of SP 800-63B-4 says services should encourage people "to maintain at least two separate means of authentication" to reduce the need for account recovery, and it requires services to allow binding more than one authenticator to an account.

Register both keys on every account that supports them, and keep the second in the offline kit, not in your laptop bag. Keep recovery codes too, for when both keys are out of reach. Our earlier post Apple security keys: why you need two and where to keep them covers the Apple setup in detail.

What do FIDO2 and passkeys change about recovery?

FIDO2 (WebAuthn plus the client to authenticator protocol) is the reason security keys and passkeys resist phishing. CISA's October 2022 fact sheet on implementing phishing resistant MFA calls FIDO/WebAuthn "the only widely available phishing-resistant authentication" and describes both roaming authenticators (separate tokens over USB or NFC) and platform authenticators built into laptops and phones.

Passkeys split that world into two kinds of credential, and the FIDO Alliance describes both:

• Synced passkeys live in a passkey provider (a platform credential manager or a password manager). Create one on a phone and it appears on your other devices signed in to the same provider. The FIDO Alliance says this syncing is end to end encrypted. If you lose a device, you sign in to the provider on a new device and the passkeys come back. Recovery has moved from the website to the passkey provider.
• Device bound passkeys never leave the device that created them, including passkeys stored on a FIDO security key. They do not come back if the device is lost. The FIDO Alliance points out that a hardware security key can act as a recovery credential if you lose all your synced devices.

NIST draws a line between them. SP 800-63B-4 Appendix B, which is normative, sets requirements for syncable authenticators: keys stored in the sync fabric must be encrypted, access to them must be protected by multi factor authentication equivalent to AAL2, and the authenticator should show you which services you have created synced keys for and where they have synced. Because a synced key must be exportable, the same document says syncable authenticators shall not be used at AAL3, which requires a non exportable private key.

For your offline kit this means two things. Your passkey provider account is now a root of trust, so its recovery material belongs in the kit. And a device bound passkey on a security key needs a second registered key, because nothing syncs it. Passkeys make recovery rarer, not unnecessary.

How do you export a password vault safely, and should you?

Most password managers can export the vault, often as plain CSV or JSON. An unencrypted export is every password you own in one readable file. Export only to migrate, or for a cold backup in case the provider locks your account or shuts down, and follow these rules:

1. Export on a trusted machine, offline if you can.
2. Keep the plain file off synced storage, including cloud synced desktop and download folders.
3. Encrypt it immediately and write only the ciphertext to your offline media, for example gpg --symmetric --output /mnt/offlinekey/vault-2026-10.gpg vault.csv.
4. Destroy the plaintext. On an SSD, a delete does not guarantee the blocks are gone, so do the export inside an encrypted volume or a RAM disk in the first place.
5. Date it and keep only the newest one or two. An old export holds passwords you have since rotated, and also some you forgot to rotate.

Many people should not bother. If your provider offers a printable emergency kit or recovery sheet, that sheet plus your master password may be a better offline backup than an export. Check what your product's documentation says the sheet covers.

Step by step: build an offline signing kit

This walkthrough creates an OpenPGP release key with an offline primary, writes it to an encrypted USB drive, and leaves only subkeys on the working machine. It uses Linux and GnuPG 2.2 or later. Adjust paths for your system.

Step 1: Prepare a clean, offline working environment

Boot a live Linux image from read only media, or use a dedicated machine. Disconnect from the network. You want the primary key to be created somewhere that has never been on the internet and will not keep a copy afterwards.

# Confirm there is no network route before generating anything
ip route
# Use a temporary GnuPG home in RAM
export GNUPGHOME="$(mktemp -d /dev/shm/gnupg.XXXXXX)"
chmod 700 "$GNUPGHOME"
gpg --version | head -1

Step 2: Create a certification only primary and expiring subkeys

# Primary key: certify only, expires in 5 years
gpg --quick-generate-key "Example Project Releases <releases@example.org>" ed25519 cert 5y

# Note the fingerprint
gpg --list-keys --with-colons "releases@example.org" | awk -F: '/^fpr:/ {print $10; exit}'
FPR=<paste the 40 character fingerprint>

# Subkeys for daily use, each expiring in 1 year
gpg --quick-add-key "$FPR" ed25519 sign 1y
gpg --quick-add-key "$FPR" cv25519 encr 1y

# Make a revocation certificate (GnuPG also pre-generates one in openpgp-revocs.d)
gpg --output "$GNUPGHOME/revoke-$FPR.asc" --generate-revocation "$FPR"

Step 3: Prepare the encrypted USB drive

Warning: the next block destroys all data on the target device. Run the device check first and confirm the path, size and model match the drive you just plugged in. A wrong path here can wipe your system disk.

# Device path check: list block devices, plug in the USB drive, list again
lsblk -o NAME,SIZE,MODEL,TRAN,MOUNTPOINTS
# The new entry with TRAN=usb is your target. Set it explicitly.
DEV=/dev/sdX    # replace sdX with the device you confirmed above
lsblk -o NAME,SIZE,MODEL,TRAN "$DEV"   # check again: is this the right size and model?

# Destructive: formats the device you confirmed above
sudo cryptsetup luksFormat "$DEV"
sudo cryptsetup open "$DEV" offlinekey
sudo mkfs.ext4 -L OFFLINEKEY /dev/mapper/offlinekey
sudo mkdir -p /mnt/offlinekey
sudo mount /dev/mapper/offlinekey /mnt/offlinekey
sudo chown "$USER" /mnt/offlinekey

Repeat Step 3 for the second drive, running the device path check again. Device names change between plugs, so never reuse the value of DEV from the first drive.

Step 4: Copy the full key material to the drive

umask 077
cp -a "$GNUPGHOME" /mnt/offlinekey/gnupg-home
gpg --armor --export "$FPR" > /mnt/offlinekey/public-$FPR.asc
gpg --armor --export-secret-keys "$FPR" > /mnt/offlinekey/secret-full-$FPR.asc
cp "$GNUPGHOME/revoke-$FPR.asc" /mnt/offlinekey/
( cd /mnt/offlinekey && sha256sum *.asc > SHA256SUMS )
sync

Write the fingerprint and the date on a paper label. Print the revocation certificate and put the printout in a different envelope from the drive.

Step 5: Export only the subkeys for your working machine

gpg --armor --export-secret-subkeys "$FPR" > /mnt/offlinekey/subkeys-only-$FPR.asc
gpg --armor --export "$FPR" > /mnt/offlinekey/public-$FPR.asc

On your everyday machine, import the subkeys file and the public key. Then confirm the primary secret is absent:

gpg --import subkeys-only-<FPR>.asc
gpg --list-secret-keys
# Expect "sec#" on the primary line: the # means the primary secret key is not here

Delete the subkeys transfer file from any removable media you used to move it, and unmount and close the offline drive:

sudo umount /mnt/offlinekey
sudo cryptsetup close offlinekey

Step 6: Back up an Android keystore the same way

If you manage your own Android signing keystore, copy it to both encrypted drives, record a checksum, and keep the passwords on paper in a separate envelope. Exporting the upload certificate (which is public) is useful for an upload key reset and is safe to keep alongside:

keytool -export -rfc \
  -keystore your-upload-keystore.jks \
  -alias upload-alias \
  -file output_upload_certificate.pem
sha256sum your-upload-keystore.jks output_upload_certificate.pem

Step 7: Enroll a second FIDO authenticator for SSH

# With authenticator 1 plugged in
ssh-keygen -t ed25519-sk -O resident -O verify-required -C "laptop key 1"
# Swap to authenticator 2
ssh-keygen -t ed25519-sk -O resident -O verify-required -C "backup key 2"
# Add both .pub files to authorized_keys and to your code host account

Put authenticator 2 in the offline kit. On a replacement laptop, ssh-keygen -K downloads the resident key handles from whichever authenticator you touch.

Step 8: Print and file the recovery codes

Download recovery codes from each code host and registry, print them on ordinary laser paper (thermal paper fades), and label each sheet with the account name and date. Put one copy in each kit. Delete the downloaded text files once printed, unless you deliberately keep them in your password manager.

How do you test that offline keys still work without exposing them?

An untested backup is a hope. The goal of a test is to prove three things: the media still reads, the passphrase still opens it, and the key inside still produces signatures that verify against the public key you publish. All of that can happen on an offline machine.

# On an offline machine or live image
sudo cryptsetup open /dev/sdX offlinekey     # confirm the device with lsblk first
sudo mount -o ro /dev/mapper/offlinekey /mnt/offlinekey
( cd /mnt/offlinekey && sha256sum -c SHA256SUMS )

# Use a throwaway GnuPG home so nothing is written back
export GNUPGHOME="$(mktemp -d /dev/shm/gnupg-test.XXXXXX)"
gpg --import /mnt/offlinekey/secret-full-<FPR>.asc
echo "kit test $(date -u +%F)" > /dev/shm/kit-test.txt
gpg --local-user <FPR>! --detach-sign /dev/shm/kit-test.txt

# Verify with the public key you actually publish
gpg --verify /dev/shm/kit-test.txt.sig /dev/shm/kit-test.txt

The ! after the fingerprint forces GnuPG to use the primary key rather than a subkey, so you are testing the thing you would need in an emergency. Wipe the RAM directory, unmount, close the drive and shut down the machine.

For other items:

• Security keys: sign in to each account with each key on its own.
• Recovery codes: using one consumes it, so check the printed sheets are legible and match the codes your account settings show. If in doubt, regenerate; GitHub notes this invalidates the old set, so reprint both copies the same day.
• Android keystore: open it with keytool -list -v -keystore <file> on an offline machine and compare the certificate fingerprint with the one shown in Play Console.

Write the test result on a log sheet in the kit: date, who tested, what passed. Put the next test in your calendar for a year out, or after any change of hardware or staff.

What is key escrow and who should hold a copy?

Key escrow means a trusted third party holds a copy of a key so it can be recovered when the owner cannot produce it. Two principles from SP 800-57 help.

Escrow decryption keys more readily than signing keys. NIST notes that losing the key to encrypted data means losing the data, so keeping copies of decryption keys is prudent until nobody needs the plaintext. Signing keys are different: Table 7 says backup is generally not advised, and when it is warranted, copies stay under the owner's control. For a project, "the owner" is the project, so escrow can mean a second maintainer or a foundation holding a sealed copy, not a random vendor.

Split the trust when one person should not hold it all. SP 800-57 defines split knowledge as splitting a key into shares so that any number below the threshold reveals nothing about the key. For a small team, a lighter version works: one person holds the encrypted drive, a different person holds the passphrase, and both must agree to open it. Write down who those people are, how to reach them, and what happens when one leaves.

For individuals, escrow is often a trusted relative or solicitor holding a sealed envelope. For Apple Accounts with Advanced Data Protection, a recovery contact plays a similar role: Apple says the contact cannot access your account and can only give you a code to help you recover. Our post on key backup and escrow and which keys to escrow goes deeper on the organizational side, and break glass credentials: backup and test covers emergency admin accounts.

How do you rotate when an offline copy is lost?

Losing a copy is not the same as losing the key, but you should assume someone else may have found it. The response depends on how well the lost copy was protected and what it contained.

1. Work out what was on it. A drive with only public keys is a non event. A drive with the primary secret key is a rotation; if it was encrypted with a strong passphrase stored elsewhere, plan it for the next release cycle rather than the next hour.
2. For an OpenPGP release root: create a new primary from the surviving copy's environment, sign the new key with the old one to give users a trust path, publish both, announce the transition in your release notes and security policy, and then publish the revocation certificate for the old key once the new one is in place. If you believe the old key was actually compromised, revoke first and explain the gap.
3. For subkeys: revoke with the primary (gpg --edit-key, select the subkey, revkey, save), add a new subkey, and publish the updated public key.
4. For an Android upload key: request an upload key reset in Play Console. For the app signing key under Play App Signing, use the key upgrade option; remember that older Android versions keep using the old key.
5. For recovery codes: regenerate on every affected account. Under SP 800-63B-4, issuing replacement codes triggers a notification to you, which is also how you would notice someone else doing it.
6. For a security key: remove it from every account at once, then register a replacement so you are back to two.
7. Rebuild the second copy. A kit with one copy left is the situation the whole plan exists to avoid.

Where Safeguard fits, and where it does not

Be clear about the boundary first. Safeguard does not store, escrow or back up signing keys, recovery codes or security keys, and it does not scan for leaked secrets. Everything in the walkthrough above happens on your own hardware and paper.

The connection is downstream. Signing keys are what make release provenance and SBOM attestations mean something. When a maintainer rebuilds a laptop after a loss, the build environment comes back from lockfiles, and whatever versions those lockfiles resolve to become your next release. Safeguard scans repositories, container images and SBOM files for known vulnerabilities, shows which projects contain a given component and version, and evaluates policies and gates before something ships. The local runner is part of the Safeguard CLI: it scans on your own machine and uploads only results, which suits a rebuilt or restricted machine. See how the local runner and offline databases work for what the docs say about offline use.

Common mistakes

• One security key. It works until the day it does not. Register two before you need either.
• Recovery codes only in the password manager on the lost phone. Keep a paper copy outside the thing you are recovering from.
• Both offline copies in the same building. SP 800-57 asks for physically separate locations for a reason.
• Passphrase taped to the encrypted drive. That turns a protected backup into a plain one.
• Keeping the primary OpenPGP secret on the laptop "for convenience". If gpg --list-secret-keys shows sec without the # on your daily machine, your offline root is not offline.
• No revocation certificate, or only one copy stored with the key. If the drive is lost, you lose both the key and the means to revoke it.
• Android keystore only on the build server. Without Play App Signing, a dead disk can end your ability to update the app.
• Never testing. Flash fails and passphrases are forgotten. A yearly test catches both.
• Forgetting the people. When a maintainer leaves, update who holds the escrow envelope and the second key.

FAQ

What should I do if I lose my GitHub 2FA device and recovery codes?

Try a passkey or a registered security key first. If none works, GitHub offers an account recovery request using a verified device, an SSH key or a personal access token as proof; Support reviews these and replies within three business days. GitHub's docs are clear that Support cannot simply turn off 2FA for you.

How many recovery codes do I get and can I make more?

GitHub issues 16 single use codes and lets you generate a new set at any time, which invalidates the old one. npm and PyPI also let you view or regenerate codes from account settings. Reprint both offline copies every time you regenerate.

Why does Apple require two security keys?

Apple's support page says you must keep at least two FIDO Certified keys, because a security key cannot be backed up and losing all keys and trusted devices can lock you out permanently. You can register up to six.

Do passkeys replace recovery codes?

Not entirely. Synced passkeys return when you sign in to your passkey provider on a new device, so the provider's own recovery material becomes the thing to protect. Device bound passkeys on a security key do not sync, so they need a second key or another recovery method.

Should I back up a code signing private key?

NIST SP 800-57 says private signature keys are generally not backed up, with exceptions such as a certificate authority's signing key, and any backup must stay under the owner's control. A release root key that users pin is like that exception. Daily signing subkeys are not: revoke and replace them instead.

What happens if I lose my Android app signing key?

With Play App Signing, Google holds the app signing key and you can reset a lost upload key in Play Console. Without it, Android's docs say you lose the ability to update the app, and the key cannot be retrieved or regenerated.

Is a hardware encrypted USB drive better than a software encrypted one?

They fail differently. Software encryption such as LUKS is inspectable and portable but needs a working machine and the passphrase. A keypad drive needs no host software but relies on firmware you cannot inspect. Many teams use one of each so a single failure mode cannot take both copies.

How often should I test an offline key backup?

At least once a year, and after any change of hardware, operating system or the people who hold copies. Test by signing a throwaway file on an offline machine and verifying it against your published public key.

Fix it without waiting for upstream

Offline keys protect who can sign a release; they say nothing about what goes into it. A maintainer who rebuilds a laptop after a loss pulls every dependency again from lockfiles and registries, so the open source components in that next signed release still need checking, and the honest fit for Safeguard here is that dependency side rather than the keys themselves.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

These demos do not touch keys or recovery codes. They show the dependency side of a rebuild, before you sign the first release from a restored machine. You can download the CLI at safeguard.sh/download and read the CLI docs.

The first demo is a real CLI session. The assistant reads a lodash finding and its advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, and pushes nothing. On a freshly restored laptop, the same flow lets you fix what the lockfile pulled in before you sign anything with your subkey.

Click through it at your own pace, or open it full screen.

The second demo sets up the local runner on your own machine, approves it with a device code, then scans from the terminal. That suits a dedicated release machine you keep tightly controlled, because the scan runs locally and only results are uploaded.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• NIST SP 800-57 Part 1 Rev. 5, Recommendation for Key Management: Part 1 General (publication page)
• NIST SP 800-57 Part 1 Rev. 5 (PDF)
• NIST SP 800-63B-4, Authentication and Authenticator Management (publication page)
• NIST SP 800-63B-4 (PDF)
• NIST FIPS 140-3, Security Requirements for Cryptographic Modules
• Apple Support: About Security Keys for Apple Account
• Apple Support: How to turn on Advanced Data Protection for iCloud
• GitHub Docs: Configuring two factor authentication recovery methods
• GitHub Docs: Recovering your account if you lose your 2FA credentials
• npm Docs: Configuring two factor authentication
• PyPI Help
• Android Developers: Sign your app
• Debian Wiki: Subkeys
• GnuPG Manual: OpenPGP Key Management
• GnuPG Manual: GPG Configuration
• OpenBSD manual: ssh-keygen(1)
• FIDO Alliance: Passkeys
• CISA: Implementing Phishing-Resistant MFA (October 2022)

Last reviewed: 23 October 2026. Platform recovery rules change; check the linked documentation for the current requirements before you rely on them.