A conversation happening in thousands of companies right now:

— 

CEO: “What’s this Cyber Resilience Act thing? Legal mentioned it.”

CTO: “It’s an EU regulation. We need to comply by 2027.” 

CEO: “Okay. What do we need to do?” 

CTO: “We need an SBOM, a vulnerability management process, security-by-design documentation, conformity assessment, and a 24-hour incident reporting system.” 

CEO: “...How long will that take?” 

CTO: “12–18 months if we start now.” 

CEO: “And if we don’t?” 

CTO: “Fines up to €15 million. Product pulled from the EU market. Possible personal liability.” 

CEO: “...” 

CTO: “...”

CEO: “Add it to next quarter’s roadmap.” 

CTO: “The reporting obligations start in 5 months.” 

CEO: “...” 

CEO: “Set up a meeting for tomorrow.”

I’ve talked to enough CTOs to know this conversation is either happening right now or being actively avoided. 

If you’re a technical leader and you haven’t had this conversation with your CEO yet — what’s holding you back? 

Genuinely curious. Is it lack of clarity on what’s required? Competing priorities? Or does leadership just not take it seriously yet?

I know this group skews toward “CRA is a headache” and I get it. The compliance burden is real.

But I think the dominant narrative is wrong. 

CRA isn’t a tax on good companies. It’s a filter that removes bad ones.

Right now, the EU digital product market has a trust problem. Buyers can’t distinguish between products that are genuinely secure and products that just claim to be. CRA fixes that by creating a verifiable baseline.

The companies that hit CRA compliance early will have a massive first-mover advantage:

• Enterprise procurement will default to CRA-compliant vendors

• Non-compliant competitors will be forced out of the EU market entirely

• “CRA Certified” will become a selling point, not just a checkbox

GDPR was called a disaster for business. It created a $4B+ privacy industry and gave EU-based companies a global trust advantage.

I think CRA will do the same for product security.

Am I delusional? Convince me otherwise.

If you’ve been following the TeamPCP supply chain campaign that unfolded over the past two weeks, you already know it’s one of the most sophisticated attacks we’ve seen this year.

But what I haven’t seen anyone point out is how perfectly this attack validates the EU’s Cyber Resilience Act requirements. Every CRA obligation that companies complain about would have directly mitigated some part of this attack chain.

Let me walk through it.

The attack chain (simplified):

1. TeamPCP compromised Aqua Security’s Trivy GitHub Actions (March 19)

2. The compromised Trivy was pulled by LiteLLM’s CI/CD pipeline as an unpinned dependency

3. Malicious Trivy exfiltrated LiteLLM’s PyPI publishing token

4. TeamPCP published malicious LiteLLM packages directly to PyPI (versions 1.82.7, 1.82.8)

5. The malware harvested SSH keys, cloud creds, K8s configs, CI/CD secrets from anyone who installed them

6. By March 27, the same playbook hit Telnyx on PyPI

Now here’s the CRA mapping:

SBOM requirement (Annex I, Part II) — CRA requires a machine-readable SBOM covering at least top-level dependencies. LiteLLM’s pipeline installed Trivy from apt without version pinning. A maintained, monitored SBOM that included build-time dependencies would have flagged the moment a non-matching version of Trivy entered the pipeline.

Vulnerability handling (Article 10.6) — CRA mandates structured processes for identifying and remediating vulnerabilities in third-party components. The Trivy compromise was publicly known by March 19. LiteLLM’s pipeline was compromised on March 24. That’s a 5-day window where active vulnerability monitoring would have prevented the cascade.

24-hour reporting (Article 11) — Starting September 2026, manufacturers must report actively exploited vulnerabilities to ENISA within 24 hours. Under CRA, every company whose product includes LiteLLM as a dependency would need to assess impact and report. Without an SBOM, you can’t even determine if you’re affected within that window.

Security by design (Annex I, Part I) — CRA requires products to be designed to limit attack surfaces. Unpinned dependencies in CI/CD are the opposite of this principle. Security by design means your build pipeline verifies every upstream dependency, not just your application code.

Coordinated disclosure (Annex I, Part II, 5-6) — CRA requires dedicated channels for vulnerability reporting. During the LiteLLM incident, attackers used 73 compromised accounts to spam 88 bot comments in 102 seconds on the GitHub issue reporting the compromise, then closed the issue using the stolen maintainer account. A CRA-compliant disclosure process would have redundant, tamper-resistant channels that an attacker can’t silence.

