CRA Art.20: Substantial Modification — When a Distributor or Importer Becomes a Manufacturer (Developer Guide 2026)

Post #466 in the sota.io EU Cyber Compliance Series

The EU Cyber Resilience Act (Regulation (EU) 2024/2847, "CRA") creates a structured supply chain compliance framework: manufacturers carry the heaviest obligations under Art.13, while importers (Art.18) and distributors (Art.19) carry lighter but still real responsibilities. Article 20 is the mechanism that collapses this distinction — the provision that converts a distributor or importer into a manufacturer, instantly and without warning, when certain modification thresholds are crossed.

Art.20 is not a penalty provision. It is a reclassification rule. When it applies, the distributor or importer does not simply incur additional obligations on top of their existing role — they become the manufacturer of the modified product and must satisfy every obligation under Art.13, including conformity assessment, CE marking, technical documentation, vulnerability reporting, and 10-year record retention. The transformation is complete and immediate upon crossing the threshold.

Understanding Art.20 is therefore essential for any economic operator who touches a product between manufacture and end-user delivery. Distributors who customise deployments, resellers who add their own branding, and managed service providers who patch and harden software at the system level must each understand precisely where the Art.20 line falls — and what crossing it costs.

Critical deadline: 11 December 2027. Art.20 applies in full from that date. The Art.14 and Art.15 vulnerability notification requirements apply earlier — from 11 September 2026 — meaning operators who cross the Art.20 line for a product with actively exploited vulnerabilities face notification obligations as the manufacturer from September 2026.

The Two Transformation Triggers

Art.20 contains two distinct transformation triggers, each with different scope and consequences.

Trigger 1: Own Name or Trademark (Art.20(1))

Any distributor or importer that places a product with digital elements on the market under its own name or trademark is considered a manufacturer for that product and is subject to the obligations laid down for manufacturers in Art.13.

This trigger is unconditional. It does not depend on whether the underlying product was modified, whether the CE marking from the original manufacturer remains valid, or whether the product's security properties were changed. The act of rebranding — affixing an own name or trademark to the product — is sufficient to trigger full manufacturer obligations for the rebranded version.

The trigger operates independently of physical modification. A distributor who takes Software X, wraps it in a white-label packaging with their own brand name, and distributes it to EU customers is a manufacturer for that white-labelled version. The underlying Software X manufacturer retains their own obligations for the original product, but the white-labeller must independently satisfy Art.13 for the version they distribute.

SaaS-specific consideration: For software products, "placing under own name or trademark" can include assigning a product name, creating a product page, or issuing a product-specific DoC or SLA that presents the software as the distributor's own offering, even when the technical stack underneath is a third-party component. Distributors who operate managed services should check whether their service presentation crosses this threshold.

Trigger 2: Substantial Modification (Art.20(2))

Any natural or legal person who substantially modifies a product with digital elements that has been placed on the Union market is considered a manufacturer of the modified product and is subject to the obligations laid down for manufacturers in Art.13 with respect to the modified product.

This trigger is modification-based. It applies regardless of whether the modifier places the product under their own name, and regardless of their prior role in the supply chain. A distributor, an importer, a system integrator, or even an end-user organisation performing internal deployments may trigger Art.20(2) if their modification is substantial.

The Art.20(2) trigger generates a new product for compliance purposes: the "modified product" to which the modifier now owes Art.13 obligations. The original unmodified product retains its existing compliance status with its original manufacturer — Art.20(2) does not retroactively affect the original.

The Art.3(23) Definition: What Is a Substantial Modification?

Art.3(23) defines "substantial modification" as:

A modification of a product with digital elements, including through a software update or upgrade, that changes the intended purpose of the product, changes the risk class of the product, or affects the compliance of the product with the essential requirements set out in Annex I.

Three independent grounds, any one of which triggers the reclassification:

Ground 1: Change of Intended Purpose

The intended purpose is defined in Art.3(24) as the use for which a product is intended by the manufacturer, including the specific context and conditions of use, as specified in the information supplied by the manufacturer in the instructions for use, promotional material, and technical documentation.

