My Email Was in a Data Breach. What Should I Actually Do?

If your email address showed up in a data breach, start by confirming the notice through the company's own website, then find out exactly what leaked with it. An address alone mostly means more phishing. A leaked password means changing it everywhere you reused it, starting with your email account, and turning on two step verification. Freeze your credit only if identity or financial data was exposed.

For most people that is the whole job. Below, each step in order, plus the part most guides skip: how to tell whether someone is already inside your mailbox. The last sections are for IT leads and for companies whose staff addresses leaked through a vendor.

Key takeaways

• Check the notice without clicking it. Type the company's address yourself, as the NCSC and FTC advise.
• What leaked decides what you do. An address alone is a phishing risk; a password, ID number or bank detail each needs more.
• Your email account is the master key. Secure it first with a unique password and two step verification.
• Look for signs someone is already in: forwarding rules, filters, delegates, unknown devices and app grants.
• Any reused password is now public. Change it everywhere it is used.
• Expect better phishing, for months. Breach data makes scams personal and convincing.
• Freeze credit only when it fits. It is free in the US but only helps when identity data leaked.
• Companies should treat it as a vendor problem: know what each supplier holds and how it protects it.

Is the breach notice itself legitimate?

This is the first question, and it has a practical answer: do not use anything in the message to check the message. The NCSC's guidance for individuals says to verify a breach through official channels, by contacting the organisation through its official website or social media rather than the links or contact details in any message you received. The FTC's phishing guidance gives the same instruction in different words: if you have an account with the company, contact it using a phone number or website you know is real.

A breach notice is a perfect phishing template: unexpected, urgent and "from" a company you use. The NCSC notes that criminals may impersonate organisations that were recently breached even if your details were not among the stolen data. So a fake notice can arrive for a real breach that never touched you.

Here is how to check a notice in about five minutes without clicking anything in it:

1. Open a new browser tab and type the company's address yourself. Look for a security notice or help centre article about the incident.
2. Sign in through the app or a bookmark you already had.
3. Search for the incident by name. If the company is real and the breach is real, there is usually news coverage or a regulator filing. No coverage at all is a warning sign, though not proof.
4. Check a breach lookup service. Have I Been Pwned (HIBP) lets you search an email address against breaches it has loaded. If the breach is listed and your address is in it, that is independent confirmation. Absence is not proof of safety, because not every breach is public or loaded.
5. Read the message's actual sender address and link targets by hovering, not clicking. CISA's phishing guidance flags lookalike domains, giving the example "amazan.com", and untrusted shortened links as common signs.

If the notice asks you to "verify your identity" through a link, enter your password, call a number in the email, or install something, treat it as a scam until proven otherwise. CISA also makes a point that is newer than most advice on this topic: good grammar no longer signals a legitimate message, since AI can produce polished text. The old tell of broken English is gone.

What a real notice usually looks like

Real notices say what happened, roughly when, and which categories of data were involved. They point to a page on the company's own domain and rarely require you to click anything to stay safe. In the UK, the Information Commissioner's Office (ICO) says you can ask the organisation to explain what happened and which of your information was affected, and that it has 30 days to acknowledge your complaint.

For IT leads: answering "is this real?"

When staff forward a breach notice to the help desk, the useful reply is not "probably fine". It is a short checklist: was the sender domain one the company actually uses, does the company's own site mention the incident, and did the employee click or enter anything. If they entered a password, treat it as a credential compromise and run the account steps below. If they did not, the main action is awareness: tell people a real breach is in the news and that phishing about it is coming. Your mail platform's view of the message's authentication results (SPF, DKIM and DMARC) helps, but a message that passes all three can still be a scam sent from a lookalike domain the attacker owns.

What was exposed: address only, password, phone, ID?

"Your email was in a breach" covers everything from a leaked newsletter list to a bank leaking full identity records. The response scales with the data.

Have I Been Pwned's own FAQ makes a related point: the service does not store passwords alongside email addresses and does not send exposed passwords to users. So when HIBP shows your address in a breach, it tells you which breach and which data classes were involved, not your actual leaked password. You then decide what to do based on those data classes.

