Nostr Key Security: Protect Your nsec with Browser Signers, Remote Bunkers & Air-Gapped Signing

Your Nostr identity is a single secp256k1 private key. There is no “forgot password”, no support desk, no recovery email — and unlike a Bitcoin seed that sits in cold storage, your Nostr key gets used constantly, because every note you publish is a signature. That changes the threat model. The goal here is not to lock the key in a vault; it is to let your software sign with it without ever exposing the raw secret. This guide walks through how to do exactly that, in plain operational steps.

The keypair model: what your nsec and npub actually are

A Nostr identity is one secp256k1 keypair. The public key is a 32-byte x-only pubkey; the private key is the 32-byte secret. Every event you publish is signed with a BIP-340 Schnorr signature over the SHA-256 event id — the same signature primitive Bitcoin Taproot uses (NIP-01). That shared cryptography is precisely why Bitcoin-style hardware signing of Nostr events is even possible, as we’ll see below.

The strings you actually see — npub1… and nsec1… — are just bech32 display encodings defined in NIP-19. Internally the keys are plain hex; the bech32 form exists so a human never pastes a secret thinking it was the public half. Burn the prefixes into memory:

• npub1… = your public key. Share it freely; it’s your handle.
• nsec1… = your secret key. Share it with nothing and no one.

Whoever holds the nsec controls the identity, exactly as whoever holds a Bitcoin private key controls the coins. (For the term-level definition, see our npub / nsec glossary entry.)

The key difference from Bitcoin — flag this for yourself. A Bitcoin key signs occasionally and lives offline. A Nostr key signs many times a day from a hot, internet-connected client. So “put it in a vault and never touch it” is not an option. The entire design problem Nostr solves with NIP-07 and NIP-46 is: let software use the key constantly without ever copying the raw secret into that software.

The four ways to hold a Nostr key, ranked by exposure

Think of these as a ladder from worst to best.

1. Raw nsec pasted into a client — don’t, except for disposable test keys

Many web and mobile clients will happily accept a pasted nsec1… and store it locally. The moment you do that, every client you pasted into holds a full copy of your identity, and a malicious or compromised client can exfiltrate it silently. No NIP blesses this approach for a key you care about. Use it only for a throwaway key you would not mind losing.

2. Browser-extension signer — NIP-07 (the good default on desktop)

NIP-07 defines a window.nostr object that a browser extension exposes to web clients, offering getPublicKey() and signEvent() (plus optional encryption helpers). The web app calls those methods; the extension does the signing and the app never sees the raw key. Compromising one website no longer leaks your identity, because the website only ever received signatures, not the secret.

Two operational cautions to internalise before you rely on it:

• The key now lives in the browser extension’s local storage. If you wipe the browser profile or lose the device without a separate offline backup, the identity is gone. Back the key up offline first (see below), then start using an extension.
• The extension itself is now your trusted component. Install only reputable, open-source signer extensions — a malicious one has the key.

3. Remote signer or “bunker” — NIP-46 (best for mobile, multi-device and shared setups)

NIP-46 (“Nostr Connect” / remote signing) lets a client request signatures from a separate signer process that holds the key. The request and response travel as encrypted events (kind 24133) over a relay, so the signer can sit somewhere the client can’t — on your phone, your home node, or a dedicated device that never opens a browser.

There are two connection flows worth knowing by name:

• Client-initiated: the client shows a nostrconnect:// URI (often a QR) that you approve in your signer.
• Signer-initiated: your signer hands you a bunker:// token that you paste into the client.

Why this is the strongest practical option: the raw key lives in exactly one place and is never copied into each client; you can revoke any single client’s access at the signer; and the signer can run on hardware that never touches the open web. It also lines up cleanly with the sovereign-stack principle — run your own bunker on your own node rather than trusting a hosted signing service.

4. Hardware / air-gapped signing — highest assurance, support still maturing

Because Nostr uses secp256k1 and Schnorr (BIP-340), the cryptography is compatible in principle with Bitcoin-style hardware signing devices. NIP-06 even specifies deriving a Nostr key from a BIP-39 mnemonic at the path m/44'/1237'/<account>'/0/0 (1237 is Nostr’s registered coin type), so a single seed can back a Nostr identity. Pair an offline signer with NIP-46 and the secret can approve signing requests while never appearing on a networked machine.

Honest caveat: hardware-wallet support for Nostr event signing is uneven and still evolving across devices and firmware in 2026. Verify that your specific device and firmware actually support Nostr signing before you depend on it, and don’t treat any single product as “the” answer.

Backing up your nsec the right way

Treat the nsec like a Bitcoin seed: offline, redundant, and tamper-evident. The same discipline from our offline Bitcoin key-storage guide applies directly.

The format matters as much as the medium:

• Raw nsec on metal or paper, in genuine cold storage, is fine.
• Encrypted (NIP-49 ncryptsec1…) is the right format for anything that might touch a synced, cloud, or carried medium. NIP-49 encrypts the private key with a passphrase using scrypt for key-derivation and XChaCha20-Poly1305 for the cipher, producing a portable, password-protected string that is safe to store where a bare nsec would be reckless — a password manager, an encrypted note, a USB stick you carry.

