iotpentest
Map a device

RED · EN 18031 · CRA

IoT penetration testing, from the board up

Six exposures decide how a connected product gets attacked: debug ports, radios, the update path, the companion app, the cloud service and the on-device interface. This is what a tester does to each, and which EU obligation it answers to.

Scope a device test Map your attack surface
  • Primary sources only
  • No vendor telemetry claims
  • Reviewed September 2026
Device under test · interface log
RefInterfaceRailRoleBench action
J1 UART 3V3 console shell probed
J2 SWD 1V8 debug lock bits read
U4 SPI NOR 3V3 firmware image dumped
RF1 BLE 5.x 2G4 pairing exchange captured
RF2 WI-FI 2G4 provisioning rogue AP joined
N1 MQTT :8883 fleet tenants crossed

An illustrative log, not a specific product. Every device presents a different set of rows; the columns are always the same.

Where the law stands today

The compliance window is open right now

Two regimes overlap. The Radio Equipment Directive cybersecurity requirements bind wireless product placed on the EU market today. The Cyber Resilience Act takes over in December 2027, and its reporting duties are already running.

  1. RED Article 3(3)(d), (e) and (f)

    Switched on for internet-connected, data-processing, childcare, toy, wearable and money-transfer radio equipment by Delegated Regulation (EU) 2022/30, after (EU) 2023/2444 moved the date from 2024.

    In force

  2. CRA Chapter IV

    Notification of conformity assessment bodies begins, so notified bodies can be designated before the substantive duties bite.

    In force

  3. CRA Article 14

    Actively exploited vulnerabilities and severe incidents must be reported to ENISA and the coordinating CSIRT on 24-hour, 72-hour and final-report clocks. Article 69(3) extends this to products already on the market.

    Live now

  4. CRA in full · RED repeal

    Annex I, CE marking and conformity assessment apply. Delegated Regulation (EU) 2022/30 is repealed the same day by Delegated Regulation (EU) 2026/339.

    Scheduled

The repeal is not an amnesty. Recital 5 of Delegated Regulation (EU) 2026/339 records that it does not affect market surveillance of Article 3(3)(d), (e) and (f) compliance for radio equipment placed on the Union market between 1 August 2025 and 10 December 2027. Primary texts: CELEX 32026R0339 and Regulation (EU) 2024/2847.

Definition

A hardware test that happens to have software in it

IoT and embedded penetration testing assesses a physical product and everything it talks to, against real units on a bench rather than against a diagram.

IoT and embedded penetration testing is an authorised assessment of a connected product carried out on physical samples: the board and its debug interfaces, the firmware image, the radio links, the companion application and the cloud service the device depends on. The output is evidence about one hardware and firmware revision, not a report on an IP range.

It exists because a product is a supply route. A device sits inside somebody else’s network, holds long-lived credentials, accepts code from its manufacturer and often keeps running for a decade. The advisory that fourteen agencies published in April 2026 puts the failure mode plainly: the edge devices absorbed into covert networks were vulnerable because they were end of life, out of date and no longer receiving updates or security patches from their manufacturers.

European law has written that expectation down. The RED cybersecurity requirements have bound wireless products placed on the EU market since 1 August 2025, and Annex I of the Cyber Resilience Act obliges manufacturers to apply effective and regular tests and reviews of the security of the product across a support period of at least five years.

So testing is no longer a pre-launch formality. It is a repeating obligation attached to a product line, and its findings now have to be legible to a market surveillance authority and a notified body as well as to an engineer.

Interactive

Device attack surface mapper

Select what your device exposes. You get the test areas that apply, the bench work behind each one, and the instrument that drives it.

What does the device expose?

Tick what is present on a production unit rather than on the development board. Two are selected to start.

Bench readout

Test areas
2
Indicative bench days
5–10

2 of 6 exposures selected. Indicative bench time 5–10 days.

