Supercell Video Platform Breach and an EU Cyber Resilience Act Filing

On 21 October 2026 Supercell said an attacker copied internal videos from the third-party platform it used for company meetings and presentations. The recordings show employees, former staff, guests and partners, and platform users' names and emails were also accessed. Supercell filed a notification under the EU Cyber Resilience Act. Anyone recorded should treat unexpected calls and requests with suspicion.

Two things make this short notice worth a long read. The first is the data itself. A library of internal meeting recordings holds faces, voices, names and the way people talk to each other at work, which is exactly the raw material an impersonation scam needs. The second is the filing. The Cyber Resilience Act (CRA) reporting duties only started on 11 September 2026, and a company publicly saying it submitted a CRA notification is still rare. This post explains what Supercell disclosed, what it did not, and how CRA reporting works according to the European Commission's and ENISA's own pages. It does not guess which video vendor was involved or why Supercell chose to file under the CRA. Supercell has said neither.

What happened

Supercell, the Finnish maker of Clash of Clans and Brawl Stars, published a notice titled "Security incident at our video platform" on its news page, dated 21 October 2026. According to that notice, Supercell was the target of "multiple cyber attacks" in the previous week. One of them led to an incident at the video platform the company used to host internal videos, such as company meetings and presentations.

An unauthorized party accessed the platform and copied some of the internal video content. Supercell says it blocked further access, took the service offline and is investigating together with the platform provider and its own security experts. It filed a police report, submitted a notification under the EU Cyber Resilience Act, and notified the Data Protection Ombudsman, Finland's data protection authority.

On the data, Supercell says that based on its investigation so far no player data was affected. The videos include current and former employees and some guests and partners who appeared at internal events, and they may contain names, images and voices. The names and email addresses of the platform's users were also accessed. Supercell says that people who spoke or presented at recorded Supercell events, or who were hosted by Supercell, are likely affected, and it asks anyone who has worked with Supercell and has questions to write to incidents-info@supercell.com.

The practical advice in the notice is about impersonation. Supercell asks people to be careful with unexpected messages, calls or video calls that claim to come from Supercell or its staff, especially when they ask for money, passwords, access or files, and to verify any such request through a channel they already know and trust. The investigation is ongoing and the company says it cannot share more yet.

Timeline

Supercell has not published the exact time it became aware of the incident or when each notification was sent, so this post does not put minute level times against those steps. The 20 October SRP upgrade is listed only because it changes how teams register on the platform; there is no indication it relates to Supercell.

Who is affected

Partners of Supercell are the group most likely to be underestimated. A partner who gave one talk at an internal event now has a recorded voice sample, a face and a name in the hands of an unknown party, along with context about what they discussed with Supercell. That is enough to make a fake follow up call from "the Supercell team" sound right.

How a meeting recording becomes an attack tool

This section explains the risk in plain terms. It does not describe how the platform was accessed, because Supercell has not said.

Recordings carry more than the words spoken

A transcript tells an attacker what was said. A video tells them who said it, how they look, how they sound, who sits in which team, which projects are live, what internal jargon is used and who reports to whom. Recorded all hands meetings and internal presentations tend to include senior people speaking at length, often in good audio quality, which is the most useful kind of sample for voice cloning.

Platform user lists give the target list

Supercell says names and email addresses of the platform's users were also accessed. Paired with the videos, that gives an attacker both the faces and voices and a list of addresses to send messages to. A phishing email that mentions a real internal presentation by name, from someone who appears to be the presenter, is much harder to dismiss than a generic lure.

The scam patterns Supercell warns about

Supercell names three: targeted phishing, impersonation, and video call scams. United States federal guidance gives a sense of what this looks like in practice. In May 2025 the FBI warned of a campaign using text messages and AI generated voice messages to impersonate senior officials, and its first piece of advice was blunt: "do not assume it is authentic." Its list of protective steps includes checking contact details independently, listening for unusual tone, word choice or lag in voice messages, and agreeing a secret word or phrase to confirm identity. The same steps apply to anyone whose voice and face now sit in a copied video library.

