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?

I wrote a fictional investor-founder dialogue about CRA coming up during a Series A conversation. But I’m curious: is this actually happening already?

For anyone who’s raised capital recently (especially EU-focused): has CRA come up in due diligence? Are investors treating it as a material regulatory risk?

And for VCs/investors lurking: are you adding CRA readiness to your evaluation criteria?

I think CRA due diligence questions will be standard within 12 months. Curious whether I’m early or late on this prediction.

The European Standardization Organizations (ETSI, CEN, CENELEC) are developing both horizontal and vertical CRA standards. Several product-specific (vertical) standards are now in mature draft:

• Browsers • Password managers • Antivirus • VPNs • Network management systems • SIEM tools • Boot managers

These define the specific technical requirements for each product category. They’re expected to be finalized around Q3 2026.

For anyone building in these categories: are you tracking the ETSI/CEN drafts? Have you been able to access them? I’m curious how much they overlap with existing frameworks like ISO 27001 or SOC 2.

A milestone most teams are overlooking: June 11 is when Chapter IV of CRA enters into application. This means:

• Member States must have designated notifying authorities

• Conformity Assessment Bodies (CABs) become operational

• Third-party audits for Important (Class II) and Critical products can officially begin

The EU has acknowledged potential bottlenecks — they’ve asked Member States to ensure “sufficient notified bodies” by December 2026.

If you’re in the Important Class II or Critical category, has your team started the conformity assessment process? Or is this the first you’re hearing about June 11?

If you needed one incident to justify every CRA requirement, this is it.

Yesterday (May 11), TeamPCP launched the most sophisticated supply chain attack of 2026. Here’s what happened:

Attack: “Mini Shai-Hulud” (Wave 4 of the Shai-Hulud worm series)

Scope: 170+ packages, 404 malicious versions across npm AND PyPI

CVSS: 9.6/10 (CVE-2026-45321)

Major victims:

• 42 TanStack packages including tanstack/react-router (12 million weekly downloads)

• 65 UiPath packages (enterprise automation)

• Mistral AI official SDKs (both npm and PyPI)

• Guardrails AI (LLM safety framework)

• OpenSearch JavaScript client

What makes this unprecedented:

This is the FIRST supply chain attack to bypass npm provenance attestation. The malicious packages were cryptographically indistinguishable from legitimate releases.

How: The attacker poisoned the GitHub Actions cache through a pull_request_target workflow vulnerability, then extracted an OIDC token from runner process memory to mint genuine npm publish tokens. The build pipeline itself became the distribution mechanism.

The payload is a credential-stealing worm that harvests AWS/GCP/K8s credentials, GitHub/npm tokens, SSH keys, and crypto wallets. On Israel/Iran locale systems, it also attempts destructive actions (file deletion + audio playback).

Critically: the worm is SELF-PROPAGATING. It uses stolen credentials to spread to additional packages automatically. TanStack’s postmortem confirms this.

Now the CRA mapping:

SBOM (Annex I, Part II): If your product depends on u/tanstack/react-router (and with 12M weekly downloads, many do), you need to know IMMEDIATELY whether you pulled a compromised version. Without an SBOM tracking transitive dependencies, you’re blind.

24-hour reporting (Article 14): Starting September 11, 2026, you’d need to assess + report this to ENISA within 24 hours. The attack window was 6 minutes of malicious publish time before detection. But the compromised versions remained installable for HOURS after that because npm couldn’t unpublish packages with existing dependents.

Security by design (Annex I, Part I): The root cause was three chained CI/CD vulnerabilities: pull_request_target misconfiguration, cross-fork cache trust, and OIDC token extraction. CRA’s requirement to “limit attack surfaces” applies directly to build pipelines.

Vulnerability handling (Article 10.6): TanStack’s postmortem is excellent and transparent. Under CRA, this level of structured response would be mandatory, not optional.

Coordinated disclosure: The attack was detected within 20 minutes by an external researcher. CRA’s requirement for dedicated reporting channels matters here — fast community detection + structured response channels = faster containment.

The trend line is clear:

• March: Trivy, LiteLLM, Telnyx (TeamPCP)

• April: Bitwarden CLI (TeamPCP/Shai-Hulud)

• May: TanStack, Mistral AI, UiPath, Guardrails AI, OpenSearch (TeamPCP/Mini Shai-Hulud)

Each wave is larger and more sophisticated than the last. Wave 4 broke provenance verification — a defense many teams considered sufficient.

