
Costs
Part of Account security: the six ways into an account
Account security lessons from shared logins and staff departures
Account security case studies for arrangements rather than individuals: shared logins, client access, a departure, and helping an older relative.
Security advice is usually written for one imaginary person with one laptop. Real situations have other people in them: clients, family, staff, a parent who needs help, a job you are leaving.
The five account security case studies below are invented, and each one changes what good security looks like. The controls are the same; the order and the emphasis are not.
What to take away
- The right setup depends on who else holds access, not on how careful you personally are.
- Every arrangement needs an exit plan written while everyone is still on good terms.
- Shared logins are the common failure in four of these five.
The freelancer with client access
You hold logins or roles for several clients. Their security is now partly your problem, and yours is partly theirs.
Freelancer client access setup
- Request named access in writing
- Use individual logins, not shared
- Enable strongest second factor
- Keep list of access held
- Ask removal on last day
- Confirm removal happened
What breaks: a compromise of your own account reaches every client at once, and a client with a shared password cannot revoke you specifically when the work ends, so it never happens.
What to set up: individual named access rather than a shared login, on every client, requested in writing at the start — a role in the client's Google Workspace, Meta Business Suite, or LinkedIn Page admin rather than a password. Your own account gets the strongest second factor available — a hardware security key such as a YubiKey, or an authenticator app like Google Authenticator or Microsoft Authenticator, ahead of a code by text message — because it is now a route into other organizations. Keep a list of what you hold access to, so offboarding is a task rather than an act of memory.
The exit: ask to be removed on the last day, in writing, and confirm the removal the same day. Access you still have after a contract ends is a liability you are carrying for free, and it is the thing you will be asked about if anything goes wrong later.
The family with shared everything
Streaming, photos, a shopping account, a family plan, and one password everybody knows.
Shared family account fixes
- Create separate profiles or accounts
- Use distinct password for card accounts
- Never read out codes to anyone
- Add legacy or inactive contacts
- Review what is published about family
What breaks: the account inherits the security of the least careful person on it, and there is usually a payment method attached. Teenagers and grandparents both get targeted, and neither loss stays contained.
What to set up: separate profiles or individual accounts wherever the service allows it, and a distinct password for anything holding a card. Agree a family rule about codes: nobody ever reads one out, to anyone, including each other. Add legacy or inactive-account contacts while it is a boring administrative task: Google's Inactive Account Manager, Facebook's Legacy Contact, and Apple's Digital Legacy.
The other half of this is what gets published about the family, particularly children, routines, and travel. That belongs to the discussion in privacy settings.
The small team with one social login
Two or three people post from the same account because setting up roles looked like effort.
Shared social login fixes
- Use platform role system
- Give lowest role that works
- Make second factor account-level
- Use unique password if no roles
- Document password change on exit
- Check scheduling and analytics tools
- Review agency and admin access
What breaks: nobody can be removed individually, the password gets shared in a chat, and the second factor is attached to whoever set it up, who may be on holiday when it is needed.
What to set up: use the platform's own role system — Meta Business Suite roles on a Facebook or Instagram page, LinkedIn Page admin roles, or a Google Workspace account — and give each person the lowest role that does their job, such as Analyst or Editor rather than Admin. Make the second factor an account-level thing rather than one person's phone: an authenticator app or a hardware security key the business holds, with backup codes stored where the team can reach them. Where the platform genuinely has no roles, that account needs a password used nowhere else and a documented change whenever anyone leaves.
Then check the things that outlive people: connected scheduling and analytics tools, agencies with access, and any personal account holding an admin role. The pass for this is the account security tools inventory, run on the business account rather than a personal one.
Somebody leaving a job
The week around a departure is when access problems are created, in both directions.
Departure access timeline
- Before last dayMove personal accounts off work email
- Before last dayRe-register second factors
- Before last dayExport legitimately personal data
- On last dayRemove roles and integrations
- On last dayConfirm removal complete
- If not amicableRemove access before conversation
What breaks for the organization: roles, integrations, and shared credentials that nobody removes. What breaks for the person: accounts registered to a work email address, second factors tied to a work phone, and personal material sitting in a work account.
What to set up, before the last day: move any personal account off the work email address and onto one you keep, re-register second factors, and export anything that is legitimately yours. On the organization's side, removal is a checklist item on the day, not a favor: disable the account, take the person out of every role in Google Workspace or Meta Business Suite, and where a shared credential genuinely remains, keep it in a password manager the business controls, such as 1Password or Bitwarden, and change it the same day.
The uncomfortable case is a departure that is not amicable. Then the timing is the control: access removed before the conversation, not after it, and a review of anything that person could have changed on their way out.
Helping an older relative
You are asked to help with an account, or you find out something has gone wrong.
Helping older relative safely
Service offers trusted or legacy contact?
Use that role, not the password
Set up alerting to both of you
What breaks: the usual answer is to take over the password, which solves the immediate problem and creates a permanent one. It removes the person's independence, it puts their credentials in your hands, and it makes future incidents harder to see.
What to set up: where the service offers a trusted or legacy contact role — Google's Inactive Account Manager, Facebook's Legacy Contact, or Apple's Digital Legacy — use that instead of taking the password. Set up alerting that reaches both of you. Agree one rule that covers most of the risk: no code, no payment, no installation, without a phone call to you first, and no offense taken when the call happens.
Then be careful about the aftermath of any incident. People who have lost money are contacted again by businesses offering to recover it, and that second approach is a scam more often than not. What to do instead is in scam reporting and recovery.
What runs through all five
- The person who set something up is not always the person who will need to fix it.
- Access granted informally is never removed formally.
- The second factor should belong to the account, not to one person's device.
- Every arrangement needs the answer to one question written down: what happens when this person leaves, changes their number, or cannot be reached.
The sign-in baseline that all five arrangements assume is set out in CISA's Multifactor Authentication (MFA) Toolkit, and the recovery route to use if one of these accounts is actually lost is the FTC's guidance on recovering a hacked email or social media account.
Where a shared or public-facing account is involved, add one more: an agreed way for the people around you to check a message that appears to come from you. Cloned and taken-over accounts are the delivery route for most of what follows, which is covered in impersonation scams.
Common questions
Is it ever acceptable to share a password?
Only where the service offers no alternative, and then with a password used nowhere else and a written note of who holds it. Anything with roles should use roles.
How do I ask a client for individual access without sounding difficult?
Frame it as their protection, because it is. Individual access means they can remove one person without changing anything for everyone else, and it shows who did what.
My relative refuses to change anything. What is the minimum?
Alerts that reach you, a unique password on their email, and the call-before-acting rule. Those three cover most of the realistic risk without touching their independence.
Should a business account use a personal phone for its second factor?
Only as a stopgap. Move it to an authenticator app or a hardware security key the organization controls, and keep printed backup codes somewhere the business can reach. The reasoning is set out in account security.
Are these based on real organizations?
No. They are constructed situations, written to show where the decisions sit. No real company, person, or incident is described.







