Social Media Security: Protecting the Account and Everything It Owns

Why the social account is the softest target you own

Compare the controls on your bank account with the controls on your Instagram account. The bank has device binding, transaction monitoring, step-up challenges, a call centre that will freeze everything on one sentence, and a legal obligation to reimburse fraud. The social platform has a password, an optional second factor, an email address, and a support form. Then consider what the account is actually worth: a business page with an ad account behind it can be monetised within hours by running fraudulent campaigns on the attached card, and a personal account with a large following can be sold, used to push scams to everyone who trusts you, or held for ransom.

The asymmetry is worse than it looks because the account is a key to other things. Services that let you sign in with a social identity trust it as an authenticator; your direct messages are a phishing channel aimed at people who know you; your profile metadata is used by platforms and data brokers to build an identity that can be used for impersonation. Compromise of a social account is rarely the end of the incident - it is the beginning of a chain that moves into email, then into financial accounts, then into anything with a "forgot password" flow that trusts the email.

That is also why the defences in this guide are mostly procedural rather than heroic. There is no configuration that makes an account safe. There is a set of decisions - which factor, which session lifetime, who holds admin, what you publish, how fast you can revoke - that moves the account from "one phishing email away" to "one phishing email away from a bad afternoon".

Seven ways accounts actually get taken in 2026

Investigations of account takeovers fall into a small number of mechanisms, and knowing which one you are facing changes the response entirely, because they leave different traces and require different cleanup.

Infostealer malware. Malware on a laptop or phone harvests saved passwords, autofill data and - crucially - session cookies, then uploads the bundle to a criminal market. The scale is industrial: Outpost24's 2026 credential exposure report found at least one employee or customer login exposed through infostealer logs at 72% of the 4,824 US and European companies it analysed, with 41% having a credential tied to a staff email address, and Flashpoint counted 7.4 million hosts infected in the first half of 2026 alone with 1.7 billion credentials and identity records extracted. Most of those credentials are old and useless. The session cookies are not.

Session cookie replay. This is the mechanism that makes the previous one dangerous. When you log in, the platform gives your browser a token that says "this is a valid session" and does not ask again. If an attacker copies that token, they are inside - no password, no second factor, no notification in most cases - and they can keep renewing it while your own session carries on working. Multi-factor authentication protects the login event; the cookie is what exists after the login event. That distinction is the single most important sentence in this guide.

Notification-driven phishing. The most effective lures in 2026 do not look like phishing because they are not fake. Huntress documented a campaign in July 2026 in which attackers used Meta's own Business Manager partner-request feature: the victim receives a genuine notification from Meta, delivered by Meta's infrastructure, passing SPF, DKIM and DMARC, asking them to approve a partner request. Approving it grants the attacker persistent partner access to the Page, the ad account, the pixel and the audiences. Nothing in the recipient's mail filters can stop it, because nothing about it is forged. The only control is knowing that you did not initiate a partnership.

One-time-code conversations. Someone contacts you as support, a colleague, a recruiter or a delivery courier and needs the six-digit code that just arrived, because "the system needs to verify you". The code is the account. Variations target voicemail, call forwarding and the phone's SMS-forwarding settings, so the code is copied silently without any request at all.

SIM swap and number recycling. A carrier representative is persuaded or bribed to port your number, or a dormant number is reassigned to a new owner who can then receive the recovery messages for accounts still anchored to it. Both put an attacker in the position of the person who receives your recovery codes.

OAuth and delegated access. You approve an app - a scheduler, a follower-analytics tool, a "who viewed my profile" curiosity - and it receives a token that can read your messages or post as you. The app is later breached, or was malicious from the start, and the token still works after you change your password. Legacy "log in with" grants are the quietest persistence mechanism on the internet.

Insider and agency access. In business settings, the intruder is often someone who was legitimately given access: a departing employee, a freelancer, an agency, a reseller. Their access was granted through a role rather than a password, which is why it is invisible to every control that focuses on the account owner's credentials and why offboarding has to include the ad account.