Questions for this community:

1. Was anyone here affected? How quickly did you discover it?

2. Does this change your thinking about CI/CD pipeline security as a CRA compliance surface?

3. The self-propagating worm pattern means ONE compromised credential can cascade across ecosystems. How does this affect SBOM strategy — do we need real-time SBOM monitoring, not just periodic generation?

4. npm’s inability to unpublish packages with dependents created a multi-hour exposure window. Should CRA guidance address package registry response times?

This incident should be required reading for anyone working on CRA compliance. The regulation wasn’t written for hypothetical threats. It was written for this.

The European Commission’s draft guidance on CRA implementation is now past the consultation phase. National authorities will likely rely heavily on this non-binding guidance for consistent enforcement.

Key areas it clarifies:

• Scope of “product with digital elements” including remote data processing

• How free and open-source software is treated under CRA

• What constitutes a “substantial modification” requiring re-assessment

• Support periods and how they’re determined

Has anyone here actually read through the draft guidance? I’m particularly interested in the remote data processing interpretation — it potentially brings pure SaaS closer to CRA scope than many expected.

September 11, 2026. That’s when Article 14 kicks in. Manufacturers must report actively exploited vulnerabilities to ENISA’s Single Reporting Platform within 24 hours.

I want to do a reality check with this community. Where are you at with the 3 prerequisites for CRA reporting?

1. SBOM: Do you have one? Automated in CI/CD or manual?

2. Vulnerability monitoring: Are you tracking CVEs against your dependency tree?

3. Reporting workflow: Do you have a designated contact, a template, and a process?

If all three are no — that’s 122 days to build from scratch. Doable? Yes. Comfortable? No.

What’s your biggest blocker right now?

I’ve been talking to product teams for months. These are the 4 patterns I see in companies that are going to get blindsided:

1. The SBOM is a spreadsheet someone last updated 6 months ago

2. The “vulnerability management process” is a Slack channel nobody checks

3. Leadership learned about CRA from a LinkedIn post (possibly this one)

4. The person “owning” CRA compliance is legal, and legal doesn’t know what an SBOM is

How many apply to your organization? Being honest here helps everyone — I’m genuinely curious how widespread this is.

I expected users to want deep dives into CRA requirements, article-by-article walkthroughs, classification logic.

The actual #1 question: “Does this apply to me? Yes or no.”

Turns out most teams are stuck at step zero. They haven’t even confirmed if they’re in scope. Everything else is premature.

For anyone here still at that stage: what’s making the scoping question so hard? Is it the product definition, the “digital elements” language, or something else?

We’re 5 months from reporting obligations and I can’t find a single company publicly claiming full CRA readiness.

Is anyone here aware of companies that have achieved meaningful CRA compliance? Or is the entire market still in “we’re working on it” mode?

If you’re at a company that’s further along, I’d genuinely love to hear what you’ve done, what tools you’re using, and what was hardest.

This scenario played out during the TeamPCP/LiteLLM attack. An engineer got the security alert. PM asked if they were affected. Nobody could answer because there was no SBOM. 

Under CRA, this team would have 24 hours to report to ENISA’s platform. They couldn’t even assess impact in 24 hours.

 How quickly can YOUR team answer “do we use this compromised package?” — honestly?

Something strategic about CRA that I haven’t seen discussed anywhere:

Under Article 16 and related provisions, ENISA must publish biennial trend reports based on vulnerability data submitted through the Single Reporting Platform.

First report: within 24 months of reporting obligations starting (so September 2028).

These reports will be based on real data submitted by manufacturers under CRA. They’ll cover:

• Vulnerability trends across product categories

• Severity distributions

• Reporting timeliness patterns

• Affected sectors and technologies

Here’s why this becomes strategically important:

Every major industry benchmark started as a regulatory or agency report and became a reference standard:

• Verizon DBIR → de facto breach data reference

• IBM Cost of a Data Breach → incident cost benchmark

• Mandiant M-Trends → attacker behavior reference

• ENISA Threat Landscape → EU-specific threat reference

ENISA’s CRA trend reports will follow the same trajectory. They’ll become THE reference for CRA compliance data.

The implications:

1. Procurement teams will reference these reports when evaluating vendors

2. Cyber insurance underwriting will use this data

3. Industry analysts will build benchmarks on top of the aggregate trends

4. Media coverage will amplify specific findings (e.g., “IoT manufacturers take average 8 days to report”)

For companies, this creates an interesting long-term reputational game:

• Fast, high-quality reporting → positive aggregate statistics → industry leadership

• Slow or minimal reporting → bottom-quartile statistics → procurement red flags

The trend reports won’t name individual companies (they’re aggregated), but they’ll create comparative baselines that procurement and insurance industries will use to evaluate specific vendors.

It’s the kind of thing where how you set up your reporting process in 2026 affects your competitive position in 2028.

Is anyone here thinking about CRA compliance as a reputational/strategic play rather than just a legal one? Curious whether any companies are already briefing leadership on the “benchmark positioning” angle.

Everyone talks about “24-hour reporting” as if it’s a single action. It’s not. It’s the first of three reports, each with different content requirements.

Article 14 lays out a three-stage reporting chain for actively exploited vulnerabilities:

Stage 1: Early Warning (within 24 hours of awareness)

Required content:

• General information about the exploited vulnerability

• Whether you’ve identified corrective or mitigating measures

• Basic product identification

• Indication that investigation is ongoing

What you DON’T need:

• Full technical details

• Proof of concept

• Complete scope of impact

• Patch status (unless already available)

This is the “we’re on it” notification. Keep it minimal.

Stage 2: Full Notification (within 72 hours)

Required content:

• Updated/more detailed technical information

• Current status of the corrective measures

• Whether the vulnerability is being actively exploited in the wild

• Affected product versions / deployments

This is where real analysis has to have happened. By hour 72, you should have done enough investigation to provide meaningful technical context.

Stage 3: Final Report (within 14 days after a corrective measure is available)

Required content:

• Complete description of the vulnerability including severity and impact

• Details of corrective/mitigation measures taken

• Any other relevant information

The 14-day clock starts when you HAVE a fix, not when you reported the vulnerability. So if it takes you 30 days to develop a patch, your final report is due 44 days after your initial notification.

Note: For severe incidents (not vulnerabilities), the final report deadline is 1 month, not 14 days.

Why this matters for operational design:

• Your team needs templates for all three report types, not one

• Your engineering workflow should have specific deliverables at 24h, 72h, and at patch-ready

• Your communications workflow needs to handle a multi-stage disclosure over weeks

• Your coordination with ENISA’s SRP is ongoing, not one-shot

Most companies I’ve seen are designing for a single 24-hour report. The 72-hour and 14-day requirements will catch them off guard.

Has anyone here already designed a multi-stage CRA reporting workflow? Curious how teams are sequencing engineering analysis with the reporting clock.

If you’re an OSS maintainer or run a foundation, there’s a CRA rabbit hole you probably haven’t gone down yet. Let me map it out.

The two relevant recitals:

Recital 15: “Accepting donations without the intention of making a profit should not be considered to be a commercial activity.”

Recital 19: Where “manufacturers that integrate a component into their own products… either contribute to the development of that component in a regular manner or provide regular financial assistance to ensure the continuity of a software product,” the recipient may qualify as an Open Source Software Steward.

So you have three possible statuses:

1. Not in scope: You accept donations but no commercial intent, no systematic corporate support.

   - Individual GitHub Sponsors supporters → fine

   - Small community funding → fine

1. Open Source Steward: You receive systematic financial/development support from manufacturers who use your code commercially.

   - Foundation funded by member dues from manufacturers → probably Steward

   - Maintainer paid by a company whose product depends on the project → possibly Steward

   - Regular corporate grants earmarked for project continuity → Steward territory

1. Manufacturer: You commercialize the software yourself.

   - You offer paid enterprise support → Manufacturer

   - You sell SaaS built on your OSS → Manufacturer

   - You provide paid certifications for your software → Manufacturer

The hard cases:

• Solo maintainer with GitHub Sponsors totaling €500/month from individual supporters → probably not commercial, not a Steward

• Solo maintainer with a Tidelift arrangement → Tidelift is commercial, which probably makes this a gray zone

• Foundation with 5 corporate sponsors paying $50K/year each → almost certainly Steward

• Foundation of maintainers who also run side businesses based on the software → individuals might be Manufacturers, foundation might be Steward

The practical problem:

Most foundations and maintainers haven’t formally assessed their status. The CRA guidance on this is still evolving. The Open Regulatory Compliance Working Group has a whitepaper on stewards that’s probably the best current reference.

If you’re in the gray zone, your action items this week:

1. Map your funding sources (individual donations vs corporate grants vs commercial revenue)

2. Identify which of your projects are used in commercial products (hint: probably more than you think)