Day bands are indicative and exclude reporting, retesting and travel. They assume one hardware revision and one firmware build. Overlapping areas share setup, so a combined engagement usually lands nearer the lower figure, and no tool can scope a product from six checkboxes.

  1. Board-level access

    UARTJTAGSWDSPII2C

    What a tester does

    1. Open the enclosure, map test points and populate headers, then find a live serial console with a logic analyser and confirm its baud rate.
    2. Attempt bootloader and shell access over that console: interrupted U-Boot, a root prompt with no password, or a diagnostic menu that survived production.
    3. Enumerate the JTAG/SWD scan chain and read back the read-out protection and debug-lock fuses to check whether they were actually blown on the production line rather than only in the design.
    4. Clip onto or desolder the SPI/eMMC flash and dump the image without the main processor, which also proves whether flash encryption is real.

    What drives it

    • ETSI EN 303 645 5.6-3 and 5.6-4: hardware should not unnecessarily expose physical interfaces, and an accessible debug interface shall be disabled in software
    • CRA Annex I Part I point (2)(j): products shall be designed to limit attack surfaces, including external interfaces
    • CRA Annex I Part I point (2)(d): protection from unauthorised access by appropriate control mechanisms

    A live console or an unlocked scan chain is the fastest route to your firmware, and it is the finding a market surveillance authority can reproduce with a USB adapter.

  2. Radio and pairing

    WI-FIBLE802.15.4LORALTE-M

    What a tester does

    1. Capture the provisioning and pairing exchange with a protocol sniffer or SDR and check whether the session key is derived, fixed in firmware, or simply sent in the clear.
    2. Walk the BLE GATT table for characteristics that read or write configuration, credentials or firmware control without authentication or bonding.
    3. Replay and fuzz the link layer: malformed frames, out-of-order association, and a forced downgrade to a weaker pairing mode such as Just Works.
    4. Stand up a rogue network with the same SSID or PAN ID and see whether the device joins it and hands over anything before it authenticates the peer.

    What drives it

    • RED Article 3(3)(d) applied to internet-connected radio equipment by Delegated Regulation (EU) 2022/30, Article 1(1): the equipment must not harm the network or misuse network resources
    • RED Article 3(3)(e) applied by Delegated Regulation (EU) 2022/30, Article 1(2) to equipment processing personal, traffic or location data, and supported by EN 18031-2:2024
    • ETSI EN 303 645 5.5 Communicate securely

    Radio findings usually land on the RED file first, because the wireless interface is the thing that made the product radio equipment in the first place.

Have OffSeq scope this against your product

Interactive mode is not available. You can read the full reference content below. No answers are assessed and no result is calculated.

