sota.io
2026-04-19·16 min read·

CRA Art.2: Scope and Product Coverage — Which Software and Hardware Falls Under the EU Cyber Resilience Act (Developer Guide 2026)

Post #455 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. Before spending any time on Art.13 manufacturer obligations, SBOM generation, or conformity assessment procedures, you need to answer a single prior question: does your product fall under the CRA at all?

Article 2 answers that question. It defines the material scope — which products are regulated — and carves out specific categories that remain outside the CRA's reach. Getting this analysis wrong in either direction is costly: false negatives miss compliance obligations that carry fines up to €15 million or 2.5% of global annual turnover, while false positives waste significant engineering resources on unnecessary CE marking procedures.

This guide gives you a systematic framework for Art.2 scope analysis, covers every exclusion in detail, explains why the SaaS/cloud carve-out is narrower than most developers expect, and provides a practical Python tool to automate the initial assessment.

Art.2(1): The Core Definition — "Products with Digital Elements"

The CRA applies to products with digital elements placed on the EU market. Art.3(1) defines this as:

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 elements require unpacking:

1. "Software or hardware product" — this is broader than most developers assume. The CRA covers both pure software (libraries, applications, firmware) and physical devices with embedded software. A router, a smart lock, an industrial sensor, a mobile app, and a cloud SDK are all potentially in scope.

2. "Remote data processing solutions" — if your product relies on backend cloud infrastructure to function, that infrastructure is part of the product for CRA purposes. A fitness tracker that uploads data to your SaaS backend is not just the physical device — it is the device plus the cloud service together.

3. "Components placed on the market separately" — standalone libraries and SDKs that developers incorporate into their own products can be in scope as independent products. The component manufacturer bears CRA obligations for their component; the integrating manufacturer bears separate obligations for the assembled product. This creates a supply-chain compliance cascade explored in detail in our CRA supply chain guide.

The "Placed on the Market" Threshold

"Placed on the market" means made available to third parties on the EU market for the first time. Products developed and used exclusively in-house — with no external distribution or commercialisation — are not placed on the market and therefore fall outside Art.2(1).

This matters significantly for enterprise software teams. Internal tools, intranet applications, and bespoke systems built for and used only by the developing organisation are excluded by default. The moment you distribute to a third party (even a subsidiary or customer), the product is on the market.

Art.2(2): The Explicit Exclusions

Art.2(2) lists seven categories excluded from the CRA's scope. Each deserves careful analysis because the boundaries are precise.

Exclusion 1: National Security and Military Purposes

Products developed exclusively for national security or military purposes are excluded. "Exclusively" is the critical qualifier. A dual-use product — one marketed commercially and also used by defence customers — does not qualify for this exclusion. The product must have been developed exclusively for those purposes from the outset.

For most commercial software vendors, this exclusion is irrelevant.

Exclusion 2: Marine Equipment

Products subject to the Marine Equipment Directive (2014/90/EU) are excluded. This covers equipment installed on ships (navigation systems, firefighting equipment, life-saving appliances). Irrelevant for most developers.

Exclusion 3: Aviation

Products covered by Regulation (EU) 2018/1139 (EASA regulation on aviation safety) are excluded. Aviation-specific software and hardware — flight management systems, aircraft components — fall under the aviation safety regime rather than the CRA.

Exclusion 4: Motor Vehicles

Products covered by Regulation (EU) 2019/2144 (vehicle type-approval) are excluded. Automotive ECUs, ADAS software, and connected vehicle systems are regulated under the vehicle framework, not the CRA. However, aftermarket software products that plug into vehicles but are not certified under 2019/2144 may remain in scope.

Exclusion 5: Medical Devices

Products covered by Regulation (EU) 2017/745 (MDR) or Regulation (EU) 2017/746 (IVDR) are excluded from the main CRA requirements. Medical device software (SaMD) and in-vitro diagnostic devices have their own cybersecurity requirements under those Regulations.

Important caveat: Recital 15 of the CRA notes that the Commission will assess whether to include medical devices within the CRA framework in a future review. The exclusion is not permanent. Additionally, software that is ancillary to a medical device — for example, a hospital management system used alongside but not integrated into a medical device — is not automatically excluded.

Exclusion 6: Civil Aviation Security Equipment

Security equipment for civil aviation under Regulation (EU) 2008/300 is excluded. Narrow and sector-specific.

Exclusion 7: Products Regulated Under National Security Frameworks

Member states retain authority over products exclusively used for national security, law enforcement, and criminal investigations. This is a member-state carve-out, not a blanket exclusion for anything marketed to governments.

Art.2(3): The Online Services / SaaS Question

This is where most cloud-native developers make mistakes. Art.2(3) provides:

This Regulation does not apply to software as a service unless that software is used for the remote data processing operations of products with digital elements.

