Changing your keys 🔁

A passphrase change swaps the lock on the door. Changing your keys replaces the keys themselves: every Secret, every Seal, every version in their history, every Authenticator credential and every encrypted attachment is decrypted in your browser and re-encrypted under a brand-new Master Encryption Key. The old key stops opening anything.

Find it under Profile → Encryption → Encryption keys → Rotate.

When this is the right tool

A passphrase change keeps the same MEK and re-splits it into new shares. That is the right answer for most worries, and it takes seconds. Changing your keys is for the case where the old key itself is the problem — because only a new key makes a copy of the old ciphertext worthless.

Changing your keys does not re-encrypt plaintext Notes. Tier 1 was never encrypted, so there is nothing there for a new key to protect.

What it asks of you before it starts

The wizard will not begin until three things are true:

1. Only this session is signed in. Every other session must be revoked. A second device writing to your vault while it is being re-keyed would write under a key that is about to stop existing.
2. No unsaved drafts are open. Local drafts are checked and you are asked to resolve them first — including a warning that unsaved drafts on other devices will be lost.
3. You save a new recovery file and prove you can read it back. The wizard mints the file for the new key and makes you upload it again before it will activate anything. This is not a formality: the new key is not written anywhere until this step passes.

While it is running

Your vault is frozen. Every write — to Notes, Secrets, Seals, tags, attachments, the Authenticator — is refused for the duration, on every device. Reading is unaffected; you keep seeing your current data, decrypted with your current key, right up to the moment it switches over.

The work happens in your browser, item by item, and reports progress. It can be paused and resumed, it survives a reload, and it can be picked up again on the same device if the tab is closed. If you close the browser mid-way, nothing is lost and nothing has changed yet.

Cancelling is always safe, right up to the last step. Until activation, your current keys, your current passphrase and your current recovery file all still work; the new ones are not live. Cancelling discards the half-finished work and unfreezes the vault.

The moment it activates

Activation is a single, atomic step. Either everything switches to the new key — the note bodies, the Seal keys, the Authenticator payloads, the attachment pointers, and the encryption profile itself — or none of it does. There is no state in between.

After that moment:

• Your old passphrase stops working. The new one is the only one.
• Every older recovery file stops working, including one you downloaded five minutes before you started. Keep only the new file. The recovery page will tell you when the file you uploaded belongs to a key that is no longer in use.
• Other devices must sign in again, because the operation revoked their sessions before it began.
• Every device with a trusted Authenticator must enroll again. A trusted device holds an offline cache keyed to the old generation; it detects the change and wipes it. Your TOTP codes are unaffected — the credentials themselves came through the rotation — but a device that was working offline will need your new passphrase once to get back to that state.

Attachments and offline access

Encrypted attachments are re-encrypted too, and they are transferred directly between your browser and the storage bucket over short-lived signed URLs, so their size does not have to fit inside an ordinary request.

A Seal's attachments go under that Seal's new note key, so each one waits for its Seal's key to be generated first. Seal attachments that were still on the account's attachment key — anything attached before Seal files were keyed per Seal — move onto their Seal's own key in the same pass. A file uploaded into a new Seal that was never saved is dropped: its key existed only in a local draft, which a key change discards.

One consequence is permanent, not just during a rotation: attachments are no longer served from the offline cache. A cached copy of an attachment may predate a key change, in which case it can no longer be decrypted — and a file that silently fails to open is worse than one that plainly says it needs a connection. Opening an attachment now always requires the network.

What the server keeps, and for how long

While the operation is running, the server holds a second, complete copy of your data: every re-encrypted body, staged under the new key, alongside the originals still under the old one. That is what makes activation atomic and cancellation free.

• On success, the originals become obsolete. The old encrypted files are queued for deletion and removed by a background job that runs once a day. The superseded database ciphertext is dropped in the same pass.
• On cancellation, the staged copy is dropped immediately and the new key is discarded with it. The objects it uploaded are queued for deletion the same way.
• If you walk away and never finish, the operation is held open so you can resume it — for seven days. After that it expires on its own: the staged ciphertext is discarded, its objects are queued for deletion, and the freeze on your vault is lifted.

That seven-day window is the one thing worth knowing about: an abandoned key change leaves a second encrypted copy of your Secrets and Seals on the server for up to a week. It is encrypted under a key that exists nowhere except the passphrase you chose and the recovery file you saved, and it is never readable by the server — but it is a second copy, and it does not disappear the instant you close the tab. If you start a key change and decide against it, cancel it rather than closing the tab.

If something goes wrong

Nothing in this process ever leaves your vault half-converted. Every failure mode ends in one of two states — the old key still active, or the new key fully active — and the app tells you which one you are in.

• A lost connection, a crashed tab, a closed laptop: resume from where you left off, or cancel.
• Another session appears: revoke it and continue. The vault stays frozen until you do one or the other.
• You lose the new recovery file after activating: download a fresh one immediately from Profile → Encryption → Backup recovery file, the same as after any passphrase change.
• You lose the new passphrase and the new recovery file: the encrypted data is gone. This is the same guarantee the rest of SigNote makes, and it applies with full force here — the old passphrase cannot bring it back.

→ Related: Security, Encryption, Threat model