CRA Art.6 Product Classification 2026: Class I, Class II, and Annex IV — Which Category Is Your Software?

Post #10 in the sota.io EU Cyber Resilience Act Series

The EU Cyber Resilience Act (CRA, Regulation 2024/2847) does not treat all software the same. Under Article 6, digital products are divided into risk tiers that determine your entire compliance path: how you conduct conformity assessments, whether you need a third-party auditor, and what certification schemes apply.

Get your classification wrong and you face two equally bad outcomes: either you conduct an insufficient self-assessment for a product that required independent review, or you over-engineer a conformity process for a product that only needed basic documentation. CRA applies to most product categories from 13 September 2026.

This guide works through the complete classification decision tree, covering every category named in Annex III and Annex IV of the final CRA text — including the infrastructure and hosting implications that most analysis misses.

The Three-Tier Classification System

CRA Article 6 creates a hierarchy of digital products based on their cybersecurity risk potential:

Tier 1 — Standard products (default): All "products with digital elements" that are not listed in Annex III or Annex IV fall into the standard category. Manufacturers may conduct their own conformity assessment using the internal control procedure (Annex VIII). No third party required.

Tier 2 — Important products (Annex III): Products with "significant cybersecurity risk potential" due to their functionality or their role in the supply chain. Annex III is subdivided into Class I and Class II, each with different conformity requirements.

Tier 3 — Critical products (Annex IV): Products where "cybersecurity failures could have a significant disruptive effect across the Union." These require a European cybersecurity certificate under a scheme adopted pursuant to the Cybersecurity Act (Regulation 2019/881), or a conformity assessment by an accredited third-party body if no relevant scheme exists.

Annex III Deep Dive: Class I vs Class II

Annex III lists "important products with digital elements." The distinction between Class I and Class II determines your conformity assessment procedure.

Class I Products (Annex III, Category 1)

For Class I products, self-assessment remains available — but only if you apply a harmonised European standard (once published) or a relevant European cybersecurity certification scheme. If no harmonised standard applies, you must use a third-party conformity assessment body (a notified body under Article 61).

The Class I list from Annex III includes:

Identity and access management software:

• Identity management systems and privileged access management software
• Password managers
• Single sign-on software (SSO systems)
• Biometric authentication software

Network infrastructure software:

• Browser and browser engines
• VPN (Virtual Private Network) software
• Network monitoring and traffic analysis software
• DNS resolvers, recursive DNS servers, and authoritative DNS servers
• Software-defined networking (SDN) software
• Software defined wide area network (SD-WAN) software
• Network management software
• Firewalls (software-based)
• Intrusion detection/prevention systems (software-based)

Endpoint and device management:

• Mobile device management (MDM) software
• Remote desktop/remote access software
• Package managers (software update/delivery infrastructure)

Operating systems and virtualisation (consumer/small business context):

• General-purpose operating systems intended for use on personal computers, routers, tablets or smartphones where not covered by Class II
• Microcontroller firmware (embedded operating environments)

Security tooling:

• Security information and event management (SIEM) software
• Public key infrastructure (PKI) software and digital certificate management
• Hardware security modules (HSMs) that are not classified as critical
• Bootloaders (if separate and updatable)

Class II Products (Annex III, Category 2)

Class II products carry higher risk due to their systemic role. The conformity assessment must involve an accredited third-party body — self-assessment is not permitted even with harmonised standards applied.

The Class II list includes:

Operating systems (server/enterprise context):

• Operating systems for servers, desktops, and mobile devices used in industrial and critical infrastructure settings
• Hypervisors and container runtime software (when used in critical infrastructure contexts)

Network security hardware and software:

• Firewalls (hardware-based or software-based for critical infrastructure)
• Industrial firewalls (OT/ICS network perimeter devices)
• Deep packet inspection software
• Hardware-based security products (HSMs for critical infrastructure)

Safety-critical industrial systems:

• Industrial control system (ICS) components with network interfaces
• Programmable logic controller (PLC) software with external connectivity
• SCADA system software components

Microprocessors with security features:

• General-purpose CPUs (when marketed with integrated security functions)
• Secure elements (hardware-based trusted execution environments)
• Smart cards and readers (with network or software interfaces)

Annex IV: Critical Products Requiring Certification