Why a third-party platform matters

The video platform was a third-party service, not something Supercell built. That is normal. Most companies record meetings in a hosted tool, and many have several: the meeting tool's own cloud recording, a separate video hosting service for internal presentations, a transcription tool, and recording features inside sales and support software. Each one is a separate store of faces and voices with its own access model, retention settings and audit log. Supercell has not named its provider, and nothing in this post should be read as a guess about who it was.

The Cyber Resilience Act, from the Commission's own pages

The CRA is Regulation (EU) 2024/2847. The European Commission's CRA page says it entered into force on 10 December 2024, that reporting obligations apply from 11 September 2026, and that the main obligations apply from 11 December 2027. It sets cybersecurity rules for "products with digital elements": hardware and software, from consumer devices to apps and computer programs, sold on the EU market.

What the CRA covers

The Commission's summary of the legal text defines a product with digital elements as a software or hardware product "and its remote data processing solutions", including components placed on the market separately. Remote data processing means processing at a distance that the manufacturer designs and develops, or that is done under its responsibility, and without which the product could not perform one of its functions.

That definition matters for anyone trying to understand where hosted services sit. The Commission's FAQ on CRA implementation says standalone Software as a Service, or other cloud solutions designed and developed outside the responsibility of a product manufacturer, are not themselves products with digital elements. Where a service does meet the definition of remote data processing, it falls within scope. The Commission's 27 July 2026 guidance goes further with worked examples. In one, a banking app integrates a customer support chat built and operated by a third-party SaaS provider: the chat is not the bank's remote data processing solution, but the guidance says it "should be treated like a third-party component" in the bank's risk assessment. In another, an e-reader maker relies on a third-party SaaS storage service; again the guidance says the manufacturer should treat the SaaS like a component and apply product level protections.

These are general rules from the Commission. They are not a statement about Supercell's products, its video platform, or the basis of its notification.

Who has to report, and what

Article 14 of the CRA puts reporting duties on manufacturers. The Commission's reporting page lists two things that must be reported:

1. Actively exploited vulnerabilities contained in the manufacturer's product with digital elements.
2. Severe incidents having an impact on the security of the product with digital elements.

The CRA defines an actively exploited vulnerability, in Article 3(42) as quoted in the Commission FAQ, as a vulnerability for which there is reliable evidence that a malicious actor has exploited it in a system without the permission of the system owner. The FAQ is explicit that a zero day found by an ethical hacker, with no evidence of malicious exploitation, is not an actively exploited vulnerability subject to mandatory reporting, although it can be reported voluntarily under Article 15.

For severe incidents, ENISA's Single Reporting Platform FAQ describes a severe incident as one with a severe impact on the security of a product, such as compromising availability, authenticity, integrity or confidentiality, with the criteria set out in Article 14(5). It describes an impacting incident as one that negatively affects, or is capable of negatively affecting, the product's protective functions.

The three deadlines

The Commission's reporting page and its guidance set out the same three stage structure:

The Commission guidance stresses that the structure is progressive: notifications are updated as the investigation advances and knowledge becomes more detailed.

When the clock starts

This is the part most teams get wrong in tabletop exercises. The Commission guidance, in section 9.1, says a manufacturer is regarded as having become aware when, after an initial assessment, it has a reasonable degree of certainty that a vulnerability in its product is being actively exploited, or that a severe incident has occurred and has led to the security of its product being compromised. The guidance says this reading of "becoming aware" is aligned with recital 31 of Implementing Regulation (EU) 2024/2690 under NIS2 and with Guidelines 9/2022 on personal data breach notification under the GDPR, so that companies with overlapping duties can use one consistent trigger.

The same guidance adds that the emphasis should be on prompt action to carry out the initial assessment. Taking a long time to decide whether you are aware is not a way to delay the clock.