The mapper needs JavaScript. The complete reference is below: the six exposures a connected product presents, the bench work each one implies, and the instrument that drives it.

  • J1 · Board-level access – Physical debug ports

    Headers, test pads or a service connector reachable inside the enclosure. Interfaces: UART, JTAG, SWD, SPI, I2C.

    What a tester does: Open the enclosure, map test points and populate headers, then find a live serial console with a logic analyser and confirm its baud rate. Attempt bootloader and shell access over that console: interrupted U-Boot, a root prompt with no password, or a diagnostic menu that survived production. Enumerate the JTAG/SWD scan chain and read back the read-out protection and debug-lock fuses to check whether they were actually blown on the production line rather than only in the design. Clip onto or desolder the SPI/eMMC flash and dump the image without the main processor, which also proves whether flash encryption is real.

    What drives it: ETSI EN 303 645 – 5.6-3 and 5.6-4: hardware should not unnecessarily expose physical interfaces, and an accessible debug interface shall be disabled in software; CRA Annex I Part I – point (2)(j): products shall be designed to limit attack surfaces, including external interfaces; CRA Annex I Part I – point (2)(d): protection from unauthorised access by appropriate control mechanisms.

    A live console or an unlocked scan chain is the fastest route to your firmware, and it is the finding a market surveillance authority can reproduce with a USB adapter. Indicative bench time 2–4 days.

  • RF1 · Radio and pairing – Wireless radios

    Wi-Fi, Bluetooth LE, 802.15.4 / Zigbee / Thread, LoRaWAN or cellular. Interfaces: WI-FI, BLE, 802.15.4, LORA, LTE-M.

    What a tester does: Capture the provisioning and pairing exchange with a protocol sniffer or SDR and check whether the session key is derived, fixed in firmware, or simply sent in the clear. Walk the BLE GATT table for characteristics that read or write configuration, credentials or firmware control without authentication or bonding. Replay and fuzz the link layer: malformed frames, out-of-order association, and a forced downgrade to a weaker pairing mode such as Just Works. Stand up a rogue network with the same SSID or PAN ID and see whether the device joins it and hands over anything before it authenticates the peer.

    What drives it: RED Article 3(3)(d) – applied to internet-connected radio equipment by Delegated Regulation (EU) 2022/30, Article 1(1): the equipment must not harm the network or misuse network resources; RED Article 3(3)(e) – applied by Delegated Regulation (EU) 2022/30, Article 1(2) to equipment processing personal, traffic or location data, and supported by EN 18031-2:2024; ETSI EN 303 645 – 5.5 Communicate securely.

    Radio findings usually land on the RED file first, because the wireless interface is the thing that made the product radio equipment in the first place. Indicative bench time 3–6 days.

  • TP4 · Firmware and update chain – Firmware update path

    Over-the-air updates, a USB or SD image, or a vendor flashing tool. Interfaces: OTA, A/B SLOT, SIGNING.

    What a tester does: Recover the update image and check whether it is encrypted at rest, and whether the signature is verified before it is written or only after the device has already flashed it. Attempt a downgrade to a known-vulnerable earlier build and confirm whether anti-rollback counters are enforced in the bootloader or merely advertised. Intercept the update channel: certificate pinning, hostname validation, and whether an unsigned image served over a valid TLS session is accepted. Unpack the filesystem and grep the result for hard-coded keys, private certificates, service accounts, debug users and build tooling that shipped by accident.

    What drives it: CRA Annex I Part I – point (2)(c): vulnerabilities addressable through security updates, and point (2)(f): integrity of programs and configuration against unauthorised modification; CRA Annex I Part II – points (1), (7) and (8): a machine-readable SBOM, secure update distribution and updates disseminated without delay; CRA Article 13(8) – the support period shall be at least five years, and vulnerability handling runs for the whole of it.

    An update path that cannot be trusted turns every future fix into a new attack, which is why the CRA regulates the mechanism and not only the patch. Indicative bench time 3–5 days.

  • APP · Companion application – Companion mobile app

    An Android or iOS app that provisions, controls or monitors the device. Interfaces: ANDROID, IOS, BLE BRIDGE.

    What a tester does: Decompile the shipped package and pull out the API hosts, static keys and provisioning secrets that every customer is carrying around. Test the local control bridge: whether another application on the same phone, or a second user’s phone, can drive the device without being enrolled. Check that authorisation is enforced server-side rather than in the interface: change the device identifier in a request and see whose hardware answers. Inspect what the app leaves unencrypted on the handset, including tokens, Wi-Fi pre-shared keys, camera thumbnails and location history.

    What drives it: RED Article 3(3)(e) – safeguards for the personal data and privacy of the user and subscriber, applied by Delegated Regulation (EU) 2022/30; CRA Annex I Part I – point (2)(d) access control, point (2)(e) confidentiality of processed data and point (2)(g) data minimisation; ETSI EN 303 645 – 5.8 Ensure that personal data is secure, and clause 6, the data protection provisions for consumer IoT.

    The app is part of the product for conformity purposes; a secret shipped in it is a secret shipped in every unit you sold. Indicative bench time 2–4 days.

  • API · Cloud and fleet control – Cloud API or fleet backend

    The service the device talks to: MQTT, REST, a fleet console or an OTA server. Interfaces: MQTT, HTTPS, REST.

    What a tester does: Establish how a device authenticates itself upstream: a per-device certificate, a shared secret compiled into every unit, or a serial number anyone can guess. Test tenant isolation on the broker and the API by subscribing to another owner’s topic tree or reading another owner’s telemetry. Exercise the claim and transfer flow: whether a device can be re-registered while it is still bound to its previous owner, and what the previous owner keeps. Probe the fleet-management surface for mass actions, because bulk firmware push, bulk reboot and bulk configuration write are the highest-impact functions you own.

    What drives it: CRA Annex I Part I – point (2)(d) access control, point (2)(h) availability of essential functions after an incident, and point (2)(i) not degrading other devices or networks; RED Article 3(3)(d) – the equipment must not harm the network or its functioning nor misuse network resources; IEC 62443-4-2:2019 – the foundational requirements for use control (UC) and restricted data flow (RDF) where the fleet is industrial.

    A fleet console is a single point from which every unit you have ever shipped can be reached, and it is rarely tested at the same depth as the device. Indicative bench time 3–5 days.

  • HTTP · On-device interface – Local web or management UI

    An on-device configuration page reachable over the LAN or a soft access point. Interfaces: HTTP, HTTPS, CGI.

    What a tester does: Run the first-boot flow as a customer would and establish whether a password is genuinely mandatory or whether the device can be left with no credential at all. Attack the embedded HTTP stack directly: command injection in CGI handlers, traversal into the configuration store, and request-parser behaviour on oversized or malformed input. Check session handling for predictable tokens and missing cross-site request forgery protection, and confirm that the LAN interface is not answering on the WAN side. Hunt the endpoints that were never meant to ship: diagnostics pages, factory test menus and firmware upload handlers left in the production build.

    What drives it: EN 18031:2024 restriction – Implementing Decision (EU) 2025/138 removes the presumption of conformity where, applying clauses 6.2.5.1 and 6.2.5.2, the user is allowed not to set and use any password; ETSI EN 303 645 – 5.1-1: passwords shall be unique per device or defined by the user in any state other than the factory default; CRA Annex I Part I – point (2)(b) secure-by-default configuration and point (2)(j) limited attack surface.

    This is where the most expensive design decision usually hides: if the flow lets a user skip setting a password, the EN 18031 restriction applies and the RED file leaves self-declaration for an EU-type examination. Indicative bench time 2–4 days.