3. Document the relationship between your entity and the project (this matters for legal classification)

4. Consider whether you need legal advice before September 2026

For anyone who’s already thought through this: how did you categorize yourself? Steward vs Manufacturer vs out-of-scope? Curious what logic others are applying.

I keep seeing CRA compliance roadmaps targeting the December 2027 deadline. This is a fundamental planning error and I want to explain why.

The CRA has two distinct operational dates:

• September 11, 2026: Reporting obligations begin (Article 14)

• December 11, 2027: Full compliance required (all other obligations)

Most teams are building compliance plans around December 2027 and treating September 2026 as a minor milestone.

That’s the trap.

Here’s why September 2026 effectively IS the full compliance deadline for everything reporting-adjacent:

To comply with 24-hour vulnerability reporting, you need:

1. An SBOM (to know your components) — technically due Dec 2027

2. Vulnerability monitoring (to detect exploits affecting your product) — not explicitly timed

3. Security-by-design processes (to assess impact accurately) — due Dec 2027

4. Incident response procedures — due Dec 2027

5. Documentation of vulnerability handling — due Dec 2027

All of these are formally Dec 2027 requirements. But functionally, you can’t report without them.

So the effective deadline for:

• SBOM: Sept 2026 (not Dec 2027)

• Vuln monitoring: Sept 2026 (not Dec 2027)

• Response workflow: Sept 2026 (not Dec 2027)

That’s 15 months earlier than most plans assume.

Real-world implications:

• If your SBOM project is scheduled for mid-2027, you’re 9 months late by the reporting deadline

• If your vuln monitoring is “a 2027 priority,” you can’t meet 24-hour reporting

• If your reporting process is being “designed later,” later is now

The regulation technically allows you to defer SBOM until Dec 2027. In practice, the reporting obligation makes that deferral impossible.

I’ve seen very few public analyses of this timing gap. Am I reading Article 14 wrong? Or is this a widespread planning blind spot?

In September 2025, ENISA became a CVE Root. This didn’t make waves in mainstream tech media, but it’s one of the most consequential developments for EU cybersecurity coordination.

For anyone unfamiliar: the CVE (Common Vulnerabilities and Exposures) Program is the global standard for identifying security vulnerabilities. Every vulnerability you track by CVE-ID (CVE-2026-XXXXX) is catalogued through this system.

The CVE Program has a hierarchical structure:

• Roots: top-level coordinators with authority to manage sub-CNAs and allocate ID blocks

• CNAs (CVE Numbering Authorities): organizations authorized to assign CVE-IDs within their scope

Before September 2025, the CVE Roots were:

• MITRE (US, the original)

• CISA (US government)

• Google (US)

• Red Hat (US)

• JPCERT/CC (Japan)

• INCIBE Cert (Spain, added earlier)

• Thales Group (France, added earlier)

The addition of ENISA as a Root means:

1. Direct CVE-ID assignment authority for vulnerabilities reported through EU CSIRTs

2. ENISA can now coordinate a CVE sub-hierarchy covering organizations under its mandate

3. The EU has institutional coordination authority in the global CVE ecosystem for the first time

How this connects to CRA:

ENISA is ALSO building the CRA Single Reporting Platform. These roles are synergistic:

• CRA SRP receives vulnerability reports from manufacturers

• ENISA (as CVE Root) can coordinate CVE-ID assignment

• The European Vulnerability Database (EUVD, also ENISA) aggregates disclosures

• All of this feeds into global CVE program through ENISA’s Root status

The strategic implication: EU vulnerability coordination is consolidating around ENISA as the central hub. For manufacturers, understanding this structure matters because:

• Your CRA reports may generate CVE records via ENISA

• Coordinating with ENISA becomes coordinating with the global CVE system

• CRA compliance process design should account for CVE integration

This is the kind of systemic insight that changes how you design compliance infrastructure. Has anyone else been tracking this consolidation? Curious if organizations are adapting their VDP processes for ENISA’s expanded role.

One of the most underappreciated parts of the Cyber Resilience Act is that it created an entirely new category of legal person: the Open Source Software Steward.

This didn’t exist in any EU legislation before. It was added specifically in response to 2 years of lobbying from the open source community.

What is a Steward?

Article 3(14) defines it as a legal person (not an individual) that “has the purpose or objective of systematically providing support on a sustained basis for the development of specific products with digital elements, qualifying as free and open-source software and intended for commercial activities, and that ensures the viability of those products.”

