TAKKT Cyberattack: Orders and Deliveries Restricted, What Buyers Do

TAKKT AG, the Stuttgart B2B equipment distributor, disclosed on 21 October 2026 that a cyberattack hit IT systems in its European Industrial & Packaging and North American Foodservices divisions. Order processing, customer service and deliveries are significantly restricted. Customers and suppliers should plan for delays and verify any payment or order change by phone.

That is the whole of what TAKKT has confirmed so far, and this post tries to keep it that way. TAKKT has not said how the attackers got in, whether data was taken, whether the attack involved encryption or extortion, or when systems will be back. Nobody outside the company and its responders knows those answers yet. What we can do is explain what the notice actually says, what an outage like this means for the people who buy from and sell to a distributor, and what any B2B distributor can take from it before the same thing happens to them.

What happened

At 16:26 Frankfurt time on Wednesday 21 October 2026, TAKKT published an ad hoc notice through the EQS newswire, in German and English, under Article 17 of the EU Market Abuse Regulation. Article 17 is the rule that forces listed companies to publish inside information, meaning facts likely to move the share price, as soon as possible. The English headline was simply "Cyber attack at TAKKT AG".

According to the notice, TAKKT has become the target of a cyberattack on parts of its IT systems. The affected systems belong to two business divisions:

• Industrial & Packaging in Europe
• Foodservices in North America

TAKKT says it took parts of its systems offline as a precaution to contain possible effects. As a result, order processing, customer service and deliveries are, in the German original, "erheblich eingeschränkt", which the English version renders as significantly restricted.

Ordering has not stopped. The notice says customers can still place orders through the online shop and other channels, which the German version calls interim solutions ("Übergangslösungen"). Processing and delivery of those orders is limited.

On response, TAKKT says it started protective measures immediately under its emergency plan, and that a dedicated task force is working with external cybersecurity experts and IT forensics specialists to restore normal operations as quickly as possible.

On damage, the company was direct: the scope of the attack is still being analysed, and TAKKT cannot yet say whether damage occurred, how large it might be, or when systems will be fully available again.

What TAKKT did not say

Reading a disclosure carefully means noticing the gaps as well as the words. As of the notice and every source we could find up to 23 October:

• No initial access vector was named.
• No malware family, ransomware brand or threat actor was named, and no group has been credibly reported as claiming the attack.
• No statement was made about data theft, customer data or supplier data.
• No estimate of financial impact was given, and the 2026 guidance was neither confirmed nor withdrawn in the notice.
• The third division, Office Furniture & Displays, was not mentioned as affected.
• No brand names were listed, so it is not public which individual TAKKT brands' systems are offline.

We searched for a follow-up notice in German and English on 23 October and found none. TAKKT's own website homepage carried no incident notice when we fetched it. If a second ad hoc or a press release appears, it will most likely come through the same EQS channel.

Who TAKKT is, and why an outage spreads

TAKKT describes itself as a B2B omnichannel distributor of business equipment. It sells mainly through ecommerce, supported by print catalogues and key account managers, and focuses on durable equipment and special items that business customers buy again and again. It is organised in three divisions: Industrial & Packaging, Office Furniture & Displays, and Foodservices.

The numbers give a sense of scale. In its half-year report published on 30 July 2026, TAKKT reported first half sales of EUR 453.8 million. Industrial & Packaging was the largest division at EUR 271.5 million, Office Furniture & Displays brought EUR 95.7 million, and Foodservices EUR 86.6 million. The same report said TAKKT sold its European foodservice equipment business, XXLhoreca, effective 30 June 2026. That helps explain why the ad hoc speaks of Foodservices in North America only.

In North America, TAKKT's foodservice businesses include Central Restaurant Products, which TAKKT acquired in 2009 and describes as the leading US direct marketing company for restaurant equipment, and The Hubert Company. Trade publication Foodservice Equipment & Supplies reported in November 2022 that the two TAKKT subsidiaries would centralise finance, IT and human resources from 1 January 2023 while continuing to operate as separate companies. We mention this as background only. TAKKT has not said which North American systems were affected, and nothing public links the 2023 consolidation to this incident.

