CRA White-Label & OEM Products: A Manufacturer's Guide

You sell tablets under your brand, and an ODM in Shenzhen builds them. Under the CRA, you are the manufacturer, the ODM is your supplier, and the trigger is the brand, not the build. This page is the white-label operational layer. For the full manufacturer obligation set see the manufacturer cluster.

Why white-label is its own category

White-label sits in a specific corner of the CRA role map. The boundary between white-label and the adjacent roles is sharp on paper but blurry in procurement reality.

Three boundaries get crossed often. First, the boundary between white-label (you are the manufacturer from day one) and substantial modification (someone modifies an already-placed product). White-label is a placement-time trigger; substantial modification is a post-placement trigger. Second, the boundary between white-label and importer: if you put your brand on the product, you crossed out of the importer role into the manufacturer role, even if you also physically import the device. Third, the boundary between white-label and component sourcing: if you place a product under your brand, you are the manufacturer of that product; if you integrate a component into a product you build yourself, the supplier due diligence playbook is your operational layer.

The "just a sticker" defence and what actually counts

Procurement leads sometimes argue that adding a brand sticker to a finished product cannot trigger full manufacturer status. The importer cluster pitfall table names this exact claim ("It is just a sticker with our logo.") and disposes of it: if the sticker presents you as the source of the product, manufacturer obligations apply. The trigger is brand presentation to the market, not the depth of the modification.

The operational question is what counts as "branded as yours" and what stays in distributor territory.

The unifying rule is source presentation. If a market surveillance authority, asked "who is the manufacturer of this product?", would point at your brand, you are the manufacturer under the CRA. Sticker depth, design effort and customisation level are not the test.

White-label scenario taxonomy

Seven scenarios cover the operational territory. Each maps to a different combination of CRA route, supplier diligence depth and contractual exposure.

1. Simple rebrand (finished product, your brand only)

You buy finished tablets, apply your logo, sell under your brand. Default white-label.

• CRA route: manufacturer from first sale.
• Conformity assessment: yours. The OEM's prior conformity assessment may inform your technical file but does not transfer.
• Diligence depth: high on the OEM as supplier, especially documentation, vulnerability handling, and support-period commitment.
• Operational risk: the OEM's willingness to ship security updates dictates your ability to honour your own support-period commitment to users.

2. Hidden white-label (your reseller re-rebrands)

You white-label an OEM product as Brand-A and sell to a reseller. The reseller strips your brand and re-rebrands as Brand-B without telling you, then places Brand-B units on the EU market.

• CRA route: the reseller becomes the manufacturer of the Brand-B units. You remain the manufacturer of the Brand-A units you placed. The OEM remains supplier to both.
• Discovery operational signal: customer-support tickets referencing Brand-B that match Brand-A behaviour, or returns arriving in Brand-B packaging when you never sold to Brand-B.
• Contractual fix: reseller agreements should prohibit re-rebranding without written consent. Without that clause, your only remedy is termination.
• Why it matters: a vulnerability you ship a patch for will not reach Brand-B units unless the reseller flows the patch through, and the reseller may have no infrastructure to do so.

3. Multi-tier white-label (you white-label, your distributor white-labels yours again)

OEM builds, you white-label as your brand, you sell to an EU distributor, the distributor white-labels yours as their own brand.

• CRA route: three legal positions stacked. OEM is supplier, you are manufacturer of the units you placed under your brand, the distributor becomes manufacturer of the units they placed under their brand.
• Operational pattern: common in industrial automation, AV equipment and B2B IoT.
• Critical clause: your contract with the distributor must specify whether re-rebranding is permitted and, if it is, that the distributor takes manufacturer status for the re-rebranded variant. Without that, both parties may end up claiming distributor status while authorities point at the visible brand on each unit.

4. Co-branded products (both names on the product)

The product carries both your brand and the OEM brand visibly to the end user.

• CRA route: typically the retail-facing brand carries manufacturer status; both parties can be designated manufacturers if both present themselves as the source.
• Contractual fix: the manufacturer designation must be written into the co-branding agreement. Default reading: whichever party signs the DoC is the manufacturer for that unit cohort.
• Operational risk: shared brand visibility can confuse users about which party to contact for vulnerability reports; the single point of contact for the product must be unambiguous.

5. Retailer private-label (Amazon Basics, Lidl Silvercrest, Tesco)