Day bands are indicative and exclude reporting, retesting and travel. They assume one hardware revision and one firmware build. Overlapping areas share setup, so a combined engagement usually lands nearer the lower figure, and no tool can scope a product from six checkboxes.

Method

The bench sequence

Six stages, run in this order because each one supplies the next. Firmware you have not extracted cannot be reviewed, and a radio protocol you have not decoded cannot be fuzzed.

  1. 01

    Scope and threat model

    Agree the sample count, the hardware and firmware revisions under test, the destructive work that is permitted, and which of the six exposures are in scope. Model who realistically attacks this product: a customer with a screwdriver, a neighbour with a radio, or an actor with the whole fleet in view.

    Output A written scope, a rules-of-engagement note and the risk assessment input the CRA expects under Article 13(2).

  2. 02

    Teardown and board access

    Photograph and annotate the board, identify the main processor, memories and radios, then find the interfaces that were left reachable: populated headers, unpopulated pads, test points and service connectors. Establish whether debug is locked in production or only in the datasheet.

    Output An annotated board map, a live interface list and a first answer on read-out protection.

  3. 03

    Firmware extraction and review

    Recover the image from flash, from an update package or over a debug interface, unpack the filesystem, and read what shipped: credentials, private keys, certificates, service accounts, third-party components and their versions. Compare the result against the software bill of materials, if one exists.

    Output An extracted image, a component inventory and the list of secrets that reached production.

  4. 04

    Radio and protocol work

    Capture provisioning and pairing, decode the link layer, and test what the device accepts: replayed frames, malformed frames, downgraded pairing modes and networks it should refuse to join. This is the stage where a wireless product usually acquires its RED findings.

    Output Captures, decoded exchanges and a verdict on key handling and peer authentication.

  5. 05

    App, API and fleet

    Test the companion application, the device-to-cloud authentication and the fleet management surface as one system, because a device identity that can be forged upstream defeats everything done on the board. Tenant isolation and the claim and transfer flow are tested with two accounts, not one.

    Output Findings against the app, the API and the fleet console, with the blast radius stated in units.

  6. 06

    Report, retest and evidence

    Write findings that an engineer can reproduce and an assessor can rely on: exact revision, exact interface, exact steps. Map each finding to the requirement it fails so the file is usable in a conformity assessment. Retest the fixes on the same revision.

    Output A reproducible report, a requirement mapping and a retest note against the shipped build.

