NIS2 Simplification 2026 + Cybersecurity Act 2: What Changes for SaaS Vendors

On January 20, 2026, the European Commission published two linked legislative proposals that together constitute the most significant reform of EU cybersecurity law since NIS2 entered into force in 2023:

1. A NIS2 simplification amendment — reshaping scope thresholds, simplifying supervisory procedures, and introducing a lighter-touch compliance regime for a new "small mid-cap" category.
2. Cybersecurity Act 2 (CSA2) — replacing the 2019 Cybersecurity Act with a new framework that adds a horizontal ICT Supply-Chain-Security-Framework, EUCS (European Cybersecurity Certification Scheme for Cloud Services) as a legislative instrument, and stronger enforcement tools.

For most SaaS developers, the reaction to "NIS2 simplification" is relief. But the Commission's reform is not simply a compliance reduction. It introduces new obligations while reducing friction in others. The interaction with CRA (Cyber Resilience Act) and the existing NIS2 creates a three-layer compliance architecture that is still underexplained in developer-facing resources.

This guide covers: what changed in NIS2 scope, what CSA2 adds, who the new "small mid-cap" category covers, and how the NIS2–CSA2–CRA triple-overlap applies to a typical SaaS vendor.

What the NIS2 Simplification Changes

New "Small Mid-Cap" Category

The biggest change for small and growing SaaS companies is the introduction of a new entity category: the "small mid-cap".

Under current NIS2, the size threshold for "important entities" is: at least 50 employees OR at least €10M annual turnover. The Commission's simplification proposal:

• Retains the existing important entity threshold at 50+ employees / €10M+ revenue.
• Adds a new "small mid-cap" sub-tier within the important entity category: under 750 employees AND under €150M annual revenue.
• Small mid-caps remain "important entities" and are fully in scope of NIS2's security measures (Article 21) — but benefit from a lighter supervisory regime and extended incident reporting timelines.

What does "lighter" mean in practice?

If your SaaS company has fewer than 750 employees and less than €150M revenue, you are still in scope—but you operate under the small mid-cap regime rather than the standard important entity regime. This matters primarily for supervisory risk, not day-to-day security controls (Article 21 applies unchanged).

Scope Expansions: New Entity Types Added

The simplification amendment also expands scope in three areas:

1. Digital Identity Wallet Providers

The European Digital Identity (EUDI) Wallet framework (eIDAS 2.0) creates a new category of identity service provider. The NIS2 simplification amendment adds EUDI Wallet providers to the essential entity list under Article 3. If your platform integrates with or operates EUDI Wallet infrastructure (not just uses it for login), you may be classified as essential.

2. Submarine Cable Infrastructure

Operators of submarine cable landing stations and submarine cable networks that carry trans-European traffic are added as essential entities. Relevant primarily for network infrastructure providers, not typical SaaS vendors.

3. Managed Security Service Providers (MSSPs)

MSSPs providing services to essential or important entities are explicitly included as important entities, regardless of size. If your SaaS product is positioned as a security monitoring, SIEM, or SOC service for other regulated organizations, you are in scope irrespective of the 50-employee threshold.

Mandatory EU Representative Requirement

Article 26 of NIS2 currently allows non-EU entities providing services to EU customers to "designate" an EU representative—but enforcement has been patchy. The simplification amendment makes this mandatory and enforceable:

• Any essential or important entity established outside the EU that provides services to entities or individuals in the EU must designate an EU representative as a legal point of contact for supervisory authorities.
• The EU representative is jointly and severally liable with the entity for NIS2 compliance.
• Failure to designate within 12 months of the amendment's entry into force triggers fines up to €5M for important entities.

For US-based or non-EU SaaS vendors targeting European customers: if your product falls in NIS2 scope and you have no EU legal presence, you will need to appoint an EU representative. This is structurally similar to the GDPR Article 27 representative obligation but carries higher fines and active supervisory interface duties.

Streamlined Incident Reporting

The simplification amendment rationalizes incident reporting to address the overlap between NIS2 and sector-specific frameworks (DORA, CER):

