EU CRA Product Classes 2026: Which Rules Apply to Your SaaS — Default, Class I and Class II Explained

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

Every SaaS developer currently trying to understand the EU Cyber Resilience Act faces the same first question: which class of product am I building? The answer determines everything — from whether you can self-certify to whether you must hire a notified body, from a simple internal checklist to a multi-month audit process with external labs.

This guide walks through the complete CRA product classification framework, explains what each class means for your compliance obligations, and provides a decision tree that lets you pinpoint your classification in under ten minutes.

The Core Distinction: What Makes a Product "In Scope" at All

Before discussing classes, the threshold question is whether your product falls under the CRA at all. The regulation covers products with digital elements (PDE) — a defined term. Pure cloud services where users only interact through a browser are explicitly excluded under Recital 15.

However, scope is a trap for the unwary. If your SaaS ships any of the following, you have a product with digital elements:

The distinguishing criterion is whether you distribute software that runs on a customer's device or infrastructure. Distribution of containerised software to customers — even on your own managed infrastructure — may also trigger scope depending on whether the container constitutes a "product" placed on the market.

When in doubt, consult a CRA-specialist legal firm. The conservative default for most SaaS developers shipping mobile or desktop clients is to assume in scope.

The Three-Tier Classification System

The CRA establishes a risk-based hierarchy with three product tiers, each carrying different conformity assessment obligations:

┌─────────────────────────────────────────────────────────┐
│  CLASS II — CRITICAL PRODUCTS (Annex III Part II)        │
│  Mandatory third-party assessment by Notified Body       │
│  Examples: OSes, hypervisors, firewalls, industrial ICS  │
├─────────────────────────────────────────────────────────┤
│  CLASS I — IMPORTANT PRODUCTS (Annex III Part I)         │
│  Third-party OR self-assessment with harmonised standard │
│  Examples: password managers, VPNs, identity mgmt, SIEM │
├─────────────────────────────────────────────────────────┤
│  DEFAULT — ALL OTHER PRODUCTS                            │
│  Self-assessment + Declaration of Conformity             │
│  Examples: most apps, plugins, SDKs, libraries          │
└─────────────────────────────────────────────────────────┘

The default tier is not a loophole — it still requires full compliance with all Annex I essential security requirements. The difference is who verifies compliance, not whether compliance is required.

Class I — Important Products: The Full Annex III Part I List

Annex III Part I lists the product categories the EU Commission considers high-risk enough to warrant stricter oversight. As a SaaS developer, these are the categories most likely to catch you:

Identity and Access Management

IAM and privileged access management (PAM) software is explicitly named. If your product manages user identities, authentication tokens, permissions, or privileged credentials — for any customer — you are likely Class I.

This includes:

• Single Sign-On (SSO) providers
• Privileged Access Management platforms
• Multi-Factor Authentication (MFA) servers
• LDAP/AD management tools
• Developer identity platforms (e.g., Okta-style SDKs)

Why it matters: Compromising an IAM product gives attackers keys to every connected system. The EU sees this as a category warranting extra verification.

Password Managers

Password managers are explicitly listed — both standalone apps and embedded password management features within larger products. If your app includes a credentials vault that stores user passwords, even as a secondary feature, you should assess whether this subsystem triggers Class I classification.

Browsers (Standalone and Embedded)

Both standalone browsers and embedded browser engines (e.g., Chromium WebView integrated into a desktop app) fall under Class I. If you ship an Electron app that bundles Chromium, the browser component may make your product Class I.

Malware Detection and Removal Software

Antivirus, endpoint detection and response (EDR), and software that searches for, quarantines, or removes malicious code falls under Class I. This includes behaviour-based detection tools, file scanners, and email filtering solutions that execute on endpoint devices.

VPN Products

Products with VPN functionality — including consumer VPN clients, corporate remote access tools, and network privacy apps — are Class I. Note this refers to the VPN product shipped to users, not using a VPN in your backend infrastructure.

Network Management and Monitoring Systems

Network management systems (NMS) and network monitoring systems deployed to manage or observe customer infrastructure are Class I. This includes on-premises agents, SNMP collectors, traffic analysers, and configuration management tools for routers/switches.

SIEM Systems

Security information and event management platforms are explicitly listed. If you sell a SIEM, log aggregation with security analytics, or security event correlation platform, you're Class I.

Boot Managers

Bootloaders and boot management software (EFI shims, secure boot tools, PXE deployment systems) are Class I. Most SaaS developers won't ship these, but they appear frequently in infrastructure tooling.

PKI and Certificate Issuance Software

Public Key Infrastructure software — including Certificate Authority (CA) software, certificate lifecycle management tools, and ACME client/server implementations — falls under Class I.

