Crime Stoppers P3 Tip Leak: Vendor Risk When Anonymity Is the Product

A March 2026 hack of P3, the tip platform Navigate360 runs for Crime Stoppers programs, exposed more than 1.5 million Canadian tips, CBC reported on 21 October. Toronto Crime Stoppers paused all intake that night. Any organisation that promises anonymity through a hosted vendor should review that vendor's data handling now.

This post sets out what the primary sources say, where they disagree, the technical facts defenders can use, and a vendor due diligence checklist for any platform whose whole value is that it keeps people unnamed: crime tip lines, school safety lines, whistleblowing hotlines and ethics reporting tools. We do not repeat any personal data from the leak and we do not link to the dataset.

What happened

P3 Global Intel is a cloud tip and intelligence management service owned by Navigate360, a US company. According to Straight Arrow News (SAN), which broke the story on 18 March 2026, a hacktivist group calling itself Internet Yiff Machine supplied SAN and the non-profit Distributed Denial of Secrets (DDoSecrets) with more than 8.3 million records taken from P3. SAN said the records span February 1987 to November 2025 and include crime tips sent to Crime Stoppers programs, police agencies, schools and parts of the US federal government.

Navigate360's chief executive, JP Guilbault, told SAN at the time that the company had hired a third party forensics firm and had "not confirmed that any sensitive information has been accessed or misused." P3 stayed online.

Seven months later, on 21 October, CBC's investigative unit published an analysis of the Canadian portion of the data. CBC found more than 1.5 million tips sent to Canadian Crime Stoppers programs over about 25 years, and said more than 850,000 of them contained personally identifiable information about tipsters, people named in tips, staff or police. Toronto Crime Stoppers paused its program the same evening and published a timeline of what Navigate360 had told it since March. Within a day, CBC reported that at least six Ontario police services had paused their partnerships with local chapters.

Timeline

Times are as published by each source. Where a source gives a timestamp in its page metadata, we give it in UTC.

What changed since the first reports

The March story was about scale and about a hacker's claims. The October story is about what the vendor's customers were and were not told.

• Canadian scope became concrete. In March, Canadian programs said they had no confirmed impact. In October CBC put numbers on it, and Toronto published the vendor's own figures for its chapter.
• The account of what was taken changed several times. Toronto's timeline records Navigate360 saying no Canadian data was taken, then some Canadian data but not Toronto's, then Toronto data from a three year window. Ali Dehghantanha, Canada Research Chair in Cybersecurity and Threat Intelligence at the University of Guelph, told CBC the chapter "apparently received six different" accounts in seven months.
• The customer still could not see its own records. Toronto says that despite repeated requests through its lawyers, Navigate360 had not provided the text of the stolen tips, so it could not assess the risk to individual tipsters.
• Police partners stopped waiting. Portland paused in March. Ontario services paused in October, most of them the day after the CBC report.
• The vendor now says remediation is complete. The national association said Navigate360 told it that third party experts investigated, found vulnerabilities and finished remediation. The association added that this cannot undo the exposure of information already taken.

Where sources disagree

These figures measure different things with different definitions, so treat them as ranges rather than contradictions.

Who is affected

If you submitted a tip and are worried, Toronto Crime Stoppers' advice is the one to remember: it will never contact you first to ask for your tip number, password or anything else. If someone does, it is not them. In danger, call 911.

Technical details

No CVE, advisory, indicator list, file hash or IP address has been published for this incident. What defenders can use is a set of facts about the platform's design and the data it held, from the vendor (as relayed by its customer), the reporters who examined the data, and public statements. Each value below is attributed.

Access and scope

Data categories reported in the dataset

These are categories, not contents: the fields an attacker can reach in a system like this.

