CRA non-EU manufacturers are businesses outside the European Union that make in-scope products available on the EU market. A headquarters in China, Taiwan, Turkey, the US or the UK does not by itself remove the manufacturer’s product-security, documentation or reporting responsibilities.
Map the economic-operator roles
| Role | What to establish | Evidence to collect |
|---|---|---|
| Manufacturer | Who places the product under its name or trademark | Product identifiers and responsible entity |
| Importer | Which EU entity brings it to the market | Supply-chain and conformity checks |
| Distributor | Which channel makes it available | Relevant handling and verification process |
| Authorised representative, if used | Which written mandate and permitted tasks apply | Mandate and named contacts |
Do not assume the importer becomes the manufacturer for every duty. Do not assume a commercial distributor agreement automatically establishes an authorised representative. The contractual and legal roles need a qualified review, especially for private-label products and brands that change across markets. Keep the product identifier and economic operator details consistent across packaging, technical documentation and declarations.
A common cross-border engineering problem
A European sales team may receive a vulnerability report before the firmware engineering team starts work in another time zone. Establish an escalation contact and a backup that can preserve the awareness timestamp and act within the reporting windows. The clock is measured from relevant awareness, not from the start of the engineering team’s next working day. Agree who can approve and submit an early warning.
SRP coordinator selection for a non-EU manufacturer needs to be understood before an incident. Consult ENISA’s current guidance and the relevant establishment and market rules. Prepare product, contact and role information in advance. Roja prepares drafts and tracks deadlines; the manufacturer reviews and submits. An internal portal entry is not evidence that ENISA received a notification.
Build stacks and sharing boundaries
Products may combine Yocto or Buildroot firmware, an Android interface, ESP-IDF or Zephyr controllers, and a companion app. Begin with the version actually shipped into the EU. Check whether regional variants use different components or update channels. An SBOM generated for a domestic release should not silently stand in for the EU image if those builds differ.
Agree which artifacts can be shared and how access is authorised. A component inventory, firmware image or container can be a starting point, but some conclusions may require source or build evidence. Record the limitation rather than asking the customer to assume a scan covers everything. Define EU hosting, authorised reviewers, retention and deletion in writing before transferring sensitive build material.
Illustrative scenario: an EU-bound sensor family
This scenario is illustrative, not a client outcome. A Taiwanese manufacturer supplies an EU distributor with a family of connected sensors. Engineering maintains two firmware branches and a mobile app. The initial assessment records the manufacturer and importer roles, checks the default-class assumption against actual functions and separates the EU release inventory from a different regional build.
The team validates components against build artifacts, triages the relevant vulnerabilities and creates an incident escalation contact spanning time zones. The technical file is structured around the EU product identifiers, with support dates and user information reviewed for the destination market. Any radio-equipment assessment is handled in its own RED context. External testing and conformity-route costs are planned separately from monitoring and documentation support.
Prepare information that travels with the product
Ensure the user information, security contact, support end date and update instructions remain accessible through the sales chain. Retailers and importers may ask for evidence, but their checklist is not the whole regulation. Maintain the underlying technical file and declaration with clear version references. Plan who will respond to an authority request if the account manager or distributor changes. The manufacturer’s continuing security process should not depend on one reseller relationship.
Build evidence that survives a release
Begin with a named product and a reproducible release reference. A marketing model number is not enough when several firmware branches, mobile applications and remote services jointly implement its functions. Record the hardware revision, firmware version, build identifier and necessary remote processing. Decide which older versions remain supported. The CRA work should refer to this boundary consistently, so a reviewer can understand which product a statement describes.
Assign responsibilities before collecting documents. Engineering should own technical facts and remediation. A product owner should agree the intended use, support commitment and customer information. An incident contact should receive vulnerability disclosures and have the authority to escalate them. The manufacturer remains accountable for conformity and reporting even when an external team prepares evidence or drafts. Outsourcing a task does not transfer the underlying obligation.
Retain both the conclusion and the evidence that supports it. An applicability decision without a release reference becomes difficult to defend after a dependency upgrade. A technical file without its underlying test results becomes difficult to update. A useful record links the requirement, the artifact, the reviewer, the decision and its date. Keep open questions visible instead of marking an item complete because a template exists.
Common mistakes to avoid
Do not use a scan score as a compliance decision. Vulnerability matches can be incomplete or inaccurate, and a component version alone does not establish exploitability in the product. Equally, a finding that appears irrelevant needs a documented technical rationale. The evidence should explain whether the affected code is present, reachable and exposed through the supported configuration, and who reviewed that conclusion.
Do not confuse a project completion date with a continuing duty. New releases, new public vulnerabilities and changes to the intended use can change the evidence. Plan how the inventory, risk assessment and customer information will be updated. Check that the incident contact still works and that an on-call substitute can make decisions when the primary owner is unavailable.
Do not assume that company size or a non-EU address removes the obligations. The relevant questions include the product, the economic-operator role and how it reaches the EU market. A distributor, importer, authorised representative and manufacturer can have different responsibilities. Borderline interpretations need qualified review. This guide explains the engineering workflow and does not provide legal advice.
A practical review meeting
Bring the product owner, release engineer and security contact together with the current evidence. Walk through a single supported version rather than discussing a hypothetical future product. Ask which assumptions can be checked immediately, which require a build or test, and which require an external conformity or legal specialist. Finish with a short list of actions, owners and dates. A small, reviewed evidence set is more useful than a large unmaintained folder.
Use the CRA guide to connect this topic to the complete lifecycle. Review the product classes before choosing a conformity route, and connect the release SBOM to the Article 14 reporting workflow. If you need a starting inventory, the free Snapshot is a bounded first step.
Frequently asked questions
Is this a substitute for a product-specific assessment?
No. Use the guide to organise the engineering work. The product boundary, applicable legal interpretation and conformity route need a documented review.
Does a small team still need a process?
Yes. Assign a product owner, incident contact and substitute. The micro and small enterprise fine exception for 24-hour early warnings does not remove the duties.
Can Roja help with the practical work?
Yes. Our engineers validate inventory, triage findings, prepare reporting drafts and help build the technical evidence. The manufacturer reviews and remains accountable.
Where should we check the requirements?
Start with Regulation (EU) 2024/2847 on EUR-Lex and ENISA guidance for the Single Reporting Platform. Check the current text and your product facts before making a decision.
Sources
General engineering information, reviewed on the date above. Product-specific interpretations and current standards should be checked before a conformity decision. Roja helps manufacturers prepare for the Cyber Resilience Act. We do not certify products or provide legal advice.