Reading this quickly, developers conclude: "SaaS is excluded." That reading is wrong.

What Art.2(3) Actually Excludes

Art.2(3) excludes pure SaaS — software delivered as a service with no hardware product, no firmware, and no standalone software artefact placed on the market. Think: a project management tool like Jira, a document editor like Google Docs, a CRM system. These are pure SaaS: the "product" is the service subscription, not a distributable software artefact.

What Art.2(3) Does Not Exclude

The exclusion explicitly does not apply to software used for remote data processing operations of products with digital elements. If your software:

…then it is not excluded by Art.2(3). It is the remote data processing solution component of a product with digital elements, and it is in scope.

The sota.io PaaS Example

A Platform-as-a-Service like sota.io runs customer-submitted containers and applications. The question under Art.2(3) is: is sota.io itself a product with digital elements, or a pure SaaS?

The analysis depends on what customers deploy. If customers deploy:

For PaaS and IaaS providers, the CRA primarily affects your customers' products rather than the infrastructure itself. However, if you distribute software tooling (CLIs, SDKs, client libraries) to customers, those tools are separate products with digital elements in scope of Art.2.

The "Free and Open Source" Safe Harbour

Art.17 of the CRA provides a limited safe harbour for open-source software. Software distributed under open-source licences and not commercially monetised (directly or indirectly) falls outside the CRA's full scope. Such maintainers face only the "CVD-light" regime of Art.14/15 (vulnerability disclosure) rather than the full Art.13 obligations.

However, if you:

…the commercial dimension removes the safe harbour. Open-source is not a blanket CRA exclusion for commercial developers.

Art.2 and Product Classification: The Four Tiers

Once you establish that your product is in scope under Art.2(1), the next question is which product tier applies. The CRA classifies products into four categories with different conformity assessment requirements:

CategoryExamplesConformity Assessment
Standard productsMost software, general-purpose appsSelf-assessment (Module A)
Important — Class APassword managers, VPNs, firewalls, network management softwareSelf-assessment with harmonised standards OR third-party audit
Important — Class BOperating systems, hypervisors, industrial control software, TPMsMandatory third-party audit (notified body)
CriticalHardware security modules, smart cards, microprocessors with security functionsEuropean cybersecurity scheme certification

Annex III lists Class A and Class B important products. Annex IV lists critical products. Products not listed are standard.

For developers, the classification question has major cost implications. A Class B designation means involving a notified body — a significant conformity assessment cost and timeline. Knowing your tier from the start allows accurate project planning.

Common Misclassifications

VPNs and firewalls are Class A, not standard. If you distribute a VPN client application (even as part of a PaaS offering), it is Class A.

Network management software (Art.3 of Annex III definition) is Class A. This includes device management platforms, network configuration tools, and monitoring agents with privileged network access.

Operating system kernels are Class B. If your product includes a custom OS or a hardened Linux kernel distribution, you are Class B.

Browser extensions with security functions — the classification is ambiguous and expected to be clarified in Commission delegated acts. Conservative approach: treat security-related browser extensions as Class A until guidance is published.

Timeline: When Does Art.2 Scope Analysis Matter?

Art.2 scope is relevant immediately. Understanding whether your product is in scope determines your compliance planning horizon:

DeadlineObligation
11 September 2026Art.14 (actively exploited vulnerability notifications to ENISA) and Art.15 (CVD policy) apply to ALL in-scope products
11 December 2027Art.13 full manufacturer obligations, conformity assessment, CE marking

If your product is in scope under Art.2, you need a coordinated vulnerability disclosure (CVD) policy operational by September 2026 — less than six months from now. The December 2027 deadline for full Art.13 compliance is 20 months away.

Products placed on the market after the applicable deadline must comply at time of placement. Products already on the market at the deadline have transition provisions, but ongoing updates restart the compliance clock.

Python CRAScopeChecker

The following tool automates the initial Art.2 scope analysis based on product characteristics:

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


class ScopeResult(Enum):
    IN_SCOPE = "IN_SCOPE"
    EXCLUDED = "EXCLUDED"
    UNCERTAIN = "UNCERTAIN"


class ProductTier(Enum):
    STANDARD = "Standard"
    CLASS_A = "Important Class A"
    CLASS_B = "Important Class B"
    CRITICAL = "Critical"


