💡 Unknown / Not sure is always an option — it will be flagged as an information gap. Fields marked * are required.
✓ Saved
Section A
Tell us about the product
We'll start with the basics — what the product is and how it's classified under the CRA. This anchors the entire risk assessment.
Product name *
Version(s) covered
i
Specify which firmware or software version(s) this assessment applies to. e.g. v1.0 or v1.0–v1.4
CRA product category *
Product type *
Section B
Intended use & users
Article 13(3) requires the risk assessment to be grounded in the product's intended purpose and who uses it. This shapes the entire threat model.
What does the product do? *
Who are the intended users?
Where is the product typically deployed?
Expected product lifetime *
Section C
Reasonably foreseeable misuse
Article 13(3) explicitly requires the assessment to cover not just intended use, but how the product could be misused — even unintentionally.
Could the product be used in a higher-risk environment than intended?
i
e.g. A consumer smart plug deployed in an industrial facility to control heavy machinery
Could an attacker use this product to access other systems on the same network?
Are there functions that could cause harm if exploited?
i
e.g. A remote unlock function triggered by an attacker to enable unauthorised physical access to a building
Could a non-technical user accidentally disable or bypass security features?
Section D
Connectivity & environment
Article 13(3) and Annex I §3(h) — the risk assessment must reflect actual conditions of use and map what an attacker could target.
Which network types does the product connect to?
Which external interfaces does the product expose?
Is any interface exposed to the public internet?
Does the product expose a remote management interface?
i
e.g. SSH, Telnet, web admin panel, cloud management console, SNMP
Does the product operate in a safety-critical environment?
i
e.g. Healthcare monitoring, industrial automation, vehicle control, water treatment
Who can physically access the device?
Section F
Data & assets
Article 13(3) requires identification of assets to be protected. The type of data handled determines the severity of a breach and which Annex I controls apply.
What data does the product process or store?
Where is data stored?
Is data transmitted to other systems?
i
e.g. Sensor readings sent to cloud every 60s over MQTT; access logs synced to mobile app over TLS
Is data encrypted in transit and at rest?
i
Annex I §3(e) requires products to protect data through encryption. In transit = data moving over a network (e.g. TLS). At rest = data stored on the device or in the cloud.
Are there high-value assets that would cause serious harm if compromised?
i
e.g. Master encryption keys, user location history, industrial control commands, medical records
Section G
Authentication & access control
Annex I §3(a)(b) — products must be secure by default and protect against unauthorised access. One of the most frequently audited areas under CRA.
How do users authenticate to use the product?
How are default credentials handled?
Is access control enforced between different user roles?
i
e.g. Separate admin and end-user roles, operator vs. read-only access, privilege separation
Are there any unauthenticated functions or interfaces?
i
e.g. Open Telnet port, public status page, unauthenticated device discovery broadcast
Section H
Availability & resilience
Annex I §3(f) — products must protect the availability of essential functions, including resilience against denial of service attacks.
Are there functions that must remain available at all times?
i
e.g. Emergency stop, alarm trigger, medical monitoring, door lock release, safety shutoff
What is the impact if the product becomes unavailable?
Is the product protected against denial of service attacks?
Does the product have a fail-safe mode if connectivity is lost?
i
e.g. Defaults to locked state if cloud connection drops; local override available; cached last-known-good config
Section I
Security logging & monitoring
Annex I §3(j) — products must record relevant internal activity, including access to or modification of data, services or functions.
Does the product log security-relevant events?
Which events are logged?
Are logs protected against tampering or deletion?
i
e.g. Logs stored on remote server, cryptographically signed, write-once storage media
Are logs accessible for security monitoring?
Section J
Updates & patch management
Annex I §3(k) and Part II §2,7 — products must support security updates, and manufacturers must have a timely, defined patch process.
How does the product receive software or firmware updates?
Are security updates delivered separately from feature updates?
i
The CRA recommends separating security patches from feature releases where feasible, to allow faster deployment of critical fixes
Are updates cryptographically signed and verified before installation?
i
e.g. RSA or ECDSA signature verified by the device before applying the firmware update
Is there a defined process for releasing security patches?
i
e.g. Internal triage within 24h, patch released within 30 days, critical patches within 72h
Final Step
Review & generate
Check your answers below, then click Generate. Claude will produce a full CRA-aligned risk assessment using the ISO 27005 methodology — this takes about 20–40 seconds.
Generating your CRA risk assessment — hang tight…
Draft Risk Assessment Report
🔒 Demo report locked. This is the saved demo output — the same report will appear every time you run the demo.
⚠️ Professional review required. This is a first-draft working document generated by AI based on the information provided. It must be reviewed and validated by a qualified cybersecurity professional before use in regulatory submissions, technical documentation, or client delivery. The consultant remains responsible for the accuracy and completeness of the final document.