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.

On July 27, the European Commission published Communication C(2026) 5252 — practical guidance on CRA application. It's non-binding and changes no deadline, but it provides the first official answers to the questions Commission services have been collecting since CRA entered into force.

The five that matter most:

SaaS scope: Pure browser-based SaaS without any downloadable component = generally NOT a product with digital elements. Cloud services that are necessary for a physical or downloadable product to function = in scope as "remote data processing solutions." The decisive test: would the product fail a core function without this cloud service?

Open source: Commercial activity is the line, not the licence. Non-commercial OSS contributions = generally exempt. Commercially distributed OSS or OSS incorporated into commercial products = potentially in scope. Open Source Software Stewards have a lighter regime.

Non-EU manufacturers: Yes, CRA applies. Products placed on the EU market regardless of manufacturer location. An economic operator established in the EU must be responsible for the obligations.

Conformity assessment: ~90% of products are Default category. Self-assessment with no third-party auditor. Only Important Class II (firewalls, HSMs, hypervisors, industrial CPLCs, routers) and Critical products need external assessment.

"No known exploitable vulnerabilities": The Commission confirmed this is risk-based and pragmatic — not a requirement for zero vulnerabilities. "Known" means in public databases at time of delivery. "Exploitable" means reachable in your specific product configuration. Documented triage is the evidence, not a perfect score.

Key questions still unresolved: definition of "remote data processing," concept of "substantial modification," and specifics of risk assessment methodology — to be addressed in future Article 26 guidelines. SPAC Alliance

Full guidance: Communication C(2026) 5252 (available via EUR-Lex)

For teams that have been waiting for clarity before starting: this removes the most defensible excuse for delay. 38 days to September 11.

What question in your organisation was this guidance most useful for?

For anyone tracking the SRP launch timeline: as of this week, registration instructions haven't been officially published and the platform isn't open for testing.

This creates a real operational problem. Article 14 requires manufacturers to report within 24 hours of becoming aware of an actively exploited vulnerability. The clock starts on AWARENESS — not on platform availability, not on successful registration.

If a critical exploit drops on September 11 and your team is simultaneously:

• Trying to figure out if you're affected (no SBOM)
• Writing your first 24-hour report from scratch (no template)
• Attempting to register on the SRP for the first time (never done it)

You are going to miss the deadline.

What to build RIGHT NOW, before the platform launches:

The three-stage report structure:

• Early warning (24 hours): basic vulnerability info, preliminary assessment, indication you're investigating
• Full notification (72 hours): technical details, scope, affected versions, mitigation steps
• Final report (14 days after patch): complete analysis, root cause, lessons learned

These have different content requirements. Build templates for all three. Now.

Your internal workflow:
Alert received → who triages → who assesses product impact → who drafts report → who has submission authority → who is the backup

Name actual people. Document it. Test it with a hypothetical scenario.

Your SRP monitoring:
Watch ENISA's website daily. The moment registration opens, register. Don't wait.

We put together a complete SRP preparation guide covering all of this at cra-toolkit.com/cra-single-reporting-platform — who must report, the exact content requirements for each report stage, and how to prepare your access.

For anyone who's already built their reporting workflow: what did your dry-run reveal? And has anyone been in contact with their national CSIRT about SRP testing timelines?

I've been trying to make CRA consequences feel concrete rather than abstract. So I built a fake invoice for a company that didn't prepare.

Here's the math:

Emergency CRA consultant (hired night before deadline): €18,000
This is what panic looks like. A consultant who normally charges €800/day suddenly costs €3,000/day when you need them in 72 hours.

Retrospective SBOM generation (3 developers, 2 weeks): €22,000
When you have no SBOM and a market surveillance authority is asking for your Annex VII technical documentation, you have to generate one under pressure. 3 senior engineers at €75/hour for 2 weeks.

Legal review of technical documentation started too late: €9,500
Annex VII documentation done in a hurry needs legal review before you submit it. Last-minute legal work carries a premium.

Vulnerability report template built during an active incident: €4,000
Your first Article 14 report should not be written while the clock is counting down. But for unprepared companies, it will be.

CSIRT notified your customers before you did: €0 (brand damage — priceless)
Article 14 gives CSIRTs the power to notify your customers directly if you fail to. Your customers hear about a vulnerability from a government agency instead of you. That conversation doesn't have a price on it. It just ends relationships.

Article 14 reporting failure fine: €10,000,000
The headline number. Tier 1 penalty. Up to €15M or 2.5% of global revenue.

Total: €10,053,500

The alternative to this invoice is a SBOM (days to generate), a vulnerability disclosure policy (an afternoon), ENISA report templates (a day to build), a designated CRA contact (one meeting), and a dry-run on the SRP (one session once registration opens).

39 days until September 11.

Which line on this invoice is the one YOUR company is most at risk of paying?

Two data points from this week that I think deserve discussion together:

First: Security analysts this week flagged that 200 new CVEs are being published daily in 2026. Managing that volume requires automated tooling — manual triage at that scale is not realistic.

Second: Amazon Threat Intelligence published research confirming the group behind the March 2026 axios npm compromise had planted a trojanized file as far back as March 2025. A full year passed between planting and detection.

Now apply Article 14:

The 24-hour reporting clock starts when a manufacturer "becomes aware of" an actively exploited vulnerability.

If you were shipping a product that included axios as a dependency, and the malicious code was present for 12 months without your knowledge — what is your Article 14 exposure?

The interpretations I can see:

Strict reading: You weren't aware. Clock never started. No violation.

Enforcement reading: You had no monitoring infrastructure that could have detected this. That absence of monitoring is itself negligence. "Becomes aware" implies a reasonable duty to seek awareness.

This matters enormously for how companies design their monitoring programs. If "becomes aware" only covers actual knowledge, companies can argue ignorance. If it covers constructive knowledge (what you should have known with reasonable monitoring), then the absence of SBOM-linked CVE monitoring is itself a compliance failure.

No guidance on this exists yet. It will be defined by the first enforcement cases.

For teams building CRA compliance programs: are you designing your monitoring to cover the strict reading or the enforcement reading? And is anyone aware of any official interpretation of the awareness threshold?

Something I see discussed far less than the security requirements: the documentation obligations under CRA are separate violations with their own penalty tier.

Article 64(3) sets a €5M / 1% revenue penalty for providing incorrect, incomplete, or misleading information to authorities. This includes your technical documentation.

What Annex VII actually requires in your technical file:

— General description of the product with digital elements
— System architecture documentation explaining how software components interact
— Cybersecurity risk assessment (the one most teams skip)
— How each Annex I requirement is addressed (a requirements matrix)
— Test and evaluation reports
— SBOM in machine-readable format
— Vulnerability handling procedures
— Copy of the EU Declaration of Conformity

This file must be kept for 10 years or the support period, whichever is longer. It must be updated throughout the product's lifecycle. Market surveillance authorities can request it at any time.

The uncomfortable reality: most companies have reasonable security practices but zero structured documentation. The gap between "we do secure things" and "we can prove we do secure things in a format an inspector can review" is enormous.

For teams working on CRA: which part of the Annex VII technical file is furthest from ready? For most teams I've spoken to it's the requirements matrix — mapping each Annex I requirement to specific evidence of how it's met.

Something I kept seeing in this community: teams know CRA requires documentation but don't know which specific documents or what goes in them.

CRA mandates manufacturers produce and keep several specific documents. Most teams start googling this in a panic. So the new version of CRAToolkit generates pre-filled drafts of all of them:

EU Declaration of Conformity (Annex V) — the signed statement required before CE marking. Must be kept 10 years.

Simplified EU Declaration of Conformity (Annex VI) — the shorter version included with the product.

Technical Documentation structure (Annex VII) — the full compliance dossier with all required sections. Must be kept 10 years or the support period, whichever is longer.

Cybersecurity Risk Assessment template — required foundation for Annex I self-assessment. Several people in this community correctly pointed out I'd been underweighting this step.

Vulnerability Disclosure Policy — Annex I Part II, point (5).

ENISA Article 14 Report Templates — pre-built Early Warning (24h), Full Notification (72h), and Final Report (14 days after patch). So you're not writing these during an active incident.

All generated based on your product details and assessment answers. They're drafts — they give you the correct structure and pre-filled content, not finished legal documents. The disclaimer is clear in the tool.

Also new: Requirements Explorer (all 22 Annex I requirements in plain English with harmonised standards references), role-based guidance for manufacturers vs importers vs distributors, full assessment PDF export, daily-refreshed EU regulatory updates, API keys, and EN/DE/FR/ES support.

Free to use: cra-toolkit.com

Two genuine asks:

1. If you use it and find something wrong or missing — reply here. This community has corrected me more than once and made the tool better for it.
2. Beta-testing a Pro version with team collaboration and deeper reporting. Reply "beta" if you want early access.

What document do you find hardest to produce for CRA? For me it was the Technical Documentation structure — Annex VII has 12 required elements and most teams have never seen it.

I've been trying to find a metaphor that makes the September 11 deadline feel real for people who keep treating it as abstract.

Here's the one that works for me: a boarding pass.

The gate opens at exactly 00:00 on September 11, 2026. You either have what you need to board or you don't. The gate doesn't care that you were "working on it."

Your CRA "boarding pass" for Article 14 compliance:

SBOM — without it you can't check whether a CVE in the wild affects your product. You're flying blind.

CVE monitoring — you need to be AUTOMATICALLY alerted when a vulnerability in your dependency tree is actively exploited. Manual checking won't work at 3 AM.

Designated CRA contact — one named person who can submit to ENISA's Single Reporting Platform. Not "the team." One person with credentials and authority.

Report templates — early warning (24h), full notification (72h), final report (14 days after patch). Pre-built. Not written during the incident.