What MFA protects, and the case where it protects nothing

Multi-factor authentication is the highest-value control available on a social account, and it is also the most over-trusted. It protects the moment of authentication: a password alone is no longer enough to establish a new session. Against credential stuffing, password reuse and most phishing, that is decisive. Against a stolen session cookie it does nothing, because the attacker is not authenticating - they are presenting a session the platform already believes in.

The factors are not equivalent either. SMS codes are the weakest practical option: they can be intercepted at the carrier, swapped, forwarded, or read out by the account holder under social pressure, and they do not survive a determined SIM swap. Authenticator apps are better - the code is generated on a device the attacker does not have - but they are still phishable in real time, because a convincing page can relay the code as you type it. Passkeys and hardware security keys are the strongest, because the credential is bound to the origin: it will not authenticate to a lookalike domain, and there is no code to read out to anybody.

Two consequences follow. First, upgrade the factor on the accounts that matter - email, then the social accounts that gate business assets - and accept that a passkey makes recovery harder if you lose every device, so register at least two. Second, stop treating MFA as the finish line: any account whose security plan ends at "2FA is on" has no plan for the mechanism that is actually being used against it.

Passkeys in 2026: synced, device-bound, and when each matters

The passkey rollout stopped being a curiosity in 2026. In April 2026 Meta announced that Accounts Center becomes the Meta Account over a year-long transition, that passkeys extend to Instagram alongside Facebook and Messenger, that security settings consolidate under a single Security Checkup, and - the detail that matters most - that accounts enrolled in Advanced Protection must create a passkey. Advanced Protection is Meta's tier for accounts at elevated risk: public figures, journalists, activists, businesses whose Page is a revenue channel. Making a passkey mandatory there is a statement about which factor the platform now considers adequate for its most attacked users.

The distinction inside "passkey" is worth understanding because it decides your recovery story. A synced passkey lives in a platform keychain - iCloud Keychain, Google Password Manager, a password manager - and syncs across your devices, which makes it convenient and means that the security of the passkey is the security of that account. A device-bound passkey stays in the secure hardware of one device and cannot be copied, which is stronger against remote theft and worse if the device is lost or destroyed. Most consumer platforms default to synced. For a business account where compromise is expensive, the stronger configuration is a hardware security key plus a synced passkey as a backup, with both registered before you need either.

Chrome's device-bound session credentials point at the same idea from the session side: bind the session token to the device so that a cookie copied from an infostealer log cannot be replayed on the attacker's machine. It is not universal and it is not a substitute for revocation, but it is the direction the industry is moving, and it is a reasonable question to ask a platform vendor: is a session token bound to the device that created it?

The practical order of work is: passkeys on email first, because every other recovery path runs through it; then on the social accounts that hold money or business assets; then on the rest. Register two credentials, keep the recovery codes offline, and test one login from a device you have never used so that you discover the recovery experience before you need it in an emergency.

The session audit that catches a takeover in progress

Every major platform exposes a list of the devices and sessions currently signed in, and almost nobody looks at it. It is the single most useful security screen on the internet, because it is the only place where a stolen cookie becomes visible: the intruder's session appears as a browser, a city, a device type, and a last-active time.

The audit takes two minutes per platform. On Meta, Accounts Center shows where you are logged in across Facebook and Instagram together, with device, location and login time, and lets you log out individual sessions or all of them except the current one. Google shows devices and third-party sessions in Security. LinkedIn shows where you are signed in and lets you end sessions individually. X shows sessions and connected apps. TikTok shows devices, and Snapchat shows connected devices. The pattern is identical everywhere: recognise every entry, remove anything you cannot name, and change the password from the cleaned device afterwards.