@dataclass
class ProductProfile:
    name: str
    # Art.2(1) characteristics
    has_software_component: bool = True
    has_hardware_component: bool = False
    placed_on_eu_market: bool = True
    distributed_to_third_parties: bool = True
    # Art.2(2) exclusion flags
    exclusively_national_security: bool = False
    covered_by_mdr_ivdr: bool = False
    covered_by_motor_vehicle_reg: bool = False
    covered_by_aviation_reg: bool = False
    covered_by_marine_equipment_dir: bool = False
    # Art.2(3) SaaS analysis
    is_pure_saas_no_hardware: bool = False
    provides_remote_processing_for_hardware_product: bool = False
    # Open-source
    is_open_source: bool = False
    has_commercial_dimension: bool = True
    # Classification (Annex III / IV)
    is_vpn_firewall: bool = False
    is_password_manager: bool = False
    is_network_management: bool = False
    is_os_kernel_hypervisor: bool = False
    is_industrial_control: bool = False
    is_hsm_smartcard: bool = False
    custom_tier_override: Optional[ProductTier] = None
    notes: list[str] = field(default_factory=list)


def analyse_scope(profile: ProductProfile) -> dict:
    result = {"product": profile.name, "scope": None, "tier": None, "reasons": [], "actions": []}

    # Step 1: Basic placement check
    if not profile.placed_on_eu_market or not profile.distributed_to_third_parties:
        result["scope"] = ScopeResult.EXCLUDED
        result["reasons"].append("Not placed on EU market / internal use only — Art.2(1) threshold not met")
        return result

    # Step 2: Art.2(2) explicit exclusions
    if profile.exclusively_national_security:
        result["scope"] = ScopeResult.EXCLUDED
        result["reasons"].append("Exclusively national security / military — Art.2(2)(a)")
        return result
    if profile.covered_by_mdr_ivdr:
        result["scope"] = ScopeResult.EXCLUDED
        result["reasons"].append("Covered by MDR/IVDR — Art.2(2)(e)")
        result["actions"].append("Verify MDR/IVDR cybersecurity requirements apply instead")
        return result
    if profile.covered_by_motor_vehicle_reg:
        result["scope"] = ScopeResult.EXCLUDED
        result["reasons"].append("Covered by Regulation (EU) 2019/2144 — Art.2(2)(c)")
        return result
    if profile.covered_by_aviation_reg:
        result["scope"] = ScopeResult.EXCLUDED
        result["reasons"].append("Covered by Regulation (EU) 2018/1139 — Art.2(2)(b)")
        return result
    if profile.covered_by_marine_equipment_dir:
        result["scope"] = ScopeResult.EXCLUDED
        result["reasons"].append("Covered by Marine Equipment Directive — Art.2(2)(d)")
        return result

    # Step 3: Art.2(3) SaaS carve-out
    if profile.is_pure_saas_no_hardware and not profile.provides_remote_processing_for_hardware_product:
        result["scope"] = ScopeResult.EXCLUDED
        result["reasons"].append("Pure SaaS with no hardware dependency — Art.2(3) carve-out")
        result["actions"].append("Verify: does any customer use your service as remote processing for a hardware product?")
        return result

    # Step 4: Open-source safe harbour
    if profile.is_open_source and not profile.has_commercial_dimension:
        result["scope"] = ScopeResult.UNCERTAIN
        result["reasons"].append("Non-commercial open source — Art.17 CVD-light regime may apply")
        result["actions"].append("Implement CVD policy by 11 Sep 2026 (Art.14/15 still applies)")
        result["actions"].append("Confirm no indirect commercial benefit (cloud hosting, support contracts)")
        return result

    # Step 5: In scope — determine tier
    result["scope"] = ScopeResult.IN_SCOPE
    result["reasons"].append("Product with digital elements placed on EU market — Art.2(1) in scope")

    if profile.custom_tier_override:
        tier = profile.custom_tier_override
    elif profile.is_hsm_smartcard:
        tier = ProductTier.CRITICAL
    elif profile.is_os_kernel_hypervisor or profile.is_industrial_control:
        tier = ProductTier.CLASS_B
    elif profile.is_vpn_firewall or profile.is_password_manager or profile.is_network_management:
        tier = ProductTier.CLASS_A
    else:
        tier = ProductTier.STANDARD

    result["tier"] = tier

    # Actions based on tier
    result["actions"].append("Implement CVD policy by 11 Sep 2026 (Art.14/15 deadline)")
    result["actions"].append("Begin Art.13 compliance programme — December 2027 deadline")
    if tier == ProductTier.CLASS_A:
        result["actions"].append("Engage notified body OR apply harmonised standards for self-assessment")
    elif tier == ProductTier.CLASS_B:
        result["actions"].append("Engage notified body — mandatory third-party audit required")
    elif tier == ProductTier.CRITICAL:
        result["actions"].append("Obtain European cybersecurity certification under applicable scheme")

    return result


