Cyber Resilience Act (CRA) Article 14 Reporting & User Protection
Robustel has established the people, processes and escalation arrangements required to meet its reporting obligations under Article 14 of the EU Cyber Resilience Act. These measures are designed to support timely security response, clear regulatory accountability and practical communication with affected users when significant product security events occur.
Need help understanding the status for a specific security requirement in your region please reach out to us below.
Robustel Cyber Resilience Act Article 14 Reporting and User Protection Statement
Reporting obligations applicable from 11 September 2026 | Guangzhou Robustel Co., Ltd. | Regulation (EU) 2024/2847
はじめに
Robustel has established the people, processes and escalation arrangements needed to fulfil its manufacturer reporting obligations under Article 14 of the EU Cyber Resilience Act (CRA), applicable from 11 September 2026. These arrangements support the protection of users of Robustel products by connecting security assessment, regulatory reporting, technical remediation and timely user communication.
This statement explains how qualifying security events are handled and what users can expect. The vulnerability reporting and user-protection arrangements described in this statement are available to Robustel users, partners and security researchers worldwide. Users do not need to determine whether a concern qualifies for reporting under the CRA before submitting it.
For CRA reporting purposes, this statement covers Robustel products with digital elements made available on the EU market, including RobustOS routers, RobustOS Pro edge gateways, the MG460 family and RCMS. In accordance with Article 69(3), Article 14 also applies to in-scope products placed on the EU market before 11 December 2027.
It covers Article 14 reporting preparedness; it is not an EU Declaration of Conformity or a statement of full CRA product conformity.
What this means for users
Article 14 provides a defined route for significant product security events to reach European cybersecurity authorities.
For Robustel users, our arrangements mean:
- Clear accountability – A dedicated Product Security Incident Response Team (PSIRT) coordinates assessment, escalation and response.
- Timely risk information – Affected users receive known risk information and available guidance without waiting for a final patch.
- Practical action – Regulatory reporting, investigation and user notification proceed in parallel, with updates as verified measures become available.
- A direct reporting route – Users and researchers can report a concern without first classifying its severity or CRA status.
Article 14 – At a Glance
ロバステル寿命終了プロセスは、国際的なライフサイクル管理基準に沿った構造化された手順に従います。各EoLフェーズは明確に定義されており、移行期間を通じて予測可能性とサポートを提供します。
|
Manufacturer |
Guangzhou Robustel Co., Ltd. (Robustel) |
|---|---|
|
Scope and Start Date |
Article 14 reporting obligations from 11 September 2026 |
|
Reporting Channel |
ENISA CRA Single Reporting Platform (SRP) |
|
Response Ownership |
PSIRT, authorised reporting personnel, primary and deputy contacts, and out-of-hours escalation |
|
Supporting Assurance |
IEC 62443-4-1 certified development process within its certificate scope; independent testing and published security resources |
Reporting and response arrangements
Our PSIRT coordinates product security response across security, engineering and product teams. Authorised personnel submit notifications through the SRP to the applicable Computer Security Incident Response Team (CSIRT) designated as coordinator and to ENISA. Our security management platform links affected products and versions, response tasks, reports and supporting evidence.
Robustel will report actively exploited vulnerabilities contained in Robustel products with digital elements, and severe incidents affecting the security of those products, where the products fall within the scope of the CRA. Triage assesses the statutory criteria, rather than relying on a severity score alone.
- Actively exploited vulnerabilities. Reliable evidence of unauthorised exploitation by a malicious actor triggers assessment for reporting; a theoretical weakness or severity rating alone is not the same as active exploitation.
- Severe incidents. The CRA criteria include actual or potential impairment of protection for sensitive or important data or functions, or actual or potential introduction or execution of malicious code in a product or a user’s systems.
|
Timing |
Stage |
Reporting Requirement |
|---|---|---|
|
Within 24 hours of awareness |
Early warning |
Submit without undue delay. Identify relevant Member States where applicable; for incidents, indicate suspected unlawful or malicious acts. |
|
Within 72 hours of awareness |
Notification |
Submit without undue delay, with available product and event details, initial assessment as applicable, measures taken and measures users can take, and information sensitivity where applicable. |
|
No later than 14 days after a corrective or mitigating measure is available |
Vulnerability final report |
Describe severity and impact, available information about the malicious actor, and the security update or other corrective measures. |
|
Within one month after submission of the 72-hour incident notification |
Incident final report |
Describe severity and impact, the likely threat or root cause, and applied and ongoing mitigation measures. |
The 24-hour and 72-hour periods both run from awareness of the reportable event; they are not consecutive allowances. Notifications and final reports need not repeat information already provided. These are reporting deadlines, not promised remediation times.
Legal reference: CRA Article 14. Reports are updated as further information becomes available; intermediate status reports are provided when requested by the coordinating CSIRT.
How reporting will operate
- Defined regulatory routing. Notifications are submitted through the SRP using the electronic endpoint of the applicable CSIRT designated as coordinator, identified in accordance with Article 14(7), and are simultaneously accessible to ENISA. Robustel documents and keeps this routing determination under review as part of its internal reporting procedure.
- PSIRT escalation and continuity. Designated primary and deputy contacts and out-of-hours escalation support prompt assessment and reporting. Internal approval arrangements account for statutory deadlines, including weekends and non-working hours.
- Traceable case management. Affected products and versions, response tasks, submissions and evidence remain linked in our security management platform so that response activity can be followed through the case.
- Structured technical assessment. Security and product teams assess reportability and escalate qualifying events promptly. Investigation, impact assessment and remediation continue alongside reporting, with updates as findings are verified.
User protection and security information
- Parallel response. Regulatory reporting, technical investigation and remediation, and user notification proceed in parallel.
- Timely notification. We promptly inform affected users and, where appropriate, all users of the product about the vulnerability or incident and its risks. We provide available corrective or mitigating measures and guidance where necessary.
- Actionable updates. Known risk information does not wait for a final patch or for mitigation guidance to become available. We provide available, verified guidance and update users as further measures become available.
- Direct communication. Public advisories supplement necessary targeted notices; they do not replace them. Information is provided in a structured, machine-readable format where appropriate under Article 14(8).
Reporting a security concern
Found a potential security issue? Please tell us.
You do not need to determine its severity or whether it qualifies for CRA reporting; our security team will assess it.
Report a vulnerability through the Security Centre reporting route, or contact Robustel Technical Support.
- What to include. Product or service name, version, a description, discovery time and reproducible steps where available. Use redacted logs or screenshots and avoid sharing live customer data or credentials.
- Acknowledgement and urgency. Reachable reporters receive acknowledgement as soon as practicable and no later than seven calendar days after receipt.Urgent risks enter immediate assessment and escalation without waiting for that deadline. Acknowledgement does not mean remediation is complete and does not extend CRA reporting deadlines.
ロバステル センター
The Security Centre brings together vulnerability reporting, security advisories, firmware and software updates, hardening guidance and supporting assurance evidence. These resources help users assess security and maintain their deployments.
Certified secure development
Robustel’s Cyber Security Development Process V1.0 is certified against IEC 62443-4-1:2018 at Maturity Level 2 under the IECEE Industrial Cyber Security Capability scheme. Certificate FR_Cyber10116 was issued on 9 January 2024 by LCIE. LCIE certificate FR_Cyber10116 covers security management, requirements, secure design and implementation, verification and validation, security issue handling, update management and security guidance.
The assessed requirements include threat modelling, security implementation review, vulnerability and penetration testing, independence of testers, and management of security issues and updates. This is certification of the defined development process within the certificate’s scope; it does not certify every product or establish CRA conformity.
Independent security testing
Public assessment summaries cover the platforms below. Each summary identifies the tested scope and findings; detailed reports are available to qualified customers and security assessors under an appropriate confidentiality agreement.
Robustel Cloud Manager Service — RCMS Cloud
Independent cloud platform security assessment
Assessment date: 15 July 2026
Scope: Production and beta RCMS web applications
Outcome: No Critical or High-severity vulnerabilities identified.
ロバストOS
Independent embedded Operating System security assessment
Assessment date: 15 July 2026
Scope: RobustOS running on a Robustel industrial router
Outcome: No Critical, High, Medium or Low-severity vulnerabilities identified.
ロバストOS プロ
Independent Edge Operating System security assessment
Assessment date: 13 April 2026
Scope: Authenticated grey-box review of RobustOS Pro running on an EG5120 edge computing gateway, informed by applicable CIS Linux benchmarks
Outcome: No Critical, High, Medium or Low-severity vulnerabilities identified.
Testing provides evidence for the assessed versions, configurations and date. It does not guarantee the absence of vulnerabilities. Ongoing security maintenance and applying relevant updates remain important.
Need the Detailed Technical Reports?
The complete assessment reports contain detailed technical findings, supporting evidence, testing methodology and remediation recommendations. These reports can be provided to qualified customers, partners and security assessors under an appropriate confidentiality agreement.
Please identify the report or reports required and provide brief details of the relevant project, procurement process or security review.
Scope and legal note
This statement addresses preparedness for CRA Article 14 reporting obligations from 11 September 2026. The wider CRA conformity regime applies from 11 December 2027. Article 14 also applies to in-scope products placed on the market before that date, as specified in Article 69(3).
This statement is not an EU Declaration of Conformity and does not replace product conformity assessment. Product capabilities, support periods and certification scope remain governed by the applicable product documentation and valid supporting records. Nothing in this statement limits Robustel’s legal obligations.
Regulatory basis: Regulation (EU) 2024/2847 — Articles 14, 69 and 71