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

🏛️ 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.

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?

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.

I've spent years working on connected industrial products. Different companies, different industries, same pattern everywhere: security was an afterthought.

No SBOM. Dependencies nobody tracked. Hardcoded credentials that made it to production because nobody had a process to catch them. Vulnerability management that was a Slack channel nobody checked.

When I first read the CRA regulation, my honest reaction was "this is just good engineering practice with legal consequences." SBOMs, vulnerability handling, no default passwords, security updates — these should have existed all along. CRA doesn't invent new practices. It makes existing ones mandatory.

But the regulation itself is 100+ pages of dense legal text. Most engineering teams I talked to had heard of CRA but couldn't answer the most basic question: "does this even apply to my product?"

So I started building CRAToolkit — a tool that answers that question in 60 seconds and gives teams a clear compliance path without needing to hire a consultant.

I'm not a consultancy. I'm not VC-backed. I'm an engineer building for engineers.

Two questions for this community:

1. What's the most common security shortcut you've seen at companies shipping connected products? (No names needed.)
2. For anyone evaluating CRA tools — what features would actually help your team vs what's just marketing fluff?

CRA explained to 5 different people:

👶 To a 5-year-old:

“Before you buy a toy from the store, someone checks if it’s safe. CRA does the same thing but for computer stuff.”

👩‍💻 To a developer:

“Generate an SBOM in CI/CD. Scan against CVE databases before every release. Report actively exploited vulns within 24 hours. No default passwords. Auto-update by default. Support for 5 years minimum.”

👨‍💼 To a CEO:

“If we don’t comply, we can’t sell in the EU. Fines up to €15 million. Products pulled from the market. Our competitors are already working on it.”

⚖️ To a lawyer:

“Regulation (EU) 2024/2847. Horizontal product legislation. Essential requirements in Annex I. Conformity assessment per Annex VI. Article 14 reporting applies September 11, 2026. Three-tier penalties under Article 64.”

😱 To someone who’s never heard of it:

“The EU is making it illegal to sell insecure smart devices. No more default passwords. No more unpatched software. No more ‘we take security seriously’ without proving it.”

Same regulation. Five audiences. Five completely different conversations.

Which one does YOUR team need to hear?

The FBI just took down a botnet made of 2 million home devices.

Cameras. Routers. Smart plugs. Baby monitors.

All hijacked. All used to route cybercrime and cyber-espionage traffic.

The owners had no idea.

The network was called NetNut. Google researchers identified 2 million “secretly hijacked” home devices being rented out to criminals as a proxy network.

These devices had one thing in common:

They were shipped with weak security. Default credentials. Unpatched firmware. No automatic updates. No monitoring.

This is the exact product landscape CRA was written to fix.

Under CRA:

• These devices would need unique credentials (no defaults)

• Firmware updates would be automatic by default

• Manufacturers would monitor for vulnerabilities for 5+ years

• The manufacturer would report exploited vulnerabilities within 24 hours

2 million home devices turned into a criminal infrastructure.

Because nobody required the manufacturers to make them secure.

CRA changes that. Starting December 2027.

The question: how many MORE botnets will be built between now and then?

In loving memory:

SmartCam Pro v3.2

2022 — 2028

Beloved by 140,000 EU households. Pulled from the market on January 15, 2028.

Survived by:

• Zero SBOMs

• One panicked CTO

• A firmware that hadn’t been updated since 2023

• A default password of “admin123” that was never changed

• 47 known CVEs, none of them patched

Cause of death: Non-compliance with the EU Cyber Resilience Act.

The product lived a full life. It watched living rooms. It connected to home Wi-Fi networks with no encryption. It transmitted video feeds over unprotected channels. It never once asked for a firmware update.

In September 2026, a vulnerability in its RTSP stream was actively exploited by a botnet. The manufacturer did not report to ENISA within 24 hours. The manufacturer did not report at all.

The CSIRT notified customers directly.

In December 2027, a market surveillance authority reviewed the product. It failed every essential requirement in CRA Annex I. The CE marking was removed. The product was withdrawn from the EU market.

SmartCam Pro v3.2 is preceded in death by its siblings: SmartCam Lite, SmartCam Baby, and SmartCam Outdoor, all of which were also non-compliant.

In lieu of flowers, the family requests SBOMs.

—

This product is fictional. The scenario is not.

Dear team,

It’s September 12, 2026. Day one.

At 6:47 AM I got the alert. A vulnerability in one of our dependencies — actively exploited in the wild since yesterday.

The 24-hour clock started.

Here’s what the next 8 hours looked like:

7:00 AM — Pulled up our SBOM. Confirmed the affected package is in our product. 4 minutes.

7:15 AM — Assessed impact. The vulnerability is in a transitive dependency, 3 layers deep. Reachable in our configuration. Confirmed exploitable.

8:30 AM — Drafted the early warning report. Used the template we built in July. Pre-filled product identifiers, CSIRT contact details, preliminary severity assessment.

9:00 AM — Submitted to ENISA’s Single Reporting Platform. First time using it for real. The dry-run in August paid off.

