What is cyber resilience?

Cyber resilience is the ability to prepare for, withstand, respond to and recover from cyber disruption. For a connected product, that means thinking beyond the vulnerabilities found in a single penetration test: how will you detect a new weakness, understand which devices are affected, deliver a trustworthy fix and restore service?

A connected gateway might pass its initial security tests but still be difficult to maintain if nobody can identify its software components or recover it after an interrupted update. Resilience connects secure design, testing, vulnerability management and recovery throughout the product’s life.

This matters to product manufacturers, software suppliers and engineering teams whose devices depend on mobile applications, cloud APIs or third-party components. A weakness at one boundary can undermine controls elsewhere.

Which cyber security requirements could apply to your product?

Start with your product, target markets and role in the supply chain. Legal duties can overlap, and a customer’s purchasing requirements may go further. This is a starting point for scoping, rather than a complete list of sector rules.

UK and EU requirements to check
Requirement	When to check it	Product security focus
EU Cyber Resilience Act (CRA)	Hardware or software with digital elements made available on the EU market, subject to scope and exclusions. UK suppliers can be affected.	Lifecycle security and vulnerability handling. Read the CRA guide and the Commission overview.
UK PSTI regime	Relevant consumer connectable products supplied in the UK. Manufacturers, importers and distributors have duties.	Baseline security and a Statement of Compliance. Read the PSTI guide and OPSS guidance.
UK GDPR	Products and supporting services that process personal data, including account details, location or user-linked telemetry.	Appropriate, risk-based security, resilience, restoration and testing. See ICO security outcomes.
UK NIS Regulations	Operators of essential services and relevant digital service providers, subject to the applicable definitions and exemptions.	Security and continuity of network and information systems. See the ICO’s NIS guide.
EU NIS2	Entities within specified sectors, including certain manufacturers. Check size, establishment, exceptions and the relevant national law.	Organisational cyber risk management and incident reporting. See the Commission’s NIS2 guidance.
UN R155 / R156	Vehicle programmes subject to these regulations in the relevant approval market. Confirm applicability with your approval team.	Cybersecurity management and software update management. See UNECE’s explanation.

Watch the UK Cyber Security and Resilience Bill. It proposes changes to the UK NIS regime. Treat proposals separately from duties already in force and check the latest status and commencement arrangements on the government’s Bill page before setting compliance deadlines.

Standards and customer requirements

ISO/SAE 21434 is an automotive cybersecurity engineering standard, rather than a blanket legal obligation on every supplier. A vehicle manufacturer may use it in supplier contracts and assurance expectations. Ask which deliverables your customer requires, which version applies and what acceptance evidence they expect.

For example, a supplier may need to provide a threat analysis, test results and evidence that identified risks were addressed. Agree those outputs early so that testing answers the customer’s actual questions.

What evidence should an engineering team prepare?

A useful starting pack connects requirements to the product you actually ship:

System boundaries: device variants, firmware versions, interfaces, companion apps, cloud dependencies and trust boundaries.
Risk decisions: credible attack scenarios, security objectives and the reasons behind control choices.
Verification: reproducible tests of boot integrity, debug access, authentication, stored secrets, API permissions and update mechanisms.
Maintenance: component ownership, vulnerability triage, security update delivery and a way to identify affected releases.
Recovery: evidence of what happens when an update fails, credentials are compromised or a supporting service becomes unavailable.

These are practical preparation steps. The exact legal documentation and assessment route depend on the applicable regime and your product.

Ongoing security for firmware already in use

Newly disclosed vulnerabilities can affect devices long after release. Rootworks provides continuous firmware vulnerability monitoring to help teams maintain visibility of potential exposure across supported products and firmware versions.

Start with an agreed inventory of known software components, using available firmware, component records or an SBOM. Track published vulnerabilities against that inventory, review matches in device context and give engineering teams clear priorities for fixes or mitigations.

Keep the record of findings, decisions and remediation current as releases change. Agree coverage, review cadence and reporting around your product range and support commitments. This gives your team ongoing evidence for product assurance and vulnerability handling work.

How Rootworks helps with cyber resilience

Rootworks combines ongoing firmware vulnerability monitoring with hands-on assessment across hardware, firmware, embedded operating systems, mobile applications and connected services. We scope the work around your product risks and the evidence your engineering, security and compliance teams need.

Define the assessment: bring your product architecture, target markets and agreed requirements so we can identify the security questions testing should answer.
Examine the implementation: use device hardware security testing, firmware analysis and application assessment to investigate realistic attack paths.
Prioritise improvements: connect reproducible findings to engineering changes, then agree focused retesting where needed.
Maintain visibility: monitor known firmware components for newly disclosed vulnerabilities throughout the agreed engagement, keeping findings and remediation decisions tied to supported releases.

Use the results to support your wider assurance work. Technical testing is one part of that work; your organisation retains responsibility for legal scope, declarations and any required conformity assessment.

Common cyber resilience questions

Is cyber resilience the same as cyber security?

Cyber security reduces the likelihood and impact of compromise. Cyber resilience also asks how the product or service continues operating, responds and recovers when preventive controls fail. A useful assessment considers both.

Does a penetration test prove compliance?

A penetration test provides evidence about the agreed scope and version at a point in time. Compliance can also involve design records, lifecycle processes, supplier duties, reporting and formal assessment steps. Build the test into that wider evidence plan.

Where should a connected-product manufacturer start?

Identify the markets you supply, your role and the product versions involved. Confirm applicable requirements, then compare existing design, test and maintenance evidence against them. Start technical work with the gaps that could change the design or block an upcoming release.

Official sources

Technical guidance, not legal advice. Confirm legal scope and obligations with your compliance or legal adviser. Requirements and guidance can change; check the linked official sources for updates.

Cyber resilience for connected products