01 / Security-by-Design, Full-Lifecycle Management and Control, and Coordinated Vulnerability Handling System
Our company has fully launched a review and upgrade of our products, R&D processes, and supporting documentation systems to meet the compliance requirements of the EU Cyber Resilience Act (CRA), while simultaneously implementing the already-in-force EU RED cybersecurity requirements (RED DA / EN 18031). Centered on security-by-design, full-lifecycle product security governance, and a standardized coordinated vulnerability handling process, the entire compliance program covers the establishment of end-to-end compliance evidence for Bluetooth wireless modules.
1.1 Core Points of the CRA Regulation
The CRA establishes unified mandatory cybersecurity requirements for products with digital elements placed on the EU market, covering five core obligations: secure development processes, closed-loop vulnerability handling, user security instructions, complete technical documentation, and long-term security update assurance.
Our existing product security specifications, PSIRT response mechanism, and third-party security certification system are already aligned with the CRA requirements, and we continue to refine the supporting materials to provide customers with complete CRA compliance delivery support.
1.2 Key CRA Timeline
2024.12.12
Published and entered into force in the Official Journal of the EU
2026.09.11
EU unified vulnerability reporting obligations take effect
2027.12.11
Full mandatory compliance with all CRA provisions; digital products sold in the EU must complete compliance demonstration
02 / RED DA / EN 18031 Transitional Compliance
2.1 / Scope of Application: RED Cybersecurity Clauses 3.3(d)(e)(f) Are Mandatory for Our Modules
The cybersecurity requirements in RED Article 3.3(d)(e)(f) became mandatory on 2025.08.01 via Delegated Regulation (EU) 2022/30 (RED DA), applying to the relevant categories of radio equipment defined therein. Our WiFi modules and the Bluetooth modules used in the aforementioned scenarios fall within the scope of application and must satisfy: network protection 3.3(d), personal data and privacy protection 3.3(e), and fraud protection 3.3(f).
2.2 / Harmonised Standards Pathway: EN 18031 Series Cited by the EU
The EU has listed EN 18031-1/-2/-3:2024 as harmonised standards for RED 3.3(d)(e)(f) (corresponding to network protection, data and privacy protection, and financial asset protection respectively). Compliance with these standards gives a presumption of conformity, enabling customers to complete their CE Declaration of Conformity. We are building module-level assessment evidence in accordance with this series of standards, directly supporting our customers' end-product certification.
2.3 / Module-Level Compliance Evidence We Provide
- Module-level conformity statements and self-assessment reports against EN 18031-1/-2/-3;
- Security design documentation (secure boot, hardware encryption, key isolation, secure-by-default configuration) and PSA / ISO 27001 security assessment certifications;
- PSIRT vulnerability handling and security update mechanism;
- End-product integration security guidance and configuration hardening guidelines.
03 / Five Core CRA Compliance Capability Areas
Area 1: Cybersecurity Risk Assessment (Cyber Risk Assessment)
Standardized Product Cybersecurity Risk Assessment System
- Hardware security foundation: self-developed secure encryption engine, root-of-trust boot, and physical tamper protection, benchmarked against the PSA security certification scheme, with the ability to issue graded security assessment reports;
- Enterprise security management certification: the entire R&D process follows the ISO 27001 information security management system, with risk control processes embedded across definition, development, testing and mass production;
Under the CRA, products are classified according to their cybersecurity-related functions or intended use and the level of cybersecurity risk they present. This classification determines the steps a manufacturer must take to achieve compliance.
Feasycom Bluetooth / WiFi modules are expected to fall under the “default” category; if deemed to constitute a physical network interface or similar cases, they may fall under “Important Class I”. The corresponding conformity assessment routes are as follows: default-category products use self-assessment (internal production control), under which we issue the EU Declaration of Conformity (EU DoC) and affix the CE marking; Important Class I products require the involvement of a notified body, with the option of EU type examination or full quality assurance.
Based on the above classification, we will proactively build the corresponding compliance evidence system and provide compliant products to customers, serving as the security cornerstone on which customers build their own solutions.
Area 2: General Compliance Baseline Requirements (General Requirements)
End-to-End Secure Development Compliance Assurance
- Security-by-design: modules integrate hardware encryption, secure boot and isolated key storage; software development implements secure coding standards, code audits, fuzzing and penetration testing throughout the entire process;
- Full-lifecycle vulnerability management: an internal closed-loop vulnerability tracking process covering requirements, development, mass production and after-sales stages, with complete handling records retained;
Area 3: Customer-Facing Security Guidance Documents (Information and Instructions to the Users)
Developer CRA Compliance Guidance and Training Resources
- Standardized development documentation: we provide Bluetooth module security development manuals, security configuration specifications and CRA compliance implementation guides, available for review in our online documentation center;
Area 4: CRA Compliance Technical Documentation Delivery (Technical Documentation)
Deliverable CRA Technical Documentation Support
To maximize security throughout the entire product lifecycle, the CRA requires documentation of several key aspects, including risk assessments, the EU Declaration of Conformity, the software bill of materials (SBOM), and a statement of the support period. The support period defines the minimum period during which the supplier plans to maintain CRA compliance.
Feasycom is currently reviewing our existing mature processes to ensure compliance with the CRA documentation requirements.
Area 5: Security Reporting and Response System (Reporting Requirements)
PSIRT Team and CRA Compliance Reporting Mechanism
- PSIRT security incident response team: we have established an independent vulnerability intake channel, a standardized coordinated vulnerability disclosure policy, and fixed response-time processes; for more information, please visit the Feasycom PSIRT page.
- Actively exploited vulnerabilities: upon learning of a vulnerability that has been actively exploited, issue an early warning notification to the CSIRT-designated coordinator and ENISA within 24 hours; issue a vulnerability notification within 72 hours providing the nature of the vulnerability, the specific circumstances involved, and the measures taken. Submit a final report within 14 days after corrective or mitigating measures have been taken.
- Severe security incidents affecting product security: upon learning of a severe incident affecting product security, issue an early warning notification to the CSIRT-designated coordinator and ENISA within 24 hours; submit an incident notification within 72 hours providing summary information on the nature of the incident, a preliminary assessment of the incident, and the measures taken. Issue a final report within one month after submission of the 72-hour incident notification.