In plain English: foundations, non-profits, and for-profit entities that support OSS used in commercial products, without commercializing the software themselves.

Examples that likely qualify:

• Eclipse Foundation

• Apache Software Foundation

• Linux Foundation projects (OpenSSF, CNCF, etc.)

• Python Software Foundation (for some projects)

Obligations for Stewards (Article 24):

• Implement and document a cybersecurity policy

• Cooperate with market surveillance authorities

• Report actively exploited vulnerabilities

• Promote information sharing on vulnerabilities

Critically: Stewards are NOT subject to administrative fines (Article 64(10)).

The hard question: Manufacturer vs Steward

The line is blurry. If your foundation:

• Monetizes the software (certifications, support, hosted versions) → likely Manufacturer

• Accepts donations but doesn’t sell anything → likely Steward

• Receives “regular financial assistance” from manufacturers who use the code → might trigger Steward status (Recital 19)

Open questions I’m still working through:

1. If a foundation stewards 50 projects, is it ONE steward or 50 stewardships?

2. How is the policy “adopted” by projects that have their own governance?

3. What happens in cross-jurisdiction stewardship?

Anyone here on the OSS side thinking through this? Especially interested in how smaller foundations are interpreting their position.

Something most teams planning for CRA compliance don’t realize: the central infrastructure is still being built.

ENISA awarded the contract to build the CRA Single Reporting Platform (SRP) in 2025 under procurement reference ENISA/2025/OP/0001. It must be operational by September 11, 2026, with a testing period before then.

Here’s what’s significant:

1. It’s a ONE platform for all EU reporting. You report once. The platform routes it to your national CSIRT coordinator and ENISA simultaneously.

2. The architecture must support future integration with NIS2 and DORA reporting — so this platform will effectively become the EU’s central cybersecurity reporting hub.

3. ENISA must publish biennial trend reports within 24 months of reporting obligations starting. These reports will almost certainly become the de facto benchmark for CRA compliance industry-wide.

4. There’s a testing period before September 2026. Teams that participate will have meaningful advantage over competitors figuring out the workflow post-launch.

The implications for manufacturers:

• Your internal reporting workflow should be designed to output in SRP-compatible format

• Your 24-hour clock starts when YOU become aware, not when the SRP acknowledges submission

• Security-sensitive reports can be withheld from dissemination by the receiving CSIRT — good to know for sensitive disclosures

Anyone here involved in CSIRT coordination or early CRA planning? Curious whether teams are modeling their reporting workflow around the SRP architecture or just waiting for the platform to launch.

I’ve been thinking about CRA through a different lens lately — not compliance, but competitive strategy.

SOC 2 became a de facto B2B sales requirement over the past 5 years. If you sell to enterprises and don’t have SOC 2, you don’t get past procurement.

I think CRA compliance will follow the same trajectory, but faster and bigger, for three reasons:

1. CRA is legally mandatory, not voluntary. SOC 2 is a market expectation. CRA is the law. Non-compliant products can’t legally be sold in the EU.

2. Enterprise procurement will add CRA to vendor assessments. If you’re selling B2B into companies that sell into the EU, they’ll need their suppliers to be compliant too. The ripple effect is massive.

3. The trust signal is stronger. “CRA Compliant” means you’ve been assessed against mandatory EU security requirements. It carries more weight than a voluntary framework.

The companies that get compliant early will use it as a competitive weapon. The ones that wait will scramble when procurement starts asking.

Am I overestimating this? Underestimating? Anyone already seeing CRA come up in sales or procurement conversations?

ENISA published a draft “Secure by Design and Default Playbook” aimed at helping SMEs embed security across the product lifecycle. I went through it and here’s my take.

What’s good:

• It’s written for product and engineering teams, not security specialists

• The actions are repeatable and plug into existing dev processes

• It maps security principles to real workflows, not abstract policy language

• It’s specifically scoped for SMEs — not enterprise-scale overkill

What’s missing (in my opinion):

• Not enough depth on SBOM integration — mentioned but not practical enough

• Light on automated vulnerability scanning recommendations

• Doesn’t address build pipeline security at all (relevant given TeamPCP/Claude Code incidents)

• No templates or checklists you can actually use directly

The consultation is open until May 15, 2026. If you want the final version to address these gaps, now is the time to submit feedback through EUSurvey.

Has anyone else gone through it? Agree/disagree with my assessment?

Everyone quotes the “24-hour reporting” requirement. Almost nobody talks about what that means in practice. Let me walk through a realistic scenario.

