Account security examples: what the cases show

The cases below are invented. They are composites of the shapes account loss actually takes, written from the position of the person it happens to, because that is the only position you will ever be in.

Each one is here for the same reason: there was a moment where an ordinary check would have ended it, and the moment did not look like a decision at the time.

What to take away

• Almost every one of these turns on a route that was never the password: a recovery contact, a session, a code, a permission.
• The hinge is usually a small courtesy under time pressure, not a technical failure.
• Cleanup that stops at the password leaves the intruder in place.

The code that arrived on its own

A message arrives saying a verification code has been sent by mistake and asking you to read it back. The code is real. It is in your messages. It arrived because someone is signing in as you at that exact moment, and the sign-in is waiting on the number in your hand.

The hinge is that the code is genuine, so it feels like evidence that the request is genuine. It is evidence of the opposite.

What the response has to include: change the password immediately, because whoever is asking already has it, then sign out other sessions, then check whether the recovery email or phone was changed in the minutes around it.

The old address nobody removed

An account is lost without the password ever being wrong. The reset went to a recovery address set up years earlier: an old work address, a university address, an address on a service that has since been abandoned and reclaimed by someone else.

The hinge was years earlier, on a screen that asked for a backup address and was answered with whatever was to hand.

What the response has to include: recovery of the account through the provider's own account-recovery route, then a pass over every other account for stale recovery contacts, because they were all set up in the same period with the same habits.

The password change that changed nothing

Suspicious activity, a new password set the same evening, relief. A week later the same activity resumes.

Existing sessions were never ended. On many services a session continues until it is explicitly signed out, and a session can set a new password of its own.

The hinge is a reasonable belief about what a password change does. The correct sequence is on account security, and the short version is: change it, then sign out everything, then check what was altered while they were inside.

The integration from a finished project

A business page starts publishing things nobody on the team posted. Every current member has a strong password and a second factor. The posts came through a scheduling tool authorized two years earlier for a campaign that ended, by someone who has since left.

The hinge is that connected access does not go through anyone's login, so nothing about improving the team's passwords touched it.

What the response has to include: revoke the integration, review every other connected app and every page role, and set a date to do it again. The audit order is in the social media account security audit.

The support conversation that worked

Access is restored to somebody else by a person at the provider who believed they were helping the account holder. The details they were given were ones that had been published: a birthday, a home town, an old handle, the year an account was created.

There is no setting that closes this. What reduces it is having less of that material publicly attached to you, and having stronger proof of your own ownership on file than an attacker can assemble. The material feeding this is exactly what is described in impersonation scams.

The number that stopped being yours

Messages stop arriving. The phone shows no service. Somewhere, a number has been moved to a different device, and every account using text messages for reset now sends its codes elsewhere.

The hinge is that a phone number was treated as an identity anchor. It is a routing address, and it can be re-routed by people who are not you.

What the response has to include: contacting the carrier immediately from another line, then working through accounts in order of value with the assumption that anything protected by a text code is exposed. Prevention is a carrier-level port lock where offered, plus moving the important accounts off text codes.

The convincing sign-in page

A message about a copyright complaint, an account restriction, or a payout on hold. A page that looks correct. A password typed into it, and then a code typed in as well, because the page asked for one and that is what the real one does too.

The hinge is that everything about the page was right except the address. A password manager would have declined to fill it, and a passkey could not have been used on it at all. That is the argument for the tooling in phishing scams rather than for trying harder to look carefully.

What all of them share

Read together, the pattern is small.

• The password was rarely the way in, and improving it rarely ended it.
• Recovery settings were the first thing altered once someone was inside, because that is what makes access survive your response.
• The victim did something reasonable. Reading a code out, keeping an old address, trusting a page that looked right, and answering a support question are all normal behavior.
• Everyone who recovered well had done one thing in advance: kept backup codes, or knew what proof of ownership they held.

The recovery route for the cases that reach a provider is the FTC's guidance on recovering a hacked account, and the sign-in change that would have ended several of them is described in CISA's advice on multi-factor authentication.

Common questions

How would I know it is happening rather than reading about it afterwards?

Codes you did not request, sign-in alerts you cannot explain, mail that stops arriving, contacts telling you they got a strange message from you, and settings that are not what you left them as. Any one of those is enough to start checking.

Is it worth reporting when nothing was lost?

Yes, and it takes two minutes. The report feeds filtering and the address or number is about to reach someone with more at stake.

Someone got in but I got the account back. Am I finished?

Not until you have checked what changed while they were there: recovery contacts, forwarding rules, connected apps, sessions, and anything financial. Regaining access is the first step, not the last.

Are these real incidents?

No. They are composites written as illustrations, with no real person, company, or event described. They are here for the decision points, which are the same whoever it happens to.