EU Cyber Resilience Act: China Sourcing Checks

The reporting start date has arrived. This update replaces the July planning guidance with a shipment handoff for the September 2026 reporting stage. The December 11, 2027 date remains the main application date for CRA product requirements; September 2026 is not a universal deadline for a CRA declaration of conformity or new CRA labelling.

Article 69 also brings products placed on the market before December 11, 2027 within Article 14 reporting. A buyer should therefore include existing EU product lines in the ownership discussion, not only the next purchase order. Keep any CE obligations that already apply under other legislation in the current release file.

Identify the manufacturer before asking who will file a report. The Commission describes the manufacturer as the person or organisation placing the product on the market under its name or trademark. A private-label buyer may therefore carry manufacturer responsibilities even when another business designs or assembles the device.

Ask the responsible team to confirm roles in writing. The sourcing file should show the company identity and the contacts who can reach the firmware developer, assess an alert, approve a fix and communicate with customers. A supplier promise to “handle compliance” is too vague to explain who acts when a security issue appears.

For an actively exploited vulnerability or a severe incident, the manufacturer must issue an early warning without undue delay and within 24 hours of awareness, followed by a notification within 72 hours. For an actively exploited vulnerability, the final report is due no later than 14 days after a corrective or mitigating measure becomes available. For a severe incident, it is due within one month after the 72-hour notification.

These are event-reporting clocks, not shipment-document deadlines. Not every bug or failed inspection is reportable. The responsible security team must assess the event against the legal criteria. A sourcing team should preserve when information arrived, which versions may be affected and whom it notified; it should not wait for a complete inspection report before escalating a credible concern.

ENISA’s launch FAQ says Assigned Representatives use personal EU Login accounts with multi-factor authentication. Prepare the contact and access route, but do not require an advance SRP registration certificate from every supplier: ENISA advises initiating registration when a notification is needed. At launch, reporting uses the platform interface; there is no reporting API.

The launch supports mandatory manufacturer reports. Voluntary reporting is deferred, and open-source software steward reporting starts December 11, 2027. ENISA also distinguishes awareness before September 11, 2026 from awareness after that date; an older vulnerability can still trigger reporting when active exploitation becomes known later.

For the buyer, the useful deliverable is a named owner and a reliable technical handoff. Do not collect personal login credentials or file dummy incidents to test a supplier. Let the responsible manufacturer follow ENISA’s current registration and notification instructions.

Use one version register for the approved reference and the shipment. Record SKU, hardware revision, firmware build, app version, relevant remote service and the date of observation. Capture version screens only through access the supplier and buyer authorise. Link the photographs and observations to sampled serial numbers or lot identifiers.

An unchanged enclosure or barcode does not explain a firmware substitution. If the factory updates units after inspection, ask which quantities changed and obtain a new version list. Where a version cannot be read, record that limit. The buyer should decide with its technical owner whether further access, engineering review or re-inspection is needed before release.

Plan separately for the main CRA requirements: cybersecurity risk assessment, technical documentation, conformity assessment, an EU declaration of conformity, CE marking and support information. A qualified owner should confirm product scope, any important or critical category, applicable exclusions and the conformity route. The Commission’s summary explains these product obligations.

For sourcing, keep a file index and revision history so that future technical documents describe the device actually ordered. Existing radio, electrical-safety, battery or other product rules may already require evidence. A CE logo or generic laboratory report cannot by itself answer whether the software, support process or CRA conformity plan is adequate.

What happened: in February 2014, the U.S. Federal Trade Commission approved a final order settling charges against TRENDnet. The FTC alleged that cameras marketed as secure contained software flaws that exposed private video feeds. The settlement required a security programme, independent assessments and customer notification about corrective software updates.

Public evidence: the FTC announcement and case docket contain the complaint and order. Buyer lesson: a functioning camera and a matching retail box cannot establish secure software or a workable customer-update process. The shipment record needs a usable link between the device version and the people responsible for security and fixes.

Limits: this older U.S. settlement is not a CRA enforcement decision, a finding about Chinese factories, or evidence that a current supplier has the same fault. It remains relevant because version identification and update communication are still practical sourcing handoff problems. Huang Sourcing did not participate in this case.