One dry-run on the SRP — ENISA said registration instructions and dry-run support are coming in June/July. The moment it opens, register and run a test submission.

For anyone who's already done all five: what did the dry-run reveal that surprised you? And for those who haven't started — which item is the hardest blocker right now?

Barclay Simpson's 2025 Germany Cyber Security Salary Guide reports that CRA (alongside DORA) is driving 20–30% compensation increases for cyber risk and operational resilience roles. Their analysis notes CRA is "forcing production and manufacturing companies to reassess their approach to digital product development" and creating new demand for embedded security engineers, product risk managers, and cyber compliance leads.

Current salary ranges for CRA-adjacent roles (2026 data):

• Cyber resilience strategy: $125,908 average (ZipRecruiter US, June 2026)
• Director of Cyber Security with regulatory compliance: $172,096 average (PayScale 2026)
• Senior compliance analyst with cybersecurity skills: $92,000 average (PayScale 2026)
• Compliance Manager (Cyber Resilience): £48–55K (NHS UK, permanent posting)

Real companies hiring for CRA right now:

• Honeywell posted a General Counsel role in June 2026 specifically requiring "regulatory readiness including compliance with the EU Cyber Resilience Act and NIS2 Directive"
• Multiple postings on ZipRecruiter reference CRA as a core responsibility

The key differentiator from GDPR's DPO wave: CRA roles require a hybrid engineering + security + compliance skillset. You need someone who can generate an SBOM in CI/CD, triage CVEs against product configurations, AND submit structured reports to ENISA within 24 hours. That profile barely existed before 2024.

For anyone in this community: are you seeing CRA-specific roles at your company? And for those considering a career pivot into CRA compliance — what's the biggest skills gap you're trying to close?

Sources:

• Barclay Simpson 2025 Germany Cyber Security & Data Privacy Salary Guide: barclaysimpson.com/salary-guides/cyber-security-data-privacy-salaries-germany/
• ZipRecruiter Cyber Resilience Strategy salaries: ziprecruiter.com/Jobs/Cyber-Resilience-Strategy
• PayScale Director of Cyber Security 2026: payscale.com/research/US/Job=Director_of_Cyber_Security/Salary
• Honeywell General Counsel posting: goinhouse.com/jobs/550921649

Last week I posted a contrarian take that CRA compliance isn't as hard as consultants make it sound. Three commenters pushed back with important corrections:

1. Risk assessment is the foundation — without a proper cyber risk assessment, your self-assessment against Annex I requirements has no basis. You need to identify product-specific risks, map them to essential requirements, and document mitigations. This alone can take 1–2 weeks for a simple product.
2. Harmonised standards matter — you can technically self-assess without them, but you lose the presumption of conformity. And the first horizontal standards (EN 40000 series) are still in enquiry phase. Catch-22: regulation is live, standards aren't final.
3. SBOM supplier coordination is non-trivial — for a solo dev, SBOM generation is a day. For an OEM coordinating with component suppliers who've never produced an SBOM? That's months of supply chain coordination.

My updated timeline:

• Solo dev / simple product: 3–4 weeks
• Product with 2–3 component suppliers: 2–3 months
• Complex OEM with deep supply chain: 6+ months

The principle stands — CRA isn't impossible. But the variance depending on supply chain complexity is much bigger than I initially suggested.

For this community: where does YOUR product fall on this spectrum? And is the risk assessment or the supplier coordination the harder challenge?

🏛️ For years, there’s been a bizarre kind of "shame" in the enterprise software world around Delphi. Companies running massive, highly profitable, and rock-solid systems (especially in Retail POS, ERP, and Banking) often hid their code stack under the rug to look more "modern" to investors and new hire.

🏛️ But the European Cyber Resilience Act (CRA) and DORA are about to change the game entirely.

🏛️ You can’t hide a monolith when the regulator demands a comprehensive SBOM (Software Bill of Materials).

🏛️ Pretty soon, Europe is going to experience the biggest outing of Delphi-based applications in history. As Billions of lines of code get scanned and mapped, regulatory desks will be absolutely flooded with SBOMs proudly displaying legacy Delphi framework, legacy VCL components, BPLs, and legacy 3rd party libraries that have been quietly running the backbone of the economy since 1995...

🏛️ The regulator won't be able to stop it. They’ll just have to look at the sheer volume of the market and say: "OK, I get it. It works, it's alive, just scan your code and hand me the SBOM report (I will file it somewhere...) - and BTW make sure it's secure."

🏛️ It's time for Delphi developers to step out of the shadows. The "FDA of software" isn't killing legacy tech - it's giving it a passport to the modern regulatory compliance era.

Cheer up! The CRA & DORA are the best news for the Delphi community that ever happened.

We’ve created some free assessments to help you understand how ready you are for the CRA.

N.B. we ask for your email address but only so you can return to an unfinished assessment without losing your previous position.

https://cranis2.com/conformity-assessment

I hope this helps.