[Home](/)/[Resources](/resources)/CE compliance across a product family

EUStrategy guide

# CE Compliance Across a Product Family

Testing every product variant from scratch is expensive and unnecessary. The representative model approach lets one test campaign cover an entire family — but only if the worst-case variant is tested and the coverage rationale is properly documented. Skipping this justification is the difference between a defensible technical file and a compliance gap waiting to be found.

Copy Link[Share on WhatsApp](https://wa.me/?text=https%3A%2F%2Fkrono-labs.com%2Fguides%2Fce-compliance-product-family)

At a glance

Variant impact types

6

Technical file structure elements

7

FAQs

4

## How product variants affect CE compliance

### Colour and cosmetic variants

**Compliance impact:** Low — no re-testing required unless the casing material change affects thermal dissipation, RF shielding, or flammability classification.

**Action required:** Document variant list in technical file. Update DoC to reference all variant model numbers. No additional testing required.

### Regional frequency variants (e.g., EU vs US radio)

**Compliance impact:** High — different radio frequency bands require separate RED testing. EU 868 MHz and US 915 MHz are not interchangeable test reports.

**Action required:** Separate CE test campaigns for each regional variant. Separate DoC per region. Clear hardware and firmware version documentation.

### Different antenna designs or positions

**Compliance impact:** High — antenna changes directly affect RF performance, SAR, and conducted/radiated EMC. Must retest.

**Action required:** Full RF testing including SAR (if applicable) for each antenna variant. Document antenna part number in test report scope.

### Different power supply ratings (e.g., 5W vs 10W charger)

**Compliance impact:** Medium — different power levels affect LVD thermal testing, conducted EMC at higher output, and potentially battery charging safety.

**Action required:** Review existing test reports for power envelope coverage. May require additional testing at the higher power level.

### Additional connectivity features in higher-tier models

**Compliance impact:** High — adding Bluetooth, Wi-Fi, or Zigbee to a variant adds RED scope where it was not previously present.

**Action required:** New RED CE assessment for variants with wireless features not covered in the base model test campaign.

### Memory or processing variants (same PCB, different flash/RAM)

**Compliance impact:** Low — purely software-addressable components that do not change RF, EMC, or safety characteristics.

**Action required:** Document in technical file. Single DoC covers all firmware/software variants unless firmware changes affect radio parameters.

## Technical file structure for a product family

01

Product family overview: describe the family, identify the representative model(s), and list all variants with their distinguishing characteristics

02

Variant matrix: table mapping each model number against all differentiating features — antenna, power supply, connectivity, frequency band, housing material

03

Representative model justification: explain why the tested configuration represents the worst case for each essential requirement tested

04

Test reports: test reports covering the representative model, with test scope clearly identifying which variants are covered

05

Delta testing record: for variants not fully covered by the representative model, document additional testing performed and rationale

06

Declaration of Conformity: single DoC or family DoC listing all covered variant model numbers, with clear reference to test reports

07

Configuration management: hardware revision table linking PCB revision, firmware version, and test report version

## Frequently asked questions

### How many products can a single Declaration of Conformity cover?

A single DoC can cover multiple products or product variants as long as they are all substantively covered by the compliance evidence referenced in the DoC. There is no legal maximum number. The DoC must clearly identify each product covered — by model number, hardware revision, or other unambiguous identifier. Covering a range that hasn't been fully tested creates legal liability — if a variant differs in a way that affects compliance and it fails in the field, the DoC is inaccurate.

### What is the 'worst case' principle in representative model testing?

Representative model testing covers a family by testing the variant most likely to fail — the worst case. For EMC, the worst case is typically the highest-power variant. For SAR, the worst case is the variant with the antenna positioned closest to tissue at maximum transmit power. For LVD, the worst case may be the highest-power variant with the smallest safety margins. If the worst-case variant passes, all variants with less severe characteristics are covered. This justification must be explicitly documented in the technical file.

### What is delta testing and when is it required?

Delta testing covers only the difference between a tested configuration and a new variant — rather than retesting from scratch. For example, if a new antenna design is introduced in one variant, delta RF testing on the new antenna may be sufficient if the rest of the hardware is identical to a previously tested configuration. Delta testing requires careful scope definition with your test laboratory and documentation that identifies exactly what changed and why the delta tests are sufficient.

### Can firmware updates add new products to an existing DoC?

No. Firmware updates can modify existing products, but adding a new model to an existing DoC requires the new model to be covered by the technical evidence referenced in the DoC. If a firmware update fundamentally changes the operating behaviour — for example, enabling a new frequency band or changing radio output parameters — the updated firmware configuration may need its own test evidence and the DoC must be reissued to reflect the change.

**Disclaimer:** Educational resource only. Representative model scope justification is a technical decision that should be reviewed with your test laboratory. Incorrect scope decisions create compliance risk across the entire product family.

🇪🇺 CE Marking roadmap for your product

Every standard, document, and test that applies — free, no account required.

See your free roadmap[

Want an expert to take your product through 🇪🇺 CE Marking compliance for you?

One consultant from Krono's compliance team takes your product from requirements to legal sale, with a fixed quote before any work starts.

See compliance services](/services)

Learn this properly

In-depth course that teaches the full process, not just this one answer.

[Start the course — $149](/courses/01-ce-marking-for-electronics-engineers)[Prefer to read? Get the book — $24.99](/books/01-ce-marking-for-electronics-engineers)

Related guides

*   [CE marking with a contract manufacturerPractical guide to CE marking when using a contract manufacturer (CM) or ODM: who holds manufacturer responsibility, how to ret…](/guides/ce-marking-with-contract-manufacturer)
*   [CE marking for accessories and spare partsPractical guide to CE marking for accessories and spare parts: when accessories need their own CE marking, when spare parts inh…](/guides/ce-marking-accessories-spare-parts)
*   [CE marking and firmware updatesPractical guide to CE marking implications of firmware and software updates: when OTA updates constitute a substantial modifica…](/guides/ce-marking-firmware-updates)
*   [EU market surveillancePractical guide to EU market surveillance: how national MSAs enforce CE marking, Regulation (EU) 2019/1020, customs controls at…](/guides/eu-market-surveillance)