Where reports go

All notifications go through ENISA's Single Reporting Platform, at portal.cra-srp.enisa.europa.eu. The Commission says manufacturers report once: the notification goes to the CSIRT designated as coordinator in the member state of the manufacturer's main establishment, and ENISA receives it at the same time unless exceptional circumstances apply. The receiving CSIRT then shares it without delay with the CSIRTs in other member states where the product was made available.

ENISA's FAQ explains how to pick the coordinating CSIRT. For a manufacturer with an EU main establishment, it is the member state where cybersecurity decisions for the products are predominantly taken, or failing that, the member state of the establishment with the most EU employees. Manufacturers with no EU establishment work down a list: the authorised representative's member state, then the importer's, then the distributor's, then the member state with the most users. The FAQ warns that choosing the wrong coordinator can lead to the notification being invalidated and resubmitted.

For Finland, ENISA's list of CSIRTs designated as coordinators points to the National Cyber Security Centre Finland (NCSC-FI) contact page at Traficom. Traficom's CRA page says Traficom acts as the CRA market surveillance authority, supervises notified bodies and receives manufacturers' vulnerability and incident notifications. Finland's national act complementing the CRA is Act 439/2026.

Telling users

Article 14(8) requires manufacturers, after becoming aware of an actively exploited vulnerability or a severe incident, to inform impacted users and, where appropriate, all users. If a manufacturer does not do this in a timely way, the CSIRTs that received the notification may inform users themselves where that is proportionate and necessary. The Commission guidance says this duty is risk based: informing users does not mean publishing technical detail indiscriminately, especially where detail could help further exploitation.

Products already on the market

The reporting duty is not limited to new products. The Commission FAQ, citing Article 69(3), says Article 14 applies from 11 September 2026 to all in-scope products, including those placed on the market before 11 December 2027. The guidance adds that, unlike vulnerability handling, reporting continues after a product's support period ends. There is no retroactive duty: a manufacturer that became aware of active exploitation before 11 September 2026 does not have to report it, though awareness after that date does trigger the duty.

Third-party components

Section 5.4 of the Commission FAQ deals with a question every software maker should know the answer to. If an actively exploited vulnerability sits in a third-party component inside your product, you must notify it, and the component's manufacturer must also notify it if the component was placed on the market. If the component has a vulnerability that cannot be exploited in your product, for example because the vulnerable code is not reachable, it is not an actively exploited vulnerability for you and mandatory reporting does not apply, although you must still report it upstream to the component's maintainer under Article 13(6).

Technical details

Supercell's notice contains no CVE identifiers, affected versions, file hashes, domains, IP addresses or other indicators of compromise. It does not name the video platform, the access method, the number of videos copied, the number of people affected or the time window of access. The defender-useful specifics that do exist are the facts of the notice and the operating details of the CRA reporting system, and they are listed here exactly as the sources give them.

Facts from Supercell's notice

CRA legal references

Single Reporting Platform operating facts

The counter detail is worth reading twice. ENISA says the platform's timers are only visibility aids and that every deadline runs "without undue delay" from awareness. A team that relies on the portal's countdown rather than its own clock could believe it has more time than it does.

Fields the platform asks for

ENISA's FAQ says the SRP Glossary gives field by field guidance, and summarises the main fields:

Some fields are required only at the 72 hour notification or the final report.

Finland contacts named by the authorities

What changed since the first reports

At the time of writing there has been no second update from Supercell. The searches run for this post found the company's own notice and no independent reporting that added facts to it. A few older stories about Supercell security incidents appear in search results, including a 2017 forum breach. They are unrelated to this incident and are not used here.

On the regulatory side, the CRA reporting system itself has moved recently. ENISA upgraded the platform to version 1.2.1 on 20 October 2026, replacing the process for inviting Secondary Assigned Representatives or backups, and says its documentation is being updated to match. Any team that registered in September should check that its backup representatives can still sign in and act.