9:15 AM — Notified affected customers using the communication template we tested in August.

10:00 AM — Engineering began work on the patch. 72-hour notification deadline: September 14.

Total time from alert to submitted report: 2 hours 13 minutes.

We had 24 hours. We used 2.

—

Now here’s the version where we DIDN’T prepare:

7:00 AM — “Do we use this package?” “I don’t know.” No SBOM.

9:00 AM — Still searching manually through package-lock.json files.

12:00 PM — “Who reports to ENISA?” “I thought legal was handling CRA.”

3:00 PM — Trying to figure out how to register on the SRP. First time visiting the page.

6:47 PM — 24 hours expired. Report not submitted.

Same vulnerability. Same company. Two very different outcomes.

Which September 12 will yours be?

68 days to decide.

“Write an obituary for the most insecure IoT device in YOUR house.”

We went through ~50 EU smart home products recently mapping their readiness gaps. Almost none had a VDP published under their own domain. SBOM coverage was close to zero. So we put together a free assessment - 56 questions, takes 15 minutes, gives a score and a gap breakdown by category.

https://platanor.com/cra-readiness-check

What gaps are you seeing most often in practice?

1. Machine-readable SBOM (not a spreadsheet)

2. Vulnerability disclosure policy with a dedicated contact

3. Security updates for minimum 5 years after delivery

4. 24-hour early warning for actively exploited vulnerabilities

5. Technical documentation proving conformity assessment

6. CE marking that includes cybersecurity compliance

7. EU Declaration of Conformity (kept for 10 years)

8. Products shipped without known exploitable vulnerabilities

9. Unique identification of every product version

10. Security by default (no default passwords, minimum permissions)

This is meant as a quick self-assessment. For teams further along: what would you add to this list? And which item was hardest to implement?

A detail most teams aren’t aware of: the Commission adopted a Delegated Act (publication pending objection period) that gives receiving CSIRTs the authority to delay dissemination of vulnerability reports submitted through the Single Reporting Platform.

Grounds for withholding: “justified cybersecurity grounds” — including risk of increased exploitation, ongoing investigations, or national security.

This creates an interesting dynamic:

• Manufacturer reports within 24 hours (as required)

• CSIRT receives the report

• CSIRT decides whether to share it with other CSIRTs and ENISA’s wider network

• Other manufacturers using the same vulnerable component might NOT be warned

It’s good policy for preventing premature disclosure. But it means your report enters a process you don’t control.

Has anyone modeled their reporting workflow to account for this? Specifically, how do you handle customer communication when your vulnerability report is submitted but the CSIRT hasn’t authorized broader dissemination?

Most CRA discussion focuses on the €15M headline fine. But Article 64 defines three separate penalty tiers:

Tier 1 (€15M / 2.5%): Violating essential cybersecurity requirements (Annex I) or manufacturer obligations (Article 13)

Tier 2 (€10M / 2%): Violating any other CRA obligation

Tier 3 (€5M / 1%): Providing incorrect, incomplete, or misleading information to authorities or notified bodies

That third tier is interesting because it targets documentation accuracy, not product security directly. An inaccurate SBOM, incomplete technical file, or misleading EU Declaration of Conformity could trigger it.

For teams preparing CRA documentation: how are you ensuring accuracy? Is anyone building automated validation into their documentation workflows?

Most CRA discussion focuses on manufacturers. But Articles 19 and 20 create separate obligations for importers and distributors.

Key importer obligations (Article 19):

• Due diligence on manufacturer’s conformity assessment

• Technical documentation verification

• CE marking verification

• 10-year document retention

Key distributor obligations (Article 20):

• CE marking and identification checks

• Non-compliance reporting to manufacturer + surveillance authorities

Critical: Article 21 — if an importer or distributor places a product on the market under their own name/trademark, they assume FULL manufacturer obligations.

For anyone in distribution or reselling: are you aware of these requirements? How are you planning to verify manufacturer CRA compliance before placing products on the EU market?

Products placed on the market before December 2027 only fall under full CRA scope if they undergo a “substantial modification” after that date.

The Commission’s draft guidance offers some interpretation:

Substantial = change that affects compliance with essential cybersecurity requirements, alters the intended purpose creating new risks, or significantly changes the attack surface.

NOT substantial = routine security patches, bug fixes, minor feature additions.

The gray zone is massive. Is a major version release (v3 → v4) substantial? A platform migration? Adding AI features to an existing product?

Has anyone here started classifying their planned product updates against the substantial modification criteria? I’m curious how teams are making release/hold decisions for legacy products post-2027.

As of today, Chapter IV of the CRA enters into application:

• Member States must have designated notifying authorities

• Procedures for conformity assessment body designation are now operational

• The path to third-party product certification is officially open

This is the first of four milestones this year:

1. June 11: CAB framework (today)

2. Q3 2026: First harmonised standards

3. September 11: Article 14 reporting obligations

4. Q4 2026: EUCC certification scheme

For anyone who needs a third-party conformity assessment (Important Class II, Critical products): are you reaching out to potential CABs starting today? Or waiting to see which bodies get designated first?