The 'Kill Switch': What Happens When an Employee Leaves Your Team?

Ask any security engineer what keeps them up at night, and "offboarding" will be near the top of the list. New employees get welcome packages, badges, and onboarding checklists. Departing employees get a Slack farewell and, if you're lucky, a half-remembered list of accounts to revoke. The asymmetry is dangerous. It's why former employees retain access to production systems for months — sometimes years — after they walk out the door.

The traditional offboarding nightmare

Most teams "offboard" by removing a user from a shared vault and rotating any passwords that the person knew. This is correct in theory and disastrous in practice. The departing employee may have copied passwords into local notes, browser autofill, password manager exports, or — most often — their own memory. Removing their seat from the SaaS dashboard does nothing about any of that. Until every credential they touched is rotated, they still hold valid keys.

What the Pwdly Kill Switch actually does

When an admin removes a member, three things happen, and all of them happen in the admin's browser, not on our servers:

1. Access removal. The member's wrapped copy of the Project Key is deleted and the server stops returning any of the project's data to them at once. Row-level security is checked on every request, so there is no window where a cached session can keep reading.
2. Project key rotation. A new Project Key is generated locally by the admin who removed them, and every secret in the project is re-encrypted under it: every credential field, every custom field and the project's encrypted audit history. The server applies the whole change in one transaction or not at all, so a project is never left half-rotated.
3. Sealed-envelope re-issuance. The new key is sealed to every remaining member's public key, exactly the way invites are delivered. The departed member receives no envelope. Members open theirs the next time they unlock their vault, and until they have, the server refuses writes from them so a tab that is still holding the old key cannot save anything under it.
4. Rotate the passwords they saw. Nothing cryptographic can take back what someone has already read. Pwdly does not yet automate this, so treat the removal as the prompt to change the underlying passwords the person had access to, starting with the ones that matter most.

Why client-side key rotation matters

A naive system would rotate keys on the server, which would require the server to briefly hold the old project key in memory to re-encrypt everything. We refused. Instead, key rotation happens entirely on a remaining admin's device. The old project key is decrypted in the admin's browser, the new key is generated locally, and the re-encrypted ciphertext is uploaded. Our servers see ciphertext-in, ciphertext-out — never the keys themselves.

Forward secrecy for shared vaults

Even if the departed employee kept a copy of the old Project Key, it is now useless. The current ciphertext on our servers, and everything the team adds or edits from here on, is encrypted under a key they have never seen. This is forward secrecy applied to a team vault, and it is the property that makes "revoking access" mean what people think it means.

The audit trail

Each credential keeps its own encrypted audit history: who created it, who changed what, and when. Rotation re-encrypts that history under the new key, so remaining members can still read it and the departed member cannot. The removal itself is visible in the project's member list.

The human side

We deliberately made removing a member a weighty action. The confirmation dialog says exactly what is about to happen: the member loses access, and the project's encryption key is rotated so nothing they kept can be used to read it. Security tooling should not be casual at the moments that matter most. Removing someone should feel like changing the locks, because that is what it does.

Closing the gap

Offboarding is the moment where most security postures quietly collapse, because it is the moment where humans are tired, distracted, and emotionally complicated. The right answer is not a better checklist. It is a system where the cryptographic guarantee snaps into place the instant the member is removed, with no follow-up required to make "revoked" actually mean revoked. That is what the Kill Switch is for.

Updated 27 October 2026

An earlier version of this article described behaviour that had not shipped: it said removing a member terminated their sessions, that key rotation was performed "by the next admin to log in", that a 90-day rotation queue flagged secrets for follow-up, and that each removal produced a signed audit entry. In reality, removal only cut the member's access and the Project Key was never rotated. An independent security researcher reported the gap (FIND-PW02) under our disclosure programme. Project key rotation with sealed re-issuance now happens as part of removing a member, as described above. We do not terminate the removed person's Pwdly session, because they remain a Pwdly user with their own personal vault; their access to the project ends the moment they are removed. We have corrected the rest of the text rather than keep claims we could not stand behind, and we are grateful for the report.