First Moves After a Suspicious Digital Event

01

What are the first moves after a hacked account?

A suspicious digital event is handled in a fixed order: contain the access, then the data, then the people. Change the password of the affected account from a clean device, revoke active sessions, and check for hidden forwarding rules before anything else. Only after containment does it make sense to choose between MFA, passkeys and a password manager, or to decide how a small team reports what happened.

The order matters because most damage after a breach comes from the attacker keeping a way back in. A password change that leaves an old session open, or a mailbox rule that quietly copies every incoming message, undoes the work. A reference guide such as Security, Applied treats these first moves as a sequence rather than a checklist, which is the right frame: each step closes a door the previous one opened.

Start from a device you trust, not the one you suspect. If the account is email, that mailbox is usually the recovery route for every other service, so it is the first to secure.

Change the password to something long and unique, generated rather than remembered. Then open the account’s active sessions or connected devices list and sign out everything. A password change alone does not always terminate sessions that were already authenticated, and an attacker who stays logged in keeps reading mail.

Next, inspect the recovery settings. Check the recovery email address and phone number, and remove anything you do not recognise. Check for forwarding rules, filters and delegated access: a rule that forwards copies of incoming mail to an outside address is a common persistence trick, and it survives a password change. Check app passwords and third party connections, and revoke the ones you cannot identify.

Finally, check the sent folder and the account’s recent activity log for messages you did not write. If the account was used to contact colleagues or clients, tell them plainly and early. A short message that says the account was compromised and to ignore recent links does more good than a careful one sent a day later.

02

How do MFA, passkeys and password managers compare?

These three tools solve overlapping problems, and the comparison is about what each one protects against.

Multi factor authentication adds a second proof of identity at login. Its strength depends on the second factor. Codes sent by SMS can be intercepted or SIM swapped; codes from an authenticator app are stronger; a hardware security key bound to the site’s domain resists phishing because it will not authenticate to a lookalike address. Where a service offers several options, the hardware key is the one to pick.

Passkeys replace the password with a cryptographic key held on the device, unlocked by a fingerprint, face or PIN. There is nothing to type into a fake login page, so phishing loses its main lever, and there is no shared secret to leak from a server. The limits are practical: not every service supports them, and losing every device that holds the key means going through account recovery. Keeping a second device enrolled, or a hardware key as backup, removes that risk.

A password manager addresses a different failure, which is reuse. One long unique password per service is not something a person can hold in memory, and a manager is what makes that possible. It also fills credentials only on the matching domain, which blocks a class of copycat pages.

The three combine rather than compete: a manager for unique passwords, MFA or passkeys for the login itself, and a hardware key where the account is important enough to justify one.

03

What to do in the first hour of a ransomware attack?

Disconnect the affected machine from the network, including wifi and any cable, and leave it powered on if encryption is still running. Pulling the plug can destroy keys held in memory that a specialist might recover, and it does not stop encryption that has already finished.

Do not pay, and do not negotiate on your own initiative. Payment does not guarantee a working decryption key, and it marks the organisation as willing to pay.

Identify what is encrypted and what is not, and isolate shared drives, backup targets and cloud sync folders so the encryption cannot follow the sync. Check whether the backup itself is reachable from the infected network: an online backup that the compromised machine can write to is not a backup in this situation.

Report the incident. In many jurisdictions a personal data breach carries a notification duty with a deadline, and the national cyber security authority or the data protection authority is the place to start. Keep a written timeline of what was observed and when, because the reconstruction will be needed for the report and for insurance.

Restore from a backup that predates the infection, on clean hardware, and verify the restored data before reconnecting. Restoring onto the same machine, or onto a network the attacker still reaches, invites a second round.

04

How should a small team prepare without a specialist?

Preparation for a team of five to fifty people is mostly a matter of writing down decisions that would otherwise be improvised at the worst moment.

A one page response plan is enough to start. It names who decides, who speaks to clients, who calls the bank and the insurer, and where the contact details are kept, on paper, because the internal wiki may be the thing that is encrypted. It lists the accounts that matter and how to reach their recovery routes.

A ransomware preparation list covers the same ground from the data side: what is backed up, where the copies live, who can restore them, and when the last restore test happened. A backup that has never been restored is an assumption, not a control.

A phishing reporting route gives people somewhere to send a suspicious message in one click, without fear of blame. Most reports will be false alarms, and that is the point: the route only works if reporting is cheap and ordinary.

A security baseline and an index of actions turn the plan into something reviewable. The baseline states what every machine and account must have, such as updates, disk encryption and MFA on email. The index records what has been done, by whom and when, so the next person can see the state of things without asking.

05

Why the order of steps is the whole method

Incident response fails less often from missing tools than from wrong sequence. Securing the mailbox before chasing the malware, isolating the network before restoring, and writing the plan before the incident are all ordering decisions, and each one is cheap when taken early.

The same logic applies to the choice between MFA, passkeys and a password manager: they are not alternatives to rank, but layers to apply in the order that closes the largest gap first. For most individuals and small teams, that means unique passwords and MFA on the email account, then passkeys where they are offered, then a hardware key on the accounts that would be most damaging to lose.

None of this requires a specialist on staff. It requires a written order of operations, tested once, and kept where it can be found when the network is down.