A modification changes the intended purpose when it redirects the product toward a use category the original manufacturer did not design, declare, or document. Examples:

The last row illustrates a common misconception: mere deployment in a regulated sector does not change the intended purpose of the software itself. The modification must change what the product is designed to do, not merely where it is used.

Ground 2: Change of Risk Class

The CRA defines three product risk classes in Art.6 and Annex III:

• Default class: no Annex III category — self-assessment conformity route
• Class I (important products, Annex III Part I): self-assessment with harmonised standards or review by Notified Body
• Class II (critical products, Annex III Part II): mandatory third-party conformity assessment by Notified Body

A modification that moves a product from default to Class I, from Class I to Class II, or that adds functionalities listed in Annex III (e.g., adding a network-facing management interface to a previously offline product) substantially modifies the product by changing its risk classification. The modifier must then perform a conformity assessment appropriate to the new class — Class II products cannot self-certify.

Ground 3: Effect on Annex I Essential Requirements Compliance

Annex I specifies the security requirements that every product with digital elements must meet. Part I covers security properties of the product itself (secure by default, minimal attack surface, data protection, vulnerability handling, access control, data integrity). Part II covers vulnerability handling obligations (coordinated disclosure, security updates, SBOM maintenance).

A modification affects compliance with these requirements when it:

• Adds a new network interface not present in the original — expanding the attack surface in a way that requires fresh conformity assessment
• Changes authentication architecture — removing or weakening access control mechanisms declared in the original DoC
• Alters the update delivery mechanism — if the original product had a documented OTA update path and the modifier replaces this with a custom update system, the security properties of the update process (Art.13(2)(b) requires security updates to be delivered promptly) must be re-evaluated
• Removes security-relevant functionality — stripping out the original manufacturer's vulnerability disclosure contact mechanism, SBOM generation, or security notification endpoints

The Annex I ground is the most technically demanding to evaluate. It requires mapping each modification against the essential requirements and determining whether the modification materially affects the product's ability to satisfy them.

What Is NOT a Substantial Modification

The inverse is equally important. Modifications that do not trigger Art.20(2):

The distinction between "configuration" and "modification" is critical for managed service providers. Operating a product within its documented parameters — even heavily customised configurations — does not trigger Art.20(2). Only modifications that alter the product itself, including custom code additions, architectural changes, or replacement of security-relevant components, cross the threshold.

The Four Most Dangerous Software Scenarios

Scenario 1: OEM White-Label (Art.20(1) Trigger)

An EU SaaS reseller takes a US-origin productivity platform, adds their corporate brand as "ResellCo Workspace Pro", markets it under their name, and sells it to EU enterprise customers.

Art.20(1) applies unconditionally. ResellCo is the manufacturer of "ResellCo Workspace Pro" regardless of what the US vendor's compliance status is. ResellCo must:

• Perform a conformity assessment for the product as they distribute it
• Draw up their own EU Declaration of Conformity identifying ResellCo as manufacturer
• Affix the CE marking under their authority
• Draw up and maintain technical documentation per Annex VII
• Handle vulnerability reporting to ENISA (Art.14) as the manufacturer responsible for the product
• Provide a 10-year record retention commitment

The US vendor's existing DoC does not transfer. It covers the original product under the original name — not ResellCo's rebranded version. ResellCo cannot piggyback on it.

Scenario 2: Managed Service Hardening (Art.20(2) Borderline)

An EU managed security services provider (MSSP) takes a customer's on-premise network monitoring tool, installs it on their managed infrastructure, applies their custom security hardening playbook (custom WAF rules, OS-level CIS benchmarks, network segmentation, disabled default accounts), and operates it as a managed service.

The Art.20(2) analysis is fact-specific. Key questions:

• Do the custom WAF rules constitute a new security component not in the original product's architecture? If yes, this may affect Annex I compliance.
• Does the OS hardening modify the product itself (replacing security libraries, recompiling binaries) or merely the deployment environment? Environment hardening is not product modification.
• Does disabling default accounts and enabling custom authentication change the access control architecture the original manufacturer documented in their DoC?