Public methodology for the device layers is available from the OWASP IoT Security Testing Guide and the OWASP IoT Security Verification Standard. For industrial equipment the verification and validation practice sits inside IEC 62443-4-1:2018.

Evidence

Why anyone bothers

Four figures, each from the document that published it. Nothing here is a vendor estimate.

200,000+
devices worldwide infected in 2024 by the Raptor Train network, built from SOHO routers, web cameras, video recorders, firewalls and NAS units
CISA and 13 partners, advisory AA26-113A, 2026
10,000+
IP cameras targeted in one GRU campaign, from the sample available to the authoring agencies; 81% of attempts were against cameras in Ukraine
NSA, FBI and partners, advisory AA25-141A, 2025
4,875
incidents analysed across the EU between 1 July 2024 and 30 June 2025
ENISA Threat Landscape 2025
5 years
minimum CRA support period, during which vulnerabilities must be handled and the product regularly tested
Regulation (EU) 2024/2847, Article 13(8)

Every figure above is quoted from the cited primary document. This site does not publish vendor telemetry percentages about how many connected devices are “vulnerable”, because they cannot be verified from a primary source.

Ledger

Which instrument drives which test

The same finding lands in different files depending on what the product is and where it is sold. This is the mapping that matters when a report has to survive an assessment.

Instruments, the products they apply to, what they oblige and what each means on the bench
InstrumentApplies toWhat it obligesWhat it means on the bench
RED cybersecurity requirementsDir. 2014/53/EU Art. 3(3)(d)(e)(f) · DR (EU) 2022/30 Internet-connected radio equipment; radio equipment processing personal, traffic or location data; childcare and toy radio equipment; wearables; equipment transferring money or virtual currency. Medical, aviation, vehicle and road-toll equipment are excluded by Article 2. No harm to the network or misuse of network resources; safeguards for personal data and privacy; features protecting from fraud. Applied to product placed on the market from 1 August 2025. Radio, network behaviour and data handling need evidence. Where harmonised standards are not applied in full, Article 17 pushes the file to EU-type examination or full quality assurance, and a notified body wants test results.
EN 18031-1, -2 and -3Cited by Implementing Decision (EU) 2025/138 The same categories, split by requirement: Part 1 for point (d), Part 2 for point (e), Part 3 for point (f). Presumption of conformity, but with restrictions. The citation withdraws that presumption where a user is allowed not to set and use any password, where parental or guardian access control is not ensured for the relevant child-facing classes, and for the rationale and guidance sections generally. Confirming the restriction on a real unit is cheap and decides the whole conformity route. It is usually the first thing to test and the last thing anyone documents.
Cyber Resilience Act, Annex IRegulation (EU) 2024/2847 · from 11 Dec 2027 Products with digital elements with a direct or indirect data connection. MDR and IVDR products, vehicles under (EU) 2019/2144, certified aviation products, marine equipment and identical spare parts are out of scope. Part I: no known exploitable vulnerabilities at market placement, secure default configuration, access control, confidentiality and integrity, minimised attack surface including external interfaces. Part II: SBOM, coordinated vulnerability disclosure, secure updates and effective and regular tests and reviews. Every Annex I point is a testable claim, and the technical documentation must justify any point the manufacturer treats as not applicable.
CRA important productsAnnex III, Art. 32 · Impl. Reg. (EU) 2025/2392 Class I includes routers, modems and switches, wireless access points, network interfaces, security-relevant microprocessors and microcontrollers, smart home security products, connected toys and health or child wearables. Class II includes tamper-resistant microcontrollers and firewalls. Class I with only partial harmonised-standard coverage, and every Class II product, must use EU-type examination plus production control, or full quality assurance. Self-declaration is not available. A notified body will read your evidence rather than your intentions. Independent test results are the shortest route through module B.
CRA reportingArticle 14 · live since 11 Sep 2026 All in-scope manufacturers, including for products placed on the market before December 2027. Early warning within 24 hours, a fuller notification within 72 hours, and a final report within 14 days of a fix for a vulnerability or one month for an incident, to ENISA and the coordinating CSIRT. The clock starts when you become aware. Testing that finds an exploited flaw before someone else does is the difference between a planned fix and a 24-hour filing.
ETSI EN 303 645V3.1.3 (2024-09) · not harmonised under the RED Consumer IoT. Referenced by UK PSTI for deemed compliance, and widely used in procurement. 13 provision areas, including no universal default passwords, a public vulnerability disclosure policy, keeping software updated and minimising exposed attack surfaces. Provisions 5.6-3 and 5.6-4 are the hardware ones: physical interfaces should not be unnecessarily exposed, and an accessible debug interface shall be disabled in software.
IEC 624434-1:2018, 4-2:2019 and 3-3:2013 Industrial automation and control systems: components, the systems built from them and their zones and conduits. A secure development lifecycle for the product (4-1) and technical component requirements against seven foundational requirements (4-2), expressed as capability security levels. Verification and validation is a named practice, so testing is part of the process evidence and not only of the product evidence.
UK PSTISI 2023/1007 · in force 29 Apr 2024 Relevant connectable products made available in the United Kingdom. Three requirements: passwords unique per product or set by the user, published information on how to report security issues, and information on the minimum security update period. A short verification against a real unit supports the statement of compliance, which manufacturers and importers must retain for ten years or the defined support period.