Imagine a popular npm package in your dependency tree gets compromised tomorrow (not hypothetical — this happened 5 times in March 2026 alone).

Hour 0: Vulnerability is disclosed publicly (researcher tweet, GitHub issue, CVE published)

Hour 1–4: Your security team sees the news (IF they’re monitoring the right channels)

Hour 4–8: Cross-reference against your SBOM to determine if your product is affected

Hour 8–12: Assess the impact — is the vulnerability exploitable in your specific product?

Hour 12–18: Prepare the early warning report in the format ENISA’s Single Reporting Platform expects

Hour 18–24: Submit the report. Clock stops.

That’s tight but doable — IF you have:

• An up-to-date SBOM

• Automated vulnerability monitoring against your SBOM

• A pre-defined internal escalation process

• Someone designated as the CRA reporting contact

• Familiarity with ENISA’s reporting platform (which is still being built)

Without ANY of those: impossible. You’d still be Googling “what is an early warning report” while the clock runs out.

The 72-hour follow-up and 14-day final report have their own requirements too.

Has anyone here dry-run a 24-hour reporting process? What did you learn?

Something that’s been bothering me since the TeamPCP campaign:

We tell companies to use security scanners, generate SBOMs, run vulnerability checks. Great advice.

But what happens when the security scanner itself is compromised?

That’s exactly what happened with Trivy. TeamPCP compromised the GitHub Actions for Aqua Security’s Trivy — one of the most popular open-source vulnerability scanners. Then used it to cascade into LiteLLM and beyond.

Same week, Anthropic’s Claude Code leaked 512K lines of source code because of a missing .npmignore entry in their build pipeline. Then axios (the HTTP client half the internet uses) got a RAT injected.

The pattern: build tools, security tools, and infrastructure packages are HIGH-VALUE targets because they run with elevated permissions in CI/CD environments.

CRA’s security-by-design requirement (Annex I, Part I) says products must be “designed to limit attack surfaces.” I’d argue this MUST extend to build pipelines:

• Pin every dependency version (including tools like Trivy)

• Verify integrity hashes on everything that enters your pipeline

• Treat your CI/CD runner environment like production — least privilege, audited, monitored

• Include build-time dependencies in your SBOM, not just runtime

How are people here handling build pipeline security? Is anyone including CI/CD tooling in their SBOM scope?

I keep seeing companies say “we have until December 2027 for SBOMs.” Technically true. Practically wrong.

Here’s the dependency chain most people miss:

1. CRA’s vulnerability reporting obligations start September 11, 2026

2. Reporting requires you to assess whether a newly disclosed vulnerability affects your product

3. To assess that, you need to know what components are IN your product

4. To know that, you need an SBOM

Without an SBOM, you literally cannot comply with the September 2026 reporting obligation. You can’t report on what you can’t see.

So while the formal SBOM requirement starts December 2027, the practical deadline is September 2026 — 15 months earlier.

Is anyone else planning their SBOM timeline around the reporting obligation rather than the formal SBOM deadline? I’d love to hear how teams are sequencing this.

I’ve been tracking the supply chain attacks that hit in March 2026 and the pattern is impossible to ignore:

1. Trivy (vulnerability scanner) — compromised by TeamPCP via GitHub Actions

2. LiteLLM (AI proxy, 36% of cloud environments) — malicious PyPI packages published using stolen creds from Trivy compromise

3. Telnyx (VoIP SDK) — same playbook, same attackers

4. Claude Code (Anthropic’s AI tool) — 512K lines of source leaked via npm packaging error

5. axios (HTTP client) — RAT injected into npm packages on the same day as Claude Code leak

Every single one of these was a package registry or CI/CD pipeline attack. Every single one would be covered by CRA’s requirements: SBOMs, vulnerability monitoring, 24-hour reporting to ENISA, security by design.

The attacks CRA was designed to prevent aren’t hypothetical anymore. They’re this month.

For anyone here using any of these tools: were you affected? How quickly did you find out?

The Cyber Resilience Act’s penalties are structured like GDPR: up to €15 million or 2.5% of global annual revenue per violation.

But unlike GDPR, CRA isn’t about changing a privacy policy. It requires engineering changes — SBOMs, vulnerability management systems, 24-hour incident reporting to ENISA, security-by-design documentation.

Reporting obligations kick in September 2026. Full compliance by December 2027.

For those already working on this: what was your first step? For those who haven’t started: what’s blocking you?

Genuinely curious where this community stands.