CRA readiness check

How securely do your devices log in, and how safe are your updates?

The Cyber Resilience Act sets requirements for every connected product sold in the EU. From 11 December 2027, every product you place on the market must comply. These questions show where your IoT device stands. Your answers stay in your browser, unless you request the improvement guide.

1. Connection and identity

How does your device log in to the server or message broker, and how do both sides know the other one is genuine?

1.1 How does the device log in to the backend or message broker?

CRA Annex I, Part I (2)(d)

1.2 Do all devices share the same credentials, or does each have its own?

CRA Annex I, Part I (2)(d)

1.3 How does the device check that it is talking to the real server?

CRA Annex I, Part I (2)(d), (2)(e), (2)(f)

1.4 How does the backend or broker verify the credentials?

CRA Annex I, Part I (2)(d)

1.5 What can a logged-in device access?

CRA Annex I, Part I (2)(d), (2)(j)

1.6 Can you lock out a single stolen or hacked device?

CRA Annex I, Part I (2)(d)

2. Keys and credentials

Where do the secrets come from, where are they kept and who can get to them?

2.1 Where are the credentials stored on the device?

CRA Annex I, Part I (2)(e), (2)(j)

2.2 How and where are the per-device credentials created?

CRA Annex I, Part I (2)(d), (2)(e)

2.3 Where is the master key (CA key or password list) kept, and who can get to it?

CRA Annex I, Part I (2)(d), (2)(f)

2.4 What can someone with physical access do through the debug or serial port?

CRA Annex I, Part I (2)(j)

3. Firmware updates

Can you roll out a new version safely and in a controlled way, also when something goes wrong?

3.1 How is a firmware update rolled out?

CRA Annex I, Part I (2)(c), Part II (7)

3.2 How does the device check that an update really comes from you?

CRA Annex I, Part I (2)(f), Part II (7)

3.3 Where is the key used to sign updates kept?

CRA Annex I, Part I (2)(f)

3.4 What happens when an update is interrupted halfway, for example by a power cut?

CRA Annex I, Part I (2)(h)

3.5 Can an older, signed version be installed again?

CRA Annex I, Part I (2)(a), (2)(f)

3.6 Do you know which firmware version each device in the field runs?

CRA Annex I, Part II (2), (8)

4. Product and process

The CRA is not only about technology. Your default settings, your component list and how you deal with vulnerabilities count too.

4.1 Does the device have a local interface (web page, wifi hotspot, app) with a default password?

CRA Annex I, Part I (2)(b)

4.2 Do you have a list of all software components and their versions (SBOM)?

CRA Annex I, Part II (1)

4.3 How do you find out about a vulnerability in your product or the components it uses?

CRA Annex I, Part I (2)(a), Part II (2), (4), (5), (6)

4.4 Can you report an actively exploited vulnerability or a severe incident to the CSIRT and ENISA within 24 hours?

CRA Art. 14, Art. 69(3)

4.5 How long will you deliver security updates for this product?

CRA Art. 13(8), Annex II (7)

4.6 Does the device record security events, like failed logins or rejected updates?

CRA Annex I, Part I (2)(g), (2)(l)

Your result

0 / 0 answered

    • In order
    • Could be better
    • Risk
    • Unknown

    Points of attention

      Want to know how to improve each point? Request our improvement guide.

      Request the improvement guide Get in touch

      A first indication, not legal advice or a conformity assessment.

      Request the improvement guide

      The guide explains for each question why it matters and how to improve it. Your answers are sent along with your request.

      We only use your details for this request.

      Example: from one password to a passport per device

      A device can work perfectly and still score red on almost every question above. A common unsafe setup next to a safe one:

      Unsafe Safe
      Login Username and password Own X.509 certificate, mutual TLS
      Per device One password for every device Every device its own key and certificate
      Broker check Compare the password Certificate must be signed by your own CA. The device only sees its own topics
      Rollout Every device polls one URL and installs at the same time The server sends the update per device
      Update authenticity Not checked The bootloader checks the signature and refuses older versions

      How the safe setup works is explained in Securely managing hundreds of IoT devices remotely. These building blocks come standard with sensor-link.