EU Cyber Resilience Act case study
Context
For manufacturers of connected products, cybersecurity is no longer just a technical consideration. The EU Cyber Resilience Act makes it a legal one. From September 2026, manufacturers must meet active vulnerability reporting obligations, with full enforcement following in December 2027.
Sentec supported an industrial customer in implementing secure in-field firmware update capability for a product based on a new embedded processor platform. The goal was to enable firmware updates in the field while protecting intellectual property, preserving device integrity, and ensuring that only trusted firmware could be installed.
Challenge
For products that need to be updated after deployment, firmware update capability must be balanced with strong security controls. The customer needed a solution that would ensure:
- Only firmware cryptographically signed by the customer would be accepted by the device
- Firmware files remained encrypted in transit and at rest
- Unauthorised users could not access the system's internal data
These requirements map directly onto CRA obligations around secure update mechanisms, vulnerability management, and access control. This is increasingly a baseline expectation from both regulators and buyers.
The project was made more demanding by the fact that the product used a relatively new processor platform. While the platform included hardware-level support for encryption, along with vendor-supplied software and firmware libraries for encryption and authentication, it did not support in-field upgrades out of the box. The project also encountered bugs in the vendor firmware and an instance of undocumented hardware behaviour that had to be diagnosed and resolved before the required functionality could be delivered.
Solution
Sentec developed a secure approach to in-field firmware updates by combining the processor's built-in security capabilities with a carefully designed update mechanism tailored to the customer's product.
The delivered solution enabled:
- Encrypted and authenticated firmware images to be transmitted to the device
- Firmware to be verified, decrypted, and stored securely on receipt
- Automatic rejection of invalid updates where data was corrupted or authentication was missing
- Protection against unauthorised access to the processor's internal data
- Rollback to the previous valid firmware version if a new version failed during first startup
Delivering this required more than integration work. Sentec identified and fixed bugs in the vendor-supplied firmware and reported them to the manufacturer for inclusion in future releases. The undocumented hardware behaviour required direct collaboration with the vendor's engineering team. Both steps went beyond the original project scope but were necessary to produce a solution that would hold up in a deployed product environment.
Outcome
The resulting firmware met the customer's functional and security requirements in full. Testing verified that the secure update process worked as intended. Any deviation from the expected update conditions (corrupted data, missing authentication, or an unrecognised firmware signature) would prevent the update from taking place. Testing also confirmed that unauthorised access to internal processor data was not possible without proper authorisation, and that the system could safely revert to the previous firmware version if a new update failed to run.
For the customer, this delivered a defensible, auditable mechanism for managing firmware vulnerabilities in deployed devices. That is precisely what the CRA requires manufacturers to demonstrate.
Conclusion
This engagement demonstrates what genuinely secure firmware development looks like when the platform is new, the documentation is incomplete, and the stakes are real. Resolving undocumented hardware behaviour and vendor firmware bugs required embedded expertise, direct manufacturer engagement, and a willingness to go beyond the original brief to get the outcome right.
For manufacturers building connected products today, secure in-field update capability is a CRA requirement rather than an optional enhancement. Products that cannot be updated safely in the field will become progressively harder to maintain, certify, and defend. Getting the architecture right before the September 2026 deadline is significantly less costly than retrofitting it under regulatory pressure.