Two habits make the audit useful rather than decorative. Do it on a schedule - quarterly, and immediately after any trip, any device change, or any notification that a login happened somewhere new. And read the geography rather than the device name: an attacker on the same continent with a plausible browser string is exactly what a hijacked session looks like, while a login from a city you have never visited is the thing that catches it.

The related screen is the recovery configuration, and it is where most takeovers are made permanent. Check the recovery email and phone number on every account - an attacker who adds their own recovery address can come back after you have changed the password - and check for forwarding rules, app-specific passwords and "trusted devices" that you did not add. On business accounts, also check who holds a role, because a role is not a session and will not appear in the device list at all.

Connected apps: the persistence layer nobody reviews

Third-party access is the part of an account's security that a password reset does not touch. When you approve an app, the platform issues it a token that survives password changes, and in many cases survives being logged out everywhere. The token typically grants a scoped but real permission: post on your behalf, read your direct messages, see your ad accounts, list your followers. The app stores it in a database, the app is breached or the app was malicious, and the attacker now has a key that no security setting you can toggle will revoke.

The audit is short and worth doing today. On Meta, Apps and Websites lists every app you have used Facebook or Instagram to sign into, with the permissions granted; remove anything you do not recognise or no longer use, and set the option to require re-authorisation. On Google, third-party apps with account access shows the same thing for the identity that gates your other accounts. On X, LinkedIn and TikTok, connected apps and services appear under security or privacy settings. On Microsoft, enterprise apps and consented permissions appear in your account's privacy settings - and for an organisation, in the tenant's enterprise applications list, which is the only place where an admin-consented grant is visible at all.

For organisations, the controls are stronger and less known. Restrict user consent to verified publishers so that an employee cannot grant a random app access to corporate data. Review enterprise application consents quarterly. Revoke orphaned grants left by departed staff, because a departed employee's token is a live credential with no owner. And treat any app that asks for messaging permissions as a data-processing decision, not a convenience, because reading direct messages is exactly what a social-engineering operation wants from a compromised follower.

Business assets: Pages, ad accounts, pixels and agencies

The business side of a social platform is a separate estate with its own rules, and it is where the money is lost. A Meta business portfolio can hold Pages, ad accounts with attached payment methods, pixels and conversions APIs, catalogues, WhatsApp business numbers and audiences. Access is granted through roles and through partner relationships, and a partner relationship is the most dangerous grant in the system because it is designed to be persistent, to be administered by the partner, and in some configurations to be invisible to the asset owner's own admin list.

The July 2026 partner-request campaign exploited exactly that design. The request was genuine, the notification was genuine, the approval was one click, and the grant gave the attacker a durable relationship with the business's assets rather than a session that could be killed. The defensive posture is administrative: know every partner your business portfolio has, review the list monthly, require two approvals for any new partner, and teach the people who receive business notifications that a partner request they did not initiate is an incident even though it looks official.

The financial controls matter as much as the access controls. Attach a virtual card with a low limit to the ad account rather than the corporate card with the treasury on it, set spend limits and billing alerts, and reconcile ad spend weekly - fraudulent campaigns on a hijacked account often run for days before anyone notices because the only signal is a line on a statement. Keep at least two human admins on every Page and ad account, both with passkeys, so that one compromised person cannot lock the organisation out of its own property. And record the asset inventory: which Page belongs to which legal entity, which ad account bills to which card, which domain is verified, which agency has which role. In a takeover, the inventory is the difference between a two-hour recovery and a two-week one.

Offboarding belongs here too. When someone leaves, the password reset is the easy part; the harder part is removing their role from the Page, the ad account, the analytics property, the catalogue and the partner relationship, and then checking that no personal email or phone number remains as a recovery contact for a corporate asset. Most organisations discover this gap during an incident, when the former employee's still-valid access is the first thing the investigating team finds.

Impersonation, duplicate profiles and synthetic media