Hardware Security Module (HSM) Software

The software component accompanying HSMs is covered, but only for software tightly integrated with hardware HSMs and sold as part of the HSM product.

Summary Table: Class I Products

Class II — Critical Products: The Full Annex III Part II List

Class II products are the highest-risk tier. They require assessment by an EU-accredited Notified Body — no self-certification option exists regardless of which harmonised standards you apply.

Operating Systems

Server, desktop, and mobile operating systems are Class II. Linux distributions, custom embedded OSes, Android forks, and purpose-built appliance OSes all qualify. If you ship a custom OS for any device (IoT gateways, kiosks, industrial equipment), you face mandatory Notified Body review.

Hypervisors and Container Runtime Systems

Type 1 and Type 2 hypervisors are Class II. Container runtimes (containerd, CRI-O, runc) also fall under this category when distributed as standalone products. Kubernetes distribution vendors should assess whether their bundled container runtime triggers Class II.

Firewalls and Intrusion Detection/Prevention Systems

Network-level firewalls, IDPS products, and unified threat management (UTM) appliances are Class II. Web Application Firewalls (WAF) sold as on-premises or embedded products may also qualify; cloud-delivered WAF SaaS without a downloadable component is likely out of scope.

General-Purpose Microprocessors

CPUs (x86, ARM, RISC-V) are Class II. This affects chip designers and semiconductor companies, not SaaS developers, but matters if you design custom silicon for edge compute or IoT.

Industrial Control Systems

SCADA systems, programmable logic controllers (PLC), industrial IoT gateways, and distributed control systems (DCS) used in critical infrastructure are Class II. If your SaaS has an on-premises agent that controls physical equipment, assess Class II applicability carefully.

Routers, Modems and Switches (Commercial Grade)

Commercial and industrial routers, modems, and network switches (not residential consumer devices) are Class II. If your product includes embedded networking firmware for commercial infrastructure, expect Class II.

Summary Table: Class II Products

Conformity Assessment Paths by Class

Your product class determines which conformity assessment route is available:

Default Products: Module A — Internal Control

Manufacturers self-assess against the Annex I essential requirements and draw up an EU Declaration of Conformity (DoC). No external body is involved. The technical documentation must be kept for at least 10 years and made available to market surveillance authorities on request.

What this requires in practice:

1. Gap analysis against all Annex I requirements
2. Documented security testing (penetration tests, static analysis)
3. Vulnerability management procedure with SLAs
4. Software Bill of Materials (SBOM) in machine-readable format (SPDX or CycloneDX)
5. Secure update delivery mechanism
6. Signed EU Declaration of Conformity
7. CE marking on the product and packaging
8. Registration on the EU market surveillance portal (EUDAMED analogue for cyber)

Class I Products: Module A with Standard OR Third-Party Assessment

Class I products have two paths:

Path 1 — Harmonised Standard Available: If a European harmonised standard covering the product category exists (published in the Official Journal), self-assessment is permitted — but you must fully comply with that standard and document compliance. The technical documentation requirements are significantly heavier than for default products.

Path 2 — No Harmonised Standard: If no harmonised standard exists, or if you choose not to apply one, you must use:

• Module B+C (EC type-examination by a Notified Body, then self-declaration based on the type)
• Module H (full quality assurance system audited by a Notified Body)

Currently, most harmonised CRA standards are still being developed by ETSI and CEN/CENELEC. Expect the first waves to be published in late 2026 and throughout 2027. Until then, Class I manufacturers without an applicable standard will need Notified Body involvement.

Practical implication: Many Class I SaaS developers will need Notified Body assessment in 2026-2027 due to the absence of harmonised standards. Budget accordingly — assessments for software products range from €15,000 to €80,000 depending on complexity.

Class II Products: Mandatory Notified Body Assessment

No self-declaration option. Class II manufacturers must engage an EU-accredited Notified Body for the full conformity assessment. The available modules are:

• Module B+C — Type-examination + production quality
• Module H — Full quality assurance (most common for software)
• Module B+D — Type-examination + production quality assurance

Notified Body availability is currently constrained. As of early 2026, only a handful of bodies have been designated for CRA assessments, primarily in Germany, the Netherlands, and France. If you're a Class II manufacturer, begin engaging Notified Bodies immediately — queues are already forming for the December 2027 deadline.

Technical Documentation: The Core Compliance Artefact

Regardless of product class, the CRA requires manufacturers to maintain comprehensive technical documentation. For the December 2027 deadline, this documentation must include:

Mandatory Technical Documentation Components

1. Product Description
   - Intended purpose and intended users
   - Hardware/software components and architecture
   - Known or foreseeable uses that could create cybersecurity risks

