Someone leaves in two weeks and they can post as the brand. The password sits in a shared vault item, the authenticator is on their phone, and nobody knows where the backup codes went. Removing them without locking the company out of its own profiles needs an order of operations.
The setup that works until it does not
The arrangement is the same from team to team. One vault item per brand account holding the login email address, the password and the TOTP seed, shared to a group called Social so several people can log in as the brand.
The failure point is the enrolment, not the password. Whoever switched on two factor authentication saw the one time recovery codes once, and those codes were printed, mailed to a personal inbox, or dismissed. They are rarely in the shared item.
Two risks get conflated. An over shared password is recoverable: rotate it and the exposure ends there. A lost recovery path on an account with two factor enforced is not, because with the authenticator gone and no codes captured the outcome rests on the provider’s recovery process rather than on anything the team controls. Google documents its own version as questions used to confirm the account is yours, and says those steps may not work for a work or school account.
So write the list before reading on: one line per brand account, who holds each factor, whether the codes exist somewhere you can point at. The audit is the work.
What the platforms actually model
The alternative to a shared credential is a role granted to a named person on a business asset. Each cell below is read off the platform’s own documentation, fetched 2026-08-26, or marked unsourced.
| Platform family | Where access is granted | Unit of access | On removal |
|---|---|---|---|
| Meta assets in a business portfolio | Not sourced. Meta’s own permissions and access token pages would not load on 2026-08-26, so nothing here is stated. | Not sourced. | Not sourced. Treat as credential held until Meta’s page says otherwise. |
| LinkedIn Pages | Page admin and paid media admin roles, granted by an existing admin. | Super admin, content admin, analyst, plus sponsored content poster, lead gen forms manager, landing pages manager. | Super admin is documented as able to add and remove any type of admin. |
| YouTube channels | Channel permissions in YouTube Studio, which YouTube states let several people manage a channel without access to your Google Account. | Owner, manager, editor, editor with limited access, subtitle editor. | Added and removed per person. YouTube states granting permissions is safer than sharing your password. |
| Any other platform you hold | Check that platform’s own help page. | Same source. | Not sourced here. Treat it as credential held until the vendor says otherwise. |
Why the vault is the wrong instrument for platform access
A shared credential makes every holder the account, so removing a holder requires changing the account. A role makes each holder a distinct grantee, so removing a holder is a revocation.
Two consequences follow. With a shared login the platform’s own activity record attributes every action to the brand account, so the team cannot answer who published a post. And revoking one person means a new password, the second factor re-enrolled on every remaining device, and fresh codes, which is why teams put it off.
The concession: delegation exists only where the platform ships it, and plenty of services have no role model at all. This argues about the shape of the mechanism, not about vendor quality.
The recovery path is the asset
What decides whether you keep the account is the recovery factors, each of which needs a named owner: the account email address and who reads that mailbox, the recovery phone number and whose handset it is, the authenticator app and whose device holds the seed, hardware security keys and who has them, and the backup codes and where they sit. Each should resolve to a company mailbox or a shared device policy, never a personal number or mailbox, contractors included.
Google states the mechanics: backup codes are the fallback when normal two step verification is unavailable, a code goes inactive once used, a new set of ten can be generated at any time, and generating a new set inactivates the old one. Regenerating codes therefore cuts a departing person out of the recovery path immediately.
Where a factor is already tied to someone leaving, rotate it while they are reachable, and verify the new factor works before the last day. The window closes when they go.
Where a shared vault entry is still the right answer
Three categories commonly ship no per person role on lower tiers.
- Link shorteners and branded short domains. Losing the domain breaks every published link, so check what your tier includes. Our link management pricing piece has the tiers.
- Small analytics and form tools. One login, opened by whoever needed a dashboard, often holding submissions that are company data.
- Adjacent single seat services bought on a card for one project. Same problem class as the adjacent tooling priced on this blog.
Four safeguards make a shared credential survivable: one item per service rather than one per team, so revocation has a defined scope; a named owner in the item; the recovery factors stored alongside, current codes included; and a written rotation trigger tied to offboarding.
Vault vendors document features for exactly this. Bitwarden’s emergency access lets a grantor invite a trusted emergency contact with view or takeover access, where takeover requires that contact to create a master password, replacing the previous one and removing any two step login methods previously set up. 1Password’s recovery codes regain access when you cannot sign in, and 1Password limits them to individual and family accounts, with business accounts recovered by administrators.
An offboarding pass you can run this week
Run this against a real departure date, in order.
- List the accounts and mark each role held or credential held. If the platform’s access screen cannot tell you, it is credential held.
- Confirm a company held recovery factor on every account first, because the rest of the pass can lock you out.
- Revoke the person’s role wherever a role exists. No credential change is needed there.
- Rotate the credential and re-enrol the second factor wherever no role exists, then store the fresh codes with the named owner.
- Remove connected app and third party authorisations the person created. They do not disappear with the role.
- Re-authorise the publishing and scheduling connections, which hold their own connection authorised by a specific person and can outlive the removal. Re-authorise under a remaining person’s access, verify with a real post, and check the tool’s documentation for revocation behaviour.
- Have someone else complete a cold login on every account, from a device the company controls. This is the skipped step: not an open session, a fresh sign in through the second factor.
The pass is done when every account has been revoked or rotated and has had a cold login by a remaining person.
What doing this properly costs
On the two platforms sourced above, delegation is part of the platform’s own tooling, not a paid add on: neither LinkedIn’s Page admin roles article nor YouTube’s channel permissions page states a price. For Meta, nothing is claimed here, because its own pages would not load on the day this was checked.
The vault side has numbers. Bitwarden’s pricing page lists Teams at $4 per month per user and Enterprise at $6 per month per user, both billed annually. 1Password’s business pricing page lists Business at $8.99 USD per user, per month, paid annually. Those billing units are the vendors’ own. Dashlane’s pricing page loaded but its plan prices and billing units were not readable from it, so no Dashlane figure appears.
A company controlled mailbox to own the recovery path is a cost line too. No figure appears here because it would have to come from the provider’s own page.
Prices verified 2026-08-26. These figures are not Watchdog data and are not on the re-verification schedule.
Disclosure: followedapp is published by the team behind RecurPost. RecurPost is a covered vendor here under the same rules as every other vendor.
Start with the list, not the tooling
None of this needs a purchase. Write one line per brand account, marked role held or credential held. If most of it is adjacent tools, start with link management pricing.
FAQ
Is sharing a login through a password manager ever acceptable?
Yes, for services that ship no per person role, with conditions: one item per service, a named owner, the recovery factors including current backup codes in that item, and a rotation trigger at offboarding. Handled that way it is a managed risk. With the codes missing it is not.
The departing person’s phone is the authenticator. What now?
Act while they are reachable. Sign in with them present, enrol a company held authenticator or hardware key, regenerate the backup codes so the previous set is inactivated, store the new set with the named owner, and confirm a cold login before their last day. If they have gone and no company held factor or code exists, recovery depends on the provider’s documented process, for a Google account the identity questions on its account recovery page.
Sources
- LinkedIn Page admin roles. Fetched 2026-08-26.
- YouTube channel permissions. Fetched 2026-08-26.
- Google backup codes. Fetched 2026-08-26.
- Google account recovery. Fetched 2026-08-26.
- Bitwarden emergency access. Fetched 2026-08-26.
- 1Password recovery codes. Fetched 2026-08-26.
- Bitwarden pricing. Fetched 2026-08-26.
- 1Password business pricing. Fetched 2026-08-26.