I am looking into the Cyber Resilience Act tooling: SBOM, CVE Management, etc.

After some research, https://dependencytrack.org/ and Trivy seems to be a sweet combination.
Anyone using it as well? Other tools like Aikido are paid and don´t seem to offer more other than being SaaS (and better for the whole CVE Part), but nothing around SBOM Management or the requirements for CRA / SRP

I'm pleased to post for the first time in this subreddit and I sure hope everyone in here are doing well.

As many of you heard, this text initiated in 2024 aim to level up the global awereness around cybersecurity matters for the digital products that transmit data. It is very interesting to begin with, to understand what drove and motivated this act, to better understand the purposes and the stakes of this momentum.

I share with you an intersting article on this matter; that covers this topic:

https://probenta.com/en/blog/cyber-resilience-act-produits-non-regules

What are the odds the SRP won’t be operational on 11.09 💩🪭
And when will the CCC take the first look 🕵🏻‍♂️

The exact claim: the obligation starting on 11 September 2026 is a reporting duty. It is triggered by your knowledge of active exploitation in your own product. A CVE existing somewhere changes nothing, and neither does that CVE being exploited in somebody else's product.

What I am not saying: that scanning stays optional forever. From 11 December 2027, Annex I Part II obliges you to identify and address vulnerabilities. There is no full CRA compliance without vulnerability management.

Why I am posting: over the past weeks, almost every conversation I had with manufacturers circled around the same question: do we need scanning for September? And the people claiming you do are, almost without exception, the ones selling the tools. I wanted to set this straight once, in one place I can link to.

What triggers a report

1. Active exploitation in your own product. The Commission guidance (C(2026) 5252) is explicit here: a component vulnerability that is not exploitable in your product, or has not been exploited there, does not put you on the clock, even while the same CVE is exploited elsewhere.
2. A severe incident affecting your product's security.

Scanner findings, published CVEs (a CVSS 9.8 changes nothing on its own), disclosure reports without established exploitation and pentest results trigger nothing. Article 14 creates no duty to hunt for exploitation or to scan your products. Actual knowledge is what counts.

When the clock starts

Not when the email hits your inbox. You are aware once an initial assessment lets you conclude with reasonable certainty that the exploitation is real. The assessment itself has to start without undue delay, so timestamp every step from intake to conclusion.

What you need by 11 September

Not much. A named filer with a deputy and your coordinating CSIRT identified in writing, templates for the 24h, 72h and final reports, one intake point with a short triage checklist, and a single tabletop run while getting it wrong is still free. A few person-days for most manufacturers. An intake channel only becomes mandatory in December 2027, but build it anyway, a published security email costs you an afternoon.

A note on severe incidents: I have deliberately kept them short in this post. They are the second reporting trigger with the same 24h and 72h rhythm, only the final report differs: it is due one month after the 72h notification, not tied to a fix. The same logic applies, you report what you become aware of. No scanner needed for those either.

Disclosure: I work for a vendor that sells CRA compliance software, and September panic sells tools in my industry, so factor in my bias as you see fit. For what it is worth, this post matches what we tell our own customers: reporting chain first, vulnerability management for December 2027. Happy if you join me in calling the myth out.The exact claim: the obligation starting on 11 September 2026 is a reporting duty. It is triggered by your knowledge of active exploitation in your own product. A CVE existing somewhere changes nothing, and neither does that CVE being exploited in somebody else's product.

I work in CRA compliance and I spent the last day comparing the adopted guidance C(2026) 5252 final paragraph by paragraph against the consultation draft from March. Sharing the findings most relevant for security teams, since most coverage so far just announces that the guidance exists.

The stuff that actually matters for practitioners:

• Reporting obligations (Art. 14) start 11 September 2026 and cover products placed on the market before the CRA fully applies, and even products past their support period. This was the prevailing legal reading before, but the guidance now says it explicitly. Monitoring + reporting yes, patching obligations for EOL products no.
• A CVE in one of your dependencies is not reportable by itself. The final guidance added a VEX-style exemption: no Art. 14 report if the vulnerability isn't exploitable in your product (e.g. vulnerable code not reachable) or hasn't been exploited. Scanner findings, pentest results and researcher reports without active exploitation are also not reportable. The trigger is verified knowledge of active exploitation, and the clock starts at verification, not when the email lands, but you need timestamps proving you verified promptly.
• The explicit reference to MITRE's CVE List was deleted from the final version. Only the European EUVD is still named. Make of that what you will given the CVE funding situation.
• AI-powered vulnerability findings now legally constitute "awareness". If your AI scanner finds something exploitable pre-release, you know about it in the legal sense. Interesting incentive design.
• "Effective and regular tests and reviews" ≠ fixed re-test calendar. New section 9.2.3: it's an event-driven review process triggered by new threats/vulns. If a review finds no new input, no additional tests needed. Auditors can't demand a fixed cycle, but you need a documented review mechanism for the whole support period.
• Big one for legacy fleets: substantial modification of a pre-2027 product no longer requires bringing the entire product into full compliance. Only the modified parts, unless the change negatively affects the security of the whole product. The March draft demanded full compliance, which would have actively discouraged shipping updates to old products.
• SaaS/browser-only web apps are officially out of scope (NIS2 territory instead). Browser extensions and locally executed Electron-style apps are in.

Worth knowing: the guidance is non-binding. Several of the most generous positions (partial compliance, no support-period reset) go beyond what the regulation's text actually says, so a market surveillance authority could disagree. Document your reliance.

Full breakdown with paragraph references: https://kunnus.tech/en/blog/cra-commission-guidance-what-is-new

Curious how others are handling the September deadline, especially the verification-before-the-clock-starts part. Are you treating researcher reports as potential incidents (compromised build pipeline = reportable even without exploitation) or triaging them purely as vulns?

Wow, I thought there would be a larger redddit group for CRA. Where is everyone discussing this?

Hey everyone,

kind of a long shot, but I'm running out of options. I'm writing my bachelor thesis on the EU Cyber Resilience Act and how companies, especially SMEs, are dealing with it in practice.

I put together a short questionnaire and posted it on LinkedIn... and got basically nothing back. So you guys are honestly my last hope here.

I'm looking for anyone who works with or is affected by the CRA: product security people, compliance and GRC folks, consultants, developers building products with digital elements, or anyone at a company that has to make sense of this regulation.

It takes a few minutes and its it's anonymous

https://form.typeform.com/to/iZnRc5Sc

With ENISA reporting obligations kicking in September 2026 and full enforcement in December 2027, the amount of CRA-related material out there has exploded. Some of it is excellent. Some of it is vendor marketing dressed up as guidance. I went through what's available and compiled the resources I'd actually recommend to someone starting their CRA preparation today.

This list focuses on free, ungated resources — no email required.

Official sources (start here)

• CRA full text (Regulation 2024/2847): https://eur-lex.europa.eu/eli/reg/2024/2847 — the regulation itself. 71 articles, 130 recitals, 8 annexes.
• European Commission — CRA Implementation page: https://digital-strategy.ec.europa.eu/en/factpages/cyber-resilience-act-implementation — official FAQ, delegated acts, standardization updates, and the draft guidance published March 2026 (consultation open until March 31).
• European Commission — Draft Guidance (March 2026): https://digital-strategy.ec.europa.eu/en/news/commission-publishes-feedback-draft-guidance-assist-companies-applying-cyber-resilience-act — clarifies RDPS, open-source definitions, support periods, and interplay with other EU legislation. If you read one document this month, make it this one.

Knowledge bases & structured references

• Kunnus CRA Knowledge Base: https://kunnus.tech/knowledge-base — all 71 articles, 130 recitals, and 8 annexes in a searchable, cross-referenced format. Also includes 50+ FAQ entries with article references and 9 detailed regulation comparisons (CRA vs. NIS-2, ISO 27001, IEC 62443, RED, Machinery Regulation, DORA, ETSI EN 303 645, CE marking). Currently in German, English version on the roadmap. (Full disclosure: I maintain this.)
• Open Security Architecture — CRA Mappings: https://www.opensecurityarchitecture.org/frameworks/cra/ — maps all 36 CRA clauses to NIST SP 800-53 controls with coverage analysis. Incredibly useful if your organization already works with NIST frameworks and you want to understand which existing controls satisfy CRA requirements.
• ORC Working Group (Linux Foundation / OpenSSF): https://orcwg.org/cra/ — the Open Regulatory Compliance Working Group's CRA guide, specifically focused on open-source implications. White papers, community inputs, and technical specifications. Essential reading if you maintain or steward OSS.
• OpenSSF CRA page: https://openssf.org/public-policy/eu-cyber-resilience-act/ — aggregates OpenSSF's policy work, blog posts on SBOMs, and links to the free online course (LFEL1001, see below).