Beyond Annex III, Annex IV lists products where "a cybersecurity failure could have a significant disruptive effect across the Union, sectors, or on society." These require a European cybersecurity certification scheme under the Cybersecurity Act, or a third-party conformity assessment by a notified body if no scheme is available.

The Annex IV list is deliberately narrow but strategically significant:

• Hardware devices with security boxes — trusted platform modules (TPMs), smart cards used in critical authentication, hardware tokens
• Routers and modems intended for consumer use — specifically residential gateways, broadband modems, and home routers
• Network switches — switches with management interfaces connecting critical infrastructure
• Microprocessors used in security-sensitive contexts

The critical distinction for Annex IV: if a European cybersecurity certification scheme exists that is relevant to your product category, you must use it. You cannot substitute an ad-hoc third-party audit. If no scheme exists yet, Article 6(4) allows a notified body assessment in the interim.

The Conformity Assessment Decision Matrix

Understanding which procedure applies requires walking the classification decision tree:

Step 1: Is your product a "product with digital elements" under CRA Art.3? (Software with data exchange capability counts. Pure offline software without network or data interfaces may be excluded, but the bar for exclusion is high.)

Step 2: Is your product in Annex IV?

• Yes → European cybersecurity certification (or notified body if no scheme yet)
• No → proceed to Step 3

Step 3: Is your product in Annex III?

• No → Standard self-assessment (Annex VIII procedure)
• Class I → Self-assessment + harmonised standard, OR notified body if no standard
• Class II → Notified body required (no self-assessment option)

Step 4: For Class I self-assessments, document your conformity to the applicable harmonised standard (ETSI EN 303 645, ISO/IEC 27001 aligned standards, or future CRA-specific standards expected 2025-2026).

What "Conformity Assessment" Actually Means for Each Tier

Standard products (self-assessment, Annex VIII)

You compile a technical file containing:

• Description of the product and its intended use
• The essential cybersecurity requirements of Annex I (Parts I and II) applied
• Vulnerability management policy
• Software Bill of Materials (SBOM) — at least top-level dependencies
• Test reports and security evaluations you have conducted internally

No external submission required. You affix the CE mark, issue an EU declaration of conformity, and keep the technical file for 10 years after placing the product on the market.

Class I products (harmonised standard route)

You conduct the Annex VIII procedure but additionally document your application of a harmonised European standard (HES). Where CRA-specific HES are not yet published (the Commission mandated ENISA and CEN/CENELEC to develop standards, expected 2025-2026), products must either use existing relevant standards (EN 303 645, IEC 62443 series, ISO/IEC 27001) or fall back to a notified body assessment.

Class II products (notified body)

You submit your technical file to an accredited notified body (a certification body designated under Article 61). The notified body:

• Examines your technical documentation
• Assesses your vulnerability management processes
• May require penetration testing or vulnerability scanning
• Issues a certificate of conformity (valid for up to 5 years, with annual surveillance reviews)

The notified body must be accredited by the national accreditation body (DAkkS in Germany, COFRAC in France, UKAS in the UK post-Brexit equivalent). The cost varies by product complexity but typically ranges from €20,000 to €150,000+ for enterprise software products.

Annex IV products (cybersecurity certification)

You apply for certification under the relevant European cybersecurity certification scheme. Current schemes under EUCS (EU Cybersecurity Certification Scheme for Cloud Services) are the most mature, but product-specific schemes for CRA Annex IV categories are still being developed. The Commission has three years from CRA entry into force to mandate specific schemes.

The Infrastructure Layer Most Classification Guides Miss

Every classification guide you will find walks through the product categories. Almost none address the infrastructure dimension that CRA Article 13(1) makes mandatory: your conformity assessment must cover your entire security architecture, including your deployment infrastructure.

If you are building a Class I identity management system and deploying it on a US-headquartered PaaS platform, your conformity assessment has a structural gap. Here is why:

The CLOUD Act compulsion problem: Under 18 USC § 2701 et seq. and the CLOUD Act, US authorities can compel US-headquartered cloud providers to produce data stored anywhere in the world — without notifying the customer, without requiring a European court order, and without triggering the legal safeguards that would apply to a purely European infrastructure provider. For an identity management system handling EU user credentials and authentication flows, this is not a theoretical risk.