A high-volume retailer commissions an OEM to build a product under the retailer's private-label brand. The retailer is the white-label brand owner.

• CRA route: retailer is the manufacturer. The volume does not change the analysis; the brand presentation does.
• Operational scale: hundreds of SKUs across multiple OEMs is typical. Per-SKU technical files, per-SKU DoCs, per-SKU support-period clocks. A retail buyer treating CRA compliance as a single-pass procurement question understates the load.
• Contractual pattern: long-term framework agreements with the OEM, support-period mirror clauses (OEM commits AT LEAST as long as the retailer commits to users), source-code escrow for the firmware, and explicit re-flow of CRA requirements to subcomponents.

6. Hardware-only ODM + your firmware

You commission ODM hardware (industrial board, ruggedised tablet, IoT gateway shell) and ship your own firmware on it. The hardware substrate is OEM-supplied; the security envelope is yours.

• CRA route: you are the manufacturer of the integrated product. The ODM is your hardware supplier. Different from the simple rebrand because you actually build something on top of the substrate.
• Diligence shape: leans on the hardware-only ODM playbook (BOM controls, secure-element source, factory-key injection, EOL window for the hardware platform).
• Common operational error: signing a multi-year customer support commitment with an ODM whose hardware EOL window is shorter. When the silicon goes EOL, your support obligation does not soften.

7. White-label SaaS or remote-data-processing component

The "product" customers see is your-branded SaaS or your-branded API. The actual processing runs on an OEM platform white-labelled to you (a managed Kafka cluster, a SaaS authentication platform, a managed device-fleet service).

• CRA route: depends on whether the SaaS itself is a "product with digital elements" under the CRA. The CRA covers "remote data processing solutions" only where they are integral to a placed product. A pure SaaS that does not integrate into a placed product is typically out of scope. If your SaaS is an integral component of a placed product (firmware that calls home, IoT device fleet management), the SaaS provider is part of your supplier chain and the cloud-service component playbook applies.
• Contractual pattern: SaaS attestation portfolio (SOC 2, ISO/IEC 27001, ISO/IEC 27017), data-processing agreement, sub-processor list, service-discontinuation notice window.

Firmware customisation: where the rebrand-bridge ends and the catch-all begins

The most common conflation in white-label compliance is between the rebrand-bridge (an importer or distributor who substantially modifies a product already placed on the market becomes the manufacturer for the modified product) and the catch-all (any other third party who substantially modifies a placed product becomes the manufacturer). Both routes are in the CRA; they cover different actors.

The boundary, mapped onto firmware customisation scenarios that white-label brand owners encounter:

Two operational implications. First, the white-label brand owner does not "escape" into the catch-all route by claiming the substantial modification was done by someone else; if you are placing the modified product on the market under your brand, the modification is part of your manufacturer scope. Second, when one of your distributors customises your white-label firmware, the rebrand-bridge route lands on them, not you, for those specific units. Track which units left your control unmodified and which were modified downstream; the support-period responsibility for the modified units shifts to the modifier.

For the verbatim text of the rebrand-bridge and catch-all provisions, see the distributor cluster FAQ which quotes both side by side.

Support-period clock for white-label

The CRA support-period clock starts when the manufacturer places the product on the EU market. For white-label, you are the manufacturer, so the clock starts when you first place your rebranded version on the EU market, not when the OEM first placed the un-branded original or sold to you.

SUPPORT-PERIOD TIMING (WHITE-LABEL)

Year 0   OEM first places the un-branded version on EU market
         OEM's support clock starts on its own DoC

Year 0   OEM ships your first rebranded batch to your warehouse
         (No CRA clock starts on you yet, not on EU market)

Year 1   You place your first rebranded units on the EU market
         YOUR support clock starts on YOUR DoC (5 years minimum)

