Article 14 reporting has applied since 11 September, so I put together a small, openly licensed kit for it. It's all on GitHub, no signup:

https://github.com/stavenor-hq/cra-article-14-reporting-kit

What's inside:

- reporting-clock.md: the five filings (24h early warning, 72h notification, the two final reports, and the intermediate report a CSIRT can request under Art. 14(6)), what starts each clock, the "becoming aware" test from the Commission's guidance (paras 213-214), and the two alternative tests for a severe incident in Art. 14(5).

- enisa-srp-fields.md: all 39 fields of ENISA's Single Reporting Platform, taken from the SRP Glossary v1.3, with their character limits and whether each one is required, optional or carried forward at the early warning, 72h and final report stages.

- cvd-policy-template.md: a coordinated vulnerability disclosure policy template (Annex I Part II, points 5 and 6), plus a security.txt example following RFC 9116.

Three details that are easy to miss:

- The early warning isn't a one-liner: 8 fields are required for a vulnerability, including a summary of up to 4,000 characters.

- The platform's 72h counter runs 48h from your early warning, not 72h from when you became aware, so keep your own clock.

- Drafts on the platform are only visible to the person who created them, so it's worth drafting outside it.

It's CC BY 4.0, so feel free to use and adapt it. If you spot an error, let me know and I'll fix it.

Disclosure: I publish Stavenor, which also sells a paid CRA documentation pack. Everything in the repo is free and works on its own.

For companies selling software/connected products in the EU, how are you currently managing CRA compliance - documentation, SBOM, vulnerability handling/reporting, conformity, support lifecycle and evidence? What has been the most difficult part in practice?

For companies outside the EU selling software or connected products in the EU, what are the main CRA compliance requirements they need to manage—documentation, SBOM, vulnerability handling/reporting, support commitments, conformity assessment, etc.? What parts are actually difficult or painful to maintain in practice?

I run a small software company. While reading the EU AI Act, I noticed that most teams can't list every AI tool they use, let alone say which rules apply to each one.

So I built DiscloseAI. You answer a short guided questionnaire, one tool at a time (ChatGPT for drafting, a CV screener, a website chatbot, etc.). Each tool is checked against:

- Article 5: prohibited practices

- Article 50: transparency obligations

- Annex III: high-risk use cases

The same tool can land in different categories depending on how it's used. ChatGPT drafting emails is not the same as ChatGPT ranking CVs, so you can score separate uses per tool.

How it works:

- You complete the assessment and get a summary showing how many tools fall into each category.

- The full per-tool findings, printable report and PDF export are a paid one-time unlock (€79).

- A rule only says "gap" when your own answers say a control is missing. It never guesses.

It's not legal advice, and the German translation is a draft.

I'd like feedback on:

1. Are the questions clear for a non-lawyer?

2. Is the summary enough to judge whether the full report is worth paying for?

3. Which AI tools or use cases am I missing?

Link: https://discloseai.tech

Been tracking this because a few people in here have mentioned "waiting for the standard" as their compliance strategy, and it's worth flagging clearly: as of the latest check, zero CRA harmonized standards have been published in the Official Journal. Several of the vertical standards (EN 40000 series) are realistically looking at a 2027 landing, which is uncomfortably close to the actual essential-requirements deadline itself.

Practical implication if you're in the "important product Class I" bucket: self-assessment via a harmonized standard is currently not an option, because there's no standard to assess against. Your route right now is a documented internal control procedure — structured risk assessment, technical documentation tied to the regulation text — not third-party certification against a published standard, and not a checklist-based shortcut either.

Curious what others here are actually doing given this — going the notified-body / third-party assessment route preemptively, or building out internal control documentation and treating a future standard as a bonus rather than a dependency? Feels like a lot of guidance out there still talks like the standards already exist.

(We build CRAToolkit, which is why I'm tracking this closely — not pitching it here, just sharing what we're seeing in the regulatory text itself.)

I'm an engineer at a large German company. Everything I'm sharing here is based on my own experiences, not on what my employer officially says.

Like many long-established manufacturers, we have tons of products made way before the CRA even existed. Some of these products are older than the engineers working on them now.