CRA Annex I, Part I, requirement 2(e) requires manufacturers to "minimise their own attack surface, including external interfaces." A legal compulsion pathway that exists at the infrastructure level — below your application code, invisible to your security monitoring — is an attack surface element you cannot minimise through software engineering alone.

The Art.13(1) "secure by design" requirement means you must be able to demonstrate, to a notified body or in your self-assessment technical file, that security is embedded in your architecture from the ground up. A deployment architecture that includes a potential legal backdoor for non-EU authorities is architecturally inconsistent with this requirement.

The FISA Section 702 exposure: For identity systems specifically, the concern extends beyond reactive data production under criminal warrants. Section 702 allows systematic intelligence collection from US cloud providers. A conformity assessor reviewing a Class I identity management product deployed on AWS, Azure, or GCP faces legitimate questions about whether the "minimised attack surface" requirement is satisfied when PRISM-equivalent access is a documented infrastructure-level capability.

The September 2026 Classification Cliff

CRA becomes applicable in stages, but the product classification requirements land in full on 13 September 2026. From that date:

• All new products placed on the EU market must have completed their conformity assessment matching their classification tier
• Existing products undergoing "substantial modification" (see Art.23) must re-assess under the new CRA framework
• Notified bodies (for Class II) and certification schemes (for Annex IV) must be in place and operational

The practical timeline implications:

Standard products: You need approximately 3-6 months to compile a thorough technical file if you have not already documented your security architecture.

Class I products: Add 2-4 months to identify and apply the appropriate harmonised standard, or initiate notified body engagement if no standard is available. With harmonised standards still being finalised by CEN/CENELEC in early 2026, Class I manufacturers face uncertainty about which standard to apply.

Class II products: Notified body assessments for complex software products take 6-18 months, including pre-assessment, gap analysis, remediation, formal assessment, and certificate issuance. If you have not started, you are behind schedule.

Annex IV products: European cybersecurity certification schemes for most CRA Annex IV product categories are not yet finalized. The Commission's three-year mandate means some schemes may not be in place before CRA full applicability. The interim fallback (notified body assessment per Art.6(4)) requires the same 6-18 month timeline as Class II.

Determining Your Classification: A Practical Checklist

For SaaS platforms and developer tools specifically:

You are likely standard tier if:

• Your product is a general-purpose SaaS application (project management, CRM, analytics) with no specific security function
• You are a platform hosting customer applications with no security product positioning
• Your software does not process authentication credentials, manage network access, or provide security monitoring functions

You are likely Class I if your product provides:

• Authentication, SSO, or identity management functions
• Password management or credential storage
• VPN or secure remote access
• Network traffic monitoring or analysis
• Package distribution or software update delivery
• Security event logging or SIEM functions

You are likely Class II if your product is:

• A hypervisor or container runtime marketed to critical infrastructure operators
• An OS for server environments in industrial settings
• Hardware with embedded security (TPMs, secure elements)
• Firewall appliances for critical infrastructure

You are definitely Annex IV if your product is:

• A consumer router or modem
• A network switch with management capabilities
• A hardware security module for critical infrastructure authentication

Infrastructure Decisions as Compliance Decisions

For manufacturers of Annex III and Annex IV products, where infrastructure runs is now a compliance decision, not just an operational preference. The conformity assessment technical file for any Class I or Class II product must demonstrate that your security architecture satisfies all Annex I requirements.

EU-native PaaS infrastructure — where the provider is incorporated in the EU, operates under EU law exclusively, and has no US parent entity subject to CLOUD Act or FISA Section 702 — removes one of the hardest-to-document risks from your conformity assessment: the non-minimisable legal backdoor that US-jurisdiction infrastructure carries by statutory design.

For Class I identity management, VPN, or network monitoring products, deploying on EU-native infrastructure is increasingly the defensible architectural choice for a CRA-ready technical file. For Class II products requiring notified body assessment, it removes a category of findings that could otherwise extend your assessment timeline by months.

CRA September 2026 is 120 days away. Your classification tier should be confirmed now — because the conformity assessment timeline for Class II and Annex IV products leaves no margin for discovering you picked the wrong tier in August.

This post is part of the sota.io CRA Series. Earlier posts covered CRA penalty frameworks, Art.13 Security by Design, Art.11 Vulnerability Notifications, Art.7 Vulnerability Handling, SBOM Requirements, Annex I Security Checklist, and the 120-Day ENISA Countdown.