2. Design and Development Information
   - Security-by-design principles applied
   - Threat model (STRIDE or equivalent)
   - Security controls implemented per threat
   - Secure coding standards followed

3. Security Testing Evidence
   - Penetration test reports (with remediation evidence)
   - Static application security testing (SAST) results
   - Dependency vulnerability scan (SCA) results
   - Fuzzing results where applicable

4. SBOM (Software Bill of Materials)
   - Machine-readable format: SPDX 2.3+ or CycloneDX 1.4+
   - All direct and transitive dependencies
   - Known vulnerabilities (CVEs) and remediation status

5. Vulnerability Handling Procedures
   - Responsible disclosure policy
   - Triage SLAs (Critical: 24h, High: 72h, Medium: 14d)
   - ENISA EUVDB notification workflow (Art.14)
   - Patch delivery timeline commitments

6. Security Update Mechanism
   - How updates are delivered to users
   - Cryptographic signing of update packages
   - Rollback capability

7. EU Declaration of Conformity
   - Signed by authorised representative
   - References to standards applied
   - CE marking authorisation

The technical documentation is the central compliance artefact. Market surveillance authorities have the right to demand it within 10 days during investigations. For Class I and II products, the Notified Body will review it as part of the assessment.

The CE Marking Process

Once conformity assessment is complete, manufacturers must affix the CE marking. For software products delivered digitally:

1. CE marking in the user interface: Required for software products. Typically placed in the product's "About" dialog, legal/compliance page, or software documentation.

2. CE marking in documentation: The user manual, installation guide, or README must include the CE marking.

3. EU Declaration of Conformity (DoC): Must be kept accessible — for digital products, a URL link to the DoC is acceptable. The DoC must include:

   • Manufacturer name and address
   • Product description and model number
   • Statement of conformity with the CRA
   • References to harmonised standards or technical specifications applied
   • Date and place of issue
   • Authorised signatory

4. Notified Body identification (Class I/II): Where a Notified Body was involved, their four-digit NB number must appear alongside the CE marking.

Timeline: Mandatory Requirements by Date

Understanding what's mandatory now versus later prevents unnecessary panic:

Key implication: The June 2026 deadline (vulnerability reporting) is immediate. The December 2027 deadline (full product certification) gives you 18 months. Use that window wisely.

Recommended Preparation Timeline (Working Backwards from Dec 2027)

Dec 2027: CE marking + DoC ready → products on market
Sep 2027: Technical documentation finalised, final testing
Jun 2027: Notified Body assessment (if Class I/II) — allow 3-6 months
Mar 2027: Gap remediation + SBOM implementation complete
Dec 2026: Internal gap analysis complete, Notified Body engaged (Class I/II)
Sep 2026: Product class determination + legal opinion
Jun 2026: Art.14 vulnerability reporting LIVE ← YOU ARE HERE

Decision Framework: Classify Your SaaS Product in 10 Minutes

Follow this decision tree:

Q1: Does your SaaS ship any downloadable software component?
    (mobile app, desktop app, CLI, npm package, Docker image, browser extension, SDK)
    
    NO  → CRA DOES NOT APPLY to the SaaS portion. Stop here.
    YES → Continue to Q2.

Q2: Is the software you ship ANY of these?
    - Operating system / hypervisor / container runtime
    - Commercial firewall or IDPS product
    - Industrial control system firmware
    
    YES → CLASS II. You need a Notified Body. Start immediately.
    NO  → Continue to Q3.

Q3: Is the software you ship ANY of these?
    - IAM / SSO / PAM platform
    - Password manager (even embedded)
    - VPN client / remote access tool
    - Malware detection / EDR / antivirus
    - SIEM / security event management
    - Network management / monitoring system
    - Browser or browser engine
    - PKI / certificate management software
    
    YES → CLASS I. Self-certify if harmonised standard available; Notified Body otherwise.
    NO  → Continue to Q4.

Q4: Is your software a general-purpose application, plugin, SDK, or library?
    YES → DEFAULT CLASS. Self-assessment + Declaration of Conformity. Full Annex I still applies.

Common Misclassification Scenarios

Scenario 1: "Our SaaS has an Okta integration SDK"

If you publish an npm/pip/gem package that other developers use to integrate with your authentication service, that SDK is a product with digital elements in scope for CRA. If the SDK includes authentication logic (not just REST calls), it may qualify as identity management software — Class I.

Action: Legal review of SDK functionality. If auth logic is embedded, assume Class I until counsel confirms otherwise.

Scenario 2: "Our DevOps platform has a CLI tool"