If you derived the key from a BIP-39 seed via NIP-06, your existing seed backup already backs up the Nostr identity — but you must record the derivation path and account index, or you can’t reproduce it.

Anti-patterns that are all leaks, full stop: an nsec in a screenshot, in a plaintext cloud note, in chat history, or in a photo of a QR code.

The rotation problem — the one place Nostr is genuinely weak

Be clear-eyed about this: there is no native, widely-adopted key rotation or recovery in Nostr. Your pubkey is your identity and your entire social graph. You cannot “change the password” while keeping the same identity, because the identity and the key are the same thing.

NIP-26 (delegated event signing) was proposed as a partial answer, letting one key authorise another to sign on its behalf — but it is largely deprecated and dropped by many clients, so do not build a security plan around it. Threshold/FROST approaches that shard the secret across devices so no single one holds the whole key are promising, but remain experimental in 2026 and are not a default you should rely on yet.

So what actually happens if your nsec leaks? You announce a new pubkey, publish a signed note from the old key pointing followers to the new one, and rely on social recovery — your followers re-follow the new npub. A NIP-05 identifier (next section) makes that migration far less painful, because you can re-point name@domain to the new key. The honest takeaway: on Nostr, prevention massively outweighs recovery, which is exactly why NIP-46 and hardware signing matter more here than on the average web app.

NIP-05 is identity verification, not authentication

NIP-05 maps a human-readable name@domain to a pubkey via a /.well-known/nostr.json file on that domain. It is a discovery and verification convenience — not a login and not a root of trust. The pubkey is always authoritative; the NIP-05 name is not.

The security nuance: the domain owner can reassign a NIP-05 name, and the whole thing depends on DNS plus a web server staying up. A green “verified” badge proves the domain vouches for that key today — it does not prove the key is trustworthy, and it is not an authentication step. If you want to own your identifier rather than rent it, see our guide to self-hosting your own NIP-05 identity.

Encryption hygiene for direct messages

Legacy Nostr DMs used NIP-04, which is deprecated: it leaks metadata such as message length and offers no authenticated encryption. Modern clients use NIP-44, a versioned scheme (ChaCha20 with HMAC-SHA256 and padding) that hides message length and authenticates the ciphertext. Prefer clients and relays that support NIP-44, and treat any NIP-04 DM as non-private. Note the residual limit even with NIP-44: it protects message contents, but who-talks-to-whom metadata is still visible to the relay.

Common mistakes checklist

1. Pasting your real nsec into web clients instead of using a NIP-07 extension or a NIP-46 bunker.
2. Confusing nsec1 (secret) with npub1 (public) and sharing the wrong one.
3. Treating a browser extension as a backup — it’s a hot key store; back the key up offline separately.
4. Storing a raw nsec anywhere synced or online instead of an encrypted NIP-49 ncryptsec.
5. Believing you can rotate your key like a password. You can’t — prevention first.
6. Trusting a NIP-05 checkmark as authentication.
7. Assuming NIP-04 DMs are private; use NIP-44-capable clients.
8. Reusing one high-value identity key for throwaway testing or bot accounts — use separate keys.
9. Approving every NIP-46 signing request blindly — a bunker is only as safe as your approval discipline.
10. Losing the derivation path or account index after a NIP-06 seed derivation.

A sensible default setup

For most people: a NIP-07 signer extension on the desktop, a NIP-46 bunker on the phone and shared devices, and an offline backup held either as a NIP-49 ncryptsec or as a NIP-06 seed derivation. Run your own bunker and your own relay on hardware you control wherever you can — the same sovereign-stack principle we apply to Bitcoin nodes and self-hosting. None of this is D-Central’s invention; it is the work of the Nostr protocol authors and the wider community. We just package the discipline. For the protocol-level detail behind every NIP referenced here, see our Nostr NIPs reference, and the broader digital sovereignty hub.

Frequently asked questions

Is my npub safe to share?

Yes — it’s public by design and is meant to be shared. Never share the nsec.

What happens if I lose my nsec?

The identity is unrecoverable. There is no reset; you must start a new pubkey and migrate your followers socially, ideally aided by a NIP-05 identifier you can re-point.

Can a hardware wallet sign Nostr events?

In principle yes — Nostr uses the same secp256k1/Schnorr cryptography as Bitcoin Taproot, and NIP-06 defines seed derivation — but support varies by device and firmware. Verify yours before depending on it.

What’s the difference between NIP-07 and NIP-46?

NIP-07 is a browser extension that signs locally for web clients on the same machine. NIP-46 is a separate remote “bunker” process that signs for any client over a relay, so the key can live on different hardware entirely.

Should I encrypt my nsec backup?

For anything that touches an online or synced medium, yes — use a NIP-49 ncryptsec. A raw nsec is only appropriate for true cold storage.

Is a NIP-05 verified badge a login?

No. It’s domain-vouched discovery, not authentication. The pubkey is the root of trust, not the name.