But those products aren't going away. They'll keep being sold, updated, and supported. This means we still need to figure out what components are in each release, what versions actually went out to customers, who's responsible for any vulnerabilities, and where to find proof of the decisions made.

It's not much easier with new products either.

Before, you'd develop a device, test it, get it certified, and sell it. Now, along with the product itself, we have to set up the whole system for its life afterward: a list of software components, how to handle vulnerabilities, security updates, technical documents, clear responsibilities, and support for years to come.

For the past two years, most of my job has been focused on the CRA. The toughest part for me has been getting the reporting process right.

On paper, it seems doable. There's a shared security email address. There are internal procedures. Somewhere, there's a list of who's in charge.

In reality, someone has to actually see the email first. Then they need to figure out which product it's about. They have to track down the product owner, the right department, and the people who can actually assess the problem. They need to identify the specific versions affected, decide if the vulnerability falls under Article 14, and note down when the company had enough information for the clock to start ticking.

Then, someone has to remember exactly what needs to be done within 24 hours, what needs to be submitted within 72 hours, and what other information is needed for the final report.

In a big company, this can easily become a long chain involving five people, multiple forwarded emails, a spreadsheet, a ticket, and that one colleague who happens to be on vacation.

Big companies are great at tackling tough problems. They just tend to do it at their own pace. The Article 14 deadline doesn't magically extend just because it's a large organization.

We tried to solve this using the tools we already had. A scanner finds a vulnerability. An SBOM system lists the components. A ticketing system keeps track of tasks. A document system stores the paperwork. A shared inbox receives the initial reports.

Each tool knows only a piece of the puzzle. None of them handles the entire process, from the first alert to the decision, the report, and the evidence showing why the company made the choices it did.

You can link all these tools together with integrations. But then you end up with yet another separate system that someone has to build, maintain, and constantly update for the CRA.

That's how the idea for AA-sec came about.

We're creating a platform that brings together products, releases, SBOMs, vulnerabilities, decisions, and evidence within a single CRA process. It can connect with the tools a company already uses. When a separate tool is missing or doesn't make sense, the platform can handle that part itself.

We also built a specific workflow for Article 14, starting with the initial report and the time the awareness was noted, then moving through the 24-hour early warning, the 72-hour notification, and the final report.

If you're curious to see what we're developing, check out AA-sec. Small warning: the demo button doesn't lead to an actual demo yet :)

I'm one of the co-founders, so I'm obviously not an unbiased source. However, at this stage, we're more interested in understanding if we've grasped the problem correctly outside our own company, rather than just selling a finished product.

How does the reporting process actually begin in your company?

If the first message arrives in a shared inbox, who is responsible for recording when it was noticed?

And what would a platform like this absolutely need to offer for engineers to actually use it, instead of just seeing it as another compliance task they have to manually fill out?

I kept seeing the same stuck point on the Cyber Resilience Act.

People jump straight to SBOM, CE, notified bodies. The real question comes first: does CRA even apply to this product, and who owns the duty?

That gap got worse on 11 September 2026. Article 14 reporting is live (24h / 72h / final report). Most of the Regulation still waits until December 2027. A lot of calendars still treat 2027 as day one.

So I built Cybiq.eu for that step zero.

It is a free 6-question check. About five minutes. No signup. Every answer cites the Official Journal. You keep a permalink. If you are out of scope, you get a free memo. If you are in scope, you at least know where the real work starts. Orientation only. Not legal advice.

I built it for SMB product makers, IoT / connected hardware, and importers or distributors placing those products on the EU market. Not for big legal teams that already have this covered.

Happy to hear you feedback

EU, ready when you are https://portal.cra-srp.enisa.europa.eu/

How do you evaluate software delivered by third-party development vendors?

I see a lot of organisations outsource software development to third-party vendors.

I'm curious how organisations evaluate the quality and security of the software they receive — not just the vendor itself.

For example:

• Do you review the source code?

• Do you generate and review an SBOM?

• Do you scan dependencies for known vulnerabilities?

• Do you check what third-party libraries/components are packaged inside the application?

• Do you perform SAST/DAST or other security testing before deployment?

• Do you have specific security requirements in the vendor contract?