A CLI tool distributed to developers (via npm, Homebrew, apt repository, etc.) is a product with digital elements. If the CLI only makes API calls, it likely falls in the Default tier. If it handles credentials, manages secrets, or has security-sensitive functionality, it may be Class I.

Action: Analyse CLI functionality. Credentials handling → likely Class I.

Scenario 3: "Our SaaS has a Docker Compose file we ask customers to run"

Docker Compose files orchestrating containers in a customer's environment constitute distributing software. The containers themselves are products with digital elements. Classification depends on what the containers do.

Action: Treat each distributed container image as a separate product with digital elements and classify each individually.

Scenario 4: "Our network monitoring SaaS has an on-premises agent"

The on-premises agent is in scope and likely Class I (network monitoring system). The SaaS dashboard component is out of scope (cloud service). You need to manage the agent separately for CRA compliance even though it's part of a larger SaaS offering.

Action: Separate your compliance obligations for the agent vs. the SaaS dashboard.

Compliance Checklist by Product Class

Default Products Checklist

• Threat model documented (STRIDE or equivalent)
• Penetration test conducted by qualified team
• SBOM generated (SPDX 2.3+ or CycloneDX 1.4+)
• Vulnerability disclosure policy published at security.txt
• ENISA EUVDB notification workflow ready (Art.14)
• Security update mechanism with cryptographic signing
• Technical documentation assembled (see above)
• EU Declaration of Conformity drafted
• CE marking applied (UI + documentation)
• DoC URL published and linked in product

Class I Products Additional Steps

• Determine if applicable harmonised standard exists (check ETSI, CEN/CENELEC)
• If standard available: full compliance documentation against standard
• If no standard: engage EU Notified Body (Module B+C or H)
• Notified Body assessment scheduled well before Dec 2027
• NB identification number confirmed for CE marking

Class II Products Additional Steps

• EU Notified Body engaged immediately (queues are building)
• Module H (full quality assurance) or B+C selected with NB
• Full audit of development and testing processes by NB
• Ongoing NB surveillance arrangements agreed
• Contingency plan if NB capacity is unavailable

EU-Hosted Infrastructure as a Compliance Advantage

One underappreciated CRA dimension: where your development and build infrastructure runs affects your security posture documentation.

For the technical documentation requirement on "security measures applied during development," companies using EU-hosted infrastructure can demonstrate that:

• Build pipelines are not subject to US Cloud Act compelled disclosure
• Dependency registries and artifact stores are under EU jurisdiction
• Security testing environments remain within GDPR-compliant boundaries

For SaaS companies managing customer data during conformity assessment (where auditors may need infrastructure access), EU-hosted platforms eliminate a class of jurisdictional risk that US-hosted build systems create.

sota.io provides EU-native managed infrastructure (Hetzner Germany) with no US parent company and no Cloud Act exposure — purpose-built for exactly this compliance posture. This means your CRA technical documentation can straightforwardly assert EU-jurisdictional control over your development environment.

What to Do This Week

Given the June 2026 vulnerability reporting deadline is already here and December 2027 is 18 months away:

Immediate (before July 2026):

1. Determine whether any component of your SaaS is a product with digital elements
2. If yes, identify your initial product class from the Annex III lists
3. Implement Art.14 vulnerability reporting workflow (ENISA EUVDB registration)
4. Publish security.txt with CSAF 2.0 field

Short-term (Q3 2026):

1. Commission a formal legal opinion on your product classification
2. Begin gap analysis against Annex I essential requirements
3. Generate your first SBOM from your CI pipeline
4. If Class I or II, start Notified Body selection

Medium-term (H1 2027):

1. Close all Annex I compliance gaps
2. Begin or complete Notified Body assessment (Class I/II)
3. Draft EU Declaration of Conformity
4. Prepare CE marking implementation plan

Conclusion

The EU CRA's product classification system is not arbitrary complexity — it reflects a proportional risk approach where the most security-critical software faces the heaviest scrutiny. For most SaaS developers shipping mobile apps, CLIs, or SDKs, the Default tier applies, requiring self-assessment but still mandating full Annex I compliance.

The companies that will struggle in 2027 are those that waited until December to discover they're actually Class I (no harmonised standard available, Notified Body queue full) or that they shipped 23 separate products with digital elements without realising it.

Start your classification analysis now. The vulnerability reporting obligation is live. The conformity assessment clock is running.

Part 3 of 5 in the sota.io EU CRA June 2026 Update Series. Previous posts: EU CRA Vulnerability Disclosure June 2026: The Deadline Every SaaS Developer Must Know and EU CRA Security Requirements Art.13 2026: SBOM, Secure-by-Default and What Every SaaS Developer Must Implement. Next: EU CRA vs NIS2 Dual Compliance Stack.