CRA Art.3: Definitions — Product with Digital Elements, Manufacturer, Vulnerability, Substantial Modification (Developer Guide 2026)

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

The EU Cyber Resilience Act (Regulation (EU) 2024/2847, "CRA") entered into force on 10 December 2024. Its Article 3 contains more than 50 definitions that act as the foundational vocabulary for every obligation, every deadline, and every enforcement action in the Regulation.

Legal definitions are not academic. In the CRA, a single word — "manufacturer," "vulnerability," "substantial modification," "actively exploited" — determines whether you need to notify ENISA within 24 hours, whether your compliance clock restarts, and whether you bear obligations as a producer or merely as a distributor. Getting these definitions wrong has direct cost consequences.

This guide decodes the 12 definitions that matter most to software developers, explains their practical significance, and provides a Python tool that automates the initial definitional analysis for your products.

Art.3(1): "Product with Digital Elements"

The central concept of the entire CRA:

'product with digital elements' means any software or hardware product and its remote data processing solutions, including software or hardware components placed on the market separately, insofar as they are not exclusively placed on the market for national security or military purposes.

Three things make this definition broader than most developers expect:

"Remote data processing solutions" — if your product relies on cloud-side processing to function (device → cloud backend → device), that entire system is the product. You cannot split the hardware unit from its cloud component and argue the backend is pure SaaS. For IoT products especially, the definition captures the full stack.

"Components placed on the market separately" — a standalone library, SDK, CLI tool, or firmware module distributed to third parties is itself a product with digital elements. The component manufacturer bears independent CRA obligations for that component. Integrators bear separate obligations for the assembled product. This creates dual liability at every layer of a software supply chain.

"Insofar as they are not exclusively placed on the market for national security or military purposes" — the exclusion applies only to products developed exclusively for those purposes. Dual-use products — commercial software also sold to defence customers — remain in scope.

What Art.3(1) Covers That Developers Miss

Art.3(4): "Manufacturer"

'manufacturer' means a natural or legal person who develops or manufactures products with digital elements or has products with digital elements designed, developed or manufactured, and markets those products under their name or trademark, whether for payment or free of charge.

Four aspects define who is the manufacturer:

1. Development or manufacturing — you develop the product yourself, OR you commission its development.

2. Marketing under your name or trademark — the obligation attaches to the entity whose brand appears on the product. If you white-label a third-party product and sell it under your brand, you are the manufacturer under the CRA — not the original developer.

3. "Whether for payment or free of charge" — commercial distribution is not required. Free software distributed to third parties can create manufacturer obligations (subject to the Art.17 open-source safe harbour).

4. The subcontract scenario — if you outsource development to an agency or contract manufacturer but market the product under your brand, you bear full manufacturer obligations. The agency building the product for you does not automatically bear these obligations; you do.

The White-Label Trap

This is the most common definitional mistake. A startup reselling a white-labelled IoT module, a platform embedding a third-party SDK in their product, or a system integrator assembling components into a certified product — each may become the "manufacturer" under Art.3(4) with full Annex I essential requirements obligations, conformity assessment requirements, and vulnerability reporting duties.

Before white-labelling any product, verify who the CRA manufacturer is contractually. Agree who maintains the SBOM, who reports vulnerabilities to ENISA, and who bears CE-marking responsibility.

Art.3(9): "Open-Source Software Steward"

This is a new concept created by the CRA with no equivalent in prior EU law:

'open-source software steward' means a legal person, other than a manufacturer, that has the purpose or objective of systematically providing support for the development of specific products with digital elements qualifying as free and open-source software that are intended for commercial activities, and that ensures the viability of those products.

The open-source software steward category covers foundations, DAOs, and organisations that maintain and support open-source projects without commercially distributing them. Think: Linux Foundation, Apache Software Foundation, or similar entities supporting widely-used projects.

Why This Definition Matters

Open-source software stewards face a lighter regime than manufacturers under Art.17:

• No full Art.13 obligations (no CE marking, no formal conformity assessment)
• Only the "CVD-light" obligations: implement a coordinated vulnerability disclosure (CVD) policy, cooperate on vulnerability remediation, notify users of vulnerabilities
• Deadline: CVD policy must be operational by 11 September 2026

However, the steward category applies only to legal persons. Individual open-source maintainers are not stewards — they may qualify as manufacturers if they commercially distribute their software, or they may fall under no CRA obligation at all if their project is entirely non-commercial.

Distinguishing Stewards from Manufacturers

Art.3(14): "Placing on the Market"

'placing on the market' means the first making available of a product with digital elements on the Union market.

"Placing on the market" triggers the CRA compliance clock. Until a product is placed on the EU market, no CRA obligations attach. Once placed, full obligations apply (subject to transition deadlines).

Key implication: products already on the market before the CRA's Art.13 deadline (11 December 2027) have transition provisions. However, a substantial modification (see Art.3(26) below) effectively replaces the original product with a new one — restarting the compliance clock as if it were a freshly placed product.

Products Placed on Market Before Art.13 Applies

If your product was placed on the EU market before 11 December 2027, the Commission is expected to publish guidance on transition provisions. Generally: products already commercially available are not required to undergo full conformity assessment retroactively for their existing version, but updates constituting substantial modifications are treated as new products.

The CVD obligations (Art.14/15) apply from 11 September 2026 regardless — including for products already on the market.

Art.3(22): "Vulnerability"

'vulnerability' means a weakness, susceptibility or flaw of a product with digital elements that can be exploited by a cyber threat.

The definition is broad and intentionally technology-neutral. It covers:

• Classic software bugs exploitable as security issues (buffer overflows, injection flaws, logic errors)
• Configuration weaknesses (insecure defaults, exposed interfaces)
• Design flaws (insecure protocol design, missing authentication)
• Supply chain weaknesses (compromised dependency, tampered component)

There is no materiality threshold in the definition. Any exploitable weakness is a "vulnerability" for CRA purposes. However, the reporting and remediation obligations calibrate by severity — specifically through the "actively exploited vulnerability" concept.

Art.3(23): "Actively Exploited Vulnerability"

'actively exploited vulnerability' means a vulnerability for which there is reliable evidence that a malicious actor has exploited it in a system in the wild.

This definition is the trigger for the most urgent CRA obligation. Under Art.14(1):

Manufacturers shall, without undue delay and in any event within 24 hours of becoming aware of an actively exploited vulnerability contained in their product, notify ENISA.

The 24-hour ENISA notification window makes "actively exploited vulnerability" operationally critical. Your monitoring, threat intelligence, and incident response systems must be able to:

1. Identify when a vulnerability in your product is being actively exploited in the wild
2. Distinguish between theoretical exploit code and actual in-wild exploitation
3. Trigger the Art.14 notification workflow within 24 hours of awareness

The "Reliable Evidence" Standard

"Reliable evidence that a malicious actor has exploited it in a system in the wild" requires actual exploitation, not theoretical exploitability. A publicly published proof-of-concept exploit does not automatically constitute reliable evidence of active exploitation. However, CISA KEV (Known Exploited Vulnerabilities) entries, threat intelligence feeds confirming active attacks, or direct evidence from your incident response systems typically satisfy the standard.

Operationally: align your ENISA notification SLAs with your threat intelligence ingestion. If you subscribe to commercial threat intel feeds or monitor CVE databases, you need a triage process that flags CRA-relevant active exploitations within hours.

Art.3(25): "Security Update"

'security update' means an update to a product with digital elements that addresses security vulnerabilities.

Security updates trigger specific Art.13 obligations:

• Manufacturers must make security updates available for a period appropriate to the expected product lifetime (minimum 5 years for most products under Art.13(8))
• Security updates must be distributed to users without additional charge (Art.13(7))
• Updates must be clearly distinguishable from functional updates (Art.13(6))

The "without additional charge" requirement has business model implications. If your product has a subscription tier that controls access to security patches, that model is non-compliant with Art.13(7) for any product subject to the CRA. Security patches must flow to all users regardless of subscription status.

Art.3(26): "Functional Update"