• Tip free text, unredacted. Toronto Crime Stoppers says its practice is to remove identifying details before a tip goes to investigators, but that some original tips with potentially identifying information were stolen from P3. CBC found hundreds of tips where staff had flagged that a tipster "self-identified" or had been "exposed", with the details still present.
• Follow up credentials in plain text. SAN reports that each tipster receives a unique ID number and password to check the status of a submission, and that SAN found IDs and passwords stored in plain text in the data.
• Two way chat logs between tipsters and the people receiving tips, including reward collection instructions, per SAN.
• Reward and banking details. CBC found hundreds of banking details related to cash rewards.
• User account details and customer support requests for the platform's customers, per SAN.
• Internal law enforcement bulletins, per SAN.
• Records of accused people, including identifiers such as dates of birth and, in the US data, Social Security numbers, per SAN.

The session capture feature

SAN published the wording of a confidential customer page describing an opt in feature called "Session Information Disclosure". According to that page, P3 can capture session information, including IP addresses, from web and mobile submissions; the feature is disabled by default on all accounts; when enabled, values are stored for up to 90 days; and they can be released to the customer on formal request in cases of serious misuse, such as threats against life or property. SAN reported that it was unclear what guardrails stop a customer from misusing the feature.

Whatever an intake system captures becomes part of its breach surface. If a feature like this exists in a platform you use, you want to know its state on your account in writing.

Retention

CBC's experts described keeping decades of closed tips in one live system as contrary to basic retention practice. Ben Coon of Unit 221B asked CBC: "If a tip is closed, does that need to stay online?" The records in the dataset begin in 1987, which predates the current platform by decades and implies historical records were migrated in.

How it works: why anonymity platforms carry a different kind of vendor risk

Most vendor reviews ask whether a supplier can lose your data. For an anonymity platform, the supplier's job is to make sure certain data never exists in usable form.

The vendor holds the raw copy. Toronto's statement shows a common pattern: the public types whatever they want, the vendor stores it, and the program redacts identifying details before passing a tip to police. Redaction happens downstream. The upstream copy, held by the vendor, still contains everything. If the vendor is breached, the redaction step protects nothing.

One customer login can expose many customers. Navigate360 told Toronto the attacker used a stolen login belonging to a customer account, and that a US program was the initial victim. Yet data from many programs in several countries was taken. How one tenant's credential reached other tenants' records has not been explained publicly. Whatever the answer, the lesson for buyers is that your data's safety depends on the controls of every other customer of a shared platform, unless tenant isolation is strong and tested.

Follow up credentials are identity in disguise. A tip ID and password let a tipster return. Stored in plain text alongside the tip, they let anyone with the data impersonate the tipster or prove which tip a person sent. They should be treated like any password: salted and hashed, never recoverable.

Metadata defeats the promise quietly. IP addresses, device identifiers, file metadata in uploaded photos and even writing style can identify a person. An anonymity platform that captures metadata, even off by default, carries the capability.

The customer cannot assess harm without the records. Toronto had tip numbers and a name list but not the tip text, so it could not say who was at risk. Without contractual rights to a copy of exposed records, the data owner cannot notify, triage or protect anyone. The national association also told CBC that the information available to it "does not distinguish people who submitted tips from people identified in them," which made notification itself a risk.

Accountability does not move with the data. Michael Geist of the University of Ottawa told CBC that the collecting organisation remains responsible even when it uses subcontractors. The Office of the Privacy Commissioner of Canada says the same in its cross border guidance: an organisation must use contractual or other means to provide "a comparable level of protection" while a third party processes the data. Whether the federal commissioner has jurisdiction over Crime Stoppers is itself disputed: CBC reports the national association assessed that commissioners "do not have jurisdiction".

What to do now

The steps below are for three audiences: organisations that use any hosted intake vendor, teams that build intake software, and individuals who have sent tips. Commands use placeholder hostnames; replace tips.example.org with your own.

If you rely on a hosted anonymous intake vendor

1. Decide your intake posture today. Toronto paused all channels and pointed people to 911 and to police non emergency lines, accepting that those are not anonymous. Write down what would make you pause, and who decides.

