EU Cyber Resilience Act: What SaaS Companies Must Do

The EU Cyber Resilience Act is not a distant regulatory proposal. It is an active law with a strict enforcement deadline on September 11, 2026 — less than six months away.

That first deadline covers reporting obligations only. But the machinery behind it — vulnerability management processes, Software Bill of Materials infrastructure, ENISA notification workflows, coordinated disclosure policies — all need to be operational before that date arrives. The full compliance deadline covering product security requirements follows on December 11, 2027.

If your SaaS company distributes software to EU customers or operates as a component in a connected product sold on the EU market, this regulation very likely applies to you. Getting the applicability question wrong in either direction — assuming you are out of scope when you are not, or overbuilding a compliance program for a product that qualifies for self-assessment — costs time and money you cannot afford to waste.

This guide covers what the Cyber Resilience Act actually requires, who it applies to, how the product classification system works, what the essential cybersecurity requirements demand in practice, and how to structure a realistic readiness program before the September 2026 reporting deadline.

What Is the EU Cyber Resilience Act?

The Cyber Resilience Act (CRA) is Regulation (EU) 2024/2847, adopted by the European Parliament on October 23, 2024, and entered into force on December 10, 2024. It is directly applicable in all EU Member States without requiring national transposition legislation — meaning it carries the force of law across the entire bloc simultaneously.

The regulation targets a specific and persistent problem: digital products — hardware, software, and connected devices — have historically been released with inadequate security, inconsistent update practices, and no clear responsibility for post-release vulnerability management. The CRA fixes this by converting cybersecurity from a voluntary product feature into a legally enforceable condition of EU market access.

The CRA sits alongside, but is distinct from, two other major EU cybersecurity frameworks:

NIS2 Directive imposes risk management and incident reporting obligations at the organizational level on essential and important entities operating critical infrastructure and services.

Cybersecurity Act establishes EU-wide cybersecurity certification schemes for ICT products, services, and processes.

The CRA regulates products, not organizations. It attaches compliance obligations directly to manufacturers, importers, and distributors of products with digital elements. That is the critical distinction.

The Two Deadlines You Cannot Afford to Miss

The CRA's obligations apply in two distinct phases.

September 11, 2026 — Reporting Deadline

By this date, manufacturers must be operationally capable of reporting actively exploited vulnerabilities and severe incidents to ENISA (the EU Agency for Cybersecurity) and relevant Computer Security Incident Response Teams (CSIRTs). The reporting timelines are strict: 24 hours for an early warning on an actively exploited vulnerability, 72 hours for a formal notification.

These are not aspirational targets. They require internal processes — detection, escalation, approval, and submission workflows — to already be running before September 11, 2026.

December 11, 2027 — Full Compliance Deadline

All in-scope products placed on the EU market must comply with the CRA's essential cybersecurity requirements, complete the applicable conformity assessment procedure, carry appropriate CE marking, and be supported by comprehensive technical documentation.

The September 2026 deadline is the urgent one for most teams. Build your vulnerability management infrastructure and reporting workflows first. Use the time between September 2026 and December 2027 to complete the broader product security program.

Who Does the CRA Apply To?

The CRA applies to any economic operator — manufacturer, importer, or distributor — that places a product with digital elements on the EU market. The company's geographic location is irrelevant. If you sell into the EU, you are subject to the regulation.

The regulation places the heaviest obligations on manufacturers, defined as any natural or legal person who designs, develops, or produces a product with digital elements and markets it under their own name or trademark. This includes companies that commission products from third parties and sell them under their own brand.

Importers and distributors carry lighter but still meaningful obligations, including the responsibility to verify that manufacturers have fulfilled their compliance obligations before a product is placed on the market.

The Critical Question for SaaS: Are You In Scope?

This is where most SaaS teams get confused, and where applicability decisions are most commonly made incorrectly.

The CRA defines a "product with digital elements" as any software or hardware product whose intended or reasonably foreseeable use involves a direct or indirect logical or physical data connection to a device or network.

Pure browser-based SaaS is generally outside the CRA scope. If your product is a platform accessed entirely through a web browser — a compliance dashboard, a project management tool, a CRM — it is likely regulated under NIS2 as a service rather than under the CRA as a product.

SaaS that powers a physical device falls within CRA scope. If your cloud software serves as the controlling intelligence for a connected product — the backend for a smart device, a firmware update service for IoT hardware, a management platform integral to industrial equipment — that software is treated as part of the product and is in scope.

Software delivered as a file that users install or execute is in scope. Desktop applications, firmware packages, mobile apps distributed to end users, and similar installable software qualify as products with digital elements regardless of whether you also offer a cloud-hosted version.

Open-source software developed outside commercial activity is generally exempt. However, when open-source components are integrated into commercial products placed on the EU market, compliance responsibility rests with the economic operator placing that product on the market — not the open-source developers.