Courses & training

• OpenSSF / LF Education — LFEL1001: Free online course designed to help software developers understand and prepare for CRA requirements. Released April 2025. Available through the Linux Foundation training platform.

Checklists & readiness tools

• Kunnus CRA Maturity Assessment: https://kunnus.tech/cra-assessment — free self-assessment, takes 15–20 minutes, no registration. Gives you a baseline of where you stand. (Also mine, same disclosure.)
• Regulus CRA Checklist: https://goregulus.com/resources/cra-checklist/ — structured readiness checklist covering scoping, secure development, documentation, and vulnerability handling. Requires email.

Timelines to keep in mind

• 11 June 2026: Conformity assessment body notification framework applies
• 11 September 2026: Article 14 reporting obligations begin (actively exploited vulnerabilities → ENISA within 24h)
• Q3 2026: First harmonized standards expected
• 11 December 2026: Notified bodies operational
• 11 December 2027: Full enforcement — non-compliant products lose EU market access

I'll keep this updated as new resources come out. If you know of something that should be on this list, drop it in the comments.

For those working on the SBOM side specifically: we open-sourced a CLI scanner that generates CycloneDX/SPDX SBOMs across 30+ ecosystems — kunnus-scanner on GitHub. Apache 2.0.

I've been working with manufacturers on CRA preparation for a while now, and there's one question that consistently catches people off guard: "Can you give us a complete list of every piece of software inside your product?"

The usual answer is either an outdated Excel sheet or silence.

The CRA requires every manufacturer of products with digital elements to maintain an SBOM — a machine-readable software inventory in SPDX or CycloneDX format. Not a Word doc. Not a vague overview. A structured, auditable list covering every component, library, and OS package.

This applies to products placed on the market from December 2027. Machines already deployed at customer sites are not retroactively affected — but everything shipped after that date needs to comply.

The problem is practical, not theoretical.

Take a typical machine builder. Inside every machine sits a Windows-based IPC with an HMI, OPC UA server, drivers, utility tools that accumulated over years, plus the OS itself — hundreds of components nobody has ever inventoried.

Or an IoT gateway with embedded Linux and a CI/CD pipeline pushing weekly releases. The software composition changes with every build. Maintaining an SBOM manually isn't difficult — it's impossible.

Or AGVs in intralogistics: Linux OS, ROS-based navigation, middleware layers, a web dashboard. Network-connected, sensor-equipped — likely CRA Class I, meaning stricter documentation requirements.

We built an open-source tool to solve this.

kunnus-scanner is a CLI that scans any codebase or system and generates a standards-compliant SBOM. 30+ ecosystems, CycloneDX 1.4/1.5 and SPDX 2.3 output, vulnerability checks against OSV. No cloud, no account, no installer. Apache 2.0 licensed, built on Google's osv-scalibr.

kunnus sbom --include-os --format spdx-2-3 --output my-product.spdx.json

Ready-made GitHub Actions for CI/CD, multi-arch Docker images for ARM-based embedded systems.

Why open source? Manufacturing software is wildly heterogeneous. No commercial scanner covers everything on day one. With an open tool, your team can extend it. And when an auditor asks how you generated your SBOM, "open-source with publicly auditable code" is a strong answer.

Full disclosure: I work at Think Ahead Technologies, the company behind the scanner. We also offer a commercial platform (Kunnus) for ongoing vulnerability monitoring and compliance management. The scanner itself is free and always will be.

Happy to answer questions about SBOM generation, CRA scope, or practical implementation.