2. Ask the vendor for your affected records, in full. Tip IDs and a name list are not enough to assess harm. Ask for the text and attachments of every exposed record, delivered to you under your own encryption, plus the date range and channels involved.

3. Rotate every account on the platform and require phishing resistant MFA. The reported entry point was a stolen customer login. CISA's fact sheet on phishing resistant MFA says not all MFA is equal and that FIDO or PKI based methods resist phishing and push bombing. Remove accounts for former staff and partners. If you use Microsoft Entra ID for single sign on to the vendor, one way to list users without MFA registration is:

   Connect-MgGraph -Scopes "AuditLog.Read.All"
   Get-MgReportAuthenticationMethodUserRegistrationDetail -All |
     Where-Object { -not $_.IsMfaRegistered } |
     Select-Object UserPrincipalName, IsMfaCapable
   

4. Check what your public intake page loads and records. Third party scripts, analytics and cookies on an anonymous form undermine the promise before the vendor is ever involved.

   # Who serves the form, and what headers and cookies it sets
   dig +short tips.example.org CNAME
   curl -sI https://tips.example.org/ | grep -iE '^(server|set-cookie|strict-transport-security|content-security-policy|referrer-policy)'
   
   # Certificate subject and issuer, to confirm whose infrastructure you are on
   echo | openssl s_client -connect tips.example.org:443 -servername tips.example.org 2>/dev/null \
     | openssl x509 -noout -subject -issuer -dates
   
   # Third party scripts referenced by the submission page
   curl -s https://tips.example.org/submit | grep -oE '<script[^>]+src="[^"]+"' | sort -u
   

   Any analytics or advertising script on a tip form should go. A Referrer-Policy of no-referrer stops the form's address leaking to other sites.

5. Get session and IP capture settings in writing. Ask whether your account has any metadata capture enabled, how long values are kept, who can request them, and whether that is logged. Ask for it to be disabled and for any stored values to be deleted.

6. Set and enforce retention. Decide how long a closed tip stays online, ask the vendor to delete older records, and ask for written confirmation of deletion, including backups and replicas.

7. Prepare for impersonation. Breached tip data invites fraud. Publish, as Toronto did, that you will never contact a tipster first to ask for a tip number or password. Dehghantanha described to CBC how a caller who knows a tip's details can build instant trust.

8. Keep a breach record and get legal advice on notification. The OPC's guidance on breaches of security safeguards says organisations subject to the federal law must report breaches that pose a real risk of significant harm, judged by the sensitivity of the information and the probability of misuse, and must keep records of all breaches. Jurisdiction for charities and public bodies varies, so take advice rather than assume.

If you build intake or reporting software

9. Hash follow up credentials. Store only a salted, slow hash of the passcode a reporter uses to return. A minimal sketch with Python's standard library:

   import hashlib, hmac, os
   
   def hash_passcode(passcode: str) -> bytes:
       salt = os.urandom(16)
       digest = hashlib.scrypt(passcode.encode(), salt=salt, n=2**15, r=8, p=1, maxmem=64 * 1024 * 1024)
       return salt + digest
   
   def verify_passcode(passcode: str, stored: bytes) -> bool:
       salt, digest = stored[:16], stored[16:]
       candidate = hashlib.scrypt(passcode.encode(), salt=salt, n=2**15, r=8, p=1, maxmem=64 * 1024 * 1024)
       return hmac.compare_digest(candidate, digest)
   

10. Encrypt free text per tenant, with keys the tenant controls. Field level encryption of the tip body and chat, with a per customer key in a key management service, limits what a single stolen credential or database dump exposes.

11. Redact at intake, not downstream. Offer reporters a warning when they type something that looks like a name, phone number or address, and give handlers a redaction step that replaces the stored original, not just the forwarded copy.

12. Do not log what you promise not to know. Web server logs record client IP addresses by default. For a tip endpoint, use a log format without them. In nginx:

log_format tips_privacy '[$time_local] "$request_method $uri" $status $body_bytes_sent';
server {
    server_name tips.example.org;
    access_log /var/log/nginx/tips_access.log tips_privacy;
}

13. Strip metadata from uploads on the server. Photos and documents can carry GPS coordinates, device identifiers and timestamps, as coverage of this incident noted. For example, exiftool -all= -overwrite_original upload.jpg removes EXIF, IPTC and XMP blocks; run it on ingest, before storage.

14. Expire closed records. A scheduled job that deletes or archives offline closed tips past your retention period, for example:

-- illustrative: adapt table and column names to your schema
DELETE FROM tips
WHERE status = 'closed'
  AND closed_at < now() - interval '24 months';

15. Test tenant isolation like an attacker would. Write automated tests that log in as tenant A and attempt to read, search or export tenant B's records through every API and admin path. Run them in CI on every release.

16. Know what your intake application is built from. Generate an SBOM for the service and its container image, and gate releases on known exploitable vulnerabilities. With the Safeguard CLI:

safeguard scan --dir .
safeguard scan --image registry.example.org/tips-intake:latest

Results are written as JSON under ./output.

If you sent a tip

Follow your local program's guidance. Toronto says it will never contact you first. Be wary of anyone who knows details of a tip and asks for more, for money, or for your follow up password. If you are in danger, call 911.

Vendor due diligence checklist for anonymity critical platforms

Use this list when you buy, renew or review any platform that receives reports from people who must stay unnamed. Each line is a question with the evidence you should ask for. It draws on what went wrong in public reporting of this incident, the OPC's accountability principle and NIST SP 800-161 Rev. 1 on cybersecurity supply chain risk management.

Item 17 comes straight from Toronto's statement: it had to instruct the vendor and the call centre separately to stop intake. Owning that switch yourself saves hours when it matters.

What would have helped

Practices any team can use

• Treat anonymity as a technical property with a test. Write down what "anonymous" means in your product and check it each release: no IPs in logs, no tracking scripts, hashed passcodes, stripped uploads.
• Short retention by default. Closed records leave the live system on a schedule. CBC's experts were blunt that decades of closed tips should not be online.
• Contract for the incident you hope never comes. Fixed notice windows, a right to a copy of exposed records, forensic summaries and the right to pause.
• A vendor register with an owner and a review date. NIST SP 800-161 Rev. 1 frames this as supply chain risk management across the organisation, not a procurement checkbox.
• Rehearse the pause. Know which channels to close, what to tell the public and how to route emergencies, as Toronto did under pressure.

Where Safeguard fits

Safeguard would not have prevented or detected this incident. It has no view into P3 or any vendor's hosted platform, it does not hold your tips, and nothing in it would have flagged a stolen customer login at a third party. Here is the narrower part it can play.

Organisations that build their own intake or case software. Safeguard builds SBOMs from repositories, container images and SBOM files (safeguard scan --dir ., --image <name>, --sbom <file>, with JSON results under ./output), matches components against vulnerability databases and uses reachability analysis to rank what your code actually calls. The platform shows which projects contain a given component and version, so when a library in your intake stack gets a critical advisory you know where it runs. Our post on SBOM incident response explains the method.

Asking vendors for SBOMs. If a vendor supplies an SBOM file as part of item 14 in the checklist, safeguard scan --sbom <file> checks it against known vulnerabilities. That tells you about the vendor's components, not about its operational controls.

Keeping the vendor review in one place. Safeguard's compliance suite (GA) includes Vendors, Questionnaires and Risks views alongside controls and evidence, so the checklist above, the vendor's answers and the risks you accepted sit together with a review history.

Policies and gates. Platform policies can gate builds of your own software on what it contains, for example blocking a release that pulls in a component with a known exploited vulnerability.

