Can you prove today which firmware version is running on which batch of your components – and who programmed them?
From December 2027, that is no longer a rhetorical question. The Cyber Resilience Act makes traceability, auditability and recall readiness mandatory – for manufacturers and their entire supply chain.
What Is the Cyber Resilience Act – and who does it affect?
The Cyber Resilience Act (CRA) is an EU regulation that establishes binding cybersecurity requirements for all products with digital elements, applying from 11 December 2027. It affects manufacturers, importers and distributors of connected and programmable products in the EU – including embedded systems, IoT devices, industrial controls and automotive components.
The CRA is not a cybersecurity directive aimed at software companies. It is a product regulation covering the entire lifecycle of a product: from development and manufacturing through to security updates and vulnerability reporting. Anyone who develops or sells products with digital elements in the EU is affected.
For procurement, there is an additional dimension: manufacturers must also be able to demonstrate that their suppliers and service providers contribute to a secure, auditable process. This fundamentally changes supplier evaluations.
These questions are already appearing in supplier evaluations today – particularly at Tier-1 suppliers operating under IATF and NIS2 pressure. The right time to ask the right questions is therefore now.
Why Programming is suddenly a compliance factor
Many companies think of the CRA primarily in terms of software development. In practice, the initialisation and programming of embedded components is equally critical: this is where security-relevant states, certificates, configurations and firmware versions are set.
If this process is not documented, a gap appears in the Technical File – the core document manufacturers use to demonstrate CRA conformity to authorities. A technically sound component without documented process evidence is regulatorily worthless.
There is also the update obligation: the CRA requires security updates to be provided throughout the entire product lifecycle. Anyone programming components today must therefore think ahead about how future changes, re-programming runs and version records will remain possible.
What makes a CRA-ready Service Provider
A CRA-capable partner needs more than good manufacturing. Processes must be structured so that manufacturers can derive evidence for their Technical File and audit documentation.
These questions are already appearing in supplier evaluations today – particularly at Tier-1 suppliers operating under IATF and NIS2 pressure. The right time to ask the right questions is therefore now.
- Documented, reproducible programming process (ISO/IATF-compliant)
- Complete audit trail: batch, serial number, firmware version, timestamp
- Exportable data for QM, audit, ERP and compliance documentation
- Formally agreed response times for incidents (SLA)
- Long-term storage of firmware versions and device configurations
- Verifiable storage conditions: climate, ESD, test intervals
This is not a claim to completeness. It is a realistic starting point for conversations with suppliers who take the topic seriously.
Why Long-Term Storage and Secure Programming belong together
The CRA thinks in lifecycles. Products must be kept secure for years – in industrial and automotive applications often for ten to twenty years. This means components must not only be available and programmable today, but also in five or ten years, when a new vulnerability is discovered or a customer extends their product lifecycle.
Secure programming without long-term availability remains piecemeal. Long-term storage without documented process and version security likewise. Only together do they create a robust lifecycle approach that withstands a CRA audit.
What Companies should do now
The CRA's main obligations apply from 11 December 2027. The first reporting obligations for actively exploited vulnerabilities come into force as early as 11 September 2026. Manufacturers developing new product generations or renegotiating supplier contracts today are already doing so for a CRA world.
Three first Steps
- Ask existing service providers what evidence they can already provide today – audit trail, traceability, response times.
- Bring together internal requirements from procurement, QM, engineering and cybersecurity. CRA is not an IT topic that can be delegated.
- Evaluate suppliers not only as operational executors, but as part of your own evidence and risk chain.
With btv SEEL® — patent pending since 2023 — one of the few auditable solutions for secure device initialization in the EU is now available. Combined with traceability, long-term storage, and documented programming processes, btv provides the building blocks for CRA-ready supply chains. We are ready.
Frequently asked questions about the Cyber Resilience Act
The Cyber Resilience Act (CRA) is an EU regulation for products with digital elements. From 11 December 2027, manufacturers must meet cybersecurity requirements across the entire product lifecycle – from development to end-of-life. This includes security updates, traceability, incident response and documentation obligations.