The attack that costs the least and spreads the fastest is not a takeover at all. It is a copy: a duplicate profile with your name, your photos and a slightly altered handle, used to message your contacts, solicit your customers, or run a scam in your brand's name. In 2026 the copy is often better than the original, because synthetic media has made it cheap to produce a video of a chief executive announcing an acquisition, or an audio clip of a relative asking for money.

Reporting works, but the quality of the report decides the speed. A useful impersonation report contains the URL of the copy, the URL of the authentic account, a short statement of the relationship and the harm - which of your customers or contacts were approached, and with what request - and evidence that you control the original: a verified badge, a corporate domain email that matches the website, or a document tying the brand to the entity. Platforms prioritise reports that arrive through their intellectual-property or verification channels over generic "report this profile" flows, and a brand with a registered trademark has a faster path than one relying on goodwill.

Under the EU Digital Services Act, very large platforms owe you a notice-and-action process and a statement of reasons for their decisions, which means a rejection is supposed to come with an explanation and an appeal path. That is worth using: an appeal with better evidence gets more attention than a first report, and the paper trail matters if the impersonation caused a loss you need to recover.

The preventive measures are unglamorous. Register the handles that look like your brand across the platforms you use and the ones you might use, because a handle you do not own is a phishing domain waiting to be created. Turn on the platform's impersonation monitoring where it exists. Publish a canonical list of your official accounts on your own domain, so that customers and staff have somewhere to check that does not depend on the platform. And brief the people who handle customer messages on what a synthetic-media approach looks like, because the first report usually comes to them.

Privacy defaults that leak more than people think

Privacy settings are security settings when the data they expose can be used against you. Three categories matter more than the rest.

Audience defaults. A post that defaults to public is indexed, cached, scraped and mirrored, and "delete" removes your copy rather than everyone's. Check the default audience for new posts, for stories, for reels and for comments, because the defaults are per-surface and they change with product launches. On a business Page, understand that the default is public by design and that the only real control is what you choose to publish.

Discovery and contact matching. Letting a platform match your phone number or email against its address book publishes a relationship without your consent - the other person's contact list now contains you, and yours contains them. This is how a personal account becomes findable by someone who has only your number, and how a private profile becomes a map of who knows whom. Turn off "let others find me by phone number or email" on every platform where the option exists, and think before syncing contacts on a device you use for work.

Tagging and check-ins. A friend's tagged photo or a check-in publishes your location and your associations, and it does so from their account, which means your own privacy settings do not apply. Require review before tags appear on your profile, turn off automatic check-in sharing, and strip location metadata from images before publishing - most platforms remove it, but not all, and not always.

None of this is about hiding. It is about deciding what a stranger can assemble: a name, a workplace, a daily route, a family relationship, a holiday date. The assembly is the risk, not any single field, and the person assembling it is usually doing so before they contact you, not after.

The email account is the root of trust

Every social account has a recovery path, and almost every recovery path terminates in an email address. That makes the mailbox the highest-value credential you own, and the one whose compromise makes every other control decorative: an attacker with your email can reset the social account, silence the notifications that would have told you, and re-establish access after your first clean-up.

Four controls do most of the work. Enable the strongest factor your provider supports - a passkey or hardware key, then an authenticator app, then SMS as the fallback you are trying to eliminate. Review the recovery options and remove anything you do not recognise: a recovery phone number you no longer control, a second email address that was added years ago, an app password created for a printer in 2019. Check the forwarding rules and filters, because a silent forward of security alerts is the classic persistence trick and it is invisible from the outside. And check the account's active sessions, for the same reason you check them on social platforms.

There is a domain-level version of this for businesses. Publish SPF, DKIM and DMARC at enforcement, because a domain that anyone can spoof is a domain whose "official" emails cannot be trusted by your own staff - and the partner-request campaign above succeeded precisely because staff had been trained to trust mail that authenticated. Enable DMARC reporting so that you see who is sending as you. And keep the domain registration and DNS under corporate control with registrar locks and two administrators, because a hijacked domain compromises every account that uses an address on it.