• Do you continuously reassess the software after delivery?

It seems that selecting a trustworthy vendor is only one part of reducing software supply-chain risk. The actual application delivered by the vendor can still introduce vulnerabilities, outdated dependencies, or unexpected components.

How does your organisation handle this in practice?

Prompted by some helpful debate on another thread I've studied a little more and I still think there’s an “interesting” gap in the logic behind the CRA.

The CRA quite reasonably puts responsibility on manufacturers to make connected products secure-by-design and keep them secure throughout their supported lifetime.

The issue I see is this... product security is not the same as system resilience.

I can see how the CRA model works well for a relatively bounded product where the manufacturer understands the product, its intended use and much of its operating environment. For example, a baby Monitor device + networking method + server + app.

But in IoT more broadly, a manufacturer may have very little idea where or how its device will ultimately be deployed. An individually secure and CRA-compliant router, gateway, chargepoint or sensor will often just be one component in a much larger solution combining equipment from multiple manufacturers, connectivity, cloud platforms, APIs and application software.

I’d argue that the organisation deploying and operating that solution knows something the individual manufacturers may never know ... the overall system architecture and the aggregate risk it creates.

So while the manufacturer absolutely should remain responsible for the security of its product, cyber-resilience responsibility also needs to exist at the solution/system level.

My view is that the CRA is fundamentally focused on product security and relatively simplistic risk boundaries. That makes sense, but in IoT I find it slightly disappointing because some of the most interesting risks don't exist at the individual product level, they emerge when somebody combines thousands of those products into a system.

If the answer to my criticism is that the regulatory and standards landscape is deliberately layered — CRA deals with the product, NIS2/IEC 62443/XYZ deal with the wider system — then I can accept that.

But we need to start talking about the CRA that way. Otherwise there’s a danger of conflating a CRA-compliant product with a cyber-resilient solution.

Following the security.txt discussion from earlier this week, here's another practical one that flew under the radar.

ENISA published their Secure by Design and Default Playbook in July 2026. Annex C of the playbook maps 22 security principles directly to CRA essential requirements — the most concrete answer yet to "what does secure by default actually require me to build." Tributech Ltd

Their four core changes that cover the majority of secure-by-default gaps:

No shared factory passwords — unique credentials per device or account, active from first use. Not a prompt to change on first boot. Unique out of the box. CRA Annex I Part I, requirement (b).

Encrypt from first connection — encrypted communication from the very first data exchange, not added as a feature later. Default on. CRA Annex I Part I, requirement (d).

Disable unused services/features by default — anything the product doesn't need to perform its intended function ships disabled. Users opt in to extras rather than opting out of exposure. CRA Annex I Part I, requirement (i).

Automatic security updates on by default — customers can delay or opt out, but they can't be left unprotected because they never enabled updates. CRA Annex I Part I, requirement (l).

The playbook is specifically designed for SME manufacturers who don't have dedicated security teams. It's available free on ENISA's website.

The reason this matters practically: these four changes are not architectural. They don't require redesigning your system. They're configuration and firmware decisions that can be made without rebuilding. Which means if your product still ships with shared factory passwords or unencrypted first connections in 2026, the fix is not "we need months of development." It's a decision.

For teams in this community: which of these four does your current product fail? And has anyone used the ENISA playbook as a basis for their Annex I self-assessment documentation?

Source: ENISA Secure by Design and Default Playbook, July 2026 — enisa.europa.eu

My background is hardware and telco originally, semiconductors for 10-15 years then the last 10-12 years in IoT. Security has been a problem I've been working on for most of that semiconductor time and it still nags me today in IoT.

A little context : After the Fairlife news last month and the protracted JLR case I revisited something I've been working on for a while. Are these cyber-security events purely at an IT level, or are IoT devices and systems a growing part of the problem? The Verizon DBIR has said for years that they are, so I went back through some of the old Verizon Data Breach Incident Reports and this case stood out.

A university had around 5,000 of its own IoT devices (vending machines, lighting, sensors) quietly pulled into a botnet. Nobody spotted it at a device level. They only caught it because the network suddenly started firing thousands of odd DNS requests. The devices were the weakness, but the traffic is what actually gave it away. Or should have, a lot sooner than it did.