The practical test: does your customer download, install, or execute your software on hardware they control? Does your software run as the embedded intelligence of a connected device you sell? If either answer is yes, you should conduct a formal CRA scope assessment immediately.

Product Classification: Four Risk Tiers

The CRA uses a risk-based categorization framework. Where your product lands determines which conformity assessment procedure you must follow.

Default Category

Products not listed in Annex III fall into the default category. These products account for the large majority of in-scope software and hardware. Default-category manufacturers can conduct internal conformity assessments — no third-party involvement is required. However, they must still complete all essential cybersecurity requirements, compile technical documentation, and affix CE marking.

Class I — Critical Products

Products listed in Annex III, Part I include identity management systems, password managers, web browsers, antivirus and anti-malware software, SIEM systems, routers, modems, switches, microcontrollers, and several other categories with elevated security relevance.

Class I manufacturers may still self-assess, but they also have the option to undergo third-party assessment to strengthen market credibility. If harmonized EU standards for their product category exist, compliance with those standards creates a presumption of conformity.

Class II — Highly Critical Products

Products listed in Annex III, Part II — including operating systems for servers, desktops, and mobile devices, hypervisors, hardware security modules, CPUs, smartcards, and secure elements — require mandatory involvement of a notified body through an EU-type examination before market placement.

Critical Infrastructure Products

A further subset of products critical to national infrastructure is subject to the most stringent assessment requirements. The European Commission retains the authority to amend Annex III via delegated acts, meaning this list can expand as the threat landscape evolves.

The Essential Cybersecurity Requirements: Annex I Explained

The core technical obligations are set out in Annex I of the CRA, divided into two parts: security requirements relating to product properties, and vulnerability handling requirements. Both apply to all in-scope products regardless of classification.

Part I: Product Security Requirements

Under Article 10, manufacturers must design, develop, and produce products in accordance with a documented cybersecurity risk assessment. That assessment must identify and analyze relevant threats and must actively inform design, development, and maintenance decisions — not sit as a document produced after the fact.

The specific product security requirements that Annex I, Part I mandates include:

No known exploitable vulnerabilities at release. Products must be placed on the market without vulnerabilities that can be actively exploited. This requirement alone demands a structured vulnerability identification process during development — threat modeling, secure code review, and pre-release security testing.

Reduced attack surface. Products must be designed to minimize external interfaces and limit exposure to exploitation paths.

Secure-by-default configuration. Default settings must prioritize security. Products must not ship in an insecure default state that requires user configuration to become reasonably safe.

Authentication and access control. Products must implement mechanisms to prevent unauthorized access, with appropriate controls proportional to the risk level.

Data confidentiality. Stored and transmitted data must be protected, including through encryption where appropriate.

Data integrity. The integrity of configurations, commands, and stored data must be protected against unauthorized modification.

Availability and resilience. Products must be designed to maintain function under adverse conditions, including protection against denial-of-service attacks.

Data minimization. Products must process only the data necessary for their intended function.

Security event logging. Products must record or monitor relevant security events to support incident detection and investigation.

Secure update mechanisms. Update delivery must be protected against tampering, and updates must be provided throughout the product support period.

Incident impact limitation. Products must include mitigation techniques designed to limit the security impact of a successful attack.

Part II: Vulnerability Handling Requirements

These obligations apply from September 11, 2026. They represent a fundamental shift from point-in-time security to ongoing lifecycle responsibility.

Software Bill of Materials (SBOM): Manufacturers must maintain an SBOM in a commonly used machine-readable format. The SBOM must cover all third-party components integrated into the product and must be updated as the product changes.

Regular security testing and review: Vulnerability identification must continue throughout the product lifecycle, not stop at initial release.

Timely vulnerability remediation: Identified vulnerabilities must be addressed without undue delay. Security updates must be provided free of charge.

Secure update distribution: Update mechanisms must prevent tampering during delivery.

Public disclosure of fixed vulnerabilities: Manufacturers must publicly disclose information about resolved security issues, including the nature of the vulnerability and remediation guidance.

Coordinated vulnerability disclosure policy: A formal CVD policy and a designated contact point for vulnerability reporting must be established and published.

ENISA notification: Actively exploited vulnerabilities and severe incidents affecting the product must be reported to ENISA and relevant CSIRTs within the required timeframes — 24 hours for early warning and 72 hours for formal notification.

CE Marking and Conformity Assessment

Before placing an in-scope product on the EU market, manufacturers must complete the full conformity sequence:

Step 1 — Cybersecurity Risk Assessment: Conduct and document a structured risk assessment in accordance with Article 10. This must be integrated into technical documentation.

Step 2 — Essential Requirements Implementation: Implement the applicable Annex I requirements across the product's design, development, and vulnerability management practices.

