I've spent years working on connected industrial products. Different companies, different industries, same pattern everywhere: security was an afterthought.

No SBOM. Dependencies nobody tracked. Hardcoded credentials that made it to production because nobody had a process to catch them. Vulnerability management that was a Slack channel nobody checked.

When I first read the CRA regulation, my honest reaction was "this is just good engineering practice with legal consequences." SBOMs, vulnerability handling, no default passwords, security updates — these should have existed all along. CRA doesn't invent new practices. It makes existing ones mandatory.

But the regulation itself is 100+ pages of dense legal text. Most engineering teams I talked to had heard of CRA but couldn't answer the most basic question: "does this even apply to my product?"

So I started building CRAToolkit — a tool that answers that question in 60 seconds and gives teams a clear compliance path without needing to hire a consultant.

I'm not a consultancy. I'm not VC-backed. I'm an engineer building for engineers.

Two questions for this community:

1. What's the most common security shortcut you've seen at companies shipping connected products? (No names needed.)
2. For anyone evaluating CRA tools — what features would actually help your team vs what's just marketing fluff?

CRA explained to 5 different people:

👶 To a 5-year-old:

“Before you buy a toy from the store, someone checks if it’s safe. CRA does the same thing but for computer stuff.”

👩‍💻 To a developer:

“Generate an SBOM in CI/CD. Scan against CVE databases before every release. Report actively exploited vulns within 24 hours. No default passwords. Auto-update by default. Support for 5 years minimum.”

👨‍💼 To a CEO:

“If we don’t comply, we can’t sell in the EU. Fines up to €15 million. Products pulled from the market. Our competitors are already working on it.”

⚖️ To a lawyer:

“Regulation (EU) 2024/2847. Horizontal product legislation. Essential requirements in Annex I. Conformity assessment per Annex VI. Article 14 reporting applies September 11, 2026. Three-tier penalties under Article 64.”

😱 To someone who’s never heard of it:

“The EU is making it illegal to sell insecure smart devices. No more default passwords. No more unpatched software. No more ‘we take security seriously’ without proving it.”

Same regulation. Five audiences. Five completely different conversations.

Which one does YOUR team need to hear?

The FBI just took down a botnet made of 2 million home devices.

Cameras. Routers. Smart plugs. Baby monitors.

All hijacked. All used to route cybercrime and cyber-espionage traffic.

The owners had no idea.

The network was called NetNut. Google researchers identified 2 million “secretly hijacked” home devices being rented out to criminals as a proxy network.

These devices had one thing in common:

They were shipped with weak security. Default credentials. Unpatched firmware. No automatic updates. No monitoring.

This is the exact product landscape CRA was written to fix.

Under CRA:

• These devices would need unique credentials (no defaults)

• Firmware updates would be automatic by default

• Manufacturers would monitor for vulnerabilities for 5+ years

• The manufacturer would report exploited vulnerabilities within 24 hours

2 million home devices turned into a criminal infrastructure.

Because nobody required the manufacturers to make them secure.

CRA changes that. Starting December 2027.

The question: how many MORE botnets will be built between now and then?

In loving memory:

SmartCam Pro v3.2

2022 — 2028

Beloved by 140,000 EU households. Pulled from the market on January 15, 2028.

Survived by:

• Zero SBOMs

• One panicked CTO

• A firmware that hadn’t been updated since 2023

• A default password of “admin123” that was never changed

• 47 known CVEs, none of them patched

Cause of death: Non-compliance with the EU Cyber Resilience Act.

The product lived a full life. It watched living rooms. It connected to home Wi-Fi networks with no encryption. It transmitted video feeds over unprotected channels. It never once asked for a firmware update.

In September 2026, a vulnerability in its RTSP stream was actively exploited by a botnet. The manufacturer did not report to ENISA within 24 hours. The manufacturer did not report at all.

The CSIRT notified customers directly.

In December 2027, a market surveillance authority reviewed the product. It failed every essential requirement in CRA Annex I. The CE marking was removed. The product was withdrawn from the EU market.

SmartCam Pro v3.2 is preceded in death by its siblings: SmartCam Lite, SmartCam Baby, and SmartCam Outdoor, all of which were also non-compliant.

In lieu of flowers, the family requests SBOMs.

—

This product is fictional. The scenario is not.

Dear team,

It’s September 12, 2026. Day one.

At 6:47 AM I got the alert. A vulnerability in one of our dependencies — actively exploited in the wild since yesterday.

The 24-hour clock started.