Open questions

• Which video platform? Supercell has not named it. Until it does, nobody outside the company knows whether other customers of the same service are exposed.
• How was it accessed? The notice does not say whether the access came through a Supercell account, a vendor side issue, or something else.
• What were the other attacks? Supercell describes "multiple cyber attacks" in one week and describes only one.
• How many people and videos? No counts are given.
• What did the CRA notification cover? Supercell says it submitted one. It does not say what it covered, and the CRA does not require manufacturers to publish their notifications. This post does not speculate.
• Is there a time window? The notice gives no dates for first access, detection or containment.

What to do now

The steps below are for any organisation that records meetings in a hosted video tool, and for any software maker that now has CRA reporting duties. They are written to be run this week.

1. If you were recorded at a Supercell event

1. Assume your voice and face may be used. Tell your finance, IT and executive assistants that a call or video from you asking for money, credentials or files must be verified on a known number.
2. Agree a verification phrase or a callback rule with the people most likely to receive a fake request in your name.
3. Treat any message referencing a Supercell event, presentation or contact with extra care, and confirm it through a channel you already trust, as Supercell advises.
4. If you have questions about whether you are affected, use the address Supercell published: incidents-info@supercell.com.

2. Inventory every place your company stores recordings

Most companies cannot answer "where are our meeting recordings?" in one sentence. Build the list from three directions.

1. Identity provider. Export the list of applications assigned through single sign on and filter for meeting, video, webinar, recording, transcription and note taking tools.
2. Finance. Pull card and invoice data for the same categories. Tools bought on a team card often never touch single sign on.
3. Mail and DNS. Look for sign up confirmations and verification records that reveal tools nobody registered centrally.

A quick way to see which third parties are verified for your domain is to read its TXT records, since many SaaS tools ask customers to add a verification string:

# List TXT records for your domain; look for vendor verification strings
dig +short TXT example.com

# Check the subdomains your teams commonly delegate to SaaS tools
for h in video meet webinar media events; do
  printf "%s: " "$h.example.com"; dig +short CNAME "$h.example.com"
done

Record each tool in a register with its owner, the data it holds, whether it is behind single sign on, and its retention setting.

3. Set retention on recordings

Recordings kept forever are a liability that grows every week. For each tool in the register:

1. Find the recording retention setting at the organisation level, not per user.
2. Set a default retention period that matches how long recordings are actually used, and an explicit exception process for recordings that must be kept.
3. Run a one time cleanup of recordings older than the new period, after confirming nothing is under legal hold.
4. Turn off automatic recording of all meetings where the tool allows it, so recording becomes a deliberate choice.

4. Lock down access

1. Require single sign on for every recording tool and disable password login where the tool allows it.
2. Remove "anyone with the link" sharing for internal recordings, or limit it to signed in members of your organisation.
3. Review who holds admin rights in each tool. Admins can usually download everything.
4. Make sure leavers lose access to recording tools at the same time as everything else. Former employees appear in Supercell's list of affected people as subjects of recordings; former employees who still hold access are a separate and avoidable risk.
5. Turn on, export and keep the tool's audit logs. Bulk download or export events are the ones to alert on.

5. Prepare for impersonation, not just phishing

Classic phishing training teaches people to distrust links. Impersonation with real voices and faces needs a different habit: verify the request, not the person. Practical rules that cost almost nothing:

1. No payment, bank detail change, credential reset or file transfer on the strength of a call or video alone. Confirm on a known number or in person.
2. A short list of named people who can approve urgent exceptions, and a rule that urgency is a reason to slow down.
3. A clear way for staff to report a suspicious call without embarrassment.

6. Make it harder to send mail as you

Impersonation often starts with email that appears to come from your domain. Check that your domain publishes a strict DMARC policy:

# Read your DMARC policy; look for p=quarantine or p=reject
dig +short TXT _dmarc.example.com