Hashed passwords are not safe passwords. Weak or common passwords can still be recovered from many hash formats. If your password was involved in any form, change it.

Stealer logs are different. HIBP's FAQ mentions that it covers pastes, stealer logs and spam lists, not just company breaches. Stealer logs come from malware on a personal device that captured saved passwords and session cookies. If your address appears in a stealer log, the problem may be a device you use, not a company. That calls for a malware check on the device as well as password changes.

"Sensitive" breaches are hidden by design. HIBP does not show some breaches in a public search because membership itself could harm people. Its FAQ says only the verified owner of the address can see those, by signing in to the dashboard.

Secure your email account first: why it is the master key

If you only have energy for one account tonight, make it your email. Nearly every other service you use, from your bank to your cloud storage to your social accounts, lets you reset a forgotten password by sending a link or a code to your email address. Whoever controls your inbox can walk through those resets one by one. The NCSC's hacked account guidance calls this out directly: criminals often set up forwarding rules so they receive copies of your emails, which lets them reset your passwords.

If you change your bank password while an attacker still reads your mail, they can reset it again. So secure email first.

What "secure" means for an email account:

1. A unique, long password that you have never used anywhere else. NIST's current digital identity guideline, SP 800-63B revision 4, tells services to require at least 15 characters for passwords used on their own, and at least 8 when the password is one factor in multi factor sign in. It also says services should not impose composition rules such as mixing character types. A random passphrase or a password manager generated password works well.
2. Two step verification turned on. The NCSC recommends two step verification especially for email and banking. CISA's multi factor guidance says users who enable it are "significantly less likely to get hacked", and that phishing resistant methods, which CISA describes as FIDO or WebAuthn based, block login attempts on fake websites. Passkeys are built on the same standards and the NCSC suggests them as an option where available. If the only option your provider offers is a code by text message, use it; CISA's position is that any multi factor authentication is better than none.
3. Up to date recovery details. Check the recovery phone number and recovery email address. Google's guidance for a compromised account says to correct any unfamiliar changes to these right away. An attacker who changed your recovery phone can take the account back after you think you have fixed it.
4. All other sessions signed out. The NCSC says to log out all devices and apps using each service's settings, privacy or account options. Changing a password does not always end sessions that are already open.

Do this from a device you trust. If you suspect malware, reset from a different, updated device.

Signs someone is already in: forwarding rules, filters, delegates, unknown sessions

Attackers who get into a mailbox set up ways to keep reading it after you change the password. These are the places to look, using Google's and the NCSC's guidance as the checklist.

Automatic forwarding

Gmail's help page on forwarding walks through this: open Settings, then "See all settings", then the "Forwarding and POP/IMAP" tab. If forwarding is on to an address you do not recognise, choose "Disable forwarding" and save. Gmail's guidance is blunt about what an unexpected forwarding notice means: change your password right away, since someone else may have access to the account. In Outlook on the web, the equivalent settings sit under Mail, in the rules and forwarding sections.

Filters and rules

Filters are quieter than forwarding: an attacker can forward only messages about invoices or password resets, or hide security alerts. In Gmail, review every entry on the "Filters and Blocked Addresses" tab. In Outlook, review every inbox rule. Delete anything you did not create, especially rules that forward, delete or hide mail.

Delegates

Gmail lets you grant another account access to read and send from your mailbox. Google's help page puts this under Settings, "See all settings", the "Accounts and Import" tab, in the "Grant access to your account" section. A personal Gmail account can have up to 10 delegates. If anyone is listed there whom you did not add, click "Delete" next to them.

POP, IMAP and app access

If you never use a desktop mail client, an IMAP or POP connection you did not set up is a red flag: someone may be syncing a full copy of your mail into their own client. Google's guidance lists checking remote access through IMAP or POP alongside forwarding and filters. On the account level, check "Apps with access to your account" (Google's wording) or the equivalent app permissions page for Microsoft and others, and remove anything you do not recognise. A malicious app granted mail access keeps working after a password change.

Devices and recent activity