Approved changes through the CLI. The Safeguard CLI's assistant can edit code and run commands on your machine, asking first in the default flow (/permissions offers Ask, Accept edits, Plan, Auto and Strict). You can ask it to replace plain text passcode storage with a hashed scheme like the one above, remove client IPs from a logging configuration or add a metadata stripping step to an upload handler, then run your tests, approving each step. The desktop and phone apps can send that work to a computer running the CLI and approve each command. In CI, safeguard exec runs the checks.

Zero-Day Discovery and Gold

These address a different problem. This incident, as publicly described, involved a stolen login and unspecified platform weaknesses at a hosted vendor, not a vulnerable package in your software.

• Zero-Day Discovery looks for previously unknown flaws before a CVE exists, in an agentic mode and a deterministic scanner mode, across seven package ecosystems. Findings are issued as SGZ advisories before they reach public CVE databases. It did not find anything in this incident and has no view into a vendor's hosted service.
• Gold Open Source at gold.safeguard.sh is free and needs no login: searchable CVE intelligence with CVSS, EPSS, KEV status, affected and fixed versions and a recommended safe version, plus a free read API and a CI gate GitHub Action. No CVE has been published for this incident.
• Gold Registry at registry.safeguard.sh is paid: hardened drop in components and container images held to zero exploitable critical or high CVEs, built to SLSA L3+, signed with Sigstore, with evidence pages. An artifact loses its badge if it regresses.

For another case of a supplier failure landing on its customers, see our post on IDCF cloud ransomware and third party risk. For the wider month, see October 2026 security incidents and what would have helped.

Common mistakes

• Treating "we have not confirmed" as "nothing happened". The vendor's March statement was accurate in its own terms, and the data still reached journalists. Plan on the worst credible case until records prove otherwise.
• Accepting tip IDs instead of tip content. Without the text, a data owner cannot judge who is at risk. Contract for full records up front.
• Leaving historical data in the live system. Every year of retained closed records adds to the blast radius.
• Notifying people in a way that exposes them. The national association warned that contacting individuals could itself jeopardise anonymity. Notification plans for anonymous services need a channel that does not reveal who is being contacted.
• Restarting intake on the vendor's word alone. Ask for evidence of remediation, an independent summary and a re test before resuming.

Open questions

• How did a single customer account's stolen login reach records from many programs in several countries?
• Which "platform vulnerabilities" did the senators' letter refer to, and which vulnerabilities did the vendor's experts identify and fix?
• When exactly was the data taken: late 2025, as SAN reported in April, or March 2026?
• What did "recovered" mean in the vendor's 28 May account, given that copies reached journalists?
• Will affected Canadian programs receive the text of their stolen tips?
• Will a privacy regulator take up the case, given the national association's view on jurisdiction?

FAQ

What is P3 and who runs it?

P3, also called P3 Global Intel, is a cloud tip and intelligence management platform owned by Navigate360, a US company. According to CBC, all Crime Stoppers chapters in Canada and the US relied on it. SAN reports it is also used by police agencies, more than 30,000 schools and parts of the US federal government.

How many tips were exposed?

SAN reported more than 8.3 million records overall. CBC identified more than 1.5 million tips sent to Canadian programs over about 25 years, of which more than 850,000 contained personal information under CBC's definition. For Toronto alone, Navigate360 reported 176,859 tips.

Why did Toronto Crime Stoppers pause?

Its chair, Sean Sportun, said the October reporting showed that for some tipsters the promise of anonymity was broken, and that the chapter would not take tips again until it could stand behind the system. Toronto also says it never received the text of its stolen tips despite months of requests.

Which police services paused their use of Crime Stoppers?

CBC reported Toronto, York Region, Halton, Hamilton and Windsor police paused partnerships, Durham removed references to the program, and Waterloo had stopped promoting it in July. In the US, Portland police advised residents in March to avoid the platform temporarily.

How did the attacker get in?