Phone numbers, SIM swap and recycling

The phone number is the weakest identity anchor in common use and it is attached to everything. A SIM swap moves your number to an attacker's SIM, at which point they receive every SMS code and every recovery message, and your phone simply loses signal. The attack is usually social: a call to a carrier's retail channel with enough personal detail to pass a verification script, sometimes with a bribe, sometimes with a compromised employee credential.

What you can control is smaller than people hope and worth doing anyway. Ask your carrier for a port-out PIN and, where it exists, a port freeze or a "no port without in-store verification" flag; carriers vary, and asking is free. Remove SMS as a factor wherever an authenticator app or passkey is available, and remove the phone number as a recovery option where the platform allows it. Keep the number active if it is your recovery anchor, because a disconnected number can be reassigned and its new owner inherits the recovery messages for accounts that still point at it.

Business accounts add a second layer: the phone number on a Page or an ad account is often a shared team number, and a shared number is a shared recovery path. Move recovery to a role-based mailbox that several people can access with individual credentials, and document which human is responsible for it.

Data you never meant to publish

Most of the sensitive material on a social account was published by the account owner, one post at a time, in a context that felt safe at the time. The pattern is consistent: a photo with a badge or a lanyard, a boarding pass with a booking reference, a document on a desk with a client name visible, a screenshot of a chat with a phone number, a story filmed in an office whose whiteboard says more than the meeting did. None of these are mistakes in isolation. Together they are a dossier.

Two habits reduce the surface. Before publishing, ask what the image proves about where you are, who you are with, what you have access to, and when you are away from home - and then crop, blur or wait until you are back. After publishing, revisit: the older a post is, the less you remember what was in the background, and a quarterly review of your own public archive is more effective than any setting.

For a business, add a publishing checklist that covers the same ground for employee advocacy and agency content: no client names in screenshots, no internal system screens on video calls, no unreleased product in the background of a photo, and a clean process for removing content when someone asks. The reputational cost of a leak from a marketing post is disproportionate to the effort of a two-line checklist.

Who owns the account: succession, dual admin and offboarding

Ownership questions surface at the worst possible moments: a founder leaves, an agency is fired, a marketing manager dies, a company is sold. The account is often registered to a personal email address, with one administrator, no documented recovery, and a password in someone's password manager that nobody else can open. Recovery in that situation is not a security problem - it is a probate problem.

The fix is a small set of decisions made before they are needed. The account should be owned by a role-based identity - a mailbox like social@yourdomain that several named people can access with their own credentials - rather than by an individual. There should be at least two administrators on every Page, ad account and business portfolio, each with their own passkey, and the second one should not be the first one's manager. The recovery phone and email should be corporate assets, documented in the asset inventory. And the roles of any agency or freelance partner should be scoped, time-limited where the platform supports it, and reviewed when the contract ends.

For personal accounts, the equivalent is a legacy or memorial setting where the platform offers one, and a written note - in the will, or in the password manager's emergency-access feature - that tells the person you trust how to close or preserve the account. It is an awkward conversation, and it is shorter than the alternative.

Children and family accounts

Family accounts are a distinct threat model, because the account owner is a minor and the adversaries are peers, scammers and occasionally adults posing as peers. The controls differ by platform and change often, but the shape is consistent: supervision tools that let a parent see who the child is talking to and set time limits without reading every message, default-private profiles, restricted direct messages from strangers, and age-appropriate defaults for discovery and contact matching.

What matters more than the settings is the conversation. A teenager who understands that a "free followers" site is a credential harvester, that a stranger asking for a photo is committing a crime, and that a suspended account can be restored without paying anyone, is better protected than one whose phone is merely locked down. The specific scams to name: follower and verification fraud, game-currency and gift-card scams, sextortion from a fake peer profile, and the "I have your photos, pay me" email that arrives with a password from an old breach and no photos at all.