Cited from the instruments themselves. Full references are listed in each bench note, and the RED and CRA texts are linked from the compliance window above.

Output

What you actually receive

The report has two audiences: the engineer who has to fix it and the assessor who has to rely on it.

  • D1

    Annotated board map

    Photographs with every interface identified, its voltage rail and whether it was reachable on a production unit.

  • D2

    Reproducible findings

    Exact hardware and firmware revision, exact interface, exact steps, and the tooling used. A finding nobody can reproduce is an opinion.

  • D3

    Requirement mapping

    Each finding tied to the provision it fails: an Annex I point, a RED essential requirement, an EN 18031 clause or an EN 303 645 provision.

  • D4

    Firmware inventory

    Components and versions recovered from the image, checked against your software bill of materials where you have one.

  • D5

    Remediation guidance

    What to change in hardware, in firmware and in the build, separated so the hardware fixes can start on the next revision.

  • D6

    Retest note

    Verification against the shipped build, which is the artefact a conformity file or a customer questionnaire can point at.

Scoping

What moves the number

Embedded work is priced by what has to be defeated, not by an IP count. These are the factors that decide it.

Debug lock state
A locked scan chain and encrypted flash turn a two-day extraction into a research problem. An unlocked device is cheaper to test and far cheaper to attack.
Radio count and stack
One BLE profile is not the same as BLE plus Wi-Fi plus a proprietary sub-GHz link. Each stack brings its own capture setup and its own pairing logic.
Firmware availability
A published update image shortens the work considerably. A signed, encrypted, download-only image means the extraction happens on the bench.
Cloud and fleet scope
Testing tenant isolation needs at least two accounts and written authorisation from whoever operates the service, which is not always the manufacturer.
Sample count
Destructive work needs spare units. Chip-off and fault-injection assume the unit may not survive.
Conformity target
A file heading for a notified body needs more documented evidence than an internal assurance test on the same hardware.

Ask any provider for a scope in these terms. A fixed price offered before anyone has seen the board is a guess with a margin on it.

Reference

Bench notes

Long-form notes on the obligations behind the testing and how a device is taken apart. Sourced from the instruments themselves.

Questions

Frequently asked

The questions manufacturers, importers and operators ask before the first engagement.