Why does that matter to people outside TAKKT? Because a distributor sits in the middle of a lot of other businesses:

• Customers rely on it for consumables and equipment with predictable lead times: shelving, racking, packaging material, workshop and warehouse equipment, restaurant equipment and supplies.
• Suppliers and manufacturers rely on it for purchase orders, forecasts, drop ship instructions and, above all, on time payment.
• Carriers and 3PLs rely on its systems for shipment data and labels.
• Finance teams on both sides rely on its invoicing, credit notes and remittance advice.

When order processing and customer service are restricted, every one of those flows slows down or moves to a fallback channel such as email, phone or spreadsheet. Fallback channels are exactly where fraud and mistakes creep in.

Timeline

Times are as published. TAKKT gave its time as CET/CEST; on 21 October 2026 Germany was still on summer time (CEST, UTC+2), because the clocks change on Sunday 25 October.

Two things stand out in the timing. First, the notice landed about an hour before the close of Xetra trading at 17:30, which is consistent with the MAR duty to publish as soon as possible rather than waiting for the market to close. Second, the attack start time is not public. A disclosure time is not a compromise time, and anyone building a timeline for their own records should keep those two apart.

What changed since first reports

Very little, and that is normal for day two of an operational incident. Early secondary coverage repeated the ad hoc almost word for word. A market commentary piece described the attack as an operational risk with an unclear financial impact and pointed out that duration and reach are the signals to watch. The KonBriefing register added the incident on 22 October and noted that the exact start date has not been confirmed. We found no new facts from TAKKT after the ad hoc as of 23 October.

Technical details

This incident has no CVE, no published indicators of compromise, no file hashes, no domains or IP addresses, and no named malware. We will not invent any. What is published, and useful for defenders and for anyone verifying communications, is below.

Disclosure facts

Incident facts as disclosed

Values worth keeping on file

If you buy from or sell to TAKKT or any of its businesses, three values from the notice are useful when you check a message that claims to be about this incident:

1. The genuine disclosure has EQS News ID 2419786 and was published at 16:26 CET/CEST on 21 October 2026. A "notice" with a different date, or one that asks you to click a link to "update your account", is not that notice.
2. TAKKT's investor relations mailbox in the notice is on the takkt.de domain. Treat lookalike domains with suspicion.
3. The notice asks nobody to do anything. It does not tell customers or suppliers to change bank details, re-enter credentials, or pay through a new channel. Any message that does should be verified out of band.

None of this suggests TAKKT's channels have been abused. It is simply the baseline we recommend after any supplier incident: write down what the real notice says, so a fake one stands out.

How an outage like this usually unfolds

Because TAKKT has not described the attack, we will not describe it for them. It is still worth explaining, in general terms, what "systems taken offline as a precaution" usually means inside a distributor, because that is what drives the experience for customers and suppliers.

A typical B2B distributor runs a chain of systems: web shops and punchout catalogues at the front; an order management or ERP system in the middle that holds customers, prices, credit limits, stock and invoices; a warehouse management system that turns orders into picks and shipments; carrier integrations that produce labels and tracking numbers; and finance systems for receivables and payables. Identity, email and file shares run underneath all of it.

When a security team finds an intruder, the safe move is often to isolate large parts of that chain at once, because they cannot yet tell which systems the intruder touched. That is a deliberate trade: stop the business for a while in exchange for stopping the attacker. It is why a web shop can keep taking orders while nothing ships. The front end is reachable, but the systems that confirm, pick, pack, invoice and dispatch are isolated until investigators clear them.

Restoration then usually happens in stages: systems are rebuilt or restored from known good backups, credentials are reset, and each system is reconnected only after it is checked. Orders captured through interim channels are then imported, often leaving a backlog, and prices, credit notes and invoices issued during the outage may need correction.

None of that is specific to TAKKT. It is why the practical advice below focuses on the hand offs between companies, where the risk is highest while the backlog clears.

Who is affected

What to do now: for customers of an affected distributor

These steps apply to TAKKT's customers this week, and to anyone who buys from a distributor that announces an outage.

1. Confirm the real status through a channel you already know

Call your account manager or customer service on a number you already have from a past invoice, contract or the company website you typed yourself. Do not use a phone number from an unexpected email. Ask three things: is my open order in the system, what is the realistic delivery window, and how will you confirm changes to it.

2. Do not place the same order twice

When confirmations stop arriving, buyers often reorder through a second channel. Once systems recover, both orders may ship and both may be invoiced. Keep a simple log of every order placed during the outage, with the channel, date, items and the name of the person you spoke to.

3. Hold any request to change payment details

During an outage you may receive new remittance instructions, a request to pay a deposit, or an invoice "reissued from our backup system". Most of these will be genuine operational noise. Some will not. The FBI's guidance on business email compromise is plain: confirm any request to change account information with the intended recipient through a secondary channel, and check the full sender address, especially on mobile. If you do pay to the wrong account, contact your bank immediately and ask for a recall, then file a report at ic3.gov.

4. Tell your own accounts payable team today

The person most likely to be targeted is not you, it is whoever pays the invoices. Send a short internal note: "Supplier X has announced a cyber incident. Until further notice, no bank detail change for this supplier is accepted without a call back to a known number and a second approver."

5. Plan for substitution, not just delay

If your work depends on a delivery date, a restaurant opening or a production line restart, line up a second source now. A distributor in recovery cannot always tell you when a particular order will ship.

6. Review what data you share with the supplier

Make a short list: punchout catalogue credentials, EDI connections, API keys, shared portals, user accounts on the supplier's web shop. If the supplier later confirms any data exposure, you will want to know which credentials to rotate. For a web shop login, rotate the password now anyway if it was reused anywhere else.

What to do now: for suppliers to an affected distributor

1. Expect late or irregular purchase orders and payments

A payment run that depends on an isolated ERP may slip. That is not a sign of fraud. A request from "the distributor" to send goods to a new address, or to pay a fee to release a payment, is.

2. Do not change the customer's ship to or bill to details on an email request alone

Order diversion fraud works the same way as payment fraud in reverse: a convincing email asks you to ship to a different warehouse. Confirm by phone with a contact you already know.

3. Agree a temporary order protocol in writing

If your customer wants to send orders by email or spreadsheet during recovery, agree who sends them, from which address, what reference format they use, and who confirms them. Keep it simple and written.

4. Watch your own receivables ageing

Flag invoices to the affected customer so collections do not escalate automatically while the customer's systems are down, and so a sudden "please resend all invoices to this new address" request stands out.

Step by step: detection and verification controls with real commands

The incident itself has no indicators to hunt for. What you can check is whether your own organisation would notice a fraudulent request that rides on it. The commands below are defensive, generic and apply to any supplier incident. Replace the example domains with your own supplier's domain.

Microsoft 365 (Exchange Online PowerShell): tag payment change emails

A transport rule can prepend a warning to external emails that mention bank changes, so the human reading them slows down.

Connect-ExchangeOnline

New-TransportRule -Name "Supplier payment change warning" `
  -FromScope NotInOrganization `
  -SubjectOrBodyContainsWords "bank details","new account","IBAN","routing number","remittance","change of bank" `
  -PrependSubject "[VERIFY BY PHONE] " `
  -SetAuditSeverity Medium

Check whether anyone in finance has an inbox rule that forwards or hides mail, which is a common sign of a compromised mailbox:

Get-Mailbox -ResultSize Unlimited | ForEach-Object {
  Get-InboxRule -Mailbox $_.UserPrincipalName |
    Where-Object { $_.ForwardTo -or $_.RedirectTo -or $_.ForwardAsAttachmentTo -or $_.DeleteMessage -or $_.MoveToFolder } |
    Select-Object MailboxOwnerId, Name, ForwardTo, RedirectTo, MoveToFolder, DeleteMessage
}

Any mail system: check a suspicious message's authentication

Open the original headers of a message and look at the authentication results. A message that claims to come from a supplier but fails DMARC alignment deserves a phone call.

# Save the raw message as message.eml, then:
grep -iE "^(Authentication-Results|Received-SPF|DKIM-Signature|From|Reply-To|Return-Path):" message.eml

Look for dmarc=pass and for a Reply-To that differs from From. A different reply address on a payment email is a strong warning sign.

Linux or macOS: look up a supplier domain's mail policy

# Replace example-supplier.com with the real supplier domain
dig +short TXT _dmarc.example-supplier.com
dig +short TXT example-supplier.com | grep -i spf
dig +short MX example-supplier.com

A p=reject or p=quarantine DMARC policy means spoofing the exact domain is harder, which pushes fraudsters toward lookalike domains instead.

Find lookalike domains of your supplier

The open source tool dnstwist generates permutations of a domain and checks which are registered.

pip install dnstwist
dnstwist --registered --format csv example-supplier.com > supplier-lookalikes.csv

Add the registered lookalikes to your mail system's block list or to a transport rule that tags them.

ERP: review changes to supplier bank details

In SAP ECC, the report RFKABL00 (Display Changes to Vendors) lists changes to vendor master records over a date range; in SAP S/4HANA the business partner change documents serve the same purpose. Filter for bank fields and run it for the last 30 days. In any ERP, export the vendor bank table and compare it with a known good copy:

# vendors_baseline.csv and vendors_today.csv: vendor_id,iban_or_account,changed_by,changed_at
sort vendors_baseline.csv > a.csv
sort vendors_today.csv > b.csv
comm -13 a.csv b.csv   # rows that are new or changed since the baseline

Every changed row should have a matching callback record. If it does not, stop the next payment to that vendor until it does.

Cloud object storage: confirm your own backups cannot be deleted

If you are a distributor reading this and wondering about your own recovery, start with the boring checks.

# AWS: check that the backup bucket has Object Lock enabled
aws s3api get-object-lock-configuration --bucket example-erp-backups
aws s3api get-bucket-versioning --bucket example-erp-backups

An Object Lock configuration in compliance mode with a retention period means backups cannot be deleted by anyone, including an attacker with stolen admin keys, until the period ends.

Lessons for B2B distributors

TAKKT has not shared lessons and we will not guess at its internal decisions. The points below are what any distributor, wholesaler or B2B ecommerce business can take from a day like 21 October.

Design for "orders without ERP" before you need it

The notice shows that a distributor can keep taking orders through the web shop while processing is restricted. The question for every distributor is whether those captured orders can be confirmed, prioritised and shipped in some reduced form while the core system is down. That means a documented, rehearsed fallback: an export of open orders and stock from the last good snapshot, a manual pick process for top customers, a way to print carrier labels outside the integration, and a clear rule on who may promise delivery dates.

Keep the web shop and the core apart, deliberately

Being able to isolate back office systems while keeping the storefront up is a strength. It depends on network segmentation and separate credentials between the storefront, order management, warehouse and finance. The less these share administrator accounts and management tools, the more selectively a team can isolate.

Separate divisions and regions where it costs little

An incident that reaches two divisions on two continents raises a general question for every multinational distributor: what is shared between business units? Shared identity, shared remote management tooling, shared file servers and shared service accounts all make a group more efficient, and all widen the area one intrusion can reach. There is no single right answer, but each shared component should be a conscious choice with its own monitoring.

Make backups immutable and test restores of the systems that ship goods

Backups that an attacker can delete do not count. Keep at least one copy that is immutable or offline, and test full restores of the ERP and warehouse systems on a schedule, timed from start to first shipped order. The restore time you measure is the number your board and your customers actually care about.

Treat the outage itself as a fraud window

Every outage pushes work into email and phone. Before an incident, write the rules for that window: payment detail changes are frozen, every order change needs a callback, and customers are told in your first notice that you will never ask them to change bank details by email.

Tell customers and suppliers what you will and will not ask for

A short customer notice that says "we will never ask you to change payment details by email" does more to prevent fraud than any filter. It is also the part of an incident notice that customers remember.

Prepare the disclosure before the incident

TAKKT's notice was clear, short and fast. Distributors that are listed should have a pre-approved disclosure template and a decision tree for inside information. Unlisted distributors should still have a customer and supplier notice ready to send within hours.

Disclosure rules: MAR day one versus the US four business days

TAKKT's notice is a useful example of how European listed companies report a cyber incident. Under Article 17 of MAR, an issuer must publish inside information as soon as possible. Delay is only allowed under narrow conditions. In practice, an operational outage that restricts order processing and deliveries is very likely to be price sensitive, which is why the first public word came as an ad hoc notice within the trading day rather than a later press release.

In the United States, the SEC's 2023 rules take a different route. A US registrant must file a Form 8-K under Item 1.05 within four business days after it determines that a cybersecurity incident is material, describing the material aspects of the incident's nature, scope and timing and its material impact or reasonably likely material impact. The clock starts at the materiality determination, not at discovery. Foreign private issuers report material incidents on Form 6-K. Disclosure may be delayed only if the US Attorney General determines that immediate disclosure would pose a substantial risk to national security or public safety.

TAKKT is listed in Germany, and we are not suggesting it has any US filing obligation. The comparison matters for US distributors and for US customers of European suppliers: the first public signal of a supplier incident may come through a stock exchange notice in another country and language. If your vendor risk process only watches US news, you may hear about it late.

Open questions

These are the questions we will watch for answers to. We do not know the answers and nobody should guess them in public.

1. How did the attackers get in, and when did the intrusion start?
2. Was data copied out of TAKKT's systems, and does it include customer or supplier data?
3. Which brands and sites in Industrial & Packaging Europe and Foodservices North America are affected?
4. Was the Office Furniture & Displays division touched?
5. When will order processing and deliveries return to normal, and how will the backlog be handled?
6. Will TAKKT quantify the financial impact, and does the incident affect its 2026 guidance?
7. Will a group claim the attack, and if so, will TAKKT confirm or dispute the claim?

What would have helped

Practices any team can use

For distributors, the controls in the lessons section above are the ones that shrink an outage like this: a rehearsed order to cash fallback, segmentation between storefront, core, finance and business units, immutable backups with a measured restore time, endpoint detection on servers, quarterly reviews of third party and remote support access, a payment change freeze written in advance, and a ready customer notice.

For customers and suppliers of a distributor:

• A vendor register that records each critical supplier, what you buy, what data and access they hold, your second source, and who to call.
• Callback verification for every bank detail change, with two approvers, at all times, not only during incidents.
• A watch on your critical suppliers' disclosure channels, including foreign stock exchange newswires when a supplier is listed abroad.

Where Safeguard fits

Safeguard's fit with this incident is indirect, and we want to be specific about it. Safeguard would not have prevented this attack, would not have detected it, does not run anyone's ERP or warehouse systems, does not filter email or detect payment fraud, and does not restore backups. If you are a TAKKT customer or supplier, the steps above matter far more this week than any software.

Where Safeguard does help is the third party side of the problem and the software every distributor runs:

• Third-Party Risk Manager (TPRM). A vendor directory with contracts and SLAs, risk tiers and a self-service vendor portal, so a buyer can record which suppliers are critical, what each holds and who to call. Vendor risk scoring covers vulnerability, compliance, component and operational risk, using EPSS and CISA KEV data. Monitoring sends alerts on events such as a new critical vulnerability, a KEV addition, a risk score change or an SBOM expiry, to email, Slack, Teams, PagerDuty or a webhook. It does not watch stock exchange newswires or news for supplier incidents; you record those yourself.
• Compliance and GRC. The suite includes Vendors, Risks, Controls, Evidence and Questionnaires, so a supplier incident like this one can be logged as a risk with an owner, linked to the controls it tests (for example, payment change verification), and closed with evidence.
• SBOM requests to suppliers. Where your critical suppliers ship you software, TPRM can request SBOMs from them and track each request from sent to validated.
• Knowing what your own storefront is built from. Distributors run large ecommerce and integration stacks. Safeguard scans repositories, container images and SBOM files (safeguard scan --dir ., --image <name>, --sbom <file>, results as JSON under ./output), matches components against vulnerability databases including CISA KEV, ranks reachable flaws first, and shows which projects contain a given component and version. Policies and gates evaluated in the platform can block a build that reintroduces a known vulnerable version.
• A person on every action. The Safeguard CLI's assistant asks before it edits files or runs commands in its default modes (/permissions offers Ask, Accept edits, Plan, Auto and Strict), and the desktop and phone apps let you approve or deny each command on a computer running the CLI. That is the same principle as a payment callback: a request is not an approval.

Zero-Day Discovery and Gold

Zero-Day Discovery looks for previously unknown flaws before a CVE exists, in an agentic mode and a deterministic scanner mode. Findings are issued as SGZ advisories before they reach public CVE databases. It covers seven package ecosystems.

Gold Open Source (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, with a free read API and a CI gate GitHub Action. Gold Registry (registry.safeguard.sh, paid) provides hardened drop in components and container images held to zero exploitable critical or high CVEs, SLSA L3 or higher, Sigstore signed, with evidence pages; an artifact loses its badge if it regresses.

None of these relate to the TAKKT incident. There is no CVE for it and no vulnerable component has been named. They matter for the web shops, integration services and container images every distributor builds and runs: pull patched, signed components from a curated source and rebuild quickly when the next widely exploited flaw lands, so the storefront you keep online during an incident is not the next way in.

Common mistakes

• Calling it ransomware. TAKKT has not said so, and no credible claim has been reported. "Cyberattack with systems taken offline as a precaution" is the accurate description.
• Treating disclosure time as attack time. The notice went out at 16:26 CEST on 21 October. The intrusion started earlier, at a time that has not been published.
• Reordering through a second channel and forgetting. Duplicate orders and duplicate invoices are a common, expensive after effect of distributor outages.
• Accepting new bank details by email during an outage. This is the single most costly mistake customers and suppliers make around a partner's incident.
• Assuming all brands or divisions are affected. The notice names two divisions in two regions. Ask your account manager rather than assuming.
• Assuming no news means no change. Recovery can move quickly once forensic work clears systems. Check the EQS channel and your account contact.
• Blaming the victim in public. It helps nobody, and the facts needed to judge are not public.
• Forgetting your own tabletop. The most useful response to someone else's incident is a two hour exercise on your own order to cash process.

FAQ

What happened at TAKKT?

On 21 October 2026, TAKKT AG disclosed in an ad hoc notice that a cyberattack hit parts of its IT systems in the Industrial & Packaging division in Europe and the Foodservices division in North America. Parts of the systems were taken offline as a precaution, and order processing, customer service and deliveries are significantly restricted.

Was it ransomware?

TAKKT has not said so, and we found no credible report confirming it as of 23 October. The notice describes a cyberattack and a precautionary shutdown. It does not mention encryption, extortion or a ransom.

Was customer or supplier data stolen?

Unknown. TAKKT said it cannot yet assess whether damage occurred or its extent. It made no statement about data theft either way.

Can I still place orders?

According to the notice, yes. Orders can still be placed through the online shop and other channels as interim solutions, but processing and delivery are restricted. Confirm delivery windows with your account contact before you rely on them.

Which TAKKT businesses are affected?

The notice names the Industrial & Packaging division in Europe and the Foodservices division in North America. It does not name individual brands or sites. TAKKT's North American foodservice businesses include Central Restaurant Products and The Hubert Company, but the notice does not say which systems are affected. The Office Furniture & Displays division was not mentioned.

I received an email about the TAKKT incident asking me to update payment details. What should I do?

Do not act on it. Call your contact at the company on a number you already have, not one from the email. The ad hoc notice does not ask customers or suppliers to change anything. If you have already paid to a new account, contact your bank immediately and ask for a recall.

When will systems be back?

TAKKT has not given a date. The notice says it cannot yet say when systems will be fully available again.

Why did TAKKT publish this as an ad hoc notice?

Because it is listed in Frankfurt and the EU Market Abuse Regulation requires listed companies to publish inside information as soon as possible. Publishing on day one, within the trading day, is the rule working as intended.

Did Safeguard detect or could it have stopped this attack?

No. Safeguard did not detect this attack and would not have stopped it. Its role is indirect: tracking critical vendors and their risk, logging supplier incidents against your controls, and keeping the software you build and ship current.

Fix it without waiting for upstream

The TAKKT incident has no published vulnerability, so nothing in this section is a fix for it. It is about the other half of resilience: the web shops, integration services and images a distributor keeps online while the back office recovers.

In incidents like this one, 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 TAKKT, a distributor's ERP or this incident. Each shows a real Safeguard flow that applies to the software a distributor keeps running during an outage, or to the principle that customers and suppliers need this week: verify, then approve.

The first demo is a real CLI session. You install the CLI, open the interactive terminal and ask it to fix the lodash CVE in a repository; it 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, prints a summary and pushes nothing. For a distributor whose web shop stays online while the back office is isolated, you would run the same scan against the storefront's repository or container image and ask for the dependency bumps that matter, approving each step.

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

The second demo sets up the runner on your own machine, approves it with its device code and then scans from the terminal. For a team rebuilding systems after an incident, this is how scans of restored services and images can run on your own hardware before those systems are reconnected.

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

The third demo is a real Android session: work is sent to a computer running the CLI, and the command is approved on the phone with Allow once, Allow for turn or Deny. It is the software version of the payment callback this incident calls for. A request arrives; you read exactly what it asks for; you approve it on a device you control, or you refuse.

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

To try Safeguard on your own repositories, download Safeguard and follow the CLI docs. For another operational incident with third party lessons, see IDCF Cloud ransomware and third party risk, and for the wider picture of this month, October 2026 security incidents and what would have helped. If your team needs to map which products a supplier's software touches, SBOM incident response: finding affected products fast walks through it.

Quick check

Sources

• TAKKT AG: ad hoc "Cyber attack at TAKKT AG", 21 October 2026, via Investegate (EQS)
• TAKKT AG: ad hoc "Cyber attack at TAKKT AG", 21 October 2026, via TradingView (EQS News ID 2419786)
• TAKKT AG: ad hoc "Cyberangriff bei TAKKT AG" (German), 21 October 2026, via boerse-online (dpa-AFX)
• TAKKT AG: ad hoc "Cyber attack at TAKKT AG", 21 October 2026, via ad-hoc-news
• TAKKT AG: half-year report 2026, 30 July 2026, via boerse-online (dpa-AFX, German)
• TAKKT AG: company homepage
• TAKKT AG: history, 2009, Central complements activities in the food service equipment market
• TAKKT AG: history
• Foodservice Equipment & Supplies: CRP and Hubert unify operations (30 November 2022)
• Goldesel: TAKKT Aktie, Cyberangriff bremst Aufträge und Auslieferungen (21 October 2026, German)
• KonBriefing: cyber attacks register, TAKKT entry (22 October 2026)
• US SEC: SEC adopts rules on cybersecurity risk management, strategy, governance, and incident disclosure (press release 2023-139)
• FBI IC3: Business Email Compromise

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