CRA Third-Party Components: Integrate or Import?

You buy a Bluetooth module. Or a firmware SDK. Or a finished connected thermostat with a supplier's logo on the box.

Those are not the same CRA problem. If you integrate the part into your own product, you own the final-product documentation. If you import a finished non-EU-branded product, you verify the maker's documentation. That distinction should be made before the purchase order, not after the shipment arrives.

The question European buyers are actually asking

The question is rarely phrased as a legal role question. It sounds like procurement:

• "We buy the wireless module from a supplier."
• "The cloud SDK comes from a vendor."
• "The ODM sends us the board and we flash our firmware."
• "The finished device arrives from a non-EU manufacturer."

Each sentence points to a different documentation pattern. The mistake is to treat all of them as "supplier due diligence".

Our view: the role decision belongs at sourcing. If procurement waits until the product is in the warehouse, the compliance team inherits a fact pattern it cannot easily change. The purchase order should already say whether your company will author the finished-product documentation or verify the supplier's finished-product documentation.

For the full role map, use the CRA role decision tree. For the buying fork, keep the focus on the records that follow from the sourcing act.

The fork: integrating parts or importing finished products

The first fork is practical:

Sourcing act	Plain-English test	Documentation result
Integrate a module, chip, SDK, library or board into your own product	The finished product reaches the EU market under your product identity	You author the final-product documentation
Import a finished non-EU-branded product	The supplier's product is already complete and keeps the supplier's identity	You verify the manufacturer's documentation
Put your name or trademark on the product	The market sees your company as the source	You move into manufacturer-level work
Resell unchanged after another operator placed it on the market	You do not affect the product's properties	You run distributor due-care checks

The takeaway: do not ask whether the supplier is "CRA compliant" in the abstract. Ask what you are doing with the part or product.

When you integrate a module, chip, SDK, or library

If you integrate a third-party component into your own product, you are not buying a finished compliance position. You are buying an input.

Article 3 defines a product with digital elements to include software or hardware components placed on the market separately. The same article defines a component as software or hardware intended for integration into an electronic information system. That is why a separately sold wireless module, firmware SDK or embedded library can have its own documentation trail.

That trail still does not become your final-product file.

When you place the finished product on the EU market, the manufacturer work sits with the entity that places that product under its own name or trademark. For an EU thermostat maker, the wireless module supplier may provide the module declaration, a component inventory, firmware version notes and vulnerability contact details. The thermostat maker still writes the thermostat's cybersecurity risk assessment, technical documentation, declaration and CE marking basis.

Both duties sit in Article 13: due diligence on the components you integrate, and the final product's technical documentation, conformity assessment, EU declaration and CE marking.

The practical rule is simple: supplier records feed your file. They do not replace it.

Useful supplier inputs include:

• Component identity: exact model, version, firmware branch, batch or hardware revision.
• Security update path: who ships component fixes, how you receive them and how they reach your product.
• SBOM or component inventory: enough detail to monitor component vulnerabilities during the support period.
• Vulnerability contact: a real channel for component vulnerabilities, not only a sales address.
• Lifecycle dates: end-of-sale and end-of-support dates for the module, SDK or board.

For the deeper supplier review, use the CRA supplier due diligence questionnaire. This page does not repeat that questionnaire. It only explains where the supplier records sit in the final-product file.

Open source counts as a third-party component

Most firmware ships with more open source than purchased code. The CRA treats open source like any other component: the due-diligence duty covers the free and open-source software you integrate, even when nobody sold it to you and no contract exists.

The record changes shape, not the duty:

• Identity still matters: record the project, the exact version and the source you pull it from, the same way you record a paid module.
• Monitoring still matters: the library goes into your component inventory so you can watch for vulnerabilities during the support period.
• Fixes flow both ways: when you find a vulnerability in an integrated component, you report it to the project that maintains it and you still fix your own product. When you patch the component yourself, you share the fix with the maintainer.

There is no supplier to question, so the review runs against the project itself: how active it is, how it publishes security fixes, and whether the version you pin still receives them.

When you import a finished non-EU-branded product

Importing a finished product is different. The product already exists as a product with digital elements. The non-EU manufacturer keeps its name or trademark on it. Your EU company is the first EU operator placing it on the Union market.

That is an importer pattern.

The importer's job is not to recreate the manufacturer's technical documentation. The importer checks that the manufacturer has carried out the conformity assessment and drawn up the technical documentation, that the CE marking and EU declaration are in place, that the required user information travels with the product, and that the product identification, manufacturer contact details and support-period end date are present.

Article 19 sets that verification pattern. It also requires the importer to keep a copy of the EU declaration for at least 10 years after the product is placed on the market or for the support period, whichever is longer. The importer must also make sure the technical documentation can be made available to market surveillance authorities on request.

One label is yours to add: the importer puts its own name, postal address and digital contact on the product, its packaging or an accompanying document.

That is a verification file, not a manufacturer file.

Use the CRA importer guide for the full receiving check. The useful distinction here is narrower: if the product remains the non-EU manufacturer's finished product, you verify. If you turn it into your product, you author.

The documentation chain: author, verify, or keep a copy

This table is the working record. Use it per product line, not per supplier. A supplier may appear in both columns if you buy a module for one product and import a finished product from the same company.

The takeaway: the same supplier document can play 2 roles. For an integrator, it becomes input evidence for a final-product file. For an importer, it supports a pre-market verification record.

Worked example: the same Bluetooth/Wi-Fi module in two CRA tracks

