Launching today
CRA Readiness Check
Is your IoT product ready for the EU Cyber Resilience Act?
11 followers
Is your IoT product ready for the EU Cyber Resilience Act?
11 followers
Free readiness check that guides IoT device manufacturers through EU Cyber Resilience Act requirements. Start with a 2-minute scope check, then get a full assessment with every question mapped to the exact CRA article or annex. Walk away with a prioritized action plan and PDF report - no signup required.
@artem_sulyma What the CRA Readiness Check shows: 34% readiness - let's break down this report
A company with 6-20 models on the market, mandatory radio interfaces, personal data processing, and a product lifecycle of 5+ years. Result: 34% CRA readiness, 40 action items, of which 7 are critical with a deadline already in September 2026.
Distribution by domains:
CRA Scope & Classification - 88%
Conformity Assessment & Documentation - 58%
Awareness & Readiness - 50%
Supply Chain Security - 40%
Security by Default & Design - 33%
Post-Market Obligations - 20%
Secure Development Lifecycle - 17%
Vulnerability Management - 13%
The pattern is typical: companies know well that CRA applies to them (88%), but fail specifically where architecture is required. What to pay attention to in each failing domain:
Vulnerability Management (most often the weakest domain). Here it's not just "writing a policy," but building a working process: intake within 5 business days, triage by CVSS v4.0, patch SLAs (for example, critical/exploited - 7 days). If you're only offered a CVD-policy document without a process behind it - that's half the work. The deadline here is tight: Art. 14 (24/72 hours for reporting exploited vulnerabilities) starts already in September 2026.
Secure Development Lifecycle. Your team actually works with the stack and embeds threat modeling and CVE scanning directly into CI/CD - not adding it as a separate audit stage once a year.
Post-Market Obligations. This is not just "releasing a patch," but proactive notification of users simultaneously with the release (Annex I Part II §6) and a public EoL policy with 12 months' advance notice (Art. 13(9)).
Security by Default & Design. Hardware Root of Trust, Secure Boot, encryption of data at rest using keys derived from the hardware root of trust, certificate-based device identity (mTLS/X.509). Check whether your team offers exactly the hardware implementation, not just a recommendation to "add encryption" without a concrete design.
Supply Chain Security. SBOM in SPDX/CycloneDX with real PURL/CPE identifiers, VEX data, automated licence scanning in the pipeline. If the SBOM is issued as a one-time PDF report rather than as part of the build process - it will not pass the currency check at the next audit.
Conformity Assessment & Documentation. The technical file (Art. 31) requires months of work and input from design, engineering, testing, and risk assessment simultaneously. Your team must be able to coordinate this as a single track, rather than passing you from one contractor to another.
The main conclusion from such reports remains constant: the gap is always greater in the technical architecture than in understanding of the regulation. Companies know that CRA exists - the question is whether your team is capable of closing exactly the architectural gaps.
Please feel free to comment below, send me a direct message, or share this post with colleagues who may be interested.