# Example analysis
if __name__ == "__main__":
    products = [
        ProductProfile(
            name="PaaS Platform (e.g. sota.io)",
            is_pure_saas_no_hardware=False,
            provides_remote_processing_for_hardware_product=False,
            has_software_component=True,
            notes=["Distributes CLI tools and client SDKs → those artefacts are in-scope products"],
        ),
        ProductProfile(
            name="IoT Fleet Management Cloud Backend",
            is_pure_saas_no_hardware=False,
            provides_remote_processing_for_hardware_product=True,
        ),
        ProductProfile(
            name="SaaS Project Management Tool",
            is_pure_saas_no_hardware=True,
            provides_remote_processing_for_hardware_product=False,
        ),
        ProductProfile(
            name="Open-Source VPN Library",
            is_open_source=True,
            has_commercial_dimension=False,
            is_vpn_firewall=True,
        ),
        ProductProfile(
            name="Commercial VPN Client Application",
            is_vpn_firewall=True,
            has_commercial_dimension=True,
        ),
    ]

    for p in products:
        r = analyse_scope(p)
        print(f"\n{'='*60}")
        print(f"Product: {r['product']}")
        print(f"Scope: {r['scope'].value if r['scope'] else 'N/A'}")
        print(f"Tier: {r['tier'].value if r['tier'] else 'N/A'}")
        for reason in r["reasons"]:
            print(f"  Reason: {reason}")
        for action in r["actions"]:
            print(f"  → {action}")

Running this produces:

============================================================
Product: PaaS Platform (e.g. sota.io)
Scope: IN_SCOPE
Tier: Standard
  Reason: Product with digital elements placed on EU market — Art.2(1) in scope
  → Implement CVD policy by 11 Sep 2026 (Art.14/15 deadline)
  → Begin Art.13 compliance programme — December 2027 deadline

============================================================
Product: IoT Fleet Management Cloud Backend
Scope: IN_SCOPE
Tier: Standard
  Reason: Product with digital elements placed on EU market — Art.2(1) in scope
  → Implement CVD policy by 11 Sep 2026 (Art.14/15 deadline)
  → Begin Art.13 compliance programme — December 2027 deadline

============================================================
Product: SaaS Project Management Tool
Scope: EXCLUDED
  Reason: Pure SaaS with no hardware dependency — Art.2(3) carve-out
  → Verify: does any customer use your service as remote processing for a hardware product?

============================================================
Product: Open-Source VPN Library
Scope: UNCERTAIN
  Reason: Non-commercial open source — Art.17 CVD-light regime may apply
  → Implement CVD policy by 11 Sep 2026 (Art.14/15 still applies)
  → Confirm no indirect commercial benefit (cloud hosting, support contracts)

============================================================
Product: Commercial VPN Client Application
Scope: IN_SCOPE
Tier: Important Class A
  Reason: Product with digital elements placed on EU market — Art.2(1) in scope
  → Implement CVD policy by 11 Sep 2026 (Art.14/15 deadline)
  → Begin Art.13 compliance programme — December 2027 deadline
  → Engage notified body OR apply harmonised standards for self-assessment

The 25-Question Art.2 Scope Checklist

Work through these questions to determine your Art.2 position:

Part A: Basic Threshold (Art.2(1))

Part B: Explicit Exclusions (Art.2(2))

Part C: SaaS Carve-Out (Art.2(3))

Part D: Open-Source Safe Harbour (Art.17)

Part E: Classification (Annex III / IV)

The Most Common Art.2 Mistakes

Mistake 1: Assuming SaaS = excluded. Pure SaaS is excluded. SaaS-plus-SDK is not. SaaS that processes hardware device data is not.

Mistake 2: Treating all open-source as exempt. Only non-commercial OSS qualifies for the Art.17 CVD-light regime. Commercial OSS distributions are in scope.

Mistake 3: Ignoring component liability. If your library is used in other companies' products, you bear CRA obligations as component manufacturer — independently of what the integrating company does.

Mistake 4: Conflating medical device exclusion with health software exclusion. The MDR/IVDR exclusion covers certified medical devices. A general-purpose health tracking app that is not CE-marked under MDR is a product with digital elements under the CRA.

Mistake 5: Assuming "internal tool" means out of scope forever. If the tool is ever licensed or distributed to a customer (even a subsidiary in a different legal entity), it is placed on the market and is in scope.

Mistake 6: Missing the September 2026 CVD deadline. Art.14/15 obligations apply from 11 September 2026 — 15 months before the main Art.13 deadline. Most in-scope products must have a public CVD policy operational within 5 months.

Next Steps After Scope Confirmation

Once you establish that your product is in scope under Art.2, the compliance roadmap has three phases:

Phase 1 — Immediate (before 11 September 2026):

Phase 2 — Short-term (before 11 December 2027):

Phase 3 — Ongoing:

The CRA creates a continuous compliance obligation, not a one-time certification. Building the processes in phases — starting with CVD in 2026 — is significantly less costly than attempting full compliance in late 2027.

See Also