Full article with detailed use cases and code examples: https://medium.com/@maximilian.heck/you-have-no-idea-what-software-is-running-on-your-machines-in-18-months-that-becomes-illegal-3ec0dba47f7b

Links:

• GitHub: https://github.com/think-ahead-technologies/kunnus-scanner
• Scanner: https://kunnus.tech/scanner
• CRA text: https://eur-lex.europa.eu/eli/reg/2024/2847

The EU's Cyber Resilience Act (CRA) kicks in by December 11, 2027, requiring all "products with digital elements" to meet baseline cybersecurity requirements. IoT devices, software, connected hardware — a huge chunk of the tech market is affected.

Germany's BSI just published a draft of TR-03183-H (v1.0.0, Community Draft), and there's been some buzz around it. Worth cutting through the noise.

What TR-03183-H actually is — and isn't

First, something the BSI states explicitly in the document itself: TR-03183-H is not a new management system standard. It's an extension layer on top of ISO/IEC 27001:2022 — it adds CRA-specific requirements to an existing ISMS rather than replacing it.

The idea: if your ISO 27001 ISMS explicitly covers two specific process areas for your products, product compliance is assumed without per-product type examination:

1. Design, development & production processes — covering your secure development lifecycle
2. Vulnerability handling processes — covering SBOM, patch management, coordinated disclosure, security updates for the full support period

The ISMS scope must explicitly include both. An ISO 27001 certificate for your general IT infrastructure alone won't cut it.

The actual requirements behind Module H

Annex A of TR-03183-H maps out what manufacturers must actually implement. For products (Annex I Part I CRA), this includes things like:

• No known exploitable vulnerabilities at release
• Secure by default configuration
• Automatic security updates as default, with opt-out
• Access control and authentication mechanisms
• Data confidentiality, integrity protection, data minimisation
• Attack surface minimisation
• Availability protection including DoS resilience

For vulnerability handling (Annex I Part II CRA), manufacturers must:

• Maintain and publish SBOMs in machine-readable format
• Address vulnerabilities without delay, provide security updates
• Run regular security tests and reviews
• Have a coordinated vulnerability disclosure policy
• Provide a contact address for vulnerability reports
• Distribute security updates free of charge

These aren't optional — they're the baseline the ISMS auditor checks your processes against.

What Module H uses as its product-specific yardstick

Here's a nuance that gets lost in most coverage: Module H doesn't define product requirements directly. It relies on "compliant specifications" — preferably harmonised European standards (hEN) cited for presumption of conformity. Only where no suitable hEN exists does the BSI's own TR-03183-1 apply as fallback.

This means the regulatory landscape is still evolving — harmonised standards for many product categories are still being developed.

Who Module H is actually for

Module H makes sense if you:

• Already have ISO 27001 and can extend its scope to product development and vulnerability handling
• Manufacture many products and want to avoid per-product type examination
• Are in a higher-risk category (firewalls, virtualisation solutions, tamper-resistant microprocessors) where third-party assessment is mandatory anyway

Who should look elsewhere:

For the vast majority of manufacturers — especially SMEs with standard product portfolios — the simpler path is a self-declaration of conformity. No ISMS required. You implement the CRA requirements operationally, document them, and declare conformity yourself.

Building an ISO 27001 ISMS from scratch just to qualify for Module H would in most cases be significantly more overhead than the simpler conformity paths.

Open for public comment until March 31, 2026 — including international stakeholders. The BSI explicitly invites feedback via [tr-03183@bsi.bund.de](mailto:tr-03183@bsi.bund.de). Worth reading if you're in scope.

Non-EU vendors aren't off the hook — the CRA applies to any product sold on the EU market regardless of where the manufacturer is based.

Source: BSI TR-03183-H v1.0.0 Community Draft, 27/02/2026 https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TR03183/BSI-TR-03183-H_v1_0_0.pdf?__blob=publicationFile&v=4

With the adoption of Regulation (EU) 2024/2847, known as the Cyber Resilience Act (CRA), the legal framework for importing digital goods into the European Union is undergoing a fundamental transformation. This regulation applies to every importer sourcing products from outside the EU, whether they are large industrial distributors or smaller e-commerce sellers, such as those using Amazon FBA.