Google's page points to "Review security events" under the recent security events panel, and "Manage devices" under "Your devices", where you can remove any device you do not recognise. Microsoft accounts have a recent activity page that lists sign ins with locations. Look for sign ins from countries you have not been in, at times you were asleep, or from device types you do not own. A VPN can make your own sign ins look odd, so one strange city alone is not proof.

Signs outside the mailbox

The NCSC lists the outward signs too: being locked out, security settings you did not change, messages sent from your account that you did not write, and logins from unusual locations or times. If friends tell you they got odd messages from you, that is a strong signal. The NCSC suggests telling your contacts you were hacked and asking them to treat recent messages from your account with suspicion.

Work accounts: what the IT lead can check

For an organisation running Microsoft 365, administrators can review a user's inbox rules and forwarding from Exchange Online PowerShell rather than asking the user to dig through settings. A typical first pass looks like this:

# Connect with an admin account
Connect-ExchangeOnline

# Inbox rules for one mailbox: look for forward, redirect or delete actions
Get-InboxRule -Mailbox user@example.com |
  Select-Object Name, Enabled, ForwardTo, ForwardAsAttachmentTo, RedirectTo, DeleteMessage, MoveToFolder

# Mailbox level forwarding set by the user or an attacker
Get-Mailbox -Identity user@example.com |
  Select-Object ForwardingSmtpAddress, ForwardingAddress, DeliverToMailboxAndForward

On Google Workspace, the admin console's audit and investigation tools show mail settings changes, including new forwarding addresses and filters. Whatever the platform, the useful habit is the same: when one user's credentials leak, check the mailbox for persistence before you close the ticket, and consider blocking automatic forwarding to external domains as a default, with exceptions on request.

Reused passwords: how to find every account that shares one

If the breach included your password, the breached site is the least of your problems. You probably already changed it there, or the company forced a reset. The real exposure is every other site where you used the same password, because attackers try leaked email and password pairs against popular services automatically. This is credential stuffing, and it works only because people reuse passwords.

The NCSC's advice is to change the password on any hacked account, then on any other account that uses the same password, and to create a strong, separate password for each account. HIBP's FAQ says the same thing from the other side: do not use a password that has appeared in a breach. NIST's guideline turns it into a rule for services: when you set or change a password, the service should compare it against a blocklist that includes passwords from breach corpuses, and should force a change when there is evidence the password has been compromised.

So how do you find every account that shares a password when you cannot remember them all?

1. If you use a password manager, start there. Most have a report that groups reused passwords and flags ones known from breaches. Sort by reused, and work through the list.
2. If you save passwords in your browser, the browser's password settings page usually offers a similar check for reused and compromised passwords.
3. If you keep passwords in your head, search your email for "welcome", "verify your email", "confirm your account" and "password reset". Every service that ever emailed you a welcome message is an account you probably still have. Your email archive is, in effect, your account inventory.
4. Prioritise. Change the reused password first on email, banking, payment services, mobile carrier, cloud storage and any account that holds your documents or can spend money. Then social media. Then shopping sites with saved cards.

Check a password without sending it anywhere

You can check whether a specific password appears in known breach data without revealing it, using HIBP's Pwned Passwords range API. According to HIBP's API documentation, you send only the first five characters of the password's SHA-1 hash, the service returns every hash suffix that shares that prefix with a count, and your computer checks locally for a match. The full hash never leaves your machine. The API is free, needs no key, and supports an Add-Padding: true header that pads responses to between 800 and 1,000 results so the response size does not hint at anything.

On macOS or Linux, this does it in a terminal:

# Read the password without echoing it to the screen or shell history
read -rs PW
HASH=$(printf '%s' "$PW" | shasum -a 1 | awk '{print toupper($1)}')
unset PW

PREFIX=${HASH:0:5}
SUFFIX=${HASH:5}

# Ask only for the prefix; match the suffix locally
curl -s -H "Add-Padding: true" "https://api.pwnedpasswords.com/range/$PREFIX" \
  | grep -i "^$SUFFIX:" \
  && echo "Found in breach data: stop using this password" \
  || echo "Not found in Pwned Passwords (still change it if it was in the breach)"