Do the RED cybersecurity requirements still apply, now that the Cyber Resilience Act exists?
Yes, and they apply today. Delegated Regulation (EU) 2022/30 made Article 3(3)(d), (e) and (f) of Directive 2014/53/EU applicable from 1 August 2025. Delegated Regulation (EU) 2026/339 repeals it, but only with effect from 11 December 2027, the day the CRA applies in full. Recital 5 of the repealing regulation also records that the repeal does not affect market surveillance of compliance for radio equipment placed on the Union market between 1 August 2025 and 10 December 2027.
What is the practical effect of the restrictions on EN 18031?
Implementing Decision (EU) 2025/138 cited EN 18031-1, -2 and -3 with restrictions. The presumption of conformity does not apply where, applying clauses 6.2.5.1 and 6.2.5.2, the user is allowed not to set and use any password; for the relevant child-facing classes in EN 18031-2 where parental or guardian access control is not ensured; for the assessment criteria in clause 6.3.2.4 of EN 18031-3; and for the rationale and guidance sections of all three parts. Where the presumption falls away, Article 17 of the RED removes the internal production control route and requires EU-type examination followed by conformity to type, or full quality assurance, both involving a notified body.
When exactly do the Cyber Resilience Act duties start?
Article 71 sets three dates. Chapter IV, on notification of conformity assessment bodies, applied from 11 June 2026. Article 14, the reporting obligations, applied from 11 September 2026. The rest of the Regulation applies from 11 December 2027. Article 69(3) extends the Article 14 reporting duty to in-scope products placed on the market before that date.
How often does the CRA require a product to be tested?
It does not name an interval. Annex I Part II point 3 requires manufacturers to apply effective and regular tests and reviews of the security of the product with digital elements, and Article 13(8) sets a support period of at least five years during which vulnerability handling must continue. In practice that means testing tied to significant releases plus a periodic full reassessment, rather than a single pre-launch report.
Is my product an important product under Annex III?
Check the core functionality against the list. Class I includes routers, modems for internet connection and switches, physical and virtual network interfaces, microprocessors and microcontrollers with security-related functionalities, smart home general purpose virtual assistants, smart home products with security functionalities such as smart door locks, security cameras, baby monitors and alarm systems, internet connected toys with social interactive or location tracking features, and health or child wearables outside the medical device regulations. Class II includes hypervisors and container runtimes, firewalls and intrusion detection systems, and tamper-resistant microprocessors and microcontrollers. Implementing Regulation (EU) 2025/2392 gives the technical description of each category.
Does the Cyber Resilience Act cover medical devices?
No. Article 2(2) excludes products to which Regulation (EU) 2017/745 or Regulation (EU) 2017/746 applies. Vehicles under Regulation (EU) 2019/2144, products certified under the aviation Regulation (EU) 2018/1139 and marine equipment under Directive 2014/90/EU are also outside the scope. Medical device security follows its own regulatory route and is not covered on this site.
Is ETSI EN 303 645 a harmonised standard under the RED?
No. The harmonised standards cited in the Official Journal for the RED cybersecurity requirements are EN 18031-1, EN 18031-2 and EN 18031-3, listed in Implementing Decision (EU) 2025/138. EN 303 645 confers no presumption of conformity under the RED. It remains a useful baseline, it is widely used in procurement, and the UK PSTI regulations reference it by name for deemed compliance.
Do you need physical samples, or can testing be done remotely?
Board-level work needs hardware. Probing a UART, reading debug lock fuses, dumping flash and injecting faults are physical operations, and destructive steps need spare units. The companion application, the cloud API and the fleet console can be tested remotely, and firmware review can start from a published update image before samples arrive.
What do you need from us before an engagement starts?
Production units at the revision you intend to ship, the firmware build under test, a schematic or board file if you can share one, credentials for a normal user account and a second account for isolation testing, and written authorisation covering the cloud service if a third party operates it. A scope written in terms of the six exposures avoids most of the argument later.
Does a test report get us a CE mark?
No. A CE mark follows a conformity assessment carried out under the applicable procedure, which for many products means a notified body. A test report is evidence you put into that file. What a good report does is make the file defensible: findings tied to the specific requirement they fail, on a stated hardware and firmware revision, with the retest recorded.