Step 3 — Conformity Assessment Procedure: Complete the applicable assessment procedure. Default and Class I products can use internal assessment. Class II products require a notified body.

Step 4 — Technical Documentation: Compile complete technical documentation under Article 31. This includes the risk assessment, design and development process documentation, vulnerability handling procedures, and testing evidence.

Step 5 — EU Declaration of Conformity: Draw up and sign the EU Declaration of Conformity under Article 30.

Step 6 — CE Marking: Affix the CE marking. The CE mark signals to market surveillance authorities, distributors, importers, and buyers that the product meets the requirements of the relevant EU directives.

Penalties: The Financial Risk of Non-Compliance

The CRA's penalty structure is tiered. The most serious category of infringement — non-compliance with the essential cybersecurity requirements set out in Annex I — carries fines of up to €15 million or 2.5% of total worldwide annual turnover, whichever is higher.

Breaches of other obligations, including many documentation and market-access requirements, carry fines of up to €10 million or 2% of global annual turnover.

Beyond financial penalties, market surveillance authorities have the power to require product modification, restrict market availability, or mandate product withdrawal and recall. For any company with meaningful EU revenue, the reputational and commercial risk of a market access block or forced recall substantially exceeds the cost of building a compliant program.

How CRA Maps to ISO 27001, SOC 2, and GDPR

Organizations that already hold ISO 27001 certification or a SOC 2 Type II report have a significant compliance foundation to build on. The overlap is meaningful but not complete.

ISO 27001 addresses organizational information security management. It covers risk assessment, access control, incident response, supplier security, and vulnerability management — all areas directly relevant to CRA requirements. However, ISO 27001 does not address product-specific requirements such as SBOM maintenance, secure-by-default configuration, or product lifecycle vulnerability disclosure. The CRA adds a product security layer on top of the organizational security baseline provided by ISO 27001.

SOC 2 covers the security, availability, and confidentiality of services as evaluated against the AICPA Trust Services Criteria. Like ISO 27001, it addresses organizational and operational controls. It provides a useful evidence base for demonstrating security practices to CRA auditors, but does not map to the product security and vulnerability management obligations in Annex I.

GDPR addresses the protection of personal data. Where CRA-compliant products process personal data of EU residents, GDPR obligations apply in parallel. The CRA's data minimization requirement — products must process only what is necessary for their intended function — directly reinforces GDPR's data minimization principle. Organizations already running GDPR compliance programs should integrate CRA product-level data-minimization requirements into their existing data protection impact assessment processes.

The key takeaway: if you already have ISO 27001, SOC 2, or GDPR programs in place, reuse that evidence infrastructure aggressively. Build the CRA-specific elements — SBOM, product risk assessment, conformity documentation, ENISA notification workflows — on top of the existing foundation rather than starting from scratch.

A Practical CRA Readiness Roadmap for SaaS Teams

With the September 11, 2026, reporting deadline months away, the following sequence prioritizes obligations that must be operationally live.

Phase 1 — Scope and Classification (Immediately)

Determine definitively whether your product qualifies as a product with digital elements under Article 3. If it does, classify it against Annex III to identify your conformity assessment path. Document this determination formally — it is the foundation of your technical documentation.

Phase 2 — SBOM Infrastructure (Within 60 Days)

Stand up tooling to generate, maintain, and update a machine-readable SBOM across all products in scope. Identify all third-party components currently in use. Establish a process to update the SBOM with every release. This is the highest-urgency technical requirement because SBOM gaps are the most common failure point in early CRA programs.

Phase 3 — Vulnerability Management and CVD Policy (Within 90 Days)

Establish or formalize your vulnerability management process. Define intake, triage, severity scoring, remediation timelines, and closure criteria. Publish a coordinated vulnerability disclosure policy with a designated security contact. Ensure your development pipeline reliably identifies and remediates vulnerabilities before release.

Phase 4 — ENISA Notification Workflow (Before September 11, 2026)

Build and test the internal escalation process for the 24-hour early-warning and 72-hour formal-notification timelines. Identify who has the authority to approve a notification submission. Confirm which CSIRT receives notifications for your relevant EU Member States. Run a tabletop exercise against the workflow to verify it functions under real conditions.

Phase 5 — Product Security Requirements and Conformity Documentation (Before December 11, 2027)

Conduct the full cybersecurity risk assessment under Article 10. Implement Annex I, Part I security requirements across your product. Compile technical documentation under Article 31. Complete the applicable conformity assessment procedure. Please draw up the EU Declaration of Conformity and affix the CE marking.

The Four Operational Capabilities That Determine CRA Success

Organizations that fail CRA compliance in 2026 typically do not fail because they lack awareness of the requirements. They fail because security, engineering, and legal functions are not coordinated around shared operational processes.

Software Composition Transparency: SBOM generation must be automated, tied to the release pipeline, and updated with every build. Manual SBOM processes break down under real release velocity.

