Cyber Resilience Act readiness

The EU Cyber Resilience Act's reporting duties have applied since 11 September 2026, and its full obligations apply to every product with digital elements placed on the EU market from 11 December 2027. The UK's PSTI regime for consumer connectable products has been in force since April 2024. Most of the companies these laws cover have an engineering team and no compliance department. This service is the engineering readiness work for companies like that: establishing where you stand, what the gaps are, and the order to close them in, starting with the items that take longest.

Who it is for

Manufacturers and hardware ventures of roughly twenty to five hundred people making connected products: devices with firmware, an app and a cloud service, sold into the EU or the UK or both. Importers and distributors who need to know what to ask their manufacturers for. And the boards, investors and lenders behind them, who want to know whether the December 2027 date is a line item in their risk. It suits companies with products already in the field as well as products about to ship; the work is harder for the first group, and more urgent.

What the audit covers

A fixed-price connected-products audit, typically a week, works through the eight things a manufacturer must be able to show, in the order that takes longest. Classification and conformity route: which class your products fall in, and therefore whether you can self-assess or need a third party, because that decides the timescale and cost of everything else. Support period and updates: whether the support period you will state is one you can keep, and whether your update capability can deliver signed, staged, reversible updates to every unit in every market. Vulnerability handling: the disclosure policy, the single point of contact and the named person running the process. The 24-hour reporting process: who makes the call, how they find out, and whether it has been rehearsed. Software bill of materials: a first machine-readable SBOM, produced during the audit, and what it reveals about licences and out-of-date components. Secure at release and by default: testing by someone who did not write the code, default configuration, default passwords, data protection. Technical documentation and risk assessment: what exists, what is missing, and what the assessor will read. Declaration, marking and user information: the paperwork that summarises the rest.

Where the product is sold to UK consumers, the audit checks the three PSTI requirements and the statement of compliance alongside, because they are a subset of the same work and they are already the law.

What you get

A written readiness report: the classification and conformity route with reasons, a status against each of the eight obligations with evidence rather than assurance, the first SBOM, the risks ranked by their effect on the December 2027 date, and a plan in the order that takes longest, with the owner each item needs. Findings are written for a leadership team, with the engineering detail in an appendix for the people who will do the work. A follow-up call after two weeks. From there I can lead the work as fractional technical leadership, advise your team as it does the work, or step back; the report is designed so a competent team can run it themselves.

This is an engineering readiness service, not legal advice and not a conformity assessment. Where your class requires a notified body or a lawyer's opinion, the report says so and says what to bring to them.

How it works

A scoping call to understand the product range, the markets and what exists today. Then the audit week: document review, interviews with the engineering and product leads, inspection of the firmware and update pipeline, the app and the cloud service, and the production of the SBOM. Fixed price, agreed at scoping. The main driver is how many distinct products or platforms are in scope: a range that shares its firmware, app and cloud service is one audit, while three unrelated products are nearer three, and a company selling into several markets with different rules adds the regulatory mapping for each. On site or remotely, in the UK and internationally.

Who does the work

I do. A week is one senior engineer on one product platform, which is the shape of most companies this service is for: twenty to five hundred people, one or two platforms, no compliance function. Where the range is larger the audit is phased, platform by platform, with the classification and the reporting process done first for all of them because those are the items with a date on them. Where the class of product requires penetration testing to a standard, or a notified body, I bring in the specialists and the lab, working to my brief and reporting through me, so you have one plan and one person who understands all of it. If what you need is a certification body rather than an engineer, I will say so at scoping.

Why me

I have run product development for connected consumer hardware sold into several markets with different rules: firmware, battery systems, Bluetooth, apps and the cloud behind them, with signed over-the-air updates that roll back and security testing throughout. I have also sat on the other side of the table, reviewing technology for a bank before it lent. I am a Chartered Engineer, I still build, and I write the map I work from: The CRA without a compliance department is the audit's structure in essay form.

Before you commission an audit

The free CRA Readiness Check takes ten minutes and gives you a readiness picture against each of the eight obligations with the first step for every gap, and the PSTI requirements alongside. If it shows you are on track, you may only need a conversation. If it shows gaps, you will know which ones and how long they take, and the audit turns that picture into evidence and a plan.

Reading

• The CRA without a compliance department: the eight things, in the order that takes longest.
• PSTI: the UK product security law that already applies to you.
• The OTA problem: why the update capability is the long pole.
• When the product is already in the field.
• Connected products versus AI-assisted attackers.