Conservative approach: MSSPs should document all modifications in a "modification log" distinguishing environmental configuration (not Art.20) from product-level changes (potentially Art.20). For any modification touching security-relevant components, obtain written confirmation from the original manufacturer that the modification falls within their declared design envelope.

Scenario 3: Bundled Security Patches from Third Parties (Art.20(2) Analysis)

An EU software integrator bundles a third-party network library with their application, and subsequently discovers a CVE in that library. Rather than waiting for the upstream vendor to issue a patch, they apply their own backport of the fix and ship it as part of their product update.

Art.20(2) does not apply here — because the integrator is already the manufacturer of their own application. They were already responsible for the third-party component under Art.9 (due diligence for third-party components) and Art.13 (manufacturer obligations for the integrated product). Patching a dependency within their own product is not "substantially modifying a product placed on the market by another" — they are the manufacturer.

The scenario only triggers Art.20 if a distributor (not the manufacturer) applies such a patch. A distributor who patches a third-party product's vulnerability independently — rather than waiting for the manufacturer's own patch — is modifying the product. Whether that modification is substantial depends on the nature of the patch and its effect on Annex I compliance.

Scenario 4: Fork-and-Customise (Art.20(2) Trigger)

An EU consultancy takes an open-source CRA-compliant security scanner (covered by the Art.8 open-source steward framework or placed on the market by an original manufacturer), adds proprietary modules for automated exploitation, changes the intended purpose from "passive security assessment" to "active penetration testing", and distributes it to clients.

Art.20(2) applies. The change of intended purpose (from assessment to active exploitation) triggers Ground 1 of Art.3(23). The consultancy is the manufacturer of the fork and must satisfy Art.13 fully.

Additionally, the Art.8 open-source steward exception applies only to stewards of open-source software not placed on the market in a commercial activity context. A consultancy forking and distributing a customised version commercially is engaging in a commercial activity — the open-source steward exception does not apply to their distribution.

Art.13 Consequences: The Full Manufacturer Obligation Stack

When Art.20 triggers, the reclassified manufacturer incurs the complete Art.13 obligation matrix:

Penalty exposure: Failure to satisfy Art.13 obligations attracts penalties under Art.64(2) of up to €15,000,000 or 2.5% of global annual turnover, whichever is higher. Market surveillance authorities in each Member State are empowered to require withdrawal of the product from the market if Art.13 obligations are not satisfied.

Art.20 and the Art.18/19 Supply Chain Intersection

Art.20 does not operate in isolation. It interacts directly with the importer and distributor frameworks:

Art.19(1)(d) requires distributors to verify that manufacturers (Art.13(12)) and importers (Art.18(3)) have satisfied their contact detail obligations. A distributor who performs this verification and then proceeds to substantially modify the product triggers Art.20(2) — and their Art.19 verification obligations for the original product become irrelevant. They are now the manufacturer of the modified version.

Art.18(5) requires importers who discover non-conformity to inform the manufacturer and market surveillance authorities. An importer who instead decides to "fix" the non-conformity by modifying the product may trigger Art.20(2) — converting a disclosure obligation into a full manufacturer reclassification. The conservative approach for importers discovering non-conformity is always to notify — never to self-repair.

Art.19(2) requires distributors who discover non-conformity to inform the manufacturer and importer, not to fix the product. The same logic applies: fixing the non-conformity by modifying the product triggers Art.20(2).

Python Implementation: CRAModificationAnalyzer

from enum import Enum
from dataclasses import dataclass, field
from typing import List, Optional

class ModificationGround(Enum):
    OWN_NAME_TRADEMARK = "own_name_trademark"          # Art.20(1)
    INTENDED_PURPOSE_CHANGE = "intended_purpose_change" # Art.3(23) ground 1
    RISK_CLASS_CHANGE = "risk_class_change"             # Art.3(23) ground 2
    ANNEX_I_COMPLIANCE_AFFECTED = "annex_i_affected"   # Art.3(23) ground 3
    NO_TRIGGER = "no_trigger"

