What is the Cyber Resilience Act and who does it apply to?
The Cyber Resilience Act (CRA) – officially Regulation (EU) 2024/2847 of the European Parliament and of the Council of 23 October 2024 – is the first horizontal regulation in the European Union introducing mandatory cybersecurity requirements for products with digital elements. The Act was published in the Official Journal of the EU on 20 November 2024 and entered into force on 10 December 2024.
The CRA applies to all economic operators involved in placing products with digital elements on the EU market:
- Manufacturers – entities designing, producing, or commissioning the production of devices
- Importers – introducing products from third countries to the EU market
- Distributors – making products available in the supply chain
What does “product with digital elements” mean?
According to Article 3(1) of the CRA, a product with digital elements is a hardware or software product and its remote data processing solutions, including software or hardware components. In practice, this means the regulation applies to any device that:
- Has firmware or embedded software
- Has a communication port (USB, Ethernet, Wi-Fi, Bluetooth)
- Connects to a network or another device – directly or indirectly
- Processes data remotely in the manufacturer’s cloud
Key principle: If your device can be connected physically (via hardware interfaces) or logically (via network sockets, APIs, software interfaces) to another device or network – even if the connection is indirect – the CRA applies to you.
Examples of products covered by the CRA
The regulation covers a wide range of electronic devices used in various sectors:
Industrial electronics:
- PLC controllers and automation systems
- Industrial computers and HMI
- Data monitoring and acquisition devices (SCADA)
- Inverters and frequency converters with network communication
Network devices and IoT:
- Routers, switches, firewalls
- IoT devices (sensors, actuators)
- Smart home systems (smart locks, alarms, monitoring)
Consumer electronics:
- Smartphones and tablets
- Health monitoring wearables
- Connected toys with network functions
- Baby monitors with IP cameras
Automotive and transport:
- Vehicle infotainment systems
- OBD diagnostic devices
Medical devices, aviation, and automotive devices subject to separate EU regulations (Regulations 2017/745, 2017/746, 2018/1139, 2019/2144) are excluded from the CRA because they already have dedicated cybersecurity requirements.
What obligations does the CRA introduce?
Security “by design”
The fundamental principle of the CRA is security by design – security built in from the design stage. Annex I Part I of the Regulation defines essential cybersecurity requirements that must be met before a product is placed on the market.
Design with cybersecurity in mind
According to Art. 13(1) CRA, the manufacturer must:
- Conduct a cyber risk analysis – identify threats to the product in the context of its intended use
- Design a secure architecture – implement protection mechanisms at hardware and software levels
- Apply the principle of least privilege – limit access to functions only to the necessary scope
- Eliminate default passwords – each device must have unique credentials or a mechanism forcing their setup at first use
Software updateability
A key requirement is ensuring the possibility of secure software updates throughout the entire support period:
- Minimum 5 years from the date of placing on the market – according to Art. 13(8) CRA
- If the expected use time is shorter than 5 years, the support period must correspond to the expected use time
- Updates must be provided free of charge to the user
- The update mechanism must be secure – protected against impersonation and unauthorized modifications
Update availability requirement: According to Art. 13(9), each security update must remain available for download for at least 10 years from the date of its release or for the remainder of the support period – whichever is longer.
No known vulnerabilities at the time of market placement
The manufacturer is obliged to exercise due diligence towards components sourced from third parties, including open-source components. Annex I Point 2(1) requires products to be free from known vulnerabilities at the time of market placement. This means the necessity of:
- Verifying components for known vulnerabilities in the CVE (Common Vulnerabilities and Exposures) database
- Checking the security update history of components
- Conducting security tests before certification
Vulnerability management
The CRA introduces detailed obligations regarding vulnerability handling throughout the product lifecycle.
Obligation to respond and report
Article 14 of the CRA defines a detailed incident reporting procedure:
1. Actively exploited vulnerabilities
The manufacturer must report any actively exploited vulnerability of which they become aware. This means situations when:
- A security breach of users resulted from exploiting a flaw in the product
- A malicious actor exploited a flaw in identification, authentication, or other security mechanisms
Reporting schedule (from 11 September 2026):
- Early warning – within 24 hours of becoming aware
- Vulnerability notification – within 72 hours with more detailed information
- Final report – within 14 days after remedial measures become available
2. Severe incidents
Severe incidents affecting product security are also subject to reporting, including situations when:
- A cybersecurity incident disrupted the development, production, or maintenance processes of the product
- The disruption may increase cybersecurity risk for users
- Example: attack on the security update distribution channel with malicious code injection
Reporting schedule:
- Early warning – within 24 hours
- Incident notification – within 72 hours
- Final report – within 1 month
All reports must be submitted through the Single Reporting Platform, which will be established by ENISA (European Union Agency for Cybersecurity).
Maintaining updates for a specified time
The manufacturer is obliged to:
- Monitor vulnerabilities throughout the support period
- Deliver patches within a reasonable time after detecting a vulnerability
- Publicly disclose information about fixed vulnerabilities after an update is made available
- Maintain a Coordinated Vulnerability Disclosure policy – the manufacturer must provide a contact address for reporting security vulnerabilities
Documentation and identifiability
This is a key section for the EMS industry – here production takes on strategic importance.
Software Bill of Materials (SBOM)
Annex VII point 2(b) of the CRA requires the manufacturer to create an SBOM – an inventory of all software components contained in the product. The SBOM must be:
- In a commonly used, machine-readable format (e.g., SPDX, CycloneDX, SWID)
- Contain at least top-level dependencies
- Be part of the product’s technical documentation
- Available to market surveillance authorities upon request
Practical significance of SBOM:
- Enables quick identification of products containing vulnerable components
- Allows precise tracking of which production batches require updates
- Forms the basis for supply chain risk management
Traceability of components and production batches
Article 13(13) of the CRA states that the manufacturer must ensure that products have a type, batch, serial number, or other element enabling their identification. In practice, this means the necessity of:
1. Production batch numbering
- Each PCB series must have a unique identifier
- This enables linking a specific board with:
- Production date
- BOM (Bill of Materials) version
- Firmware version loaded
- Components used (batches)
2. Register of used components
- Documentation must contain a complete list of components used in each batch
- Particularly important when a vulnerability is detected in a supplier’s component
- Allows quick identification of which products are affected
3. Ability to reconstruct production configuration
- Recorded assembly process parameters
- Tooling versions (solder paste stencil, fixtures)
- Test equipment calibration
Why does this matter in the CRA context?
When a vulnerability is detected in a component (e.g., Bluetooth module, cryptographic chip), the manufacturer must:
- Immediately identify all affected products
- Notify users and supervisory authorities
- Provide an update or mitigation instructions
Without full traceability, this is impossible to execute within the 24-72 hour timeframe required by the CRA.
Change control and version management
Annex VII point 1(b) requires documentation of software versions affecting compliance with cybersecurity requirements. In practice, EMS must:
- Maintain a firmware version register for each batch
- Document ECO (Engineering Change Order) procedures
- Ensure firmware version is compatible with hardware version
- Enable verification of which software version was loaded into a specific device
What does the Cyber Resilience Act mean for electronics production?
The CRA shifts cybersecurity from a purely software dimension to the domain of physical production. For EMS partners, this means transitioning from the role of assembly executor to co-responsible participant in the cybersecurity assurance process.
1️⃣ Importance of quality control
Automated Optical Inspection (AOI)
AOI is a technology using cameras and vision algorithms for automatic PCB inspection. In the CRA context, AOI takes on new significance:
Detecting assembly defects affecting security:
- Improper soldering of components responsible for security functions (e.g., cryptographic chips)
- Missing components in protection circuits
- Bridges that may lead to unpredictable behavior
Verification of component authenticity:
- Modern AOI systems can detect counterfeit integrated circuits through marking analysis
- Verification of physical appearance compliance with component manufacturer documentation
Functional Testing
According to Annex VII point 6, the manufacturer must provide test reports verifying compliance with cybersecurity requirements. In the production context, this means:
Communication and encryption tests:
- Verification of proper implementation of secure communication protocols
- Checking encryption mechanisms operation
- Testing communication ports for unauthorized access
Authentication mechanism tests:
- Confirmation of no default passwords
- Verification of secure boot mechanisms
Firmware programming tests
An improperly programmed PCB series can mean a mass security breach – this is the most important conclusion for the EMS industry.
Key aspects of firmware testing in the CRA context:
- Firmware integrity verification:
- After loading firmware, verify checksum/hash
- Confirmation that loaded software is identical to the approved version
- Version control in production:
- System must prevent loading of incorrect firmware version
- Automatic logging of version loaded to specific serial number
- Post-programming tests:
- Device startup and verification of basic security functions
- Secure boot test
- Verification of certificates and cryptographic keys
Risk scenario: If during production of a batch of 10,000 units, a vulnerable firmware version is loaded (e.g., containing hard-coded credentials), the manufacturer must:
- Report the incident within 24 hours
- Identify all affected units
- Notify distributors and end users
- Provide an update or conduct a recall
Without precise documentation of the programming process, the scale of the problem is impossible to determine.
2️⃣ Production batch identifiability
Batch numbering
The CRA requires each product to be identifiable (Art. 13(13)). In EMS production, this translates to:
Serial or batch numbers at PCB level:
- Applying identifier via laser marking, UV printing, or label
- Linking the number with production database
Identification at finished product level:
- Marking the enclosure (label, engraving)
- Digital twin – digital representation of physical device in MES system
Register of used components
Why is this critical in the CRA context?
In 2023, a critical vulnerability was discovered in a popular Wi-Fi module used in millions of IoT devices. Manufacturers who did not have a precise component register had to conduct costly analyses of each production batch to determine which devices were affected. This process took weeks – far exceeding the 24-hour reporting deadline required by the CRA.
Elements of component traceability system:
- Incoming Quality Control (IQC):
- Registration of component lot code upon receipt
- Verification of authenticity certificates from distributors
- Storage of samples from each batch (for later analysis if needed)
- Material Resource Planning (MRP) with traceability function:
- System must record which component batch was used in which PCB batch
- Link: Component Lot Code → PCB Batch Number → Finished Product Serial Number
- BOM change documentation:
- Each component change (e.g., replacement due to EOL) must be documented
- Marking the boundary point in production – from which unit the change was implemented
Ability to reconstruct production configuration
Practical scenario: It was discovered that during a specific time period (e.g., March 15-17, 2027), the reflow oven thermal profile parameters were incorrect, which could have affected the quality of solder joints on the cryptographic chip.
The traceability system must enable:
- Identification of all PCBs produced during this period
- Linking to finished product serial numbers
- Quick notification of customers about potential issue
Elements to document:
- Assembly process parameters:
- Thermal profiles (temperature, time, heating curve)
- Pick-and-place pressure and speed
- Type and manufacturer of solder paste (with batch number)
- Equipment calibration:
- Last calibration dates of AOI, X-ray, flying probe tester
- Software versions of production equipment
- Production environment:
- Temperature and humidity in ESD zone
- Cleanroom class (if applicable)
3️⃣ Supply chain control
Component authenticity
Counterfeit integrated circuits are a growing threat. According to a 2018 Semiconductor Industry Association report, fake components cost the U.S. semiconductor industry over $7.5 billion annually.
In the CRA context, a counterfeit component may contain a backdoor or known vulnerability of which the manufacturer is unaware. This violates the fundamental requirement of Annex I Point 2(1) – the product cannot contain known vulnerabilities at the time of market placement.
Methods for verifying component authenticity:
- Purchase from authorized distributors:
- Verification of distributor status with component manufacturer
- Requirement for certificates of authenticity (CoC – Certificate of Conformity)
- Physical and electrical tests:
- Marking analysis under microscope (counterfeits often have blurred markings)
- Electrical parameter testing (comparison with catalog data)
- X-ray inspection (verification of internal die structure)
- Blockchain for traceability:
- Some distributors are implementing blockchain systems to confirm supply chain authenticity
Risk of End-of-Life (EOL) components and substitutes
Problem: A component used in the design goes EOL (End-of-Life) status during the product lifecycle. The manufacturer must find a replacement.
Impact on CRA:
- The replacement may have different security properties (e.g., different cryptographic protocol implementation)
- Requires new risk analysis for cybersecurity
- May necessitate SBOM update and technical documentation
- In extreme cases – new testing and certification cycle
Role of professional EMS:
- Proactive Obsolescence Management:
- Monitoring PCN (Product Change Notification) and EOL notices status
- Early warning to customer about approaching component EOL
- Proposing alternative components while maintaining security properties
- Qualification of new components:
- Support in replacement qualification process
- Conducting comparative tests
- Validation of change impact on security functions
- Change documentation:
- Precise marking from which production batch the replacement was implemented
- BOM update in MES system
- Enabling customer to update SBOM
How can a professional EMS support manufacturers under CRA requirements?
It’s worth emphasizing: a professional EMS partner does not “implement CRA” for the client – legal responsibility for compliance with the regulation rests with the manufacturer (as defined by the CRA). However, properly organized production can significantly reduce operational risk associated with regulatory requirements.
Stable production processes
Standardization
ISO 9001 as foundation: A certified quality management system is the minimum in the context of CRA requirements. A professional EMS should have:
- Documented procedures for all production stages
- Process control – monitoring critical parameters in real time
- Non-conformities and corrective actions – CAPA (Corrective and Preventive Actions) system
Additional industry standards:
- IPC-A-610 – Acceptability of Electronic Assemblies standard
- IPC-J-STD-001 – Requirements for Soldered Electrical and Electronic Assemblies
- IEC 61340-5-1 – ESD protection standard
Adherence to these norms ensures process repeatability, which is crucial for CRA-required traceability.
Change control (Engineering Change Order – ECO)
ECO in the CRA context:
Every change in the production process that may affect product security must be:
- Documented – formal ECO procedure with change description
- Risk-assessed – analysis of impact on security functions
- Approved by the customer (manufacturer as defined by CRA)
- Marked in production – clear determination of implementation boundary point
Example changes requiring ECO:
- Change of component supplier (even if part number remains the same)
- Modification of reflow thermal profile
- Change of solder paste type
- Update of test equipment software
Technological documentation
Work Instructions and Process Flow:
Professional EMS maintains detailed process documentation:
- Assembly drawings – assembly diagrams with component orientation marking
- Process travelers – production cards accompanying each batch
- Inspection criteria – acceptance criteria for AOI, X-ray, functional tests
- Test procedures – test procedures, including security-related tests
This documentation constitutes part of proof of compliance with CRA requirements – proves that the production process is controlled and repeatable.
Full traceability
PCB batch
Unique Device Identifier (UDI):
Each PCB board (or finished product) receives a unique identifier that allows:
- Backward traceability: From finished product → to PCB batch → to component batches → to supplier
- Forward traceability: From component batches → to PCB batches → to finished products → to end customer
Identification technologies:
- QR code / Data Matrix – most commonly used, scannable in process
- RFID tags – for demanding environments (e.g., automotive)
- Laser marking – permanent PCB marking (non-removable)
Component batch
Linking component lot code with PCB serial number:
The MES (Manufacturing Execution System) should automatically record:
- From which reel/tray the component was taken
- Component manufacturer’s lot code (read from label)
- Component date code (production date by manufacturer)
- To which PCB board the component was mounted
Practical implementation:
- Barcode scanning at pick-and-place station – operator scans reel label before loading
- Automatic reel ID – SMD machine automatically reads RFID tag from reel
- Manual logging – for manually mounted components (THT)
BOM (Bill of Materials) version
During a product’s lifetime, the BOM may evolve (component changes, optimizations). The traceability system must:
- Version BOM – each change receives a new version number
- Link BOM version with production batch – in the MES system, record which BOM version was used for a given batch
- Enable version comparison – identification of differences between versions
Impact on CRA: If a component containing a vulnerability was changed in a new BOM version, the manufacturer can quickly identify which product batches are affected (only those produced according to the old BOM version).
Firmware version
Firmware Version Control in production:
1. Secure firmware storage:
- Firmware is stored on a secured server
- Each version has a unique hash (SHA-256)
- Access control system – only authorized operators can download firmware
2. Programming station:
- Programmer verifies firmware hash before loading
- After loading, readback is performed – device memory read and comparison with original
- Automatic logging: Serial Number → Firmware Version → Date/time → Operator ID
3. Database recording:
- MES system records which firmware version was loaded to which serial number
- Enables later identification of all devices with a specific version
Use scenario: A critical vulnerability was detected in firmware v2.3.1. The MES system shows that:
- Firmware v2.3.1 was loaded to devices SN 10000-15000
- These devices were produced in March 2027
- Distributor X received 3000 units from this range
- Manufacturer can immediately notify distributor and end users
Programming and testing
Secure firmware loading
Secure Boot Chain:
A professional firmware loading process in the CRA context should include:
- Firmware source verification:
- Firmware is digitally signed by the manufacturer (EMS client)
- Programmer verifies signature before loading
- Prevents loading of unauthorized firmware
- Encrypted firmware transfer:
- Firmware is transferred in encrypted form from server to programmer
- Decryption occurs only in the target device (if equipped with secure element)
- Device authentication:
- Before programming, device authenticity is verified (not counterfeit)
- E.g., through reading unique chip ID (UID)
Version control
Version Lock-Out Mechanism:
The production system should prevent loading of incorrect firmware version. Example workflow:
- Work Order specifies:
- PCB batch number: LOT-2027-0315
- Required firmware version: v3.1.5
- Required hardware version (PCB revision): Rev B
- Programmer verifies:
- Whether firmware v3.1.5 is compatible with hardware Rev B (database check)
- Whether operator is attempting to load the correct version
- If mismatch – lockout and alarm
- After loading:
- Readback and verification
- Automatic recording in MES system: “Device SN 10523 programmed with FW v3.1.5 at 2027-03-15 14:32 by Operator ID 045”
Functional tests before shipment
Post-Programming Functional Test:
After loading firmware and closing the enclosure, the device must undergo comprehensive functional testing. In the CRA context, the test should include:
1. Security Functions Test:
- Boot Sequence: Device starts correctly, secure boot verifies firmware integrity
- Authentication Test: Test of login mechanisms, verification of no default passwords
- Encryption Test: If device encrypts data, test encryption/decryption correctness
- Communication Security: Test of secure communication protocols (TLS, HTTPS, SSH)
2. Interface Test:
- Test of all communication ports (Ethernet, USB, RS-485, etc.)
- Verification that unsecured diagnostic ports are disabled or properly secured
3. Firmware Version Verification:
- Reading firmware version via interface (e.g., CLI, API)
- Comparison with expected version from Work Order
Test results documentation:
- Each test generates a Pass/Fail report for each device
- Reports are archived and linked to serial number
- In case of Fail – device doesn’t leave the line, Root Cause Analysis begins
Support in redesign
Component changes for security
Scenario: The manufacturer (EMS client) learns that a component used in their product contains a vulnerability. A replacement must be found.
Role of professional EMS in the process:
- Component Recommendation:
- EMS engineers propose alternative components with similar parameters
- Key: Replacement must meet the same or higher security requirements (e.g., support TLS 1.3, not only 1.2)
- Risk Assessment Support:
- Help in assessing whether component change affects security functions
- Analysis of whether recertification is required (for “important” or “critical” category products – probably yes)
- Prototyping and Testing:
- Quick production of prototypes with new component
- Conducting functional and security tests
- Verification that change doesn’t introduce new vulnerabilities
- Qualification Run:
- Production of small series (e.g., 50-100 units) with new component
- Extended testing – accelerated reliability tests, environmental tests
- Confirmation that large-scale production is possible
DFM/DFT (Design for Manufacturing / Design for Testing) consultations
DFM in the CRA context:
Professional EMS offers Design Review at the project stage, allowing avoidance of production problems that could affect security.
Example DFM recommendations affecting security:
- Component Placement:
- Cryptographic chips and secure elements should be placed in hard-to-access locations on PCB
- Limits possibility of physical attacks (probing, bus sniffing)
- Test Points:
- Test points are needed in production phase to verify security functions
- But in final product should be removed or secured (potted with epoxy) to prevent unauthorized access
- Debug Interfaces:
- JTAG, SWD interfaces used in development phase must be disabled or secured in final production
- DFM: Recommendation that PCB design considers possibility of physically cutting debug interface (jumper, fusible link)
DFT in the CRA context:
Design for Testability means designing with testability in mind. In the CRA context:
- Testability of Security Functions:
- Design must enable testing of security functions on production line
- E.g., encryption test requires API access – test interface should be designed
- Built-In Self-Test (BIST):
- Embedding self-test security functions in firmware
- Ability to run test from command line during production
- Boundary Scan (IEEE 1149.1 JTAG):
- Enables testing of PCB connections without physical test points
- Useful in production phase, but JTAG must be disabled later (secure boot lockdown)
Practical EMS support:
- Design Review Meetings: EMS engineers meet with client’s R&D team at project stage
- DFM Report: Detailed report with design analysis for manufacturability and testability
- Security-focused recommendations: Specific recommendations regarding security aspects (e.g., “We suggest adding test point for secure boot verification, but with possibility of physical removal in production version”)
How to prepare now? Checklist for manufacturers
The CRA fully comes into effect on 11 December 2027, but reporting obligations start on 11 September 2026 – less than 2 years from today. Here’s a practical action checklist:
☑ Verify whether your device is subject to the CRA
Verification steps:
- Does the product have digital elements?
- Firmware, embedded software, software components – YES
- No software, purely mechanical – NO
- Does the product connect to another device or network?
- Directly (Wi-Fi, Ethernet, Bluetooth) – YES
- Indirectly (through gateway) – YES
- Doesn’t connect at all – NO (exception: if updateable via USB, still YES)
- Is the product placed on the EU market as part of commercial activity?
- Sale within EU – YES
- Only for internal company use (not placed on market) – NO
- Open-source without monetization – NO (with exceptions, see Art. 18 CRA)
- Is the product excluded by other regulations?
- Medical devices (per Reg. 2017/745, 2017/746) – YES, excluded
- Vehicles (per Reg. 2019/2144) – YES, excluded
- Aviation (certified per Reg. 2018/1139) – YES, excluded
- Other products – Likely subject to CRA
☑ Check product category (default / important / critical)
Product categories according to CRA:
1. Default – approximately 90% of all products
- Conformity assessment: Self-assessment by manufacturer
- Requirements: Meet essential cybersecurity requirements (Annex I)
- Examples: Most IoT devices, consumer electronics
2. Important – Annex III CRA
- Conformity assessment: In most cases, assessment by notified body required
- Criteria: Product performs function carrying significant risk in terms of impact on health, safety, or protection of users
- Examples from Annex III:
- Class I: Identity management systems, web browsers, password managers, VPN
- Class II: Microcontrollers, microprocessors, operating systems for servers/PC/mobile, smart cards
- Class II: Routers, switches, firewalls, smart locks, alarm systems, baby monitors
3. Critical – Annex IV CRA
- Conformity assessment: Assessment by notified body
- Criteria: Product meets “important” criteria and is used in critical infrastructure context or performs critical function within networks or services
- Examples from Annex IV:
- PKI (Public Key Infrastructure) device management
- Virtualization hypervisors
- Industrial firewalls and IDS/IPS
How to determine category?
- Check Annex III and IV of CRA – products are listed with descriptions
- If product not on list → “Default” category
☑ Ensure you have production version documentation
Minimum required documentation:
- Version Matrix:
- Table of relationships: Hardware Version ↔ Compatible Firmware Versions
- Example: PCB Rev. B is compatible with Firmware v2.x.x and v3.x.x, but not v1.x.x
- Changelog for each version:
- What was changed in each version
- Whether change relates to security functions (if yes, requires special attention)
- Configuration Management Plan:
- Version control procedures
- Who has authority to approve new versions
- ECO (Engineering Change Order) process
If you don’t have this documentation:
- Start now – even if product is already on market
- Retrospective reconstruction – review Git history, production documents, emails – reconstruct version history
- Define “baseline” – current version becomes baseline from which all changes will be documented
☑ Ensure component identifiability
What needs to be implemented:
- Component Traceability System:
- MES or ERP system with traceability function
- Registration of component lot codes upon material receipt
- Linking lot code → PCB batch number → product serial number
- SBOM Generation:
- Use tools to generate SBOM (e.g., Syft, CycloneDX, SPDX tools)
- SBOM should be in machine-readable format (JSON, XML)
- Update SBOM with each component change
- Supplier Declarations:
- Require compliance declarations or certificates from component suppliers
- For “important” category components – verify they have CE marking (after 2027)
Practical tools:
- Open-source SBOM tools: Syft (Anchore), CycloneDX CLI, SPDX Tools
- Commercial solutions: Finite State, Fortress, FOSSA
- ERP/MES integration: Many systems (SAP, Oracle, Epicor) offer traceability modules
☑ Ensure firmware control at production stage
Procedures to implement:
- Firmware Release Process:
- Each firmware version intended for production must be formally “released”
- Firmware is digitally signed by R&D
- Firmware hash is recorded in database
- Production Programming Procedure:
- Programmer downloads firmware from central server (not from operator’s local disk)
- Before programming – hash verification
- After programming – readback and verification
- Automatic logging: SN → FW version → Timestamp → Operator
- Version Control in Production:
- Work Order specifies firmware version for given batch
- System blocks loading of different version
- Alert if operator tries to use wrong version
- Archive and Retention:
- All firmware versions are archived for at least 10 years (CRA requirement Art. 13(9))
- Documentation of which version was used in which production period
☑ Choose a production partner that ensures traceability
Criteria for selecting EMS in the CRA context:
- Certificates and standards:
- ISO 9001 (quality management) – minimum
- ISO/IEC 27001 (information security management) – recommended
- IPC-A-610 (acceptability of assemblies standard) – required
- IATF 16949 (automotive, if applicable)
- IT systems:
- Having MES (Manufacturing Execution System) with traceability
- Ability to generate reports: Component lot code → PCB batch → Serial numbers
- Integration with client’s system (API, EDI)
- Experience in regulated industries:
- Production for medical, automotive, aerospace sectors – these sectors already have high traceability requirements
- Experience with audits and compliance
- Physical and cyber security:
- Secured production space (access control)
- Cybersecurity in production systems (secured firmware server)
- Data protection procedures (GDPR compliance as maturity indicator)
- Technical support:
- Engineers with experience in embedded security
- DFM/DFT consultation capability
- Support in redesign and obsolescence management
Questions to ask potential EMS partner:
- “Does your MES system register component lot codes and can link them to product serial numbers?”
- “How long do you retain production documentation?” (CRA requires minimum 10 years)
- “Do you have procedures for secure firmware programming with version control?”
- “Do you conduct functional tests verifying security functions (e.g., secure boot)?”
- “What systems do you use to verify component authenticity?”
Summary – regulation as risk but also competitive advantage
The Cyber Resilience Act is not merely a legal regulation imposing additional obligations. It’s a paradigm shift in the approach to designing, producing, and maintaining electronic devices in the European Union. The CRA clearly communicates: cybersecurity is a fundamental requirement, on par with electrical safety or electromagnetic compatibility.
Production has strategic importance
Traditionally, cybersecurity was perceived as the domain of programmers – secure coding, penetration testing, code analysis. The CRA extends this to the entire value chain, including physical production. An improperly programmed PCB series, use of counterfeit component, lack of batch traceability – all can result in mass security breach, obligation to report within 24 hours, and potentially costly recall.
For manufacturers, this means choosing an EMS partner is no longer just a decision about costs and timelines – it’s a decision about the ability to meet regulatory requirements and manage cyber risk.
Competitive advantage of early adopters
Companies that proactively implement CRA requirements before 2027 will gain market advantage:
- Faster product market entry:
- When CRA becomes mandatory, unprepared companies will have to go through a long process of audit, corrections, re-testing
- Early adopters will go through this process earlier, without time pressure
- Better negotiating position:
- B2B customers (especially in regulated sectors – finance, critical infrastructure) already require high cybersecurity levels from suppliers
- Having CRA-compliant CE marking will become a tender requirement
- Lower operational risk:
- Full traceability and supply chain control is not just compliance – it’s a quality management tool and rapid response to problems
- Reduction of risk of costly recalls and reputation loss
- Ability to expand to non-EU markets:
- Other jurisdictions (USA, Australia, Japan) are working on similar regulations
- Experience with CRA will facilitate adaptation to future regulations in other regions
Role of professional production partner
Choosing a professional EMS partner who understands CRA requirements is not an investment in “regulation implementation” – it’s an investment in operational stability and ability to respond quickly to security incidents.
Professional EMS:
- Ensures traceability – enables identification of affected products within hours, not weeks
- Controls supply chain – minimizes risk of counterfeit components and unauthorized firmware
- Supports certification process – provides production documentation required for conformity assessment
- Enables rapid response – in case of vulnerability detection, ability to reprogram batches or withdraw specific serial numbers
In practice, security starts not only in code, but also on the assembly line. The Cyber Resilience Act is recognition of this truth at the EU legislative level.
Sources
- Regulation (EU) 2024/2847 of the European Parliament and of the Council of 23 October 2024 on horizontal cybersecurity requirements for products with digital elements (Cyber Resilience Act). Official Journal of the European Union, L, 2024/2847. Available: https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng
- European Commission – Digital Strategy. “Cyber Resilience Act | Shaping Europe’s digital future”. Available: https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act
- TXOne Networks. “The Cyber Resilience Act: A Guide for Manufacturers”. April 18, 2025. Available: https://www.txone.com/blog/cra-guide-for-manufacturers/
- Anchore. “EU CRA SBOM Requirements: Overview & Compliance Tips”. Updated June 4, 2025. Available: https://anchore.com/sbom/eu-cra/
- Cyber Resilience Act official resource. “Annex VII – Content of the technical documentation”. Available: https://cyber-resilience-act.com/annexes/annex-vii/
- The Embedded Kit. “The 3 product categories covered by the Cyber Resilience Act”. June 2025. Available: https://theembeddedkit.io/blog/product-categories-cyber-resilience-act/
- PCBONLINE. “PCB Component Traceability: The Complete Guide”. Available: https://www.pcbonline.com/blog/PCB-Component-Traceability.html
- Siemens Digital Industries Software. “Are Counterfeit PCBA Parts Still A Risk In 2025?”. Available: https://siemensmfg.com/electronics-manufacturing-trends/are-counterfeit-pcba-parts-still-a-risk-in-2025/
- Semiconductor Industry Association. “Detecting and Removing Counterfeit Semiconductors in the U.S. Supply Chain”. 2018. Available: https://www.semiconductors.org/wp-content/uploads/2018/06/ACTF-Whitepaper-Counterfeit-One-Pager-Final.pdf
- Finite State. “Understanding The EU CRA’s SBOM & Technical Documentation Requirements”. Available: https://finitestate.io/blog/eu-cra-sbom-technical-documentation-guide
- Memfault. “EU Cyber Resilience Act: A Guide for Manufacturers & Developers”. Available: https://memfault.com/blog/eu-cyber-resilience-act-guide/
- ENISA (European Union Agency for Cybersecurity). “Cyber Resilience Act Requirements Standards Mapping”. November 2024. Available: https://www.enisa.europa.eu/sites/default/files/2024-11/Cyber Resilience Act Requirements Standards Mapping
- NTT DATA Benelux. “Cyber Resilience Act: What manufacturers must do”. Available: https://benelux.nttdata.com/insights/blog/cyber-resilience-act-what-manufacturers-must-do
- Taylor Wessing. “Cyber Resilience Act: Overview for affected companies”. 2025. Available: https://www.taylorwessing.com/en/insights-and-events/insights/2025/11/cyber-resilience-act-overview
- ArmorCode. “EU Cyber Resilience Act (CRA) Requirements Guide”. Available: https://www.armorcode.com/learning-center/eu-cyber-resilience-act-cra-requirements-guide
Legal disclaimer: This article was prepared based on the official version of Regulation (EU) 2024/2847 and publications from European institutions and specialized industry firms. It does not constitute legal advice. In case of doubts regarding the application of the CRA to a specific product, consultation with a lawyer specializing in EU law and with a notified body is recommended.