'functional update' means an update to a product with digital elements that provides new or modified functionalities.

The distinction between security updates and functional updates matters because:

1. Substantial modification analysis: some functional updates may constitute "substantial modifications" that restart the compliance clock (Art.3(27))
2. Disclosure: manufacturers must provide documentation enabling users to distinguish security updates from functional updates
3. Commercial terms: unlike security updates, functional updates may be gated behind commercial terms

In practice, many updates are "mixed" — they add features while also fixing security issues. CRA guidance is expected to address mixed updates; the conservative approach is to treat any update containing a security fix as a security update for Art.13(7) purposes.

Art.3(27): "Substantial Modification"

'substantial modification' means a modification of the product with digital elements, after its placing on the market, that affects the security of the product with digital elements or results in a change to the intended purpose for which the product with digital elements has been assessed...

A substantial modification has one critical consequence: the modified product is treated as a new product placed on the market. The compliance clock restarts. The manufacturer must re-assess conformity, potentially re-engage a notified body, and re-issue the Declaration of Conformity.

What Constitutes a Substantial Modification

The CRA specifies that substantial modification includes:

• Changes that affect the cybersecurity properties of the product
• Changes to the intended purpose for which the product was assessed
• Software changes not covered by planned security or functional updates
• Changes that a new conformity assessment would be required for

What Does NOT Constitute a Substantial Modification

Routine maintenance updates — security patches, bug fixes, performance improvements that do not add new functionality or change the product's security posture substantially — are not substantial modifications. Continuous delivery models can update products without restarting the compliance clock, provided:

• Updates fall within the scope of the product's existing conformity assessment
• Updates are documented in the technical file
• Updates do not change the intended purpose or substantially alter cybersecurity characteristics

For DevOps-heavy teams deploying multiple times per day: ordinary CI/CD deployments are not substantial modifications. The question is whether a deployment changes the product's CRA-assessed characteristics, not whether it changes code.

Art.3(36): "Significant Cybersecurity Risk"

The CRA uses "significant cybersecurity risk" as a threshold for certain obligations, including the notification obligations under Art.14(3) (serious incidents affecting security). The definition references ENISA guidelines on cybersecurity risk assessment.

Practically: significant risk involves combination of likelihood of exploitation and potential impact — typically involving potential for data breach, service disruption, safety impact, or supply-chain compromise. Minor vulnerabilities in non-critical functions with limited exposure are unlikely to cross the "significant" threshold; remotely exploitable authentication bypasses in internet-facing software almost certainly do.

The Six Economic Operator Roles

Beyond manufacturer (Art.3(4)), the CRA defines five additional economic operator roles that bear specific — and significantly lighter — obligations:

For B2B software supply chains, the importer and distributor roles create derivative liability. If you distribute third-party software products (e.g., a marketplace model, an app store, or a software catalogue), you bear obligations to verify the CE marking and compliance documentation of products you distribute — even if you are not the manufacturer.

Art.3(32): "Recall" and Art.3(33): "Withdrawal"

These terms define two market correction mechanisms:

• Recall (Art.3(32)): any measure aimed at returning a product already placed on the market or made available to end-users — requiring users to return non-compliant or dangerous products
• Withdrawal (Art.3(33)): any measure aimed at preventing a product in the supply chain from being made available on the market — pulling products that have not yet reached end-users

Market surveillance authorities can order recalls and withdrawals of non-compliant products under Art.54. The practical risk: if your product is found non-compliant (missing CVD policy, no conformity assessment, missing CE marking), you may face a recall order requiring you to contact all customers and remediate.

Understanding these definitions matters for contract drafting — indemnification clauses, liability allocation between manufacturer and distributor, and supply-chain agreements should address the possibility of recall or withdrawal proceedings.

Python CRADefinitionsAnalyser

The following tool automates definitional classification for a software product:

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