Navigate360 told Toronto Crime Stoppers that someone accessed P3 with a customer account's stolen login. US senators cited reports of exploited platform vulnerabilities. No specific vulnerability or CVE has been published.

Is the leaked data public?

Not openly, according to the experts CBC consulted. DDoSecrets shared it with vetted journalists and researchers, and SAN reported in April that the group offered it for sale. Do not search for or download it.

Is it safe to send anonymous tips now?

That is each program's call. Toronto and Guelph Wellington paused intake. Crime Stoppers in New Brunswick told CBC it would continue, after resetting passwords and mandating two factor authentication. In an emergency, call 911.

Does Canadian privacy law cover this?

Michael Geist told CBC that the collecting organisation stays responsible even when it uses a vendor, and that Navigate360 could also be accountable, though cross border enforcement is hard. The national association has said it believes commissioners lack jurisdiction over Crime Stoppers. Expect this to be argued.

Would Safeguard have stopped this?

No. Safeguard does not monitor third party hosted platforms or customer logins at vendors. It helps teams that build their own intake software know what that software contains, fix vulnerable components and keep vendor reviews and evidence together.

Fix it without waiting for upstream

In this incident the fix had to come from the hosted vendor. If you build your own intake, case management or reporting tools, though, most of your exposure sits in the open source components you ship, and that part you can fix yourself.

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.

See how Safeguard would have helped

None of these demos show the P3 incident. Each is a real Safeguard session, and the text says how the same flow applies to an organisation that runs or builds anonymous intake.

The first demo is a CLI session that fixes a lodash CVE: the assistant reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, and pushes nothing. For an in house tip intake service, you would open the same session in its repository and ask it to replace plain text passcode storage with a salted scrypt hash and drop client IPs from the request logger, then run the tests. It asks before each edit and command.

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

The second demo is a desktop app session. The CLI session shows in the conversation list, you ask for work on your computer, pick the folder, then Approve or Deny each command and file edit, and it ends with an upgrade done and tests passing. A small team maintaining a whistleblowing portal could use the same flow to add a metadata stripping step to the upload handler and a retention job for closed reports, approving each change as it goes.

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

The third demo shows Claude connected to the Safeguard MCP server with OAuth, with you choosing which tools Claude can use. During a vendor review, you could then ask Claude to pull the scan results for your intake service and its container image into the review notes, using only the tools you allowed.

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

To try it on your own repositories, download Safeguard and follow the CLI documentation. For a broader playbook, see our incident response playbook for a compromised dependency.

Quick check

Sources

• CBC News: More than 1.5 million Canadian Crime Stoppers tips leaked, CBC exclusive finds
• CBC News: Toronto Crime Stoppers pausing program; police services pause partnerships
• CBC News: Crime Stoppers data breach, what's next
• CBC News: Windsor police pause Crime Stoppers after data breach
• Toronto Crime Stoppers: Statement on the P3 data breach (21 October 2026)
• The Record: Toronto crime tips org freezes operations after details of data breach come to light
• Straight Arrow News: Millions of anonymous crime tips exposed in massive Crime Stoppers hack
• Straight Arrow News: Portland police urge residents to avoid Crime Stoppers following hack
• Straight Arrow News: Hackers who stole crime tip records offering data cache
• Straight Arrow News: Senators demand answers over breach of 8.3 million anonymous crime tips
• Waterloo Regional Police: Monitoring cybersecurity incident involving Crime Stoppers service provider
• CKTB News: Hamilton Police notified of cybersecurity incident affecting Crime Stoppers software provider
• Office of the Privacy Commissioner of Canada: Guidelines for processing personal data across borders
• Office of the Privacy Commissioner of Canada: Mandatory reporting of breaches of security safeguards
• CISA: Implementing phishing resistant MFA (fact sheet, PDF)
• NIST SP 800-161 Rev. 1: Cybersecurity Supply Chain Risk Management Practices

Last reviewed: 23 October 2026. This is a developing story; check the linked advisories for the latest status.