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.
The first deadline applies as early as 11 September 2026: from that date, actively exploited vulnerabilities must be reported within 24 hours to the national CSIRT and ENISA. Anyone without a reporting process in place – or whose suppliers cannot provide batch-level traceability – faces a structural risk.
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.
An often overlooked point: anyone placing products on the EU market under their own name or brand – including importers and distributors – is treated as a manufacturer under the regulation and bears full CRA obligations. White-labelling or making modifications to third-party components is sufficient to trigger full manufacturer responsibility.
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 – and makes CRA compliance a procurement issue.
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.
Chain of Trust: What the CRA really demands – and how btv delivers it
At its core, the CRA requires proof of an unbroken Chain of Trust: every step in the supply chain – from procurement through programming to delivery – must be documented, traceable and auditable. This is not an abstract requirement, but a concrete proof that authorities can demand at any time.
btv technologies provides exactly this evidence chain – through the combination of two building blocks:
- TAK Model: Full Traceability across the entire Supply Chain
The TAK model documents every step: which component came from which source, when it was stored, under what conditions it is held, and when it is delivered into production. Every batch is traceable – at batch level, across all sites, for all production locations, Tier-1 suppliers and EMS partners. This is the foundation of every CRA audit. - btv SEEL®: Highly secure, auditable Programming
btv SEEL® – patent pending since 2023 – is one of the few auditable solutions for secure device initialisation in the EU. Every programming run is documented with a complete audit trail: batch, serial number, firmware version, timestamp, operator. This data is exportable for QM, ERP, Technical File and authority audits – closing the gap that exists at many manufacturers between component procurement and finished product.
Together, TAK and btv SEEL® form a seamless, provable Chain of Trust – from the component to the programmed, deployment-ready assembly.
Why Programming becomes 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 a CRA-ready Service Provider should deliver
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.
- 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
- Batch-level traceability across the entire supply chain
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 – and that closes the Chain of Trust not just at the point of initial programming, but across the entire product lifecycle.
What Companies should do now
- First deadline in focus: from 11 September 2026, reporting obligations for actively exploited vulnerabilities apply – that is less than four months away
- 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
- Ensure full CRA conformity by 11 December 2027
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.
Frequently asked questions about the Cyber Resilience Act
Manufacturers, importers and distributors of products with digital elements placed on the EU market – regardless of where the company is based. Anyone placing products under their own name or brand, or making modifications to third-party components, is treated as a manufacturer under the regulation.
The Chain of Trust is the unbroken, auditable proof of every process step along the supply chain – from component procurement through storage and programming to delivery. The CRA requires this proof for the Technical File and authority audits. TAK provides the traceability; btv SEEL® provides the auditable programming.
Buyers must increasingly evaluate suppliers on their auditability, traceability and process documentation. Anyone outsourcing component programming or storage must ensure these service providers can deliver CRA-relevant evidence — firmware traceability, audit trails and incident response times become procurement criteria.