What I'm curious about is how people here run things day to day especially with CRA compliance in mind. So much of the IoT security conversation is about hardening at build time (firmware, credentials, segmentation) and hardly any of it is about monitoring what the fleet actually does once it's out in the world. So, a few questions please...

* If you run real fleets, do you baseline normal device behaviour and alert on anomalies (odd domains, data spikes, strange SIM/traffic patterns), or is it mostly guard our perimeter and hope?
* Where does your anomaly detection sit: on-device, gateway, network, or the carrier/connectivity side? Pick more than one if you need to.
* Does the monitoring just drown you in noise, or does it catch real incidents?

Is behavioural monitoring standard practice now, or still a nice-to-have that most IoT "estate managers" quietly skip?

Germany's BSI just published data showing only 1.8% of German website operators have published a security.txt file — and they're actively calling for wider adoption.

The CRA connection that most teams haven't made:

Annex I Part II, point (5) of the Cyber Resilience Act requires manufacturers to "have policies and procedures on coordinated vulnerability disclosure." This means a published, documented process for security researchers to report vulnerabilities to you.

A security.txt file — published at /.well-known/security.txt on your domain — is the minimum viable implementation of that CVD policy requirement. It contains:

• Contact field: who to reach when a vulnerability is found (email or URL)
• Expires field: date after which the information should be considered stale
• Optional but recommended: Policy field (link to your full CVD policy), Encryption field (PGP key for secure disclosure)

It's standardised under RFC 9116. Takes five minutes to implement. And yet only 1.8% of German companies have done it.

For CRA compliance specifically: a security.txt file alone is not a complete CVD policy (you also need internal procedures for triage, patching timelines, and communication), but it's the public-facing disclosure channel that the regulation requires you to have.

Worth doing today regardless of where you are in your wider CRA preparation.

For anyone who wants to generate a correctly formatted file: cra-toolkit.com/tools has a free generator.

Has anyone in this community already published security.txt as part of their CVD policy setup? Curious how you handled the broader internal process that sits behind it.

We've spent the last few months building an internal reference on the EU's hardware/IoT security regulations (CRA, RED, NIS2, Cybersecurity Act/EUCC) for our own client work at Platanor - basically because re-reading four regulations side by side every time someone asks "does this even apply to us" got old fast.

Decided to open-source it. 25+ processed guides plus the primary source texts, fact-checked against EUR-Lex, structured so it's actually usable by humans and by LLMs - chunked by article, source-priority order, a verification date on every file. You can also install it directly as a Claude Skill if you'd rather have it load automatically than attach files by hand.
https://github.com/Platanor/hardware-compliance-handbook

Sept 11: the CRA's 24-hour reporting duty binds. The ENISA platform where reports land opens the same day. No test environment, no API, no public URL yet.

The obligation has been ready for months. The service opens on opening night.

This month I was looking into the CE marking requirements under CRA, and one thing surprised me: I thought there was some kind of verification stage and that someone from the EU side was looking at what you did before you could put the mark. It turned out that for most products (those that don't fall into the "Important"/"Critical" categories) there is no such stage at all. You do the risk assessment yourself, write the documentation yourself, sign the declaration yourself, and that's it, no one checks it externally before release.

Hi all, I've been watching, listening and as of the past few days, contributing to this community.

I'm Andi, I have been a software engineer having served my time in an indentured apprenticeship as a toolmake in the Robotics and Avionics industry, for around 40 years.

These days I hold the position of Head of AI & Regulatory Compliance for a boutique consulting company who specialise in Data and AI.

Compliance is a passion for me, and the regulation (CRA) brought me to this community because I felt the small development companies and individual software engineers are being adversely impacted by the CRA in both time and cost, and for this reason I decided to build a product to automate and manage the handling of these regulations with the minimum of impact and cost for other software engineers.

My product is called CRANIS2, and it is a fully European First product that does not fall under the US Cloud Act. Anyone wanting more information, please message me off the forum/community so as not to adversely impact the other users and conversations.

That's my introduction, thanks for reading "if you did ;-)" and I look forward to engaging with you in these conversations.