Can you prove today which firmware version is running on which batch of your components — and who programmed it?
The Cyber Resilience Act has been in force since 10 December 2024. From 11 December 2027, that will no longer be a rhetorical question, since full applicability takes effect then. The Cyber Resilience Act makes traceability, auditability, and recall readiness mandatory — for manufacturers and their entire supply chain.
The first deadline already applies from 11 September 2026: from this date, actively exploited vulnerabilities must be reported to the national CSIRT and ENISA within 24 hours. Anyone without a reporting process today — or whose suppliers can't deliver evidence at packaging-unit level — carries a structural risk.
What is the Cyber Resilience Act – and who does it affect?
The Cyber Resilience Act (CRA) is an EU regulation that has been in force since 10 December 2024, with full applicability taking effect from 11 December 2027 — introducing binding cybersecurity requirements for all products with digital elements. It applies to manufacturers, importers, and distributors of connected and programmable products in the EU, including embedded systems, IoT devices, industrial controls, and automotive components.
The CRA isn't a cybersecurity directive for software companies. It's a product regulation covering the entire lifecycle of a product: from development through manufacturing to security updates and vulnerability reporting. Anyone developing or distributing products with digital elements in the EU today is affected.
An often-overlooked point: anyone placing products on the EU market under their own name or brand — including as an importer or distributor — is legally considered a manufacturer and carries all CRA obligations. White-labeling or modifying third-party components is enough to trigger full manufacturer responsibility.
For procurement, there's an added dimension: manufacturers must also be able to prove that their suppliers and service providers contribute to a secure, auditable process. This fundamentally changes supplier evaluations — and turns CRA compliance into a procurement issue.
Which software version was flashed onto which component, when, by whom, under what conditions? This question must be answerable at any time — not only internally, but also to authorities and customers.
When known vulnerabilities are identified, affected batches must be identifiable within 24 hours. Anyone lacking this data — or whose service provider can't deliver it — carries a structural risk.
These questions already appear in supplier evaluations today — particularly among Tier-1 suppliers who are themselves under IATF and NIS2 pressure. The right time to ask the right questions is therefore now.
The Journey of a Component — and Where Evidence Is Created
At its core, the CRA requires proof of an unbroken chain of trust: every step in the supply chain — from procurement through storage and processing to programming and delivery — must be documented, traceable, and auditable. This isn't an abstract requirement; it's concrete evidence that authorities can demand at any time.
At btv technologies, this chain of evidence is built along the entire journey a component takes through manufacturing.
btv TAK® Documents the Starting Point
It's fully documented which component comes from which source, when it was put into storage, under what conditions it's stored, and when it's delivered into production. Every batch is traceable at the level of the individual packaging unit, across all production sites, Tier-1 suppliers, and EMS partners.
btv TAK® is more than a documentation tool: it's a supply chain solution that can also serve as a one-stop solution — covering procurement, storage, and delivery to the line, all from a single partner. This is the foundation of every CRA audit.
Component Services Extend the Chain of Evidence to Every Processing Step
In testing, reconditioning, drying and baking, taping, or repackaging, every action, every operator, and every goods movement is documented — along with storage conditions such as climate and ESD values during processing. This creates a chain of evidence that covers not just goods receipt and storage, but every process step a component goes through on its way to production.
Programming Completes the Chain — Traceability Is Already Standard Here
The complete audit trail — batch, serial number, firmware version, timestamp, operator — is documented for every programming run, regardless of the method used, and reaches down to the level of the individual component. This data is exportable for QM, ERP, the technical file, and regulatory audits — closing the gap that exists for many manufacturers between component procurement and the finished product.
btv SEEL® Additionally Secures the Flashing Process Itself
btv SEEL® — patent-pending since 2023 — addresses a single point: securing the flashing process itself. Firmware and keys are provided exclusively in encrypted form and processed exclusively in volatile memory (RAM) — with no persistent data traces. Once programming is complete, an automated, irreversible memory wipe follows. Individual key pairs per chip and signature-based authentication additionally protect the process against manipulation.
Traceability is naturally already in place: btv SEEL® builds on the same programming process that is already fully documented in the standard workflow — the additional security mechanism supplements the audit trail, it doesn't replace it.
For devices that later need to uniquely identify and authenticate themselves within a network — for example, for OTA updates in the field — btv SEEL® UNLIMITED can additionally integrate individual certificates. Each certificate is uniquely assigned to a single component and documented accordingly.
Together, btv TAK®, the component services, and btv SEEL® form a continuous, verifiable chain of trust — from the component to the programmed, production-ready assembly.
If this process isn't documented, a gap emerges in the technical file — the core document manufacturers use to demonstrate CRA conformity to authorities. A technically flawless component without process evidence is regulatorily worthless.
There's also the update obligation: the CRA requires that security updates can be provided throughout the entire product lifecycle. Anyone programming today must therefore consider how later changes, reprogramming, and version records will remain possible at all.
- Documented, reproducible programming process (ISO/IATF-compliant)
- Complete audit trail: batch, serial number, firmware version, timestamp
- Exportable data for QM, audits, ERP, and compliance documentation
- Contractually agreed response times for incidents (SLA)
- Long-term storage of firmware states and device configurations
- Verifiable storage conditions: climate, ESD, test intervals
- Evidence at packaging-unit level, and at individual-component level for programming
This isn't a claim to completeness. It's a realistic starting point for conversations with suppliers who take the topic seriously.
The CRA thinks in lifecycles. Products must remain secure over years — often ten to twenty years for industrial and automotive-adjacent applications. Secure programming without long-term availability remains a fragment. Long-term storage without documented process and version security is equally incomplete. Only together do they create a resilient lifecycle approach that can withstand a CRA audit.
What Happens in the Event of Non-Compliance
The CRA provides for a tiered fine system: up to €15 million or 2.5% of global annual turnover for violations of essential security requirements, up to €10 million or 2% for other obligations such as reporting or documentation requirements, and up to €5 million or 1% for incorrect or misleading information provided to authorities. In addition, products can be withdrawn from the market or recalled.
Next Steps
- Keep the first deadline in view: reporting obligations for actively exploited vulnerabilities apply from 11 September 2026
- Ask existing service providers what evidence they can already deliver today — audit trail, traceability, response times
- Bring together internal requirements from procurement, QM, development, and cybersecurity — CRA isn't an IT topic you can delegate
- Stop evaluating suppliers purely as operational executors; treat them as part of your own evidence and risk chain
- Ensure full CRA conformity by 11 December 2027
Frequently asked questions about the Cyber Resilience Act
The chain of trust refers to the unbroken, auditable evidence of every process step along the supply chain — from component procurement through storage and processing to programming and delivery. btv TAK® and the component services provide traceability; programming — whether standard or btv SEEL® — provides the complete audit trail down to component level.
Not traceability — that applies equally to both processes, including traceability down to individual-component level. The difference lies solely in securing the flashing process itself: btv SEEL® processes firmware and keys exclusively in encrypted form and exclusively in volatile memory, with an automated memory wipe once programming is complete. With btv SEEL® UNLIMITED, individual certificates can additionally be integrated — for example, for unique device identification on a network or for later OTA updates.