# Read your SPF record
dig +short TXT example.com | grep -i "v=spf1"

A policy of p=none only reports; it does not stop spoofed mail. Move towards p=quarantine and then p=reject once your legitimate senders are aligned. This will not stop lookalike domains, so also watch for newly registered domains that resemble yours.

7. Build your CRA clock before you need it

If your company makes software or hardware sold in the EU, the CRA reporting duty already applies. Steps for this week:

1. Name the people. Decide who will be the Primary Assigned Representative and at least two Secondary ARs. Each needs a personal EU Login account with multi-factor authentication.
2. Pick the coordinating CSIRT on paper. Work through ENISA's rules: main establishment where product cybersecurity decisions are taken, otherwise the establishment with the most EU employees. Write down the answer and the reasoning.
3. Do not register early for the sake of it. ENISA advises registering only when a notification is needed. Instead, keep the registration steps and links in your incident runbook.
4. Define "aware" in your runbook. Use the Commission's wording: reasonable degree of certainty after an initial assessment. Assign who makes that call.
5. Run your own timers. Do not rely on the portal's counters. A simple way to compute deadlines from the awareness time:

# Awareness time in UTC
AWARE="2026-10-24T09:30:00Z"

# Linux (GNU date)
date -u -d "$AWARE + 24 hours" +"Early warning due: %Y-%m-%dT%H:%MZ"
date -u -d "$AWARE + 72 hours" +"Notification due:  %Y-%m-%dT%H:%MZ"

# macOS (BSD date)
date -u -j -f "%Y-%m-%dT%H:%M:%SZ" -v+24H "$AWARE" +"Early warning due: %Y-%m-%dT%H:%MZ"
date -u -j -f "%Y-%m-%dT%H:%M:%SZ" -v+72H "$AWARE" +"Notification due:  %Y-%m-%dT%H:%MZ"

6. Run CRA and data protection notifications in parallel. Supercell notified the police, the CRA channel and the data protection authority. Your runbook should have owners for each channel so one does not wait on another.
7. Draft the user notice template. Article 14(8) requires informing impacted users. A pre-agreed template, reviewed by legal, saves hours.

8. Know what is inside your products

The CRA FAQ's third-party component rule means that when a vulnerability in a library you ship is exploited in your product, you have to report it, and when it cannot be exploited in your product, you do not. You can only make that call quickly if you know which components and versions you ship and whether the vulnerable code is reachable. Generate an SBOM for each product release and keep it next to the release:

# Scan a repository and write results under ./output
safeguard scan --dir .

# Scan a built container image
safeguard scan --image registry.example.com/app:1.4.2

# List component names and versions from a CycloneDX SBOM
jq -r '.components[] | "\(.name)@\(.version)"' sbom.cdx.json | sort -u

For a deeper walkthrough of finding affected products fast, see SBOM incident response: finding affected products fast.

What would have helped

Nothing in the public record says how the video platform was accessed, so this section does not claim any single control would have prevented it. It lists practices that reduce the damage of this class of incident, and the CRA readiness work that makes the reporting side calmer.

Practices any team can use

• A SaaS register that includes recording tools. Video hosting, meeting recording, transcription and note taking tools hold some of the most sensitive data in a company and are rarely on the list. Owner, data held, single sign on status and retention for each.
• Retention by default. A recording that has been deleted cannot be copied. Short default retention with deliberate exceptions limits what any breach can take.
• Single sign on and least privilege. Every recording tool behind single sign on, link sharing restricted to signed in members, and admin rights limited to the few who need them.
• Audit logs with an alert on bulk export. Copying a library of videos leaves a trail of downloads in most tools. Someone should be watching for it.
• Offboarding that covers SaaS. Leavers lose access to every tool in the register on the same day.
• Third-party review that asks about recordings. When buying a video or recording tool, ask how customer content is isolated, how admin access by the vendor is controlled and logged, and how quickly the vendor will notify you of an incident.
• Verification habits against impersonation. Callback rules, approval lists and verification phrases cost nothing and work against cloned voices as well as plain phone scams.
• A notification runbook with every channel. Police, data protection authority and, for product makers, the CRA platform, each with an owner, a template and a clock.
• Practice the 24 hour early warning. Run a tabletop where the team has to decide, with incomplete information, whether the incident affects the security of a product, and submit a mock early warning inside 24 hours.