A result of "not found" does not make a password safe. It only means that exact password is not in that dataset. If a breach notice says your password leaked, change it regardless.

Scripted lookups of an email address need a key: HIBP documents its breached account endpoint as an authenticated API. Most people should use the website and its free "Notify me" alerts.

Follow-up phishing that uses breach data

The NCSC warns that scam messages may arrive well after the breach becomes public, and that criminals use breach information to make phishing emails and texts look legitimate. A message that knows your name, the company you use, maybe your last order or your phone number, feels real in a way generic spam never did.

The patterns to expect, drawn from the NCSC, CISA and FTC guidance:

• "Fraudulent activity on your account." The NCSC lists this as the classic follow up. It asks you to log in or verify your account through a link that leads to a convincing fake page.
• Compensation and refunds. After a big breach, messages offering compensation or a refund for "affected customers" are common. The NCSC lists compensation among its warning signs. Real compensation schemes are announced publicly and do not ask for your card number by email.
• Password reset prompts. A reset email you did not request may be an attacker testing your address, or a fake that leads to a credential harvesting page.
• Phone calls. If phone numbers were stolen, the NCSC says you may get calls asking for banking details, passwords or access to your computer. A caller who knows your account details is not proof the call is real.
• Payment detail updates. The FTC's guidance is direct: legitimate companies will not email or text with a link to update your payment information.

The core rule from the NCSC is worth memorising: your bank or any other official organisation will never ask for your personal information in an unsolicited message. When in doubt, hang up or close the message, and contact the organisation through a number or site you already know. The ICO's guidance adds a practical option for UK readers: if you are unsure whether a call from your bank is genuine, hang up and call the number on your card, use the bank's app, or call 159 if your bank supports it.

Where to report it

When to freeze credit or add fraud alerts

A credit freeze is the strongest single step against someone opening new credit in your name, but it only makes sense when the leaked data could be used for that. If only your email address and a password leaked, a freeze adds little. If your Social Security number, date of birth and address leaked together, it is one of the best things you can do.

The FTC's guidance on the US options:

A few practical points. You can have a fraud alert even if you already have a freeze, according to the FTC. When you apply for a loan, you can lift the freeze only at the bureau the lender will use and then put it back. And the freeze does not stop existing creditors from seeing your file or stop misuse of accounts you already have, so watching statements still matters.

If your identity was actually misused, IdentityTheft.gov is the FTC's official site. It gives a free personal recovery plan, tracks your progress and generates pre filled letters to send to credit bureaus, businesses and debt collectors. Its phone line is 877 438 4338.

Outside the US

The UK has no direct equivalent of the free US credit freeze. The ICO's guidance for people affected by a breach suggests checking bank statements, getting a copy of your credit report, reporting lost or stolen documents to their issuers, and applying to Cifas for protective registration, which adds a warning flag to your details on its National Fraud Database so organisations make extra checks. The ICO notes there is a fee. Other countries have their own schemes; your national data protection authority or consumer protection agency is the right first stop.

For companies: what to do when a vendor's breach exposed your staff's emails

IT leads get the company version of this question often: a SaaS tool, event organiser or payroll provider was breached and staff work addresses were in the data. Treat it in two parts.

Part one: protect the people

• Tell staff before the phishing arrives. A short internal note that names the vendor, says what data was involved, says the company will never ask for passwords by email, and points to the internal reporting route does more than any filter.
• Check whether passwords were involved. If staff used work addresses to sign up and the vendor stored passwords, assume some reused them on corporate systems. If you run single sign on to that vendor, the vendor may not have held passwords at all, which is one quiet benefit of single sign on.
• Force resets where reuse is plausible, and check affected mailboxes for persistence (rules, forwarding, delegates, app grants) using the commands above. NIST's guideline supports forcing a change when there is evidence of compromise and nowhere else.
• Find out which addresses leaked. HIBP's domain search lets a verified domain owner see which addresses on the domain appear in loaded breaches. Its FAQ says larger domains may need a subscription unless a breach is marked as free for domain searches. Our post on checking whether your nonprofit email addresses are in breaches walks through the domain verification process, and it applies to any organisation.