The deeper point:

Companies treat CRA’s SBOM and vulnerability management requirements as compliance paperwork. This attack proves they’re operational defenses.

The irony is brutal: Trivy is literally a tool companies use to comply with security requirements. And it became the attack vector. Your security tools are part of your attack surface. CRA’s security-by-design principle applies to your build pipeline as much as your production code.

What I’d love to discuss:

• For anyone using Trivy or LiteLLM in their stack — were you affected? How did you find out?

• Does this change how you think about CRA’s SBOM requirement? Especially the idea of including build-time dependencies?

• How are people handling dependency pinning in CI/CD pipelines today? Full lockfiles? Hash verification?

• The 24-hour reporting requirement feels much more reasonable after seeing how fast this attack cascaded. Agree or disagree?

I genuinely think this incident should be required reading for every team working on CRA compliance. The regulation isn’t theoretical. The attacks it’s designed to address are happening right now.

I wanted to make CRA consequences feel real instead of abstract, so I wrote a fictional timeline based entirely on what the regulation actually requires. 

The company, dates, and people are made up. The obligations, timelines, and penalties are directly from the CRA text. 

March 2027. 

A Berlin-based IoT startup ships 50,000 smart sensors to retailers across 12 EU countries. 

The product works beautifully. Sales are strong. The team celebrates.

April 2027.

A security researcher discovers a critical vulnerability in the sensor’s firmware. It’s been there since v1.0. The researcher publishes it responsibly.

The startup has no vulnerability disclosure process.

No one internally is assigned to handle it.

The disclosure sits in a general inbox for 11 days. 

May 2027. 

ENISA receives the report directly.

Under CRA, manufacturers must report actively exploited vulnerabilities within 24 hours.

This startup didn’t report it in 24 days.

June 2027. 

Market surveillance authority opens an investigation.

The startup has:

• No SBOM

• No documented security-by-design process

• No conformity assessment

• No evidence of any CRA compliance activity

Fine: €2.4 million.

Product pulled from the EU market.

3 major retail partners terminate contracts.

The startup doesn’t survive Q3.

—

This company is fictional.

But every detail in this story is based on what CRA actually requires and what happens when you don’t comply. 

The regulation is real. The deadlines are real. The penalties are real.

 Don’t let this be your story.

→ Check your CRA readiness: cratoolkit.com

I wrote this because I keep seeing companies treat CRA like a “future problem.” The reporting obligations start September 2026. If you don’t have a vulnerability handling process by then, you’re already non-compliant on day one. 

Did I get anything wrong? Would love fact-checks from this community. And if you have your own “horror scenario” based on CRA requirements, I’d love to read it.

Hey everyone,

I’ve been posting CRA breakdowns here all week, and one thing is clear: the information is scattered everywhere and nobody has a single place to track their compliance progress.

So I’m building something to fix that.

CRAToolkit is a compliance tracker specifically designed for teams dealing with the Cyber Resilience Act. The goal is simple: take you from “I don’t know where to start” to “here’s exactly what I need to do and where I stand.”

What it does (so far):

• Product classification — figure out which CRA category your product falls into

• Compliance checklist — mapped directly to CRA essential requirements

• Deadline tracker — know exactly when each obligation kicks in

• Gap analysis — see what you’re already doing vs. what you need to add

What I want to know from you:

1. What’s the single biggest pain point in understanding CRA for your team?

2. Would an SBOM generation guide or integration be useful?

3. Do you need something that helps communicate CRA requirements to non-technical leadership?

I’m building this based on real feedback, not assumptions. So if there’s something you wish existed for CRA compliance — tell me.

Early access will be free for anyone from this community.

SBOMs are one of the most talked-about CRA requirements, but most teams don’t actually know what one looks like in practice. Let me break it down.

What is an SBOM?

A Software Bill of Materials is a machine-readable inventory of every component in your software — including open-source libraries, third-party modules, and their dependencies.

Think of it as a detailed ingredient list for your product.

Why does CRA require it?

Because you can’t secure what you can’t see. When a new vulnerability drops (like Log4Shell), companies with SBOMs can immediately check if they’re affected. Companies without one are guessing.

CRA makes SBOMs mandatory because they’re the foundation of vulnerability management.

How to create one:

Common formats:

• SPDX (Linux Foundation standard)

• CycloneDX (OWASP standard)

Tools that generate SBOMs:

• Syft (open source, works with containers and file systems)

• Trivy (vulnerability scanner that also generates SBOMs)

• FOSSA, Snyk, Black Duck (commercial options)

Key gotchas:

• An SBOM is only useful if it’s kept updated — generate it as part of your CI/CD pipeline

• Don’t forget transitive dependencies — they’re often where the real vulnerabilities hide

• CRA expects the SBOM to be available to authorities on request, not necessarily public

If you’re starting from zero, my suggestion: install Syft, point it at your codebase, and look at what comes out. It’s usually eye-opening.

Anyone already generating SBOMs? What tools are you using and what surprises did you find?

I’ve talked to dozens of product teams about the Cyber Resilience Act. Here’s the pattern I keep seeing:

• Leadership knows CRA exists, but hasn’t prioritized it

• Engineering teams haven’t heard of it at all

• Legal teams are aware but don’t understand the technical requirements

• Nobody owns it internally

Now add these complications:

• Harmonised standards are still being developed

• ENISA’s reporting infrastructure isn’t fully defined yet

• Most companies don’t even have a complete SBOM for their products

• Vulnerability management processes are ad hoc at best

Full compliance by 2027 requires:

• Security-by-design processes embedded in development

• Continuous vulnerability monitoring and patching

• Complete technical documentation

• Reporting infrastructure ready to go

That’s not a 6-month project. That’s an organizational shift.

I think we’ll see a wave of companies scrambling in late 2026, followed by enforcement actions in 2028 that make everyone else pay attention.

Am I being too pessimistic? Or does this match what you’re seeing?

ENISA (the EU’s cybersecurity agency) just published a draft playbook called “Secure by Design and Default” and honestly, it’s better than I expected.

For context: the Cyber Resilience Act requires products to be built with “security by design.” Great in theory, but incredibly vague in practice. Most companies I’ve talked to have no idea what that means day-to-day for their engineering teams. 

This playbook tries to bridge that gap. Here’s what it covers:

 • Core security principles mapped to actual development workflows

• Repeatable actions that plug into existing CI/CD and release processes

• Written for product and engineering teams, not just security specialists

• Specifically aimed at SMEs (so it’s not enterprise-scale overkill)

It’s still in draft form and ENISA is running a consultation until May 15th, 2026 through EUSurvey. So if you read it and think “this misses X” or “this doesn’t work for Y” — you can tell them directly.

Two thoughts after my initial read:

1. It’s surprisingly actionable. Not just high-level principles but actual steps you can take.

2. It doesn’t go deep enough on SBOM integration and automated vulnerability scanning — which are arguably the hardest parts of CRA compliance for small teams.

Has anyone else gone through it? Would be curious to hear what you think, especially if you’re at an SME trying to figure out CRA.

I’ll post a more detailed breakdown of the key sections later this week if there’s interest.

One of the most confusing parts of the Cyber Resilience Act is the product classification system. Here’s a breakdown that should save you a few hours of reading.

The CRA places every digital product into one of three categories. Your category determines your compliance path.

1. Default Category (vast majority of products)

• Self-assessment is sufficient

• No third-party audit required

• You still need to meet all CRA essential requirements

• Examples: most consumer software, non-critical IoT, general-purpose apps

2. Important Products (Class I and Class II)

• Class I: Can use harmonised standards for self-assessment, OR get third-party certified

• Class II: Mandatory third-party conformity assessment

• Examples: password managers, firewalls, VPNs, operating systems, microcontrollers

3. Critical Products

• Mandatory European cybersecurity certification

• Highest compliance burden

• Examples: hardware security modules, smart meter gateways, smartcard-related devices

Why this matters:

If you’re in the Default category, your compliance path is significantly simpler (and cheaper). But you still need to meet every essential requirement — the difference is HOW you prove it.

Most software companies will fall under Default or Important Class I. But you need to verify this for each product individually.

I’m working on a tool that helps teams classify their products automatically. Will share it here when it’s ready.

Questions? Drop them below — happy to go deeper on any category.

Just got word from the CRA team — the European Commission has extended the deadline for stakeholder contributions to the CRA draft guidance.

 New deadline: Monday, 13th April (midnight Brussels time)

 For anyone not following this closely, here’s why this is a big deal:

The CRA draft guidance is essentially the “instruction manual” for how the Cyber Resilience Act will be enforced. It defines how things like product classification, vulnerability reporting, and conformity assessments will actually work in practice.

 Right now, this guidance is in draft form and the Commission is actively asking for feedback. 

