From 2027, connected products sold in the EU will need to meet new baseline cybersecurity requirements under the Cyber Resilience Act. For IoT and networked devices, that means security-by-design, vulnerability management, and evidence of compliance or a real risk of losing access to the EU market.
Cybersecurity moves from a competitive differentiator to a baseline condition for selling. This shift is tied to two specific dates in 2026 and 2027, which define when different obligations under the Cyber Resilience Act begin to apply.
In this article, we examine what the Cyber Resilience Act means in practice for manufacturers of IoT and networked products, with particular attention to the two upcoming milestones. The analysis is informed by practical input from Promwad’s engineering team, who support clients worldwide in addressing cybersecurity requirements in product design.
Why this matters to manufacturers outside Europe
You do not need to be based in the EU to be affected. If your connected product is placed on the EU market — directly, through distributors, or via online sales — CRA expectations apply. For global product teams, that makes the CRA less like a regional policy change and more like a new commercial constraint that must be engineered for.
The key timeline: what happens in 2026 and 2027
The Cyber Resilience Act has already been adopted and came into force in December 2024 as EU Regulation 2024/2847. Two milestones matter for product roadmaps:
11 September 2026: reporting obligations begin
From September 2026, the Cyber Resilience Act introduces its first operational obligations. At this stage, manufacturers of in-scope products are expected to be able to identify, assess, and report actively exploited vulnerabilities and serious security incidents within defined timeframes.
This date does not yet block products from being sold. However, it effectively tests whether a company has real security processes in place — not just technical controls, but also internal workflows for vulnerability handling, escalation, and communication. Organisations that lack visibility into their software components or do not have clear responsibility for security issues may struggle to meet these requirements.
11 December 2027: core CRA requirements become mandatory
From December 2027, the Cyber Resilience Act’s main security requirements apply to new products with digital elements placed on the EU market. From this point onward, cybersecurity is a formal condition for market access.
Manufacturers must be able to demonstrate that their products meet baseline security expectations, including secure design principles, vulnerability management throughout the product lifecycle, and the ability to deliver security updates. Products that fail to meet these legal minimums may not be placed on the EU market, regardless of functionality or commercial demand.
For many product teams, this marks the moment when cybersecurity shifts from an internal quality goal to an external regulatory requirement — one that directly affects whether a product can be legally sold in Europe.
What changes for IoT and networked products under the CRA
The CRA pushes the market towards two outcomes: fewer preventable vulnerabilities at launch, and better maintenance throughout a product’s supported life. In practical terms, that translates into three operational shifts for manufacturers.
Security becomes a design requirement
Many IoT and networking products are built around cost, performance, and time-to-market. Under CRA pressure, security must be treated similarly: something that is designed in, reviewed, and tested as part of standard product engineering.
For connected products, that often means decisions such as:
- how devices authenticate and manage identity;
- which services are exposed by default and why;
- how credentials, keys, and secrets are stored and protected;
- what happens when a component is compromised and how the blast radius is limited.
Software supply chain visibility becomes unavoidable
Modern devices ship with large dependency trees: operating systems, open-source packages, third-party SDKs, and bundled services. The CRA environment raises the expectation that manufacturers can identify what is inside their products and react when vulnerabilities emerge.
As a result, many teams are accelerating work on:
- producing and maintaining a software bill of materials (SBOM);
- identifying known vulnerabilities (CVEs) and prioritising remediation;
- establishing release processes that can deliver security patches reliably.
Vulnerability handling becomes a process, not an event
One-off security testing before launch is not enough. The CRA ecosystem rewards organisations that can detect, triage, fix, and communicate security issues as a routine capability — including meeting reporting duties that start earlier than the main 2027 obligations.
This is where many companies feel the gap. It is not just “add another test”; it is a cross-functional change touching engineering, QA, product management, customer support, and legal.
What CRA readiness looks like in real engineering work
Regulatory language can make security sound abstract. In practice, CRA-aligned work tends to look like disciplined product security engineering: threat modelling, audits across hardware and firmware, evidence-driven testing, and documented remediation.
Below are a few case studies from Promwad, illustrating the types of security work companies are already undertaking as they prepare for CRA requirements, particularly for IoT and network equipment.
Router security audit (OpenWRT/prplOS, Realtek platform)
In a recent router audit, the work covered the full stack:
- threat analysis guided by the MITRE ATT&CK threat framework;
- hardware review including PCB-level checks and platform features that could expand the attack surface;
- firmware analysis including SBOM generation and identification of known vulnerable components;
- penetration testing to validate resilience against realistic attack paths.
The value of this approach is not only finding issues. It produces an ordered plan: what must change in design, configuration, firmware composition, and update strategy to reduce the risk profile in a measurable way.
Industrial switch security audit (firmware hardening & protocol exposure)
Industrial networking equipment sits in sensitive environments where availability and segmentation matter. In one industrial switch-focused engagement, the scope included:
- threat analysis and attack-path mapping;
- hardware weakness review;
- firmware hardening work tied to vulnerability clean-up and dependency visibility;
- protocol review and testing aligned to real-world misuse scenarios;
- penetration testing to confirm that mitigations work under pressure.
This matters because industrial devices often have long deployment lives. Without robust maintenance and a reliable patch path, even a small weakness can become a persistent entry point.
Wi-Fi access point security scanning (authorised testing)
Wireless edge devices are exposed by design. In an authorised assessment for a wireless solutions vendor, Promwad engineers tested a Wi-Fi access point for weaknesses including password-cracking risk and configuration issues that could enable compromise. Findings were used to improve device security, which supported the customer’s ability to proceed with an enterprise supply contract.
Full technical case study: Access point vulnerability scanning.
The lesson is straightforward: compliance narratives do not stop attackers. Only testing that reflects attacker behaviour will reveal which assumptions fail in the field.
A practical checklist for teams selling into the EU
If you build or ship connected products, the following steps are a pragmatic starting point for CRA-era expectations:
- Confirm what is in scope: map device variants, software components, and bundled services.
- Run threat-led analysis: identify credible attack paths and prioritise the highest impact risks.
- Establish SBOM and vulnerability management: know what you ship, track known issues, and assign ownership for remediation.
- Harden default configurations: remove unnecessary services, reduce exposed interfaces, and secure credentials and keys.
- Validate with penetration testing: verify controls under realistic conditions and document results.
- Prepare operationally: ensure you can ship patches predictably and meet incident/vulnerability handling duties, including reporting where required.
The bottom line
The Cyber Resilience Act raises the floor for cybersecurity in the EU. For IoT and networked products, the commercial implication is hard to ignore: from 2027, security is not just about reputation or customer trust — it is about whether the product can be sold at all.
Organisations that start the CRA transition early, by tightening architectures, documenting dependencies, and treating patching as a routine capability, will find the regulation far less disruptive than those attempting to retrofit security at the end.