class EconomicOperatorRole(Enum):
    MANUFACTURER = "Manufacturer"
    AUTHORISED_REPRESENTATIVE = "Authorised Representative"
    IMPORTER = "Importer"
    DISTRIBUTOR = "Distributor"
    OSS_STEWARD = "Open-Source Software Steward"
    SUBSTANTIAL_MODIFIER = "Person Who Substantially Modifies"
    NON_COMMERCIAL_OSS = "Non-Commercial OSS (Art.17 regime)"
    OUTSIDE_SCOPE = "Outside Scope"


class VulnerabilityClassification(Enum):
    NOT_VULNERABILITY = "Not a vulnerability"
    VULNERABILITY = "Vulnerability (Art.3(22))"
    ACTIVELY_EXPLOITED = "Actively exploited vulnerability (Art.3(23)) — 24h ENISA notification required"


@dataclass
class ProductProfile:
    name: str
    has_software_or_hardware: bool = True
    placed_on_eu_market: bool = True
    distributed_to_third_parties: bool = True
    # Economic operator analysis
    develops_under_own_brand: bool = False
    commissions_development: bool = False
    white_labels_third_party: bool = False
    is_non_eu_manufacturer_eu_rep: bool = False
    imports_non_eu_product: bool = False
    distributes_without_modification: bool = False
    is_oss_foundation_or_steward: bool = False
    is_purely_non_commercial_oss: bool = False
    # Modification analysis
    is_substantial_modification: bool = False
    modification_changes_security_posture: bool = False
    modification_changes_intended_purpose: bool = False
    # Security update classification
    addresses_vulnerability: bool = False
    adds_new_functionality: bool = False
    notes: list[str] = field(default_factory=list)


@dataclass
class VulnerabilityReport:
    description: str
    affects_product_in_scope: bool = True
    is_exploitable: bool = False
    has_public_poc: bool = False
    cisa_kev_listed: bool = False
    threat_intel_confirms_exploitation: bool = False
    direct_incident_evidence: bool = False


def classify_operator(profile: ProductProfile) -> dict:
    result = {
        "product": profile.name,
        "role": None,
        "obligations": [],
        "deadline_sep_2026": [],
        "deadline_dec_2027": [],
        "warnings": [],
    }

    if not profile.placed_on_eu_market or not profile.distributed_to_third_parties:
        result["role"] = EconomicOperatorRole.OUTSIDE_SCOPE
        result["obligations"].append("No CRA obligations — product not placed on EU market")
        return result

    if profile.is_purely_non_commercial_oss:
        result["role"] = EconomicOperatorRole.NON_COMMERCIAL_OSS
        result["obligations"].append("Art.17 CVD-light regime — lighter obligations")
        result["deadline_sep_2026"].append("Publish coordinated vulnerability disclosure (CVD) policy (Art.15)")
        result["warnings"].append("Verify: no indirect commercial benefit (paid support, hosted version)")
        return result

    if profile.is_oss_foundation_or_steward:
        result["role"] = EconomicOperatorRole.OSS_STEWARD
        result["obligations"].append("CVD policy (Art.15)")
        result["obligations"].append("Vulnerability disclosure cooperation (Art.14)")
        result["deadline_sep_2026"].append("Publish CVD policy (Art.15)")
        return result

    if profile.distributes_without_modification and not profile.develops_under_own_brand:
        result["role"] = EconomicOperatorRole.DISTRIBUTOR
        result["obligations"].append("Verify CE marking on distributed products")
        result["obligations"].append("Do not distribute products without CE marking after Art.13 deadline")
        result["deadline_dec_2027"].append("Cease distributing non-compliant products (Art.20)")
        result["warnings"].append("Check: do any distributed products lack conformity documentation?")
        return result

    if profile.imports_non_eu_product:
        result["role"] = EconomicOperatorRole.IMPORTER
        result["obligations"].append("Verify CE marking and technical documentation before placing on market")
        result["obligations"].append("Label product with own name and contact details")
        result["obligations"].append("Ensure manufacturer has drawn up technical file")
        result["deadline_dec_2027"].append("Only import compliant products (Art.19)")
        return result

    if profile.is_non_eu_manufacturer_eu_rep:
        result["role"] = EconomicOperatorRole.AUTHORISED_REPRESENTATIVE
        result["obligations"].append("Act as point of contact for market surveillance authorities")
        result["obligations"].append("Register in ENISA EUCC database")
        result["obligations"].append("Verify manufacturer has fulfilled obligations before accepting mandate")
        return result

    # Manufacturer — white-label or own development
    if profile.develops_under_own_brand or profile.commissions_development or profile.white_labels_third_party:
        result["role"] = EconomicOperatorRole.MANUFACTURER
        result["obligations"] = [
            "Annex I essential requirements (security-by-design, vulnerability handling)",
            "Annex II technical documentation",
            "SBOM (Art.13(1))",
            "CE marking (Art.20)",
            "Declaration of Conformity (Art.22)",
            "Conformity assessment (Art.23-36)",
            "Security updates free of charge for minimum product lifetime (Art.13(7-8))",
            "CVD policy (Art.15)",
            "ENISA notification of actively exploited vulnerabilities within 24h (Art.14(1))",
            "ENISA initial report within 72h of active exploitation awareness (Art.14(1))",
        ]
        result["deadline_sep_2026"] = [
            "Publish CVD policy (Art.15)",
            "Establish 24h ENISA notification process (Art.14)",
        ]
        result["deadline_dec_2027"] = [
            "Complete conformity assessment",
            "Affix CE marking",
            "Draw up Declaration of Conformity",
            "Ensure technical documentation complete",
        ]
        if profile.white_labels_third_party:
            result["warnings"].append(
                "White-label arrangement: you bear manufacturer obligations even though you did not develop the product"
            )
            result["warnings"].append(
                "Ensure supply agreement requires upstream manufacturer to provide SBOM, technical file, and vulnerability support"
            )

    if profile.is_substantial_modification:
        result["role"] = EconomicOperatorRole.SUBSTANTIAL_MODIFIER
        result["warnings"].append(
            "Substantial modification: this version is treated as a new product — full conformity assessment required"
        )
        result["obligations"].append("Re-run conformity assessment for modified product")
        result["obligations"].append("Update Declaration of Conformity")
        result["obligations"].append("Update technical documentation")

    return result