Part two: deal with the vendor

"What did this vendor hold about us?" should have an answer before the breach. If you cannot answer it within an hour, the gap is in your vendor inventory.

1. Ask the vendor specific questions in writing. What data classes about our organisation and staff were affected? Were credentials or tokens involved? Were any integrations, API keys or connected accounts exposed? What is the root cause, and has it been fixed? For individuals, the ICO's guidance says an organisation has 30 days to acknowledge a complaint; as a business customer, your contract usually sets the notice terms.
2. Rotate anything the vendor could reach. API keys, OAuth grants, service accounts and webhooks connected to the vendor should be rotated or reauthorised, even if the vendor says they were not affected.
3. Record it. Note the incident against the vendor, along with the data involved and the vendor's response. This becomes evidence for audits and for the next renewal conversation.
4. Review the relationship. Did the vendor need all that data? Could you have used single sign on, a shared mailbox or a per vendor address instead? Some teams give each vendor a unique address so a leak points straight at its source; our post on per vendor canary email addresses covers how that works.

Our longer post, a vendor just told you they were breached, goes deeper into the vendor side of the response.

Where Safeguard fits, and where it does not

To be clear about scope: Safeguard does not offer breach monitoring, dark web monitoring or credential monitoring, and it will not tell you whether your email address or password is in a breach. For that, use the free lookup services and official guidance in this post.

Where Safeguard helps is the company side of the question, as third party risk. Safeguard's Third Party Risk Manager lets a security team onboard vendors into a register, request SBOMs or product information from them, score and monitor supplier risk over time, and apply policies and gates. The compliance side keeps vendors and their documents alongside your other evidence. When a vendor tells you it was breached, that register is how you answer "what does this vendor hold and how do they protect it?" in minutes instead of days, and where you record what happened for the next audit. It does not stop a vendor from being breached, and it does not replace asking the vendor hard questions.

A step by step walkthrough: the first hour after a breach notice

Here is the whole process as one ordered list. Most people finish it in an evening.

1. Do not click anything in the notice. Type the company's address and find its incident page.
2. Find out what leaked from that page and from a breach lookup service, then pick your tier from the table above. Address only means steps 7 and 8. Password means everything.
3. Secure email from a trusted device: a new unique password of at least 15 characters and two step verification, preferably a passkey or security key.
4. Check recovery details and hunt for persistence: forwarding, filters or rules, delegates, POP and IMAP, connected apps. Delete what you did not set up, then sign out every other session.
5. Change every reused password, starting with banking, payments, mobile carrier and cloud storage.
6. If identity or financial data leaked, freeze credit at all three US bureaus or, in the UK, check your credit report and consider Cifas protective registration. Contact your bank or card issuer.
7. Set your phishing guard for the next few months and verify anything about that company through known channels.
8. Sign up for breach alerts for your address and write down every contact with the organisation, as the ICO recommends.

Common mistakes

Clicking the link in the notice to "check". This is the one that turns a breach into a compromise. Real or fake, the safest move is the same: go to the company yourself.

Changing the breached site's password and stopping there. The breached site often forces a reset anyway. The damage happens on the other sites where the same password worked.

Securing everything except email. If someone still reads your mail, every reset you do elsewhere can be undone. Email first.

Changing the password but missing the forwarding rule. An attacker who set up forwarding or a delegate keeps reading your mail after the password change. Persistence checks are not optional when a password leaked.

Assuming "not in Have I Been Pwned" means safe. Breach lookup services only know about breaches that have been made public and loaded. Plenty of incidents never reach them.

Trusting a caller because they know your details. That proves only that the caller has the breach data. Hang up and call back on a number you trust.

Freezing credit for the wrong reason, or not at all. A freeze does nothing about phishing or account takeover. But skipping it after a Social Security number leak is a mistake; the FTC says it is free and does not affect your score.

For companies: having no vendor inventory. If the first question after a vendor breach is "do we even use them?", the problem started long before the breach.

Fix it without waiting for upstream

