Costs

Part of Account security: requirements and practical steps for 2027

Account security case studies: findings and lessons

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 situations 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.

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. Your own account gets the strongest second factor available, 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 and confirm it. 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.

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.

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.

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, give each person the lowest role that does their job, and make the second factor an account-level thing rather than one person's phone. 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.

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.

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.

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, 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 guidance on multi-factor authentication, and the recovery route to use if one of these accounts is actually lost is the FTC's guidance on 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 something 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.

More in Costs

Features

Account security: requirements and practical steps for 2027

Account security ordered by the way accounts are actually lost: the email account, the recovery route, second factors, sessions and connected apps.

Costs

Account security guide: what matters in 2027

A social account security audit run in the intruder's order: sessions, recovery routes, connected apps, and the settings that would be changed first.

Guides

Account security changes 2027: facts and context

Account security decays on its own: the drift list, how to handle an announced change without being caught by a fake version, and what ages worst.

Reviews

Account security examples: what the cases show

Account security incidents written from inside them: the code, the stale recovery address, the reused session, and the moment each one turned.