def classify_vulnerability(report: VulnerabilityReport) -> dict:
    result = {
        "description": report.description,
        "classification": None,
        "notification_required": False,
        "notification_deadline_hours": None,
        "evidence_basis": [],
        "recommended_actions": [],
    }

    if not report.is_exploitable:
        result["classification"] = VulnerabilityClassification.NOT_VULNERABILITY
        result["recommended_actions"].append("Document as non-security issue in technical file")
        return result

    # Check for active exploitation evidence
    active_exploitation_evidence = []
    if report.cisa_kev_listed:
        active_exploitation_evidence.append("Listed in CISA Known Exploited Vulnerabilities catalogue")
    if report.threat_intel_confirms_exploitation:
        active_exploitation_evidence.append("Threat intelligence confirms in-wild exploitation")
    if report.direct_incident_evidence:
        active_exploitation_evidence.append("Direct incident evidence from own systems or customers")

    if active_exploitation_evidence:
        result["classification"] = VulnerabilityClassification.ACTIVELY_EXPLOITED
        result["notification_required"] = True
        result["notification_deadline_hours"] = 24
        result["evidence_basis"] = active_exploitation_evidence
        result["recommended_actions"] = [
            "Notify ENISA within 24 hours via EUVDB (Art.14(1)(a))",
            "Submit initial notification to national CSIRT within 24 hours (Art.14(1)(b))",
            "Submit detailed report within 72 hours (Art.14(1)(c))",
            "Prepare final report within 14 days (Art.14(1)(d))",
            "Begin patch development — Art.13 requires security updates without undue delay",
            "Notify affected users if workaround is possible before patch",
        ]
    else:
        result["classification"] = VulnerabilityClassification.VULNERABILITY
        result["notification_required"] = False
        result["recommended_actions"] = [
            "Log in vulnerability register (required by Art.13(1))",
            "Assess severity and develop remediation timeline",
            "Disclose via CVD policy process (Art.15)",
            "Issue security update without undue delay once remediated (Art.13(6))",
        ]
        if report.has_public_poc:
            result["recommended_actions"].insert(
                0, "WARNING: Public PoC exists — monitor threat intel for active exploitation evidence"
            )

    return result