Many of the vendor breaches that put staff addresses in circulation start with a known vulnerability that sat unpatched in a component the vendor built or deployed. You cannot patch your vendor's systems, but you can make sure the same gap does not sit in the software your own team ships. The block below is about that half of the problem.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

FAQ

Is it dangerous if only my email address was leaked?

Not directly. An address alone cannot sign in to your accounts. The risk is more convincing phishing, especially messages that mention the breached company, so verify anything that asks you to act.

Should I change my email address after a data breach?

Usually no. It costs a lot of effort for little gain. Change the password, turn on two step verification and check for forwarding rules instead. The NCSC suggests a new account mainly when the old one cannot be recovered.

How do I know if my email has been hacked, not just leaked?

Look for actions you did not take: forwarding to an unknown address, filters you did not create, delegates, unfamiliar devices or sign in locations, sent messages you did not write, changed recovery details, or being locked out. The NCSC and Google both list these. A leak means your data is out there; a hack means someone is using it inside your account.

Is Have I Been Pwned safe to use?

It is widely used, and the UK NCSC names it as one tool you can use to check whether your details appear in other breaches. According to its FAQ, searches are not logged by the site itself, it does not store passwords alongside email addresses, and its password checker sends only a partial hash so your password is never revealed. As with any site, type its address yourself rather than following a link.

Does a credit freeze hurt my credit score?

No. The FTC says a freeze does not affect your credit score. It is free to place and lift in the US, and it lasts until you lift it. You need to contact each of the three bureaus separately, while a fraud alert needs only one.

How long after a breach should I watch for scams?

Months, at least. The NCSC warns that scam messages may arrive well after the breach becomes public, because breach data gets reused.

What should a company do when employees get a vendor breach notice?

Confirm the incident with the vendor directly, tell staff what to expect before the phishing arrives, force password resets where reuse with corporate systems is plausible, check affected mailboxes for forwarding rules and app grants, rotate any keys or integrations connected to the vendor, and record the incident against the vendor in your third party risk register.

Can I sue or get compensation after a data breach?

It depends on where you live. In the UK, the ICO says to complain to the organisation first and then to the ICO; its breach steps page does not cover compensation. Keep records of every contact, and be wary of "compensation" emails, a favourite phishing lure.

See how Safeguard would help

Safeguard does not check whether your email is in a breach. The demos below show Safeguard's own flows; each applies a pattern from this topic, such as keeping a human in control of every action. When you are ready to try it on your own code, download the apps at safeguard.sh/download and read the CLI documentation.

This first demo is a real Android session. Work is sent to a computer running the Safeguard CLI, and each command waits for approval on the phone with Allow once, Allow for turn or Deny. That approval step is the same principle as the account security in this post: nothing sensitive should happen on your behalf without you seeing it first. If you want more on keeping a phone that holds approvals safe, see our lost phone playbook for engineers.

Click through it at your own pace, or open it full screen.

This second demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. For a team handling a vendor breach, the useful habit is the one shown here: grant an assistant only the access it needs, and get answers from your own Safeguard data rather than a guess. Which tools appear depends on your account's plan and your administrator's settings.

Click through it at your own pace, or open it full screen.

This third demo sets up the Safeguard runner on your own machine, approves it with its device code, and then scans from the terminal. It shows the "fix your own half" side of a vendor breach: while you wait on the vendor's answers, you can scan your own repositories and images locally and see which known vulnerable components you ship.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• NCSC: Data breaches, guidance for individuals and families
• NCSC: Recovering a hacked account
• FTC: What to know about identity theft
• FTC: Credit freezes and fraud alerts
• FTC: How to recognize and avoid phishing scams
• CISA: Recognize and report phishing
• CISA: More than a password (multifactor authentication)
• ICO: What steps should I take if I have experienced a data breach?
• NIST SP 800-63B revision 4: Authentication and authenticator management
• Have I Been Pwned: FAQs
• Have I Been Pwned: API v3 documentation
• Google: Automatically forward Gmail messages to another account
• Google: Set up mail delegation
• Google: Secure a hacked or compromised Google Account

Last reviewed: 23 October 2026. Official guidance and lookup service features change; check the linked pages for the latest advice.