class Art20Result(Enum):
    MANUFACTURER_RECLASSIFIED = "manufacturer"
    NOT_TRIGGERED = "not_triggered"
    BORDERLINE_SEEK_LEGAL_ADVICE = "borderline"

@dataclass
class ModificationRecord:
    description: str
    affects_intended_purpose: bool
    affects_risk_class: bool
    affects_annex_i_compliance: bool
    adds_own_brand: bool
    evidence: str = ""
    legal_advice_obtained: bool = False

@dataclass
class CRAModificationAnalysis:
    product_name: str
    original_manufacturer: str
    operator_role: str  # "distributor", "importer", "integrator"
    modifications: List[ModificationRecord] = field(default_factory=list)

    def analyze(self) -> tuple[Art20Result, List[ModificationGround], str]:
        grounds: List[ModificationGround] = []
        recommendations: List[str] = []

        for mod in self.modifications:
            if mod.adds_own_brand:
                grounds.append(ModificationGround.OWN_NAME_TRADEMARK)
                recommendations.append(
                    f"Art.20(1) triggered: own name/trademark on '{self.product_name}'. "
                    "You are now the manufacturer. Initiate conformity assessment."
                )
            if mod.affects_intended_purpose:
                grounds.append(ModificationGround.INTENDED_PURPOSE_CHANGE)
                recommendations.append(
                    "Art.3(23) ground 1: intended purpose change detected. "
                    "Document original and modified intended purpose. Seek legal advice."
                )
            if mod.affects_risk_class:
                grounds.append(ModificationGround.RISK_CLASS_CHANGE)
                recommendations.append(
                    "Art.3(23) ground 2: risk class change detected. "
                    "Determine new class per Annex III. If Class II, Notified Body required."
                )
            if mod.affects_annex_i_compliance:
                grounds.append(ModificationGround.ANNEX_I_COMPLIANCE_AFFECTED)
                recommendations.append(
                    "Art.3(23) ground 3: Annex I compliance affected. "
                    "Map modification against each essential requirement. Borderline — seek legal advice."
                )

        if not grounds:
            return Art20Result.NOT_TRIGGERED, [], "No Art.20 triggers identified."

        has_unconditional = ModificationGround.OWN_NAME_TRADEMARK in grounds
        has_borderline = (
            ModificationGround.ANNEX_I_COMPLIANCE_AFFECTED in grounds
            and not has_unconditional
        )

        if has_unconditional:
            result = Art20Result.MANUFACTURER_RECLASSIFIED
        elif has_borderline:
            result = Art20Result.BORDERLINE_SEEK_LEGAL_ADVICE
        else:
            result = Art20Result.MANUFACTURER_RECLASSIFIED

        summary = (
            f"Art.20 analysis for '{self.product_name}' "
            f"({self.operator_role} → potential manufacturer). "
            f"Grounds triggered: {[g.value for g in set(grounds)]}. "
            f"Recommendations: {'; '.join(recommendations)}"
        )
        return result, list(set(grounds)), summary

def check_art20_modification(
    product_name: str,
    operator_role: str,
    original_manufacturer: str,
    modifications: List[dict],
) -> dict:
    records = [
        ModificationRecord(
            description=m.get("description", ""),
            affects_intended_purpose=m.get("affects_intended_purpose", False),
            affects_risk_class=m.get("affects_risk_class", False),
            affects_annex_i_compliance=m.get("affects_annex_i_compliance", False),
            adds_own_brand=m.get("adds_own_brand", False),
            evidence=m.get("evidence", ""),
        )
        for m in modifications
    ]
    analyzer = CRAModificationAnalysis(
        product_name=product_name,
        original_manufacturer=original_manufacturer,
        operator_role=operator_role,
        modifications=records,
    )
    result, grounds, summary = analyzer.analyze()
    return {
        "result": result.value,
        "grounds": [g.value for g in grounds],
        "summary": summary,
        "requires_art13_compliance": result == Art20Result.MANUFACTURER_RECLASSIFIED,
    }