def classify_update(addresses_vulnerability: bool, adds_functionality: bool) -> dict:
    if addresses_vulnerability and not adds_functionality:
        return {
            "type": "Security Update (Art.3(25))",
            "must_be_free": True,
            "counts_as_substantial_modification": False,
            "note": "Must be distributed free of charge to all users (Art.13(7))",
        }
    elif addresses_vulnerability and adds_functionality:
        return {
            "type": "Mixed Update — treat as Security Update for Art.13(7) purposes",
            "must_be_free": True,
            "counts_as_substantial_modification": False,
            "note": "Conservative approach: any update containing security fixes is a security update under Art.13(7)",
        }
    else:
        return {
            "type": "Functional Update (Art.3(26))",
            "must_be_free": False,
            "counts_as_substantial_modification": "Assess: does it change security posture or intended purpose?",
            "note": "May be gated behind commercial terms; assess for substantial modification",
        }


# Example runs
if __name__ == "__main__":
    examples = [
        ProductProfile(
            name="Commercial IoT SDK (white-labelled)",
            develops_under_own_brand=True,
            white_labels_third_party=True,
            distributed_to_third_parties=True,
        ),
        ProductProfile(
            name="Open-Source Foundation (e.g., supports OSS project)",
            is_oss_foundation_or_steward=True,
        ),
        ProductProfile(
            name="EU Distributor of US Security Software",
            distributes_without_modification=True,
            imports_non_eu_product=True,
        ),
    ]

    print("=== OPERATOR CLASSIFICATION ===")
    for p in examples:
        r = classify_operator(p)
        print(f"\nProduct: {r['product']}")
        print(f"Role: {r['role'].value if r['role'] else 'N/A'}")
        for o in r["obligations"][:3]:
            print(f"  Obligation: {o}")
        for w in r["warnings"]:
            print(f"  ⚠ {w}")
        for d in r["deadline_sep_2026"]:
            print(f"  → Sep 2026: {d}")

    print("\n=== VULNERABILITY CLASSIFICATION ===")
    vulns = [
        VulnerabilityReport(
            description="Auth bypass in API endpoint",
            is_exploitable=True,
            cisa_kev_listed=True,
            threat_intel_confirms_exploitation=True,
        ),
        VulnerabilityReport(
            description="SQL injection (PoC published, no confirmed exploitation)",
            is_exploitable=True,
            has_public_poc=True,
        ),
        VulnerabilityReport(
            description="Logic error with no security impact",
            is_exploitable=False,
        ),
    ]
    for v in vulns:
        r = classify_vulnerability(v)
        print(f"\nVulnerability: {r['description']}")
        print(f"Classification: {r['classification'].value if r['classification'] else 'N/A'}")
        if r["notification_required"]:
            print(f"  ⏰ NOTIFY ENISA WITHIN {r['notification_deadline_hours']}h")
        for a in r["recommended_actions"][:2]:
            print(f"  → {a}")

The 10 Art.3 Definitions That Determine Your Compliance Level

To summarise the hierarchy of obligations driven by Art.3 definitions:

Key Deadlines for All In-Scope Manufacturers

The Art.3 definitions feed directly into two critical CRA deadlines:

The September 2026 deadline is 5 months away. If your product is a product with digital elements under Art.3(1) and you have not yet begun CVD policy development, that gap needs to close now.

See Also

• CRA Art.2: Scope and Product Coverage — Which Software Falls Under the CRA
• CRA Art.13: Manufacturer Obligations — Security-by-Design, SBOM, and 10-Year Update Support
• CRA Art.16: Vulnerability Reporting to ENISA and Coordinated Disclosure
• EU Cyber Resilience Act: SBOM and Vulnerability Handling
• CRA and NIS2 Overlap: Dual Compliance for Software Manufacturers