For parents, two operational rules. First, the child's account recovery must run through a parent-controlled mailbox that the child cannot unilaterally change - not to surveil, but so that a lockout can be resolved in minutes rather than weeks. Second, if a child's account is compromised or they are being extorted, preserve the evidence before deleting anything, do not pay, and report to the platform and to the police in your jurisdiction; the platform's minor-safety reporting channel is faster than the general abuse flow.

The regulatory frame: GDPR, DSA and platform process

Two European instruments give you leverage that most people never use. The GDPR, because a social account holds personal data about you and the platform is a controller or joint controller for some of it; the Digital Services Act, because it governs how platforms must handle reports of illegal content and impersonation.

The GDPR rights that matter in practice are access and erasure. Article 15 gives you the right to a copy of your personal data within one month, free of charge in the first instance, and the response is often more revealing than expected: shadow profile data, inferred interests, login history, device identifiers and the categories the platform has assigned to you. Article 17 gives you the right to erasure in defined circumstances, and the answer will explain what is deleted and what is retained for legal reasons. Article 32 requires the platform to secure the data, and Article 33 requires it to notify a personal-data breach to the supervisory authority within 72 hours - which is why a platform that tells you nothing after a credential-stuffing wave is worth challenging.

The DSA's contribution is procedural. Platforms above the size thresholds must operate a notice-and-action mechanism, give you a statement of reasons when they restrict content or an account, and provide an internal complaint-handling system and access to an out-of-court dispute settlement body. For an impersonation or a hacked account used for fraud, that sequence is more effective than repeating a generic report: notice, statement of reasons, appeal, dispute settlement.

Two practical points. First, keep your own copy of everything you send: timestamps, screenshots, the case references, the platform's replies. Second, when a breach or a takeover exposes other people's data - your customers' messages, your employees' details - the clock that matters is your own: organisations typically have 72 hours from awareness under the GDPR, and shorter deadlines under sector rules, so the runbook below has to be executable on day one rather than written on day three.

A takeover runbook: first 60 minutes, first day, first week

The difference between a bad afternoon and a bad quarter is whether the response is a sequence rather than a panic. This is the sequence we work through with clients, and it assumes the attacker may still be inside.

First 15 minutes: stop the bleeding. From a device you trust - ideally one that was not involved - change the password on the email account first, then on the social account. If you cannot get in, use the platform's recovery flow immediately, before you start collecting evidence, because every minute of access the attacker retains is a minute they can use to remove your recovery options. Then revoke every session and every device except your current one, and remove every connected app you do not recognise.

First hour: remove persistence. Check and correct the recovery email and phone number. Check for forwarding rules and filters in the mailbox. Check who holds admin or partner roles on the business assets, and remove anything you did not grant. Check for new two-factor methods or backup codes you did not create. If the platform exposes it, review recent logins for the addresses and devices the attacker used and screenshot the list before it ages out of the interface.

First day: contain the consequences. Tell the people who need to know - your team, your agency, your bank if a card was attached, your customers if messages went out under your name. Post a short, plain statement from an account you control. Report the takeover to the platform through the compromised-account flow, which usually requires an identity verification step and can take days. If money was spent, dispute the charges with the card issuer in writing, with the timeline. If the attacker messaged your contacts, give them a sentence they can use to warn their own contacts.

First week: establish what happened and prove the fix. Pull the evidence together: platform login history, mailbox logs, the chargeback correspondence, the messages the attacker sent if the recipients kept them. Identify the entry point - a stolen cookie from a personal laptop, a reused password, a partner-request approval, a code read out over the phone - because without that answer the same door is still open. Then close it: passkeys everywhere, sessions and apps audited, roles reviewed, offboarding completed, and a written note of what changed. If personal data of other people was exposed, this is also when the regulatory assessment has to be documented.

Per-platform hardening checklist

