Obligations that attach to what you ship out of the door. If your organisation sells anything with software in it, this domain reaches your engineering roadmap, your release process and your vulnerability handling.
What we track
Cyber Resilience Act
EU. Essential requirements for products with digital elements, vulnerability handling duties, and the reporting obligations now in their first application phase.
CRA steward obligations
EU. What the regulation asks of open-source stewards, and what that means for the components inside your product.
UK PSTI regime
UK. Consumer connectable products, the statement of compliance, and the first enforcement action against an importer.
UNECE R155 and R156
International, automotive. Cybersecurity and software update management systems, and the supplier evidence auditors now expect.
EU Machinery Regulation
EU. Cybersecurity requirements for machinery, confirmed for January 2027, including software that affects safety functions.
Certification schemes
EU. Schemes under the Cybersecurity Act, and the sectors where certification is moving from voluntary to expected.
Who is in scope
Manufacturers, importers and distributors of products with digital elements, which is a wider category than most companies assume. It includes hardware with software in it, software sold on its own, and remote data processing solutions that the product depends on. Business-to-business products are covered as well as consumer ones.
Importers and distributors have duties of their own, so a company that rebadges or resells someone else’s device does not escape by pointing upstream. Open-source stewards have a distinct and lighter set of obligations, which matters to anyone maintaining a widely used component.
Where the deadlines fall
Product regimes phase in, and the vulnerability reporting duties usually land before the full essential requirements do. That ordering catches teams that planned around the headline application date and missed an earlier obligation to report actively exploited vulnerabilities.
The automotive regimes work on type approval cycles instead, so the binding date follows your model programme. Machinery cybersecurity requirements are confirmed for January 2027.
Where organisations get caught
Scope is wider than people expect. A product with a digital element is more than a device with a screen. Companies that think of themselves as manufacturers are routinely in scope for the same obligations as software vendors, and they usually have none of the processes those obligations assume.
The second surprise is upstream. You inherit vulnerability handling duties for components you did not write, which turns your component inventory into a compliance artefact. A software bill of materials that was a nice-to-have in engineering becomes the thing a regulator asks to see.
The third is support lifetime. Several regimes require you to state a support period and then honour it. That converts a marketing decision into a contractual one, and it reaches products already in the field.
Questions worth asking now
- Which of our products have a digital element, and who maintains that list?
- Are we a manufacturer, an importer or a distributor for each of them, and does the answer differ by market?
- Do we have a software bill of materials we could hand to a regulator this week?
- Who receives a vulnerability report from outside, and what happens in the first day?
- What support period have we published, and can we meet it for the oldest product still in the field?
- If a component we depend on is compromised, how quickly can we tell which products contain it?
Related domains
Third-party and supply chain risk covers the components you inherit. Robotics and autonomous systems covers machinery where safety and security meet. Incident reporting covers the vulnerability reporting duties.