CRA Art.25: When Importers & Distributors Inherit Full Manufacturer Obligations — White-Labelling, Rebranding & Substantial Modification (Developer Guide 2026)
Post #471 in the sota.io EU Cyber Compliance Series
The EU Cyber Resilience Act (Regulation (EU) 2024/2847, "CRA") draws a clear hierarchy among economic operators: manufacturers bear the heaviest obligations, while importers and distributors carry more limited duties. Article 25 closes the gap that would otherwise allow operators to escape manufacturer-level obligations through rebranding or product modification. When an importer or distributor crosses any of three defined thresholds, they are treated as a manufacturer for every purpose under the CRA.
Critical deadline: 11 December 2027. Art.25 obligations apply in full from that date. Software resellers, white-label SaaS providers, and distributors who make changes to third-party products must have their classification and compliance posture locked in before this deadline.
The Three Triggers: When Art.25 Applies
Art.25 establishes three distinct scenarios in which an importer or distributor is treated as a manufacturer and must meet all obligations set out in Art.13 through Art.24:
| Trigger | Description | Who Is Affected |
|---|---|---|
| Trigger 1 | Places a product on the market under their own name or trademark | Importers and distributors who rebrand |
| Trigger 2 | Modifies a product already placed on the market in a way that may affect conformity | Distributors and importers who make substantial or non-substantial changes |
| Trigger 3 | Makes a substantial modification to a product | Any economic operator in the chain |
Each trigger produces the same legal consequence: the operator is treated as the manufacturer for the purposes of the CRA. They must carry out the conformity assessment (Art.17), prepare technical documentation (Art.22), draw up the EU Declaration of Conformity (Art.23), affix CE marking (Art.24), and register the product in the EU database.
Trigger 1 — Own-Name Placement: The White-Label Trap
The most commercially significant Art.25 trigger for software businesses is placing a product on the market under your own name or trademark. This is the "white-label trap": any operator who takes a third-party product and presents it to the market as their own becomes a manufacturer under the CRA, regardless of who originally developed the underlying technology.
What "Own Name or Trademark" Means
The own-name criterion is met whenever the product's presentation to end users and market surveillance authorities identifies the operator — not the original developer — as the responsible party. This includes:
- Brand substitution: replacing the original manufacturer's name on the product, packaging, accompanying documents, or UI
- Trademark affixing: applying the operator's registered trademark to a product they did not develop
- Label removal: removing or obscuring the original manufacturer's identification without replacing it, and placing the product under the operator's commercial identity
- Domain branding: delivering a white-label SaaS via the operator's own domain in a way that makes the operator the apparent provider to users
The key question is: who does a reasonable user or market surveillance authority identify as the entity responsible for the product's conformity? If the answer is the importer or distributor rather than the original developer, Art.25 Trigger 1 is engaged.
Software-Specific White-Label Scenarios
White-labelling is extremely common in the software industry. Art.25 creates compliance obligations in scenarios that operators may not recognise as "rebranding":
SaaS reseller with custom domain: An EU company resells a US-developed SaaS product under its own domain and brand. The underlying software is unchanged, but the operator is the only entity visible to customers. Result: Art.25 Trigger 1 applies. The EU reseller must obtain conformity documentation from the original developer, carry out or verify the conformity assessment, and become the named party on the EU DoC.
OEM software integration: A hardware manufacturer embeds third-party security software into its own product and ships the combined product under the hardware manufacturer's brand. The software component is not visible to users as a separate product. Result: the hardware manufacturer's conformity assessment under Art.17 must cover the software component; if the software has its own CRA obligations, the hardware manufacturer's technical documentation must reference the software's conformity.
White-label compliance tooling: A consultancy purchases a compliance monitoring SaaS platform from a developer, rebrands it, and offers it to clients as "ComplianceMonitor by [Consultancy]". Result: Art.25 Trigger 1. The consultancy must obtain the original developer's technical documentation and EU DoC, or carry out a new conformity assessment covering the full product.
Marketplace bundling: A cloud marketplace bundles third-party developer tools under a unified "Cloud Developer Suite" brand with the marketplace operator's name. Result: Art.25 analysis required — if the marketplace's brand is the primary identifier of conformity responsibility, Trigger 1 may apply.
Trigger 2 — Modification Affecting Conformity
Art.25 Trigger 2 applies when an importer or distributor modifies a product already placed on the market in a way that may affect its conformity with the essential requirements in Annex I of the CRA.
This trigger is narrower than Trigger 1. A distributor who makes a conformity-neutral change — applying a sticker, translating documentation, repackaging without altering the software — does not trigger Art.25. The modification must create a genuine risk that the product's conformity with Annex I essential requirements (security properties, vulnerability handling, SBOM requirements) is affected.
Changes That Engage Trigger 2
| Modification Type | Art.25 Trigger 2? | Analysis |
|---|---|---|
| Repackaging (no software change) | No | Physical presentation only; no conformity impact |
| Translating user manual | No | Documentation change; does not affect product security properties |
| Configuring default security settings | Likely yes | Security configuration directly affects Annex I(1)(d) secure-by-default |
| Enabling or disabling software modules | Yes | Changes the attack surface and vulnerability profile |
| Integrating third-party authentication library | Yes | Introduces new code with independent vulnerability footprint |
| Applying a firmware update not issued by the manufacturer | Yes | Modifies the product's security posture post-market |
| Disabling automatic security updates | Yes | Directly affects Art.13(1)(c) obligations |
The practical test is: does the modification change the product's security properties or its vulnerability profile in a way that the original manufacturer's Annex I analysis no longer covers? If yes, Trigger 2 is engaged.
Relationship to Art.20 Substantial Modification
Trigger 2 overlaps with but is distinct from Art.20 (Substantial Modification). Art.20 applies to the original manufacturer when they release an update that constitutes a substantial modification — requiring them to restart the conformity assessment process. Art.25 Trigger 2 applies when a different operator (importer or distributor) makes a modification. The consequence of Trigger 2 is that the modifying operator steps into the manufacturer role for the modified product and must treat it as a new placement on the market.
Trigger 3 — Substantial Modification
Art.25 Trigger 3 is the most sweeping: any economic operator who makes a substantial modification to a product with digital elements is treated as a manufacturer. A substantial modification under Art.3(32) is one that:
- Affects the product's compliance with the essential requirements in Annex I Part I or Part II, or
- Changes the intended purpose of the product (including changes to cybersecurity risk classification), or
- Represents a change of such significance that the product must be considered a new product
Substantial Modification Examples in Software
AI model retraining: A distributor takes a commercial AI security scanning tool, retrains it on new data, and redistributes. The retraining changes the model's behaviour and security detection capabilities. Result: Trigger 3 — the distributor is now a manufacturer for the retrained product.
Protocol implementation change: A reseller swaps the TLS library in a network appliance firmware for a different implementation with a different vulnerability footprint. Result: Trigger 3.
Scope expansion: A distributor extends a vulnerability scanner originally designed for web applications to cover cloud infrastructure, fundamentally changing the attack surface it operates on and its security classification. Result: Trigger 3 — the scope change likely alters the product's cybersecurity risk classification under Art.7.
Security feature removal for cost reduction: A distributor strips multi-factor authentication from an enterprise product before reselling into a lower-cost segment. Result: Trigger 3 — the removal directly affects compliance with Annex I Part I(1)(d) (secure by default).
Legal Consequences of Art.25 Classification
When Art.25 applies, the importer or distributor must meet all obligations that apply to manufacturers under the CRA, specifically:
- Art.13: General manufacturer obligations — security requirements, vulnerability handling, SBOM, lifecycle obligations
- Art.14: Vulnerability reporting obligations to ENISA and national CSIRTs (24-hour early warning, 72-hour notification, final report)
- Art.15: Single point of contact designation
- Art.16: Security update supply and publication obligations
- Art.17: Conformity assessment — internal control (Annex VIII), third-party audit (Annex IX), or notified body (Annex X)
- Art.22: Technical documentation — full Annex V dossier (design records, SBOM, test results, vulnerability handling procedures)
- Art.23: EU Declaration of Conformity
- Art.24: CE marking — placement, format, digital affixing for software
The original manufacturer's conformity documentation does not transfer to the Art.25 operator. The Art.25 operator must prepare their own documentation covering the product as placed on the market under their name or after their modification.
Supply Chain Liability Allocation
The Art.25 framework creates significant contractual risk for software supply chains. Best practice is to allocate Art.25 responsibilities in commercial agreements:
Key Contractual Provisions
Conformity documentation licence: The original developer grants the white-label partner a right to rely on existing technical documentation and conformity assessment results, subject to the partner not making modifications that would engage Art.25 Trigger 2 or 3.
Modification restriction clause: White-label agreements should prohibit modifications without written consent, specifying that any permitted modification triggers the partner's Art.25 manufacturer obligations.
EU DoC co-signing or assignment: For white-label deployments where the partner places the product under their name, the agreement should specify who prepares the new EU DoC — the developer on behalf of the partner, or the partner independently.
Indemnification for trigger events: If the partner's white-labelling or modification triggers Art.25, the agreement should specify which party bears the cost of the resulting conformity assessment and documentation obligations.
Information rights: Partners should have audit rights to access the original manufacturer's technical documentation sufficient to verify that the underlying product meets Annex I requirements before they place it on the market under their own name.
Python CRAEconomicOperatorClassifier
This utility determines the CRA obligation level for a given commercial scenario:
from dataclasses import dataclass
from enum import Enum
from typing import Optional
class OperatorRole(Enum):
MANUFACTURER = "manufacturer"
IMPORTER = "importer"
DISTRIBUTOR = "distributor"
class CRAObligationLevel(Enum):
MANUFACTURER_FULL = "full_manufacturer_obligations"
IMPORTER_STANDARD = "importer_art18_obligations"
DISTRIBUTOR_STANDARD = "distributor_art19_obligations"
@dataclass
class OperatorScenario:
base_role: OperatorRole
places_under_own_name: bool
makes_modification: bool
modification_affects_conformity: bool
modification_is_substantial: bool
original_manufacturer_is_eu_established: Optional[bool] = None
def classify_cra_obligations(scenario: OperatorScenario) -> dict:
"""
Classify CRA obligations per Art.25.
Returns obligation level and applicable articles.
"""
art25_triggers = []
# Trigger 1: own-name placement
if scenario.places_under_own_name:
art25_triggers.append("Trigger 1 (Art.25(1)(a)): own-name placement")
# Trigger 2: modification affecting conformity
if scenario.makes_modification and scenario.modification_affects_conformity:
art25_triggers.append("Trigger 2 (Art.25(1)(b)): modification affecting conformity")
# Trigger 3: substantial modification
if scenario.makes_modification and scenario.modification_is_substantial:
art25_triggers.append("Trigger 3 (Art.25(1)(b)): substantial modification")
if art25_triggers:
return {
"obligation_level": CRAObligationLevel.MANUFACTURER_FULL,
"art25_triggers": art25_triggers,
"required_articles": ["Art.13", "Art.14", "Art.15", "Art.16",
"Art.17", "Art.22", "Art.23", "Art.24"],
"action": "Prepare new EU DoC, technical documentation, CE marking. "
"Register as manufacturer in EU database. Assign single point of contact.",
"warning": "Original manufacturer's conformity documentation does NOT transfer.",
}
if scenario.base_role == OperatorRole.IMPORTER:
return {
"obligation_level": CRAObligationLevel.IMPORTER_STANDARD,
"art25_triggers": [],
"required_articles": ["Art.18"],
"action": "Verify manufacturer's conformity documentation before EU market placement. "
"Retain EU DoC copy for 10 years. Cooperate with MSAs.",
}
return {
"obligation_level": CRAObligationLevel.DISTRIBUTOR_STANDARD,
"art25_triggers": [],
"required_articles": ["Art.19"],
"action": "Verify CE marking and EU DoC present. "
"Report non-conformities to manufacturer and MSA. "
"Do not make modifications that affect conformity.",
}
# Example: SaaS white-label reseller
white_label_scenario = OperatorScenario(
base_role=OperatorRole.IMPORTER,
places_under_own_name=True, # uses own brand
makes_modification=False,
modification_affects_conformity=False,
modification_is_substantial=False,
)
result = classify_cra_obligations(white_label_scenario)
print(result["obligation_level"])
# CRAObligationLevel.MANUFACTURER_FULL
print(result["art25_triggers"])
# ['Trigger 1 (Art.25(1)(a)): own-name placement']
Art.25 Checklist: 25 Items for Importers and Distributors
Pre-Classification (5 items)
- C-01: Identify all products in your portfolio that are not manufactured by your own legal entity
- C-02: For each third-party product: confirm whether you place it on the EU market under your own name, trademark, or brand identity
- C-03: For each third-party product: confirm whether you make any modifications before or after market placement
- C-04: Document your classification (manufacturer, importer, distributor) per product and per trigger analysis
- C-05: Obtain written confirmation from original manufacturers of their CRA obligation status
If Art.25 Applies — Conformity Assessment (6 items)
- C-06: Obtain or prepare Annex V technical documentation covering the product as you place it on the market
- C-07: Conduct or verify conformity assessment per Art.17 (Annex VIII, IX, or X based on product class)
- C-08: Prepare EU Declaration of Conformity under Art.23 in your name
- C-09: Affix CE marking under Art.24 per NLF format requirements
- C-10: Register product in the EU database for products with digital elements
- C-11: Assign a single point of contact per Art.15 for vulnerability coordination
Supply Chain Documentation (5 items)
- C-12: Obtain SBOM from original manufacturer or prepare your own per Art.13(1)(b) and Annex I Part II
- C-13: Verify the original manufacturer's vulnerability handling procedures are documented in technical docs
- C-14: Establish a CVD (Coordinated Vulnerability Disclosure) policy per Art.16(2) in your name
- C-15: Confirm security update supply chain obligations can be met for the product's supported lifetime
- C-16: Document the contractual allocation of Art.25 obligations in your white-label agreement
Modification Controls (5 items)
- C-17: Establish an internal modification review process that flags changes potentially engaging Art.25 Trigger 2 or 3
- C-18: For every contemplated product modification: run Art.20 substantial modification analysis before implementation
- C-19: If a modification is substantial: treat the modified product as a new placement and restart conformity assessment
- C-20: For configuration-only changes: document that the change does not affect Annex I security properties
- C-21: Prohibit downstream partners from making modifications that would engage Art.25 without your written consent
Ongoing Obligations (4 items)
- C-22: Retain EU DoC and technical documentation for 10 years after last product placement (Art.18(5) / Art.25(2))
- C-23: Implement ENISA vulnerability reporting workflow per Art.14 (24h early warning, 72h notification)
- C-24: Cooperate with national market surveillance authorities per Art.21
- C-25: Review Art.25 classification after any product update, pricing-tier change, or business model change that affects how the product is presented to market
See Also
- CRA Art.18: Importer Obligations — Standard importer duties when Art.25 does not apply
- CRA Art.19: Distributor Obligations — Standard distributor duties and when distributors must act
- CRA Art.20: Substantial Modification — What counts as substantial modification for the original manufacturer
- CRA Art.22: Technical Documentation — Annex V documentation requirements you must meet if Art.25 applies
- CRA Art.23: EU Declaration of Conformity — Preparing the EU DoC in your name as Art.25 manufacturer
- CRA Art.24: CE Marking — Affixing CE marking as Art.25 manufacturer for software