Fifteen minutes per platform, in this order. The settings names change with every redesign; the functions do not.

Meta (Facebook, Instagram, Messenger). Accounts Center, Password and security: set a passkey, add an authenticator app as the backup factor rather than SMS, review where you are logged in and log out everything else, review Apps and Websites and remove anything unfamiliar. Then set the default audience for posts and stories, turn off contact discovery by phone and email, turn on tag review, and for business users review People, Partners and Ad account roles separately - they are three different lists and only one of them appears in the device view.

Google (and YouTube). Security: passkeys or a hardware key, two-step verification with prompts rather than SMS, review your devices, review third-party access and remove anything with mail or drive scope you do not use, check recovery options and app passwords, and set up the Advanced Protection Programme if you are a public figure or hold sensitive data. YouTube channel ownership follows the Google account, so the channel is only as strong as the mailbox.

LinkedIn. Sign-in and security: passkeys where offered, authenticator app, review where you are signed in, review permitted services, and check the email addresses on the account - a secondary address is a recovery path. For company pages, review admin roles and remove admins who have left.

X. Security and account access: passkeys or a security key, review sessions and connected apps, check the phone number and email on file, and enable login alerts. If you use a third-party scheduler, give it the narrowest permission it needs.

TikTok. Security: two-step verification with an authenticator or SMS fallback, manage devices, review authorised apps, and for business accounts review Business Center members and ad account roles.

Snapchat and messaging-first platforms. Two-factor authentication, connected devices, and a review of who can contact you and who can see your story. Snapchat's account recovery is unusually email-dependent, so the mailbox control matters more than usual.

Metrics and the quarterly review

Security on social accounts is a maintenance discipline, and maintenance needs a rhythm and a number. Four measurements are enough for an individual and for a small business.

Credential hygiene: the share of accounts with a passkey or hardware key, and the share still relying on SMS. Track the direction, not the absolute number, and aim to move the accounts that gate money and identity first.

Session cleanliness: the number of unrecognised sessions found at each quarterly audit. Zero is the target; anything else is either a device you have forgotten or an intruder, and both are worth a minute of investigation.

Access roster accuracy: for business assets, the share of admins and partners that match the current org chart. Every mismatch is either an offboarding gap or an unrecorded grant.

Time to revoke: how long it takes, from the moment you suspect a compromise, to have every session killed and every recovery path corrected. Write the number down after a tabletop exercise; it is the number that determines the damage.

The review itself should be on a calendar, not on memory: once a quarter, walk the checklist above, review the asset inventory, and read the platform's security and privacy changelog - because the toggles move, and a setting that was on last year may have been replaced by a product that defaults differently.

Conclusion: defend the estate, not the password

The accounts that get taken are rarely taken by cleverness. They are taken because a session cookie was sitting in a browser profile on a laptop that had malware, because a partner request looked like every other notification, because someone read out six digits to a person who sounded helpful, or because the role granted to an agency in 2023 was never removed. Each of those is a design gap rather than a user failure, and each has a control: session revocation, two-person approval on partner grants, passkeys that cannot be talked out of you, and an access roster reviewed on a schedule.

The order that works is email first, then the accounts that hold money or business assets, then everything else. Passkeys where offered, authenticator apps where not, SMS only as the last resort. A quarterly session audit that names every device. Connected apps pruned to the ones you actually use. Privacy defaults set deliberately rather than inherited. And a runbook short enough to follow while you are angry and frightened, because that is when you will need it.

Where this connects to the rest of our work: if an account has already been taken and the platform's recovery flow has failed, the account-recovery material in the Snapchat recovery guide and the TikTok account security guide covers the evidence and escalation paths, and the encrypted messaging guide covers what to do about the conversations that were exposed. The key-custody side is in our password manager guide, and the wider containment sequence is in the incident response plan guide. The Italian version of this guide is at sicurezza dei social media.