# Usage example
if __name__ == "__main__":
    analysis = check_art20_modification(
        product_name="ResellCo Workspace Pro",
        operator_role="distributor",
        original_manufacturer="OriginalVendor Inc.",
        modifications=[
            {
                "description": "Added ResellCo brand name and logo to product",
                "adds_own_brand": True,
                "affects_intended_purpose": False,
                "affects_risk_class": False,
                "affects_annex_i_compliance": False,
                "evidence": "Product marketing page, reseller agreement",
            }
        ],
    )
    print(f"Result: {analysis['result']}")
    print(f"Requires Art.13 compliance: {analysis['requires_art13_compliance']}")
    print(f"Summary: {analysis['summary']}")

See Also

This post completes the CRA supply chain operator series:

• CRA Art.13: Manufacturer Obligations — Security-by-Design, SBOM, and 10-Year Update Support
• CRA Art.12: Authorised Representative — EU Mandate for Non-EU Manufacturers
• CRA Art.18: Importer Obligations — Product Verification and Supply Chain Compliance
• CRA Art.19: Distributor Obligations — Market Availability and Non-Conformity Response
• CRA Art.9: Due Diligence for Third-Party Components and Open-Source Integration

Art.20 Risk Checklist (20 Items)

Trigger Identification (Items 1–6)

• 1. Have we placed this product on the EU market under our own name or trademark? (Art.20(1) trigger — unconditional)
• 2. Have we made any modification to a product already placed on the market by another party? (Art.20(2) scope check)
• 3. Does any modification change the product's intended purpose as documented by the original manufacturer?
• 4. Does any modification move the product from one Annex III risk class to a higher one?
• 5. Does any modification add, remove, or replace a security-relevant component affecting Annex I compliance?
• 6. Have we applied patches, fixes, or updates authored by us (not the original manufacturer) to a third-party product?

Scope and Documentation (Items 7–12)

• 7. For each modification, have we documented the original product state and the modified state?
• 8. Have we mapped each modification against the Art.3(23) three-ground test?
• 9. Have we obtained written confirmation from the original manufacturer for any modification they assert is within their design envelope?
• 10. For borderline Annex I modifications, have we obtained qualified legal or technical advice?
• 11. Have we maintained a modification log distinguishing environmental configuration from product-level modifications?
• 12. Are our managed service agreements clear about where environmental hardening ends and product modification begins?

Art.13 Compliance (Items 13–17)

• 13. If Art.20 applies: have we performed a conformity assessment for the modified product?
• 14. If Art.20 applies: have we drawn up an EU Declaration of Conformity identifying us as manufacturer?
• 15. If Art.20 applies: have we affixed the CE marking to the modified product under our authority?
• 16. If Art.20 applies: have we drawn up Annex VII technical documentation for the modified product?
• 17. If Art.20 applies: have we established a vulnerability disclosure contact and SBOM for the modified product?

Ongoing Obligations (Items 18–20)

• 18. Have we established a process to re-evaluate Art.20 status for each future modification cycle?
• 19. Have we identified the market surveillance authority in each Member State where we distribute the modified product?
• 20. Have we ensured 10-year record retention capability for all Art.13 documentation associated with the modified product?

Art.20 is the CRA's supply chain accountability closure mechanism. Manufacturers, importers, and distributors each have calibrated obligations — but Art.20 ensures that the entity closest to the final product state carries the compliance weight for that state. Operators who rely on their supply chain role without examining their modification practices are exposed to full manufacturer liability, often without realising the threshold has been crossed. The distinction between configuration and modification, between environmental hardening and product alteration, is the most operationally consequential question the CRA poses to managed service providers and system integrators in 2026.

For EU-native deployment of CRA-compliant software products — with data residency, GDPR compliance, and infrastructure under EU jurisdiction — sota.io provides a managed PaaS that eliminates CLOUD Act exposure and simplifies the Art.14/15 notification stack for EU manufacturers.