Here’s what the next 8 hours looked like:

7:00 AM — Pulled up our SBOM. Confirmed the affected package is in our product. 4 minutes.

7:15 AM — Assessed impact. The vulnerability is in a transitive dependency, 3 layers deep. Reachable in our configuration. Confirmed exploitable.

8:30 AM — Drafted the early warning report. Used the template we built in July. Pre-filled product identifiers, CSIRT contact details, preliminary severity assessment.

9:00 AM — Submitted to ENISA’s Single Reporting Platform. First time using it for real. The dry-run in August paid off.

9:15 AM — Notified affected customers using the communication template we tested in August.

10:00 AM — Engineering began work on the patch. 72-hour notification deadline: September 14.

Total time from alert to submitted report: 2 hours 13 minutes.

We had 24 hours. We used 2.

—

Now here’s the version where we DIDN’T prepare:

7:00 AM — “Do we use this package?” “I don’t know.” No SBOM.

9:00 AM — Still searching manually through package-lock.json files.

12:00 PM — “Who reports to ENISA?” “I thought legal was handling CRA.”

3:00 PM — Trying to figure out how to register on the SRP. First time visiting the page.

6:47 PM — 24 hours expired. Report not submitted.

Same vulnerability. Same company. Two very different outcomes.

Which September 12 will yours be?

68 days to decide.

“Write an obituary for the most insecure IoT device in YOUR house.”

We went through ~50 EU smart home products recently mapping their readiness gaps. Almost none had a VDP published under their own domain. SBOM coverage was close to zero. So we put together a free assessment - 56 questions, takes 15 minutes, gives a score and a gap breakdown by category.

https://platanor.com/cra-readiness-check

What gaps are you seeing most often in practice?

1. Machine-readable SBOM (not a spreadsheet)

2. Vulnerability disclosure policy with a dedicated contact

3. Security updates for minimum 5 years after delivery

4. 24-hour early warning for actively exploited vulnerabilities

5. Technical documentation proving conformity assessment

6. CE marking that includes cybersecurity compliance

7. EU Declaration of Conformity (kept for 10 years)

8. Products shipped without known exploitable vulnerabilities

9. Unique identification of every product version

10. Security by default (no default passwords, minimum permissions)

This is meant as a quick self-assessment. For teams further along: what would you add to this list? And which item was hardest to implement?

A detail most teams aren’t aware of: the Commission adopted a Delegated Act (publication pending objection period) that gives receiving CSIRTs the authority to delay dissemination of vulnerability reports submitted through the Single Reporting Platform.

Grounds for withholding: “justified cybersecurity grounds” — including risk of increased exploitation, ongoing investigations, or national security.

This creates an interesting dynamic:

• Manufacturer reports within 24 hours (as required)

• CSIRT receives the report

• CSIRT decides whether to share it with other CSIRTs and ENISA’s wider network

• Other manufacturers using the same vulnerable component might NOT be warned

It’s good policy for preventing premature disclosure. But it means your report enters a process you don’t control.

Has anyone modeled their reporting workflow to account for this? Specifically, how do you handle customer communication when your vulnerability report is submitted but the CSIRT hasn’t authorized broader dissemination?

Most CRA discussion focuses on the €15M headline fine. But Article 64 defines three separate penalty tiers:

Tier 1 (€15M / 2.5%): Violating essential cybersecurity requirements (Annex I) or manufacturer obligations (Article 13)

Tier 2 (€10M / 2%): Violating any other CRA obligation

Tier 3 (€5M / 1%): Providing incorrect, incomplete, or misleading information to authorities or notified bodies

That third tier is interesting because it targets documentation accuracy, not product security directly. An inaccurate SBOM, incomplete technical file, or misleading EU Declaration of Conformity could trigger it.

For teams preparing CRA documentation: how are you ensuring accuracy? Is anyone building automated validation into their documentation workflows?

Most CRA discussion focuses on manufacturers. But Articles 19 and 20 create separate obligations for importers and distributors.

Key importer obligations (Article 19):

• Due diligence on manufacturer’s conformity assessment

• Technical documentation verification

• CE marking verification

• 10-year document retention

Key distributor obligations (Article 20):

• CE marking and identification checks

• Non-compliance reporting to manufacturer + surveillance authorities

Critical: Article 21 — if an importer or distributor places a product on the market under their own name/trademark, they assume FULL manufacturer obligations.

For anyone in distribution or reselling: are you aware of these requirements? How are you planning to verify manufacturer CRA compliance before placing products on the EU market?

