pull the report before you delete the account

Two other guides touch the shared vault and neither opens it.

The day one guide shows a new hire getting far more than the job needs on the first morning, and the shared vault is part of that: whoever you add to it gets every credential ever put in it. The hostile departure guide says that when somebody leaves, you rotate what they knew, because removing their account does not unknow it.

Both are right and both skip the question underneath: what did they know?

The vault is the one system in your company that can answer that. It is also the one system that stops being able to answer it at the exact moment you remove the person.

the report expires when you need it

1Password produces a usage report showing which items a team member has accessed over the last twelve months. It is item-level, which is what makes it a rotation worklist and more than a vague indication.

1Password’s documentation also says you cannot create reports for team members who have been removed from your organisation.

Now read the offboarding sequence most companies run. Somebody leaves, you go through the checklist, you remove them from the password manager because that is obviously the security-conscious thing to do, and in doing so you delete your own ability to find out which credentials they opened.

1Password’s own offboarding guidance tells you to change the passwords and tokens that were shared with the person, item by item, in the vaults they could reach. That is correct, and it is a lot more work without the list.

So the vault inverts the order of almost every other system in these guides. Everywhere else you cut access first and investigate afterwards. Here you pull the report first, then remove.

the vendors disagree about whether this matters

Worth knowing, because it tells you how much the tool will help you.

1Password’s guidance is unambiguous: rotate.

Bitwarden’s is conditional. Its documentation says that if you anticipate malicious exploitation, you should update the credentials the member had access to when you remove them. That puts the decision on your reading of somebody’s intent, and the hostile departure guide explains why designing around intent goes wrong in both directions.

Keeper’s offboarding page says the user’s vault is deleted along with their account, and says nothing about rotation or about what happens to items that were shared.

Three vendors, three different implied answers to the same question: should a credential a departing person could read be treated as known?

It should. A credential is knowledge, and you cannot revoke knowledge. That is what separates this from every other offboarding step.

what gets logged, and where it is cheaper than you expect

One good piece of news, against the pattern of most of these guides.

Bitwarden logs at item level, with separate event types for viewing an item, viewing a password, copying a password and auto-filling. Its documentation says events are retained indefinitely, can be viewed for just over a year, and organisation event logs are available on its Teams plan. So the useful thing is not behind an enterprise wall. You have simply never pulled it, and the offboarding checklist you run deletes the ability to.

1Password says most of its reports are available only on 1Password Business; Teams customers can trial them. If you are on Teams without reports, the first step of the routine below is not available to you, and the standing fix at the end is your whole intervention.

the default is a pile

Both 1Password and Bitwarden set you up with a shared space everybody can see: a shared vault in one, a default collection in the other.

That default is where this problem lives.

A vault everybody is in is a pile. Nothing in it is scoped to a role, nothing in it has an owner, and everything in it has been readable by every person who has passed through your company since it was created, including the people who left years ago.

So for anything in that default vault, the rotation question has nothing to do with the specific leaver. Everybody who was ever here knows it.

the vault runs in the opposite order

every other system

cut first, look later

• Suspend the account
• Then check what they did
• The logs are still there

the password manager

look first, cut later

• Export the usage report
• Then rotate what they opened
• Remove them last, because the report goes with them

the routine, thirty minutes, on the day notice is given

One exception first, and it overrides everything below. In the hostile case, containment comes first: suspend immediately, even if that might cost you the worklist. Rotating the whole shared vault by hand is a worse afternoon than losing the list, and a better outcome than a live account. Everything below assumes an ordinary resignation with notice, which is most departures.

Before you touch the account, pull the report. In 1Password, open the person’s usage report and export it. In Bitwarden, filter the event log by that member and export it. This is the rotation worklist, and it may be unrecoverable afterwards.

List their vaults and collections. Anything in the default shared vault counts as known by everybody, which changes what you are rotating and why.

And be honest about what the report covers. It shows items the person opened, never items they could have opened. Somebody who copied everything out in their first month and never touched the vault again produces a clean report. That limit is why the standing fix below matters more than the routine: a narrow vault makes the report meaningful, and a pile makes it decorative.

Rotate in this order. First the items the report shows they opened. Then anything administrative, billing or root in the shared vaults, whatever the report says, because those are the ones where being wrong is expensive. Then the rest, over the following week.

Then suspend, then remove. In that order.

Test the suspension question once, before you need it. The documentation says removed members lose their report. It does not say what happens to a suspended member’s report. Suspend a test member, try to create their report, and write down the answer. If the report survives suspension, you can suspend immediately in every case without losing the worklist, and the exception above disappears.

And the standing fix, which is worth more than the routine. Empty the default shared vault. Move each item into a vault scoped to the people who genuinely need it, with a named owner, which is the ownership guide arriving in a different console. Anything you cannot find an owner for is a candidate for the switch-off method: rotate it, put it somewhere narrow, and see who complains.

the case this is not about

One case gets used badly here.

The LastPass incident of 2022 is the one everybody reaches for, and it is a vendor breach, unrelated to offboarding. According to LastPass, what was taken was a backup containing unencrypted data such as website URLs alongside encrypted fields including usernames, passwords and secure notes. In 2023, Krebs on Security reported researchers linking over thirty-five million dollars in cryptocurrency theft from more than a hundred and fifty victims to seed phrases that had been stored in those vaults.

That story shows that credentials outlive the container they were stored in. It shows nothing about leavers, and using it here would be borrowing fear from an adjacent problem.

The case for this guide is simpler and needs no breach. Your vault can tell you what somebody knew. Your offboarding process deletes that capability before it is used. Swapping two steps costs nothing.

the number that does not exist

Somebody will ask what normal looks like.

There is no credible published figure for how many credentials a company your size keeps in shared vaults. What circulates is consumer survey data about password reuse and a widely repeated count of passwords per employee, and neither measures this.

You can find out in about a minute by opening your own vault and counting. That number is more useful than any survey, and you will know exactly how it was collected.

While you are counting, sort by age. The oldest items in a shared vault are the interesting ones: an item added four years ago has been readable by everybody who has worked at your company since, has almost certainly never been rotated, and belongs to a system whose original owner probably left. Every argument these guides make about accounts applies to those entries with more force, because a credential does not need an account to work.