• Entities in scope of both NIS2 and DORA (financial sector) report only to their sector regulator under DORA's procedures. NIS2 is satisfied by the sector report.
• Entities in scope of both NIS2 and CRA (product manufacturers) report vulnerability incidents under CRA procedures to ENISA. NIS2 incident reporting obligations are satisfied for the same incident.
• Single reporting window: Member states must operate a national single-point-of-contact that routes NIS2 reports to relevant sector regulators without requiring duplicate filings.

For SaaS vendors shipping software products (in CRA scope): a CRA-compliant vulnerability report to ENISA under Article 14 satisfies the parallel NIS2 Article 23 notification for the same incident.

Cybersecurity Act 2 (CSA2): What's New

The original Cybersecurity Act (2019) established ENISA's permanent mandate and created the European Cybersecurity Certification Framework (ECCF). CSA2 replaces it and adds three significant elements:

EUCS as a Mandatory Legislative Instrument

The European Cybersecurity Certification Scheme for Cloud Services (EUCS) has been in development since 2020. Under the original Cybersecurity Act, certification schemes were voluntary and member states could not make them mandatory in public procurement.

CSA2 changes this by:

• Elevating EUCS to a legislative instrument that member states can reference in public procurement law.
• Creating a new "sovereign" cloud tier in EUCS (alongside Basic, Substantial, High levels) specifically for data that must remain under EU-jurisdiction control chains.
• Allowing member states to require EUCS certification for cloud services procured by public authorities under the CADA (Cloud and AI Development Act) framework (expected Commission proposal: May 27, 2026).

For SaaS vendors selling to EU public sector customers: EUCS "Substantial" or "High" certification will become a de facto procurement prerequisite in major member states (Germany's BSI-C5, France's SecNumCloud already operate as voluntary precursors). CSA2 creates the legal mechanism to make this mandatory.

Horizontal ICT Supply-Chain-Security-Framework

This is the most technically significant addition in CSA2 and addresses a gap that neither NIS2 nor CRA fills: cross-organization supply chain security obligations.

Current NIS2 requires essential and important entities to assess their suppliers' security practices (Article 21(2)(d)). But there is no standardized process for how that assessment works, what suppliers must disclose, or how to handle cascading supply chain risk. CSA2 introduces:

• Tier-1 Supplier Obligations: Any organization supplying ICT products or services to essential entities must maintain a "security factsheet" — a standardized disclosure of their security practices, vulnerability management process, and subprocessors.
• Cascading Assessment Protocol: Essential entities must document their dependency chain for critical functions down to Tier-3 suppliers. The protocol specifies what information must be available at each tier.
• Critical Dependency Designation: ENISA (with national cooperation) publishes a list of ICT products or services classified as "critical dependencies." Entities relying on a critical dependency must notify their NCA and document a contingency plan.

For SaaS vendors: if your product is used by any essential entity (hospital, energy operator, bank, public authority), you become a Tier-1 supplier under the ICT Supply-Chain-Security-Framework and must:

1. Maintain and provide a security factsheet on request.
2. Disclose your own critical subprocessors (Tier-2).
3. Notify customers promptly of any change to critical subprocessors.

The security factsheet format is not yet final (ENISA is developing the template), but the disclosure categories are specified in CSA2 Annex III: vulnerability management policy, patch cadence, incident response contact, subprocessor list, certification status.

The NIS2–CSA2–CRA Triple-Overlap

The three regulatory instruments are designed to be complementary but interact in ways that are often confusing in practice.

Who Falls Under Each