Year 1   OEM continues to sell un-branded original in parallel
         (Two independent clocks now run; OEM's covers OEM units, yours covers yours)

Year 4   OEM stops production
         Your support obligation continues until at least Year 6
         (and beyond if you placed units after Year 1)

The mirror-clause obligation that follows: your OEM contract must commit the OEM to ship security updates to you for AT LEAST as long as you commit to your users. If you commit five years to users and the OEM commits three years to you, you carry a two-year gap with no source of patches. Source-code escrow and second-source qualification are the two standard mitigations.

When the OEM ceases operations

A common misconception: when the OEM goes out of business, the CRA imposes a notice duty on you that transfers some of the OEM's obligations.

Two clarifications matter. First, the CRA notice duty on a manufacturer's cessation sits on the importer, not on you. When you are the white-label brand owner, you are the CRA manufacturer of your rebranded product; the OEM was your supplier, not the manufacturer of your branded product. The importer-cessation notice provision does not apply to you in this scenario, because the OEM was not the CRA manufacturer of your branded product. The importer cluster cessation section walks through the importer-side duty in detail.

Second, the support obligation does not "transfer" from the OEM to you because it was always yours. You committed to your users at first placement; the OEM ceasing changes your supply situation, not your statutory commitment. The practical fallback is what the contract committed to (source-code escrow, second source, transition services), not the importer-cessation provision.

The one statutory cessation notice that DOES apply to you, the white-label brand owner, is the manufacturer's own cessation duty: if YOU as manufacturer cease operations, you must inform the market surveillance authorities and, by any means available, your users.

Cross-border white-label

You source from an Asian ODM, white-label, and place the product on the EU market via your EU subsidiary. The white-label trigger (you are the manufacturer from first sale) combines with a no-EU-establishment question for vulnerability and incident reporting.

If your white-label brand is held by a non-EU parent and the EU subsidiary is the entity placing the product on the market, two routes are possible. Route A: the EU subsidiary is the legal manufacturer, with the parent acting as a commercial brand owner; the EU subsidiary's Member State is the home authority. Route B: the non-EU parent is the legal manufacturer (brand owner of record) and the EU subsidiary is the importer; the non-EU-manufacturer fallback cascade routes incident reporting via AR Member State → importer Member State → distributor Member State → highest-user Member State.

Pick the route deliberately in your group's legal structuring; do not let it fall out of the brand-ownership accident. A non-EU brand owner with no EU establishment and no appointed AR routes its incident reporting to the importer Member State by default, which means the EU subsidiary's MSA gets the reports whether or not the subsidiary is set up to handle them.

White-label SBOM provenance

The supplier sibling covers SBOM contract clauses in the abstract. For white-label, the operational reality is sharper: you cannot generate the SBOM from your own build pipeline because you did not build the code.

Three operational consequences.

First, the SBOM is a contracted deliverable from the OEM, not an internal artifact. Your contract must specify format (CycloneDX or SPDX), update cadence (per release), depth (transitive dependencies, not just direct), and refresh trigger (any firmware version bump). Without this, the OEM may deliver a direct-only SBOM that misses 90% of the actual risk surface.

Second, the SBOM authority bears your brand even though you did not author the components. When the SBOM lists a vulnerable transitive dependency, the component due diligence duty lands on you. The diligence record cannot be a copy-paste from the OEM; it has to be your own decision and your own risk acceptance per integrated component. Use the supplier due diligence playbook for the FOSS, cloud, hardware-only and OSS-steward sub-cases inside the OEM's SBOM.

Third, hardware-only ODM scenarios split into hardware BOM (BOM of physical components) and software SBOM (BOM of the firmware you ship). The hardware BOM is OEM-supplied; the software SBOM is yours (because the firmware is yours). The technical file must distinguish the two, and the vulnerability monitoring split has to match: hardware BOM monitoring flows from the OEM to you, software SBOM monitoring is your direct responsibility.

Liability split contract clauses

Seven contract clauses carry the white-label arrangement under CRA. Each plugs into a specific manufacturer obligation that originates with you, the brand owner, and depends on the OEM to make good.

1. CRA manufacturer acknowledgement

Supplier acknowledges that Buyer will place the Product
on the EU market under Buyer's name or trademark and
that Buyer will be considered the "manufacturer" under
Regulation (EU) 2024/2847 (Cyber Resilience Act).
Supplier agrees to support Buyer's compliance obligations
as set out in this Agreement.

2. Technical documentation (Annex VII)

Supplier shall provide to Buyer:
(a) Complete technical documentation meeting the
    requirements of Annex VII of Regulation (EU) 2024/2847
(b) All documentation necessary for Buyer to:
    - Conduct the conformity assessment
    - Prepare the EU Declaration of Conformity
    - Respond to market surveillance reasoned requests
(c) Updates to documentation within [10] business days
    of any change affecting compliance status

Supplier grants Buyer a perpetual, irrevocable, royalty-
free licence to use such documentation for compliance
purposes, including production for any market surveillance
authority in a language the authority understands.

3. SBOM provision (with transitive depth)

Supplier shall provide:
(a) Software Bill of Materials in [CycloneDX/SPDX] format
(b) Updated SBOM within [5] business days of each firmware
    release that changes direct or transitive components
(c) SBOM including transitive dependencies, not direct
    dependencies only
(d) Component identification with name, version, supplier,
    licence, known vulnerabilities at delivery

4. Vulnerability notification (hours, not "promptly")

Supplier shall notify Buyer within [24/48] hours of
becoming aware of any security vulnerability in the
Product or in any transitively integrated component
that:
(a) Is actively exploited
(b) Has a CVSS score of 7.0 or higher
(c) Is subject to public disclosure

Patch development:
(a) Acknowledge within [24] hours
(b) Severity assessment within [72] hours
(c) Deliver patch within [7/30/90] days
    for Critical/High/Medium severity

Buyer retains final authority on customer communications
and update release timing.

5. Support-period mirror

Supplier commits to providing security updates for the
Product for a minimum period that matches or exceeds
Buyer's support-period commitment to its end users, and
in any case for at least [5/7/10] years from the date of
first market placement by Buyer in the EU.

Supplier shall provide [90] days written notice before
any planned discontinuation. On discontinuation, Supplier
shall release source code and build artefacts under
[source-code escrow / transition assistance terms].

6. Conformity assessment support and audit rights

Supplier shall:
(a) Support Buyer's conformity assessment activities,
    including providing test reports, certificates, and
    evidence on reasonable request
(b) Allow Buyer or Buyer's Notified Body to audit
    production facilities upon [30] days written notice
(c) Maintain quality controls consistent with the
    assessed product type

7. Subcomponent flow-down and disclosure

Supplier shall:
(a) Provide and maintain a list of subcomponent suppliers
    that contribute to or have access to security-relevant
    parts of the Product
(b) Flow down relevant CRA requirements to subcomponents
(c) Notify Buyer within [30] days of any material change
    to the subcomponent supplier list
(d) Maintain subcomponent supplier qualification records
    for the duration of Buyer's support period plus 10 years

Risk allocation summary

Post-M&A inherited white-label arrangements

You acquire a brand and discover half its catalogue is white-labelled with no compliance trail. The CRA does not grant an M&A grace period; the acquiring entity inherits manufacturer obligations on day one for every product currently on the EU market under the acquired brand.

POST-M&A WHITE-LABEL TRIAGE (90 DAYS)

DAY 1-15: Inventory
[ ] Pull SKU list from acquired entity's ERP
[ ] Tag each SKU as own-design / white-label / OEM-modified
[ ] Identify the OEM behind each white-label SKU
[ ] Cross-check against current shipping status (active vs EOL stock)

DAY 15-30: Documentation gap analysis
[ ] For each active white-label SKU: is there a Buyer-named DoC?
[ ] For each active white-label SKU: is there a technical file in Buyer's name?
[ ] For each active white-label SKU: is there an SBOM?
[ ] Tag SKUs by gap severity (no DoC > incomplete tech file > no SBOM)

DAY 30-60: Tier 1 remediation
[ ] SKUs with no DoC: pull from EU market until DoC is in place
[ ] SKUs with no technical file: build from OEM evidence + your own assessment
[ ] SKUs with no SBOM: contract the OEM for SBOM delivery; if OEM refuses or has ceased, plan replacement or sunset

DAY 60-90: Decision gate
[ ] Each white-label SKU classified: keep / sunset / replace OEM
[ ] OEM contracts assessed against the 7-clause set; gaps mapped
[ ] Support-period mirror coverage analysed end to end

ONGOING:
[ ] Tag the acquired-via-M&A origin in each SKU record for audit
[ ] Roll inherited SKUs into normal release-cycle SBOM and vulnerability monitoring

The triage is not a paper exercise. Authorities asking why a 12-year-old white-label SKU has no DoC after acquisition will accept "we discovered the gap in our 90-day post-acquisition triage and pulled the SKU until remediated" more readily than "we are still working out which OEM made it".

Common pitfalls

This article is for informational purposes only and does not constitute legal advice. For specific compliance guidance, consult with qualified legal counsel familiar with EU product regulations.