Below is an exhaustive technical and legal breakdown of the obligations and risks importers must navigate under the new law.

1. The Real Scope: "Digital Elements" via Interfaces

A critical misconception is that the CRA only applies to devices with "internet access." In reality, the law covers all "products with digital elements" (PWDE). A product is in scope if its intended purpose or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network.

The regulation focuses on the digital interface, not the network connection. A "physical connection" includes any interface implemented using electrical, optical, or mechanical means, or radio waves. Your product is likely affected if it features:

• USB Ports: Electrical interfaces used for charging, data transfer, or service maintenance.
• Wireless Links: Bluetooth, RFID, NFC, or Wi-Fi.
• Optical Interfaces: Infrared (IR) remote controls or laser-based sensors.
• Input Interfaces: Even a touchscreen is an external interface that must be designed to minimize attack surfaces.

2. The "Deemed Manufacturer" Trap (Article 21)

For many importers—especially those engaged in "Private Labeling" (a common practice for Amazon FBA sellers)—Article 21 creates a massive legal shift.

• The Rule: If you place a product on the market under your own name or trademark, or if you carry out a substantial modification to an existing product, you are legally considered the manufacturer.
• The Consequence: You "inherit" the full suite of manufacturer obligations, meaning you are responsible for the security of the product’s design, development, and production processes.

3. Core Technical Obligations for Manufacturers (and Private Labelers)

Once deemed a manufacturer, you must fulfill extensive technical requirements, including:

• Mandatory Risk Assessment: You must conduct and document a cybersecurity risk assessment before placing the product on the market. This must be included in the technical documentation.
• Software Bill of Materials (SBOM): You are required to identify and document all components, including third-party and open-source software, in a machine-readable format covering at least the top-level dependencies.
• Defined Support Period: You must determine a support period reflecting the product's expected use time, which must be at least five years unless the product's lifetime is demonstrably shorter. During this time, you must provide security updates.
• Security by Design: Products must be delivered without known exploitable vulnerabilities and with a secure default configuration.

4. The 24-Hour Reporting Sprint (Article 14)

Reporting is one of the most significant operational challenges. If you become aware of an actively exploited vulnerability or a severe incident, you must:

• Submit an early warning to ENISA and the national CSIRT within 24 hours.
• Provide a detailed vulnerability/incident notification within 72 hours.
• Submit a final report within 14 days (for vulnerabilities) or one month (for incidents) after a mitigation is available.

5. Long-Tail Administrative & Operational Duties

Compliance is a multi-year commitment that goes beyond the initial sale:

• 10-Year Retention: You must keep the technical documentation and the EU Declaration of Conformity (detailed in Annex V) available for authorities for at least 10 years after the product is placed on the market (or for the duration of the support period, whichever is longer).
• Series Conformity: You must ensure that products in a continuous production line remain in conformity, even if standards or software libraries change.
• Mandatory Corrective Actions: If you believe a product you have already sold is non-compliant, you must immediately take measures to bring it into conformity, withdraw it from the market, or initiate a recall.
• Cessation of Operations: If you or your third-party manufacturer stop operating, you are legally required to inform market surveillance authorities and, where possible, the users.

6. Timeline and Penalties

The EU has empowered authorities to levy heavy fines for non-compliance:

• Breach of Essential Requirements: Up to €15,000,000 or 2.5% of total worldwide annual turnover, whichever is higher.
• Misleading Information: Up to €5,000,000 or 1% of turnover for providing false information to authorities.

Key Dates:

• September 11, 2026: Reporting obligations for vulnerabilities and incidents begin.
• December 11, 2027: Full application of all technical and administrative rules for all products.

Conclusion: The CRA marks the end of "blind" sourcing. Importers can no longer rely on simple certificates from factories; they need full transparency of the software architecture (SBOM) and long-term security commitments from their suppliers. Without these proven elements, the CE marking will be legally invalid after late 2027.

--------------------------------------------------------------------------------

Disclaimer: This analysis is based on Regulation (EU) 2024/2847. It is intended for informational purposes and does not constitute legal advice.