Where Obligations Overlap (and Where They Don't)

Incident Reporting: NIS2 requires 24h early warning for significant incidents. CRA requires 24h early warning for actively exploited vulnerabilities. For the same incident (a zero-day exploit affecting your SaaS and your customers), you may need to file under both frameworks—but the simplification amendment creates the single-reporting-window described above.

Vulnerability Management: CRA Article 13 requires vulnerability management throughout the product lifecycle. NIS2 Article 21(2)(e) requires vulnerability handling procedures. CSA2's security factsheet requires you to disclose your vulnerability management policy. These are substantively the same process—document it once, fulfill it three times.

Supply Chain Assessment: NIS2 Article 21(2)(d) requires essential entities to assess supplier security. CSA2's ICT Supply-Chain-Security-Framework formalizes this into the security factsheet. CRA Article 13(6) requires manufacturers to assess component security. If your SaaS product uses open-source components (it does), you must assess them under CRA and disclose your process under CSA2.

Practical Compliance Architecture

For a SaaS vendor in scope of all three:

NIS2 (entity-level):
  ├── Security measures (Art.21) — governance, access control, encryption, BCP
  ├── Incident reporting (Art.23) → single window (post-simplification)
  └── Supply chain (Art.21(2)(d)) → satisfied by CSA2 factsheet + CRA SBOM

CRA (product-level):
  ├── Secure-by-design (Art.13) — vulnerability management, no default passwords
  ├── SBOM (Art.13(4)) — machine-readable software bill of materials
  └── Vulnerability reporting (Art.14) → ENISA → satisfies NIS2 Art.23 for same incident

CSA2 (market-access / supply-chain):
  ├── Security factsheet (Annex III) — disclosed to essential entity customers on request
  ├── Subprocessor change notification — 30-day notice
  └── EUCS certification (if serving public sector at Substantial/High tier)

The key insight: most of what NIS2 and CSA2 require is already required by CRA. CRA compliance, done properly, substantially satisfies the supply-chain and product-security obligations of both NIS2 and CSA2. The incremental cost of NIS2 + CSA2 compliance for a CRA-compliant SaaS vendor is primarily organizational (governance, incident response procedures, EU representative) rather than technical.

Timeline and What to Do Now

Legislative Timeline

• January 20, 2026: Commission proposals published (NIS2 simplification amendment + CSA2).
• Q2–Q3 2026: European Parliament and Council begin parallel readings.
• Q1 2027 (target): Political agreement (Trilogue conclusion). Not binding—this is an ambitious target.
• 12 months after entry into force: Member states transpose NIS2 simplification.
• Immediately on entry into force: CSA2 ICT Supply-Chain-Security-Framework obligations for Tier-1 suppliers apply (no transposition required—directly applicable as a regulation).

The current NIS2 (as transposed) applies now. The simplification amendment does not retroactively change current obligations until adopted and transposed. If you are already in scope, your current NIS2 obligations remain unchanged until the simplification is adopted.

What to Prioritize Now

If you are already NIS2-compliant:

• Begin mapping which of your customers are essential entities—this determines if you will be a Tier-1 supplier under CSA2.
• Prepare a draft security factsheet using CSA2 Annex III categories (now is the time to document what you already do).
• If you have no EU legal entity and serve EU B2B customers in regulated sectors, evaluate the EU Representative requirement.

If you are not yet NIS2-compliant but are above the thresholds:

• The simplification does not reduce scope—if you are above 50 employees / €10M, you are in scope now.
• The small mid-cap lighter-touch regime is a supervisory benefit, not an exemption.
• Prioritize Article 21 security measures (governance, access control, incident response) as these are unchanged by the simplification.

If you are building software products (CRA in scope):

• Your CRA compliance work (SBOM, vulnerability management, incident reporting to ENISA) will satisfy substantial parts of both NIS2 and CSA2.
• Document the cross-mapping explicitly in your compliance architecture—this makes NCA audits significantly faster.

Key Takeaways

The NIS2 simplification package is not a compliance holiday. It addresses real friction points (duplicate reporting, unclear small-company obligations, non-EU entity gaps) while simultaneously expanding scope (EUDI wallets, MSSPs, mandatory EU representative) and adding new obligations (CSA2 security factsheet, ICT Supply-Chain-Security-Framework).

For SaaS vendors, the most consequential change is the Tier-1 supplier framework in CSA2: if your product serves essential entities, you will be required to maintain and disclose a standardized security factsheet regardless of your own NIS2 status. This creates a de facto supply-chain compliance requirement for SaaS vendors who might otherwise sit below NIS2 thresholds.

The NIS2–CSA2–CRA triple-overlap is manageable if architected correctly: CRA compliance provides the technical foundation, NIS2 adds the organizational layer, and CSA2 adds the market-interface (factsheets, EUCS certification for public sector). Build once, satisfy all three.

sota.io runs on EU infrastructure only — no US data transfers, no CLOUD Act exposure. Our EU compliance blog tracks NIS2, CRA, GDPR, and EU AI Act developments weekly.