Zero-Day Discovery and Gold

Safeguard's Zero-Day Discovery looks for previously unknown flaws in open source packages before a CVE exists, in an agentic mode and a deterministic scanner mode, across seven package ecosystems, and issues findings as SGZ advisories before they reach public CVE databases. Gold Open Source at gold.safeguard.sh is a free, no login source of CVE intelligence with CVSS, EPSS, KEV status, affected and fixed versions and a recommended safe version, with a free read API and a CI gate GitHub Action. Gold Registry at registry.safeguard.sh provides hardened drop in components and container images held to zero exploitable critical or high CVEs, with SLSA L3 or higher provenance, Sigstore signatures and evidence pages.

None of these applies directly to this incident. A hosted video platform is not an open source package, and nothing published so far points to a vulnerable library. Where these capabilities do matter is the CRA side of the story: a software maker with reporting duties needs to know quickly whether an exploited vulnerability is in a component it ships, and needs a fast path to a fixed version. Pulling patched, signed components from a curated source and rebuilding quickly shortens the time between a CRA early warning and the corrective measure that starts the 14 day final report clock.

Where Safeguard fits

Be clear about the limits first. Safeguard does not monitor third-party SaaS video platforms, does not detect deepfakes, and would not have stopped someone copying videos from a hosted service. It does not file CRA notifications for you.

Where it does help:

• Knowing what is in your products. Safeguard scans repositories, container images and SBOM files (safeguard scan --dir ., --image <name>, --sbom <file>) and the platform shows which projects contain a given component and version. That is the information you need to decide, under the CRA FAQ's component rule, whether an exploited vulnerability is in your product.
• Reachability. Reachability analysis shows whether your code calls the vulnerable path. The Commission guidance gives unreachable vulnerable code as an example of a vulnerability that is not actively exploited in your product.
• Fixing fast. Autonomous remediation opens tested fix pull requests when a fixed version exists. It ships switched off, with every category set to Manual.
• Policies and gates. Policies and gates evaluated in the platform can stop a known vulnerable version shipping in the next release.
• Compliance tracking. Safeguard's compliance suite includes the EU Cyber Resilience Act among its frameworks, along with a vendors register where recording and video tools can be tracked with their owners and reviews.
• Human approval on every change. The Safeguard CLI's assistant can edit code and run commands with your approval, and the desktop and phone apps let you approve each command on a computer running the CLI. /permissions sets the mode: Ask, Accept edits, Plan, Auto (the default) or Strict.

Common mistakes and troubleshooting

If you cannot find a recording tool's retention setting: check the organisation admin console rather than user settings, and ask the vendor in writing. If the tool cannot enforce retention, that is a reason to move recordings elsewhere.

If you cannot tell whether an incident affects a product's security: write down the evidence you have, the decision you made and when. The Commission guidance accepts that awareness can take time to establish, but expects prompt action on the initial assessment.

FAQ

What happened at Supercell?

Supercell says that during a week of multiple cyber attacks, an unauthorized party accessed the third-party platform it used to host internal meeting and presentation videos, and copied some of the content. It blocked access, took the service offline and is investigating with the vendor.

Was player data affected?

Supercell says that based on its investigation so far, no player data was affected.

Who is affected?

Current and former employees, and guests and partners who appeared in recorded internal events. Supercell says the videos may contain names, images and voices, and that names and email addresses of the platform's users were also accessed. People who spoke at recorded Supercell events are likely affected.

Which video platform was it?