Take one wireless module. Same model. Same firmware. Same supplier.

The CRA work changes when the buying pattern changes.

Scenario A: EU thermostat maker integrates the module.
You build a connected thermostat under your brand. You buy the Bluetooth/Wi-Fi module and embed it in your board. The module supplier gives you the datasheet, firmware version, security contact and lifecycle statement.

You still author the thermostat file. Your file explains how the module affects pairing, local network exposure, update delivery, vulnerability monitoring and support-period planning. The module supplier's records sit inside your evidence set as inputs.

Scenario B: EU importer buys the finished thermostat.
You buy a finished non-EU-branded thermostat. The wireless module is already inside the device. The non-EU manufacturer keeps its brand on the box, firmware, app and declaration.

You verify the manufacturer's documentation. You do not write a new thermostat technical file. You keep the import verification record, the declaration copy and the supplier commitments needed to answer a market surveillance request.

The same module creates different work because the product placed on the market is different.

How to read supplier documents without over-trusting them

Supplier documents are useful when they answer a product question. They are weak when they only say "compliant" with no product, version or support trail.

Start with 5 checks:

Supplier document	What it should prove	How you use it
Module declaration or certificate	Exact product, model and firmware scope	Link it to the component version inside your product record
SBOM or component list	Software and firmware elements you can monitor	Feed your product inventory and vulnerability watch
Vulnerability contact	A route for component vulnerabilities	Store it in the product's vulnerability workflow
Support or lifecycle statement	How long the component receives fixes	Compare it with your product support period
Change notice process	How you hear about new firmware, chips or SDK versions	Trigger a product-file review before release or import

The takeaway: the document is only useful when it attaches to a named product, version and decision. A generic supplier PDF with no SKU, date or contact route should not carry a release decision.

For an integrator, the supplier package should answer one question: can this part sit inside the product without weakening the product's cybersecurity during the support period?

For an importer, the supplier package should answer a different question: has the non-EU manufacturer done the finished-product work, and can you show that you checked it before EU placement?

The opinion is not "collect more files". The opinion is "decide what each file proves before you buy".

The purchase-order gate

Put the role decision into the buying process. The main CRA obligations apply from 11 December 2027, and anything you place on the market from that date needs these records in place. A compliance review after goods arrive is late, expensive and often political.

Before the purchase order is signed, ask these questions:

1. What are we buying? A component, a board, an SDK, a cloud dependency, or a finished product.
2. Whose name reaches the market? Your brand, the supplier's brand, or both.
3. Will we change firmware, cloud routing, update paths or security defaults? Any yes answer needs a role review.
4. Which records arrive with the part? Declaration, technical-documentation index, SBOM, support date, vulnerability contact and user information.
5. Which records do we author? Mark final-product documentation, declaration and support-period records as yours only when your product identity reaches the market.
6. Which records do we verify? Mark supplier or manufacturer records as verification evidence only when the finished product remains under the supplier's identity.
7. What event reopens the decision? Firmware change, supplier EOL, rebrand, new module revision, cloud endpoint change or vulnerability notice.

The buyer should be able to answer those questions in one page. If it takes a meeting series, the purchase is not ready for release planning.

Common mistakes at the sourcing stage

These mistakes appear before engineering sees a vulnerability. They start in purchasing, private labelling and receiving.

• "The module is CE marked, so our product file is done": the module mark does not cover the finished product's architecture, update path, support period or risk assessment. Treat it as input documentation.
• "The supplier says CRA compliant, so we can import": a sales statement is not a verification record. Ask for the declaration, technical-documentation index, support-period statement, vulnerability contact and user information.
• "We put our brand on it but still call ourselves importer": own-brand placement points to manufacturer-level work. Use the white-label and OEM guide before the listing goes live.
• "We changed the firmware but kept the supplier's declaration": changing the firmware, cloud endpoint or update path can change the assessed product. Run the role check before you ship.
• "We only distribute, so no one needs to check anything": distributors still run due-care checks before making products available. Use the distributor checklist for the receiving desk.

The shortest safe rule: if the product changes or your name becomes the source, stop and run the role analysis again.

Edge cases covered on other pages

Use these pages when the fact pattern leaves the component fork:

Edge case	Where to go	Why
You sell an OEM product under your own name	White-label and OEM guide	Own-brand placement moves the work into manufacturer territory
You need a supplier questionnaire	Supplier due diligence questionnaire	That page owns red flags, playbooks and clauses
You only resell unchanged products	Distributor checklist	The receiving check is visible-mark and document focused
You need the full role tree	Who must comply with the CRA	This page does not replace role classification
One legal entity has several roles	Multi-role CRA guide	Role stacking is a company-portfolio problem

The takeaway: link out when the question changes. Do not turn a component sourcing page into a general CRA role guide.

What evidence to keep before EU market placement

Start with one product line. Then attach records to that product line, not to a generic supplier folder.

Use this order:

1. Classify the sourcing act. Write integrated component, finished-product import, own-brand product, or unchanged resale next to the SKU.
2. Name the document owner. Mark the technical documentation as ours, manufacturer's, or not held.
3. Attach supplier inputs. Store datasheets, SBOMs, support dates, firmware versions, vulnerability contacts and declarations against the product record.
4. Record the decision. Keep the date, reviewer and reason for treating the record as authoring, verification or due-care evidence.
5. Set the review trigger. Reopen the record on supplier firmware change, module end-of-life, vulnerability notice, rebrand, cloud endpoint change or support-period change.