What Happens If You Remove a Passkey in CardanoWall?

Remove a passkey and CardanoWall re-encrypts your current identity vault to the factors you still have, then hard-deletes the old ciphertext. The passkey you removed can no longer open the vault that exists afterward. That is genuine revocation for future unlocks.

What it is not is retroactive. If that passkey was already used to open the vault while it was valid, removal cannot reach back and undo it. In that case you treat the identity as compromised, not merely as "one factor short."

This article explains exactly what changes, what stays the same, and when a removal is enough versus when you need a new identity.

What does the passkey actually protect?

It protects access to your hosted identity vault — nothing more, nothing less.

The vault is an encrypted bundle holding the Identity Seeds your account owns and the private labels you gave each one. Each passkey you register is one unlock factor for that bundle. The server stores only ciphertext it cannot read; your passkeys are the only thing that can open it. (For the full picture of how that vault is built, see how CardanoWall stores your identity and how passkeys protect your identity vault.)

The distinction that matters here: your identity is the seed, not the passkey. A passkey is just a convenient way to open the encrypted copy of the seed. Removing it changes who can open that copy — it does not change the identity itself.

What happens during removal?

The vault is re-encrypted to the factors that remain. The sequence is:

You unlock the vault with a valid factor.
CardanoWall drops the selected passkey from the recipient set.
Your browser rebuilds the vault ciphertext for the remaining factors.
The current vault row is replaced with the new ciphertext and a higher version number.
The old ciphertext is hard-deleted.
The removed credential record is deleted.

The order is enforced on the server: a credential that still appears in the vault's recipient set cannot be deleted. Revocation has to be real — no ciphertext the removed passkey can open is allowed to survive — never cosmetic. Once the call returns, the removed passkey opens nothing that still exists.

Why does deleting the old ciphertext matter so much?

Because old ciphertext can still be opened by old factors.

If every historical copy of the vault were kept forever, removing a passkey would be theater. The removed factor could still decrypt an older vault version, and that older version contains the very same seeds. You would have "removed" a key that still works on a copy sitting right there in storage.

That is why the hosted vault is a single current row that gets replaced, not an append-only history. Hard deletion is what gives factor removal teeth. Ordinary backup-rotation windows can exist in real infrastructure, but the product is designed never to keep historical vault ciphertext as a feature.

What if it was my last passkey?

Then the vault itself is deleted.

If no factor remains, CardanoWall does not keep ciphertext that nothing registered can open. The account falls back to the seed-entry path: you regain access by pasting your Identity Seed.

That is fine if you saved your seed. It is dangerous if you did not. Removing your last factor without a saved seed can lock you out of future use of that identity — not because anything broke, but because you have removed every way back in. The seed is the real backup; the vault is only a convenience layer on top of it. (Why the seed still matters covers this in depth.)

Does removing a passkey affect my published proofs?

No. Published Label 309 records stay on chain and stay verifiable.

A proof's validity does not depend on your current passkeys, your current account, or your current vault state. Anyone with the transaction reference can verify it using only the on-chain metadata, the content bytes if needed, and a public Cardano explorer — no CardanoWall login required. If a proof verified before you removed a passkey, it verifies the same way after.

Passkey removal governs future access to your identity vault. It does not rewrite anything already on chain.

I just lost a passkey. What should I do?

Remove it promptly.

If you lost a phone, a laptop, or a hardware security key, removing the passkey is the right first move. After the vault is re-encrypted without that factor, the lost device can no longer open the current vault.

If you are confident the lost factor was never used by someone else — a key that fell behind a desk, a phone wiped before resale — removing it may be all you need. No identity rotation required.

If you cannot rule out that someone used it, keep reading.

What if the passkey may have been stolen and used?

Treat the risk seriously, and be precise about what a stolen passkey alone can and cannot do.

A stolen passkey by itself is not the same as a stolen seed. To open your vault, an attacker also needs the vault ciphertext (which only travels inside an authenticated session) and whatever user verification the authenticator demands — a biometric or device PIN. A passkey on its own holds a key, not the ciphertext it unlocks.

But if the attacker may have used the passkey before you removed it — inside a hijacked session, against the live vault — then they may have opened the vault and read your Identity Seed. Once the seed is exposed, the identity is fully compromised: the holder of the seed can derive every private key, decrypt sealed records addressed to that identity, and sign new records under it.

In that scenario, passkey removal is not enough. Revocation protects the vault going forward; it cannot un-expose a seed that already left.

What should I do after a possible seed exposure?

Move to a new identity. A compromise response is a fresh identity, not an in-place reset of the old one — because the seed and the identity are bound together permanently, there is no "change the seed" operation.

If you cannot rule out seed exposure:

create a fresh identity and save its new Identity Seed;
register new passkey factors on it;
deactivate the compromised identity in CardanoWall (this blocks new signing and publishing while still letting you decrypt anything sealed to it);
stop sharing the old receive addresses;
republish your new public keys everywhere you published the old ones — public profiles, your own site, DNS records, .well-known, and your contacts;
publish a superseding record where it helps downstream readers.

One seed is one identity. (Active, deactivated, deleted walks through each lifecycle state.) Note the honest limit: anything already sealed to the compromised keys stays decryptable by whoever holds them — Cardano and Arweave keep no revocation primitive for content already published. Deactivation and a superseding pointer are signals to relying parties, not a recall of past data.

What is the version pin, and why does it exist?

It is a defense against a server replaying a stale vault.

The vault row carries a version number that only ever increases. Your browser remembers the highest version it has seen. If a compromised server tried to hand back an older vault ciphertext — one that a since-removed passkey could still open — the client can notice the returned version is lower than expected and refuse it.

This is defense-in-depth, not a substitute for seed custody. It closes one specific gap: stale-vault replay against a removed factor. It does nothing to help you if you lose the seed and every unlock factor at once.

The short version

Removing a passkey re-encrypts your current identity vault to the remaining factors and hard-deletes the old ciphertext. The removed passkey can no longer open the vault that exists after removal.

The one caveat: if that factor may already have been used while valid, assume the seed may have been exposed and move to a new identity. Revocation protects the future. It cannot change the past.