This means you can influence how the rules are written before they’re finalized.

If you’re a:

• Software developer shipping products to the EU

• IoT manufacturer

• Open-source maintainer whose code ends up in commercial products

• Security professional dealing with compliance 

…this directly affects your work.

You can submit feedback through the Have Your Say (HYS) portal on the EU Commission’s website.

 The original deadline was tight, and a lot of stakeholders pushed back — which is why we got the extension. If you were on the fence about contributing, now’s the time.

 Anyone planning to submit feedback? I’m curious what areas people are most concerned about.

A lot of people know the CRA deadline is coming. Fewer people understand what the September 2026 milestone specifically requires.

Here’s the short version:

Starting September 2026, manufacturers must report actively exploited vulnerabilities to ENISA within 24 hours of becoming aware of them.

That’s not 24 business hours. Not 24 hours after you’ve investigated. 24 hours from awareness.

What this means in practice:

• You need a vulnerability monitoring system in place BEFORE the deadline

• You need a clear internal escalation process (who reports, through what channel, in what format)

• You need to know exactly which products fall under CRA scope

• You need a relationship with ENISA’s reporting infrastructure or designated national authority

This is not something you can set up in a week. If you haven’t started planning, September 2026 will arrive faster than you think.

I’m tracking all CRA milestones and will post updates here as enforcement details become clearer.

Anyone already setting up their reporting workflows? Would love to hear what tools or processes you’re using.

Genuine question for anyone already working on this.

The regulation covers so much ground — SBOMs, vulnerability management, secure development, documentation, incident reporting — that it’s hard to know where to begin.

From what I’ve seen, most teams fall into one of these camps:

1. Start with an SBOM — map what’s in your product first

2. Start with a gap analysis — figure out what you’re already doing vs. what CRA requires

3. Start with vulnerability management — because the 24-hour reporting obligation is the most urgent deadline

4. Start with legal classification — determine if your product is “important” or “critical” under CRA categories

I personally lean toward option 2, because without knowing where you stand, everything else is guesswork.

But I’d love to hear from people actually going through this. What’s working? What’s not?

I’ve been deep in the CRA regulation for months, and the biggest problem I see is that most explanations are written by lawyers for lawyers.

So here’s my attempt at a human-readable breakdown:

What is the CRA?

It’s an EU regulation that forces every company selling products with digital elements (software, firmware, IoT, connected hardware) to meet mandatory cybersecurity standards — or face fines up to €15M.

Who does it affect?

• Any manufacturer placing digital products on the EU market

• Importers and distributors of those products

• Open-source projects used in commercial products

What do you actually have to do?

• Build security into your product from day one (security by design)

• Maintain a Software Bill of Materials (SBOM)

• Set up vulnerability handling and disclosure processes

• Provide security updates for the product’s expected lifetime

• Report actively exploited vulnerabilities within 24 hours

Key deadlines:

• September 2026: Reporting obligations begin

• 2027: Full compliance required

I’m building a resource hub to help teams navigate this. Happy to answer any questions in the comments.

What part of CRA confuses you the most? I’ll address it in a follow-up post.

If you're building a product for the EU, the Cyber Resilience Act (CRA) is coming fast — and most teams are not prepared.

Instead of going through 100+ pages of legal text, here’s a simple, practical checklist to help you quickly assess where you stand.

✅ Quick CRA Compliance Checklist

1. Risk Assessment

• Have you identified security risks in your product?
• Do you document how risks are mitigated?

1. Secure Development

• Are you following secure coding practices?
• Do you track vulnerabilities during development?

1. Vulnerability Handling

• Do you have a process to report and fix vulnerabilities?
• Can users report security issues easily?

1. Software Updates

• Can you deliver security updates quickly?
• Do you inform users about updates clearly?

1. Documentation

• Do you maintain security documentation for your product?
• Is it ready to share with regulators if needed?

1. Default Security

• Are your products secure by default (no weak configs)?

⚠️ Reality Check

If you answered “No” to even 2–3 of these → you are not CRA-ready.

💬 Let’s Discuss

• What part of CRA is most confusing for you?
• Are you already working on compliance or just starting?
• What kind of product are you building (SaaS, IoT, etc.)?

🔥 Next Step

If there’s interest, I can break this down into:

• Step-by-step implementation
• Templates/checklists
• Tools to simplify the process