Supercell has not named it, and this post does not guess.

What did Supercell notify?

It filed a police report, submitted a notification under the EU Cyber Resilience Act, and notified the Data Protection Ombudsman. It has not published the content of those notifications.

What is the Cyber Resilience Act?

Regulation (EU) 2024/2847, an EU law that sets cybersecurity rules for products with digital elements sold in the EU. It entered into force on 10 December 2024. Reporting obligations apply from 11 September 2026 and the main obligations from 11 December 2027.

What must manufacturers report under the CRA?

Actively exploited vulnerabilities in their products and severe incidents having an impact on the security of their products, through ENISA's Single Reporting Platform: an early warning within 24 hours, a notification within 72 hours, and a final report within 14 days of a fix for vulnerabilities or within one month of the 72 hour notification for severe incidents.

Is a SaaS tool a product under the CRA?

The Commission FAQ says standalone SaaS designed and developed outside a manufacturer's responsibility is not itself a product with digital elements, while services that meet the definition of remote data processing are in scope. The guidance says third-party SaaS a product relies on should be treated like a component in the manufacturer's risk assessment.

Where do CRA reports go in Finland?

All CRA reports are submitted through ENISA's Single Reporting Platform. ENISA's list of coordinating CSIRTs points to NCSC-FI at Traficom for Finland, and Traficom says it receives manufacturers' vulnerability and incident notifications.

How do I protect myself if my voice or face was in the videos?

Expect impersonation. Agree verification rules with the people who might receive fake requests in your name, confirm any unusual request on a known channel, and never act on a call or video alone when money, credentials or files are involved.

Fix it without waiting for upstream

This incident started in a hosted service, not a library. But the CRA reporting clock it illustrates runs fastest for software makers whose products ship open source components, and the time from early warning to a corrective measure is mostly the time it takes to get a fixed version into production.

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 shows Supercell, a video platform or a CRA filing. Each is a real Safeguard session, and each intro explains how the same flow applies to the work in this post.

This real CLI session fixes a lodash CVE in a sample repository: 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. Under the CRA, the gap between an early warning about an exploited library and the corrective measure that starts the 14 day final report clock is exactly this kind of upgrade, done with a human approving each step.

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

This real desktop app session shows the CLI session in the conversation list, a request for work on your computer, a folder pick, and Approve or Deny on each command and file edit, ending with an upgrade done and tests passing. For CRA readiness you would pick the folder that holds your incident runbook and ask for the deadline script and notification templates from this post to be added, approving each file edit yourself.

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

This session connects Claude to the Safeguard MCP server with OAuth and chooses which tools Claude can use. It is the same discipline this incident argues for with recording tools: decide exactly what a connected service can reach, and keep that list short and reviewed.

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 docs. For what the CRA expects from SBOMs, read EU Cyber Resilience Act SBOM requirements. For another incident shaped by a provider relationship, see IDCF Cloud ransomware and third party risk, and for the wider month, October 2026 security incidents and what would have helped.

Quick check

Sources

• Supercell: Security incident at our video platform (21 October 2026)
• European Commission: Cyber Resilience Act
• European Commission: CRA reporting obligations
• European Commission: Summary of the CRA legal text
• European Commission: FAQs on the Cyber Resilience Act
• European Commission: New guidance to support timely CRA implementation (27 July 2026)
• European Commission: Guidance on the application of Regulation (EU) 2024/2847, C(2026) 5252 annex
• European Commission: CRA implementation factpage
• ENISA: Single Reporting Platform (SRP)
• ENISA: The CRA Single Reporting Platform is launched
• ENISA: SRP frequently asked questions
• ENISA: List of CSIRTs designated as coordinators
• Traficom NCSC-FI: Cyber Resilience Act (CRA)
• Traficom NCSC-FI: Contact
• FBI IC3: Senior US officials impersonated in malicious messaging campaign (PSA I-051525-PSA)

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