Product Security Operations: Continuous vulnerability monitoring, risk-based triage, documented remediation timelines, and controlled update distribution must function as a managed operational discipline, not an ad-hoc reactive process.

Incident and Reporting Execution: The ENISA notification timeline — 24 hours for early warning, 72 hours for formal notification — requires a tested, owned, and rehearsed internal process. The timeline starts from the moment a vulnerability is discovered, not from when leadership decides to act.

Audit-Ready Evidence: Technical documentation, conformity assessment records, SBOM histories, risk assessment updates, and vulnerability handling logs must be maintained in a state where they can be produced on request for market surveillance authorities, notified bodies, enterprise buyers, and insurers.

If any of these four capabilities is weak, the overall compliance posture is compromised when it matters most.

What Enterprise Buyers and Partners Are Already Asking For

CRA compliance is becoming a trust signal in commercial relationships, not just a regulatory requirement. Enterprise buyers procuring software for EU deployment are beginning to ask vendors for:

• Confirmation of CRA scope determination (in or out of scope, with rationale)

• SBOM availability for in-scope products

• Coordinated vulnerability disclosure policy documentation

• Evidence of a structured vulnerability management process

• CE marking status for applicable products

• Security update commitment and support period documentation

Being able to respond to these requests with documented, production-grade answers is increasingly a deal-accelerator in the same way that SOC 2 reports became table stakes for enterprise SaaS sales over the past decade.

Is Penetration Testing Required Under the CRA?

The Cyber Resilience Act does not explicitly mandate penetration testing by name. The regulation is intentionally technology-neutral: it defines security outcomes and lifecycle obligations rather than prescribing specific methodologies.

That said, penetration testing is a practical tool for satisfying several CRA obligations. Testing against external interfaces demonstrates attack surface analysis. Authentication and access control validation through testing provides evidence for Annex I requirements. Pre-release testing that identifies and remediates vulnerabilities before market placement supports the requirement that products be placed on the market without known exploitable vulnerabilities.

A penetration test report included in technical documentation under Article 31 strengthens the conformity assessment, particularly for Class I products and any product undergoing independent review. It is not legally required — but it is practically valuable.

Frequently Asked Questions

Does the CRA apply to companies headquartered outside the EU? Yes. The CRA applies to any economic operator placing in-scope products on the EU market, regardless of where the company is incorporated or based.

If I offer pure SaaS through a browser, does the CRA apply? Generally not. Pure browser-based services accessed entirely online typically fall under NIS2 as a service rather than under the CRA as a product. However, if your SaaS is the controlling software for a connected physical device you sell, the CRA applies.

What is the penalty for missing the September 2026 reporting deadline? Non-compliance with vulnerability handling obligations can be fined up to €10 million or 2% of global annual turnover. Reporting failures are also likely to attract additional scrutiny from market surveillance authorities.

Does open-source software need to be CRA compliant? Free and open-source software developed outside commercial activity is generally exempt. However, when it is integrated into a commercial product placed on the EU market, the manufacturer of that product is responsible for CRA compliance covering the open-source components.

How long do I have to patch a reported vulnerability? The CRA requires vulnerabilities to be addressed "without undue delay." While it does not specify a universal SLA, the 24-hour early warning and 72-hour formal notification timelines for ENISA effectively define the reporting window. Remediation timelines should be defined in your vulnerability management policy, with severity-based SLAs.

How does the CRA interact with NIS2? NIS2 applies to organizations providing essential or important services and imposes security and incident reporting obligations at the organizational level. The CRA applies to products. If you are both a manufacturer of in-scope products and an entity that qualifies under NIS2, both frameworks apply. They have complementary but distinct requirements.

Is a Software Bill of Materials required from day one? The SBOM requirement is part of the vulnerability handling obligations under Article 14, which apply from September 11, 2026. Work backward from that date to ensure your SBOM infrastructure is production-ready before the deadline.

Next Steps: Where DSALTA Fits In

Building CRA readiness requires coordinating product security requirements, vulnerability management workflows, conformity documentation, and evidence infrastructure across engineering, security, and legal teams — often simultaneously.

Organizations that approach CRA compliance as part of a unified multi-framework strategy — mapping controls across ISO 27001, GDPR, SOC 2, and CRA in a single evidence layer — consistently reach readiness faster than those managing each framework as a separate program.

DSALTA's AI-powered compliance platform helps product and security teams manage multi-framework control mapping, maintain continuous evidence collection, and build audit-ready documentation across the regulatory requirements that matter to their buyers and regulators. Whether you are starting your CRA scope assessment today or working to close specific gaps before September 2026, the right platform eliminates the coordination overhead that consumes most compliance timelines.

Ready to see how DSALTA handles CRA alongside your existing ISO 27001 and GDPR programs? Book a demo and see the platform in action.