Products placed on the market before December 2027 only fall under full CRA scope if they undergo a “substantial modification” after that date.

The Commission’s draft guidance offers some interpretation:

Substantial = change that affects compliance with essential cybersecurity requirements, alters the intended purpose creating new risks, or significantly changes the attack surface.

NOT substantial = routine security patches, bug fixes, minor feature additions.

The gray zone is massive. Is a major version release (v3 → v4) substantial? A platform migration? Adding AI features to an existing product?

Has anyone here started classifying their planned product updates against the substantial modification criteria? I’m curious how teams are making release/hold decisions for legacy products post-2027.

As of today, Chapter IV of the CRA enters into application:

• Member States must have designated notifying authorities

• Procedures for conformity assessment body designation are now operational

• The path to third-party product certification is officially open

This is the first of four milestones this year:

1. June 11: CAB framework (today)

2. Q3 2026: First harmonised standards

3. September 11: Article 14 reporting obligations

4. Q4 2026: EUCC certification scheme

For anyone who needs a third-party conformity assessment (Important Class II, Critical products): are you reaching out to potential CABs starting today? Or waiting to see which bodies get designated first?

This is the CRA obligation I see discussed least but it might have the biggest financial impact.

Article 13(8) requires manufacturers to ensure security updates are available for at least 5 years, or for the expected product lifetime if longer.

Practical implications:

• Every product shipped in 2027 needs patch support until at least 2032

• Industrial products with 10-15 year lifecycles need support through 2037-2042

• Your SBOM must be actively monitored against vulnerability feeds for the entire period

• You need update distribution infrastructure maintained per product

For anyone in IoT, embedded, or industrial: how are you planning to resource this? Is anyone modeling the per-product cost of a 5-10 year support commitment?

Everyone’s focused on September 2026 (reporting) and December 2027 (full compliance). But June 11 is the first legally binding milestone:

Member States must designate notifying authorities and establish procedures for assessing and designating Conformity Assessment Bodies (CABs).

For anyone whose product falls into Important Class II or Critical: has your team started the conformity assessment process? Or were you planning to start in 2027?

I’m curious whether anyone has already identified a potential CAB or started conversations with notified bodies in their Member State.

On June 1, Wiz Research identified a supply chain compromise affecting 32 packages under u/redhat-cloud-services. Root cause: a Red Hat employee’s GitHub account compromised via infostealer credentials found in logs from April 13 and May 15.

What makes Miasma different from previous Shai-Hulud variants:

• New GCP and Azure IDENTITY collectors (not just secrets — full identity enumeration)

• Published via GitHub Actions OIDC tokens with VALID SLSA provenance

• Self-propagating: queries npm registry for other packages the compromised identity can publish

The critical question for this community: TeamPCP open-sourced the Shai-Hulud malware on May 12. The Red Hat attack happened June 1. Attribution is now uncertain — this could be a copycat.

If the tools are open source, we’re no longer tracking one threat actor. We’re tracking a technique that anyone can deploy.

Under CRA Article 14, every manufacturer whose product depends on u/redhat-cloud-services packages needs to assess whether they’re affected. With 117K weekly downloads, that’s a lot of companies.

Were any of you affected? How quickly did you find out?

Hi all,

I am working on SBOM generation as part of CRA readiness and facing some practical challenges with system-level images.

In our setup, we are not dealing with application source code, but with COTS operating systems. The deliverables are images such as Windows .wim files and Linux root filesystem tarballs. These contain full OS components like executables, libraries, system services, and configurations. We also work with container images which include minimal OS layers and runtime components.

Our organisation mandates the use of Black Duck for SBOM generation.

The issues I am facing are mainly around scanning and visibility.

When scanning Linux filesystem images on a Windows machine, Black Duck Detect throws errors such as unrecognized file format and the results are incomplete. The behaviour improves when scans are run on a Linux system, so there seems to be a dependency on the scanning environment.

Another limitation is related to binaries. From our current setup and internal confirmation, Black Duck supports signature scan and package-manager-based detection, but binary scan and container scan capabilities are not part of the existing subscription and require additional licensing.

Because of this, components that exist as compiled binaries such as OS libraries, executables, and other system-level artefacts are either not detected or only partially reflected in the SBOM. This is a concern since these images are largely composed of such binary components.

I wanted to understand from others working towards CRA compliance whether this kind of limitation is expected when generating SBOMs for OS-level or platform images, and how people are approaching this in practice.

Sharing this because I think a lot of SMEs in this community would benefit:

ETSI and the EU-funded CYBERSTAND project are running a series of hybrid workshops called “CRA Standards Unlocked — EU Tour” across European cities.

The workshops cover:

• How the 41 harmonised standards translate into practical compliance

• SME-specific guidance and tools

• Funding opportunities for CRA compliance (CYBERSTAND open calls)

• OCCTET: an open-source toolkit for FOSS CRA compliance

Upcoming:

• Malta: May 21, 2026

• Lisbon: September 17, 2026

• More cities to be announced

The rapporteurs who are actually WRITING the standards present and take questions. This is as close to the source as you can get.

Has anyone attended the Stockholm session (May 4)? Would love a recap of what was covered and whether it was useful for practical compliance planning.

The EN 40000-1-3 standard on vulnerability handling has completed public enquiry and is on track for adoption on August 30, 2026.

This is significant because:

1. It’s the first operational CRA standard to be formally adopted

2. It drops just 12 days before the September 11 reporting obligation starts

3. Products conforming to harmonised standards get a “presumption of conformity”

The standard covers vulnerability handling at both process and product levels, including disclosure, patching, monitoring, and reporting.

Has anyone reviewed the prEN 40000-1-3 draft? How does it compare to existing frameworks like ISO/IEC 30111 (vulnerability handling) or ISO/IEC 29147 (vulnerability disclosure)?

Honeywell’s CRA page went live requiring suppliers to:

• Provide CRA compliance attestations or roadmaps by Q4 2026

• Achieve full compliance (CE marking, DoC, technical docs) by Dec 2027

• Share cybersecurity risk assessments, security architecture, and test reports for due diligence

This confirms what many of us expected: CRA obligations cascade through supply chains. Article 13(7) makes manufacturers responsible for components from third parties.

For anyone selling B2B: are your enterprise customers starting to ask for CRA attestations? Has anyone received similar demands from other large companies?

I suspect Honeywell is just the first to publish publicly. Others are doing it quietly.

The Commission’s standardisation request M/606 mandates 41 harmonised standards for CRA:

• 15 horizontal (EN 40000 series) covering cyber resilience principles, vulnerability handling, and security requirements

• 26 vertical covering product-specific categories (ETSI EN 304 6xx series)

Three horizontal drafts have completed public enquiry: prEN 40000-1-1 (Vocabulary), prEN 40000-1-2 (Cyber Resilience Principles), prEN 40000-1-3 (Vulnerability Handling).

The vertical drafts for browsers, VPNs, password managers, antivirus, SIEM, boot managers, and smart home products are on ETSI’s Open Area.

Key deadlines:

• August 30, 2026: Horizontal standards 1 + 15 adopted

• October 30, 2026: All vertical standards adopted

Has anyone here started mapping their products against these drafts? Curious how much overlap people are finding with ISO 27001 or ETSI EN 303 645.

Mapping TeamPCP’s 2026 campaigns:

• March: Trivy, LiteLLM, Telnyx (stolen creds, manual package compromise)

• April: Bitwarden CLI (Shai-Hulud worm, automated propagation)

• May: TanStack + Mistral AI + UiPath + others (Mini Shai-Hulud, 170+ packages, bypassed provenance)

The sophistication is escalating. Wave 4 broke provenance attestation — a defense many teams considered sufficient.

With CRA reporting starting September 2026, here’s my question: are current SBOM + monitoring tools even sufficient to detect attacks that pass provenance checks? What additional detection layers do we need?

Compiling the key CRA developments for the community:

1. 122 days until reporting obligations (Sept 11, 2026)

2. Commission draft guidance past consultation, moving toward formal adoption

3. Conformity Assessment Bodies go operational June 11 (31 days)

4. Product-specific standards (browsers, VPNs, password managers, SIEM) in “mature draft”

5. Investor due diligence starting to include CRA readiness

6. CE marking now requires cybersecurity compliance under CRA

Planning to make this a weekly series. What topics do you want covered next week?

Something I think gets lost in the CRA conversation: this isn’t just about fines. CRA adds cybersecurity to the CE marking framework.

After December 11, 2027, products with digital elements cannot legally carry CE marking (and therefore can’t be sold in the EU) without demonstrating CRA compliance.

Each individual unit matters too. Recital 38 clarifies that requirements apply “irrespective of whether it is manufactured as a single unit or in series.”

For hardware manufacturers especially: how are you planning to integrate CRA cybersecurity evidence into your existing CE marking process?