EU CRA vs NIS2 Dual Compliance Stack: How SaaS Developers Satisfy Both at Once (2026)
Post #1367 in the sota.io EU Cyber Compliance Series
If you build software products that are also used as part of networked services, you are almost certainly subject to both the EU Cyber Resilience Act (CRA) and NIS2. The two regulations approach cybersecurity from different angles — CRA governs products, NIS2 governs organizations — but their technical requirements overlap substantially. Done right, a single compliance stack can satisfy 70–80% of both frameworks simultaneously.
This guide maps the intersection, identifies the divergence points, and gives you a concrete dual-compliance plan.
Who Is Subject to Both CRA and NIS2?
Before mapping requirements, establish whether you are in scope for one or both.
CRA Scope (as of June 2026 partial applicability)
The CRA applies to "products with digital elements" — any hardware or software product that connects directly or indirectly to a network or another device. Key SaaS-adjacent cases that are in-scope:
- CLI tools distributed as installable binaries
- SDKs, libraries, or npm/PyPI packages
- Docker images or container-based software sold or distributed as a product
- On-premises agents or connectors that customers install
- Desktop applications that communicate with cloud backends
Out of scope (pure SaaS): If your product is delivered entirely as a hosted service with no installable component, CRA does not apply to the service itself. However, if you ship a client SDK, CLI, or agent alongside your SaaS, that component is in scope.
NIS2 Scope
NIS2 applies to entities operating in sectors listed in Annexes I and II — not to products. Key categories for SaaS developers:
- Cloud service providers (IaaS, PaaS, SaaS) above thresholds: ≥50 employees OR ≥€10M turnover → "Important entity"; ≥250 employees OR ≥€50M turnover → "Essential entity"
- Managed service providers (MSPs) and managed security service providers (MSSPs) regardless of size
- DNS service providers, TLD registries, data center services, CDN providers, trust service providers
- Companies in critical sectors (energy, water, health, transport, finance, digital infrastructure)
Important: NIS2 is already in force (transposition deadline was Oct 2024; most EU states enacted it through 2024–2025). CRA Article 14 obligations (vulnerability disclosure) apply from June 2026; full CRA requirements apply from December 2027.
The Overlap Zone
Most cloud-native SaaS businesses that distribute any installable component and cross NIS2 size thresholds are subject to both. Classic dual-scope profiles:
| Profile | CRA | NIS2 |
|---|---|---|
| SaaS + CLI tool | ✅ (CLI is a PDE) | ✅ (if cloud service provider) |
| B2B SaaS + on-prem connector | ✅ (connector is PDE) | ✅ (if MSP/cloud category) |
| Developer tool / SDK on npm | ✅ (library is PDE if monetized) | ✅ (if >50 employees) |
| Pure hosted SaaS, no installable | ❌ CRA N/A | ✅ (if cloud service provider) |
The Core Requirement Frameworks
CRA Article 13 — Security Requirements (PDEs)
CRA Annex I sets the baseline security obligations for in-scope products:
- No known exploitable vulnerabilities at time of placing on market
- Secure by default configuration — secure defaults out of the box, no unnecessary ports, no default credentials
- Confidentiality and integrity of data processed
- Minimal attack surface — principle of least privilege, disable unused features
- SBOM — machine-readable software bill of materials covering direct and transitive dependencies
- Vulnerability handling — documented process for receiving, evaluating, and remediating reports
- Security updates — ability to deliver timely updates; clear end-of-life date with 5-year minimum support
- Incident capability — logging, monitoring, audit trail for forensic analysis
NIS2 Article 21 — Security Measures (Entities)
NIS2 requires all in-scope entities to implement "appropriate and proportionate" technical and organizational measures. Article 21 mandates at minimum:
- Risk analysis and information security policies — documented risk assessment, security policies, governance structure
- Incident handling — procedures for detection, analysis, containment, recovery; 24h early warning to CSIRT, 72h detailed notification
- Business continuity — backup management, disaster recovery, crisis management
- Supply chain security — assess security of suppliers and third-party service providers
- Network and information system security — securing acquisition, development, and maintenance practices
- Effectiveness assessment — security audits, penetration testing, vulnerability assessments
- Cyber hygiene and training — basic hygiene practices, staff training, awareness
- Cryptography and encryption — use of encryption for data in transit and at rest
- Access control and asset management — authentication, authorization, identity lifecycle
- Multi-factor authentication (MFA) — for privileged access and where appropriate
The Intersection Map: Controls That Satisfy Both
The good news: a well-designed security program addresses most of these requirements through the same underlying controls. Here is the intersection matrix:
Shared Control Area 1 — Vulnerability Management
| Requirement | CRA Reference | NIS2 Reference |
|---|---|---|
| Vulnerability disclosure policy (VDP) | Art. 14, Annex I §8 | Art. 21(2)(b) incident handling |
| 24h ENISA notification (actively exploited) | Art. 14(2)(a) | Art. 23(4) — CSIRT early warning |
| 72h detailed vulnerability report | Art. 14(2)(b) | Art. 23(5) — CSIRT notification |
| Patch within defined SLA | Annex I §8(d) | Art. 21(2)(e) — network security maintenance |
Single control: A unified vulnerability management program (intake → triage → patch → disclose) with a shared ticketing system satisfies both. Your 24h/72h notification obligations are effectively identical; one process covers both.
Shared Control Area 2 — Supply Chain Security
| Requirement | CRA Reference | NIS2 Reference |
|---|---|---|
| SBOM (software bill of materials) | Annex II, Art. 13(6) | Art. 21(2)(d) supply chain security |
| Third-party component risk assessment | Annex I §2 | Art. 21(2)(d) |
| Supplier security questionnaires | Art. 21 (operator obligations) | Art. 21(2)(d) |
Single control: Maintain one SBOM per product covering direct + transitive dependencies. Use this same SBOM as the artifact for NIS2 supply chain risk documentation. Third-party risk assessments feed both frameworks.
Shared Control Area 3 — Secure Development
| Requirement | CRA Reference | NIS2 Reference |
|---|---|---|
| Secure coding standards | Annex I §1, §3 | Art. 21(2)(e) — secure acquisition/dev |
| Static analysis (SAST) | Annex I §1 | Art. 21(2)(e) |
| Dependency scanning (SCA) | Annex I §6 (SBOM) | Art. 21(2)(d) |
| Penetration testing | Annex I §1 (testing) | Art. 21(2)(f) |
Single control: Integrate SAST (e.g. Semgrep, CodeQL), SCA (e.g. Dependency-Track, Grype), and annual penetration tests into your CI/CD pipeline. One pipeline, two compliance boxes checked.
Shared Control Area 4 — Access Control + MFA
| Requirement | CRA Reference | NIS2 Reference |
|---|---|---|
| Least privilege | Annex I §4 | Art. 21(2)(i) access control |
| MFA for privileged access | Annex I §4 | Art. 21(2)(j) |
| No default credentials | Annex I §2(b) | Art. 21(2)(a) risk policies |
Single control: Enforce MFA on all admin/privileged accounts. Remove all default credentials. Role-based access control (RBAC) with documented role matrix satisfies both. This is often your quickest win.
Shared Control Area 5 — Logging and Monitoring
| Requirement | CRA Reference | NIS2 Reference |
|---|---|---|
| Security event logging | Annex I §8 | Art. 21(2)(b) incident detection |
| Log retention for forensics | Annex I §8(f) | Art. 23 — evidence for CSIRT reports |
| Anomaly detection | Annex I §5 | Art. 21(2)(b) |
Single control: A centralized SIEM or log aggregation platform (e.g. Wazuh, OpenSearch, or a commercial SIEM) feeding a 90-day retention policy covers both. Retain raw logs for at least 12 months for incident investigation under NIS2.
Shared Control Area 6 — Encryption
| Requirement | CRA Reference | NIS2 Reference |
|---|---|---|
| Encryption in transit | Annex I §3(a) | Art. 21(2)(h) cryptography |
| Encryption at rest | Annex I §3(b) | Art. 21(2)(h) |
| Key management | Annex I §3 | Art. 21(2)(h) |
Single control: TLS 1.2+ everywhere, AES-256 at rest, documented key rotation policy. The same cryptography controls satisfy both frameworks completely.
Shared Control Area 7 — Incident Response
| Requirement | CRA Reference | NIS2 Reference |
|---|---|---|
| Incident detection | Annex I §8 | Art. 21(2)(b) |
| Incident response playbooks | Art. 14 (coordinated disclosure) | Art. 21(2)(b) |
| Post-incident documentation | Art. 14(2)(c) | Art. 23(7) — final report |
Single control: One IR plan covering detection → containment → eradication → recovery → disclosure. The NIS2 CSIRT notification and CRA ENISA vulnerability disclosure can be routed through the same process.
Where CRA and NIS2 Diverge
Not everything overlaps. Here are the key divergence points where you need framework-specific work:
Divergence 1 — Technical Documentation (CRA Only)
CRA requires a formal technical documentation file for each product (Annex VII). This includes:
- General product description + intended use
- List of applicable standards or specifications
- Risk assessment methodology and results
- SBOM with all components and versions
- Evidence of conformity assessment (Module A self-declaration, or NB certification for Class I/II)
- Declaration of conformity (EU Declaration of Conformity)
- CE marking
NIS2 has no equivalent technical documentation requirement. This is CRA-specific and represents 20–30% of your CRA compliance effort.
Action: Create a Technical Documentation folder per product. Use templates from ENISA or BSI. Update on every major release.
Divergence 2 — CE Marking (CRA Only)
CRA requires CE marking on all in-scope products before they can be placed on the EU market. NIS2 has no marking requirement.
- Default class: Self-declaration (Module A) — write your own Declaration of Conformity, affix CE mark
- Important products (Annex III Part I): Module A + standard (or notify a Notified Body) — see our Class I guide
- Critical products (Annex III Part II): Mandatory Notified Body certification
If your product is Default class (most SaaS SDKs, CLIs, developer tools), this is just paperwork: write a DoC referencing Annex I compliance, keep it on file for 10 years.
Divergence 3 — Organizational Risk Governance (NIS2 Only)
NIS2 places obligations on management bodies that have no CRA equivalent:
- Board/senior management personal liability for NIS2 compliance failures
- Management must approve security policies (Art. 21 is an entity obligation)
- Annual cybersecurity training for management bodies (Art. 21(2)(g))
- Board can be held personally liable for fines (Art. 32 — up to €10M or 2% global turnover for important entities)
CRA fines fall on the economic operator (legal entity). NIS2 can reach individual managers.
Action: Designate a named CISO or equivalent. Get board sign-off on your NIS2 security policy. Document board-level security training annually.
Divergence 4 — Business Continuity and Recovery (NIS2 Only)
NIS2 Art. 21(2)(c) requires documented BCM/DRP covering business continuity during and after incidents. CRA focuses on product security, not organizational resilience.
Action: Maintain a Business Continuity Plan (BCP) and Disaster Recovery Plan (DRP) covering your service. Define RTO and RPO targets. Test DR procedures annually.
Divergence 5 — Notification Targets
Both regulations require incident notifications, but to different authorities:
| Trigger | CRA Target | NIS2 Target |
|---|---|---|
| Actively exploited vulnerability | ENISA (via single reporting platform) | National CSIRT |
| Significant cybersecurity incident | ENISA | National CSIRT (24h + 72h + final report) |
| Serious incident affecting end users | Art. 14(8) — notify users | Art. 23 — notify CSIRT, may notify users |
Action: Map your national CSIRT (Germany: BSI CERT-Bund; France: ANSSI; Netherlands: NCSC-NL). Set up dual-routing in your IR playbook: one trigger, two notification pathways.
Timeline: CRA vs NIS2
Understanding which requirements are live vs. upcoming helps prioritize:
| Requirement | CRA Status | NIS2 Status |
|---|---|---|
| Vulnerability disclosure (Art.14) | LIVE June 2026 | LIVE (since 2024/25 national transposition) |
| Security update obligation | Dec 2027 | LIVE |
| SBOM requirement | Dec 2027 | Recommended now (supply chain risk) |
| Technical documentation | Dec 2027 | N/A |
| CE marking | Dec 2027 | N/A |
| Incident reporting | CRA Art.14 June 2026 | LIVE |
| MFA / access control | Dec 2027 | LIVE |
| Penetration testing / audit | Dec 2027 | LIVE |
Bottom line: NIS2 obligations are fully in force now. CRA Art.14 vulnerability disclosure kicks in June 2026. Full CRA applicability is December 2027. This gives you a sequenced roadmap: address NIS2 gaps immediately, then use the 18 months until Dec 2027 to build out CRA-specific documentation and CE marking.
The Dual Compliance Action Plan
A practical 5-step sequence to achieve dual compliance:
Step 1 — Scope Confirmation (Week 1)
- Identify all products with digital elements (CRA scope audit)
- Determine NIS2 entity category (size, sector)
- Map which components require which CRA class (Default / Class I / Class II)
- Output: Scope matrix document
Step 2 — Quick Wins: NIS2 + CRA Shared Controls (Weeks 2–4)
These satisfy both frameworks and eliminate the most critical gaps:
☐ Enforce MFA on all admin access (CRA Annex I §4 + NIS2 Art.21(j))
☐ Remove all default credentials (CRA Annex I §2 + NIS2 Art.21(a))
☐ Enable TLS 1.2+ everywhere, AES-256 at rest (CRA §3 + NIS2 Art.21(h))
☐ Deploy SAST in CI/CD pipeline (CRA Annex I §1 + NIS2 Art.21(e))
☐ Generate initial SBOM from lockfiles (CRA Annex II + NIS2 Art.21(d))
☐ Write Vulnerability Disclosure Policy (CRA Art.14 + NIS2 Art.21(b))
☐ Set up centralized logging (CRA Annex I §8 + NIS2 Art.21(b))
Step 3 — NIS2-Specific Gaps (Months 1–3)
Focus on NIS2 obligations that are live now and have no CRA equivalent:
☐ Document NIS2 risk assessment (organizational risk, not product risk)
☐ Write and board-approve security policy
☐ Register with national competent authority (where required)
☐ Create Incident Response Plan with CSIRT notification paths
☐ Establish Business Continuity Plan + DRP
☐ Document supply chain risk assessment for top 10 vendors
☐ Schedule annual management security training
Step 4 — CRA-Specific Work (Dec 2026 – Dec 2027)
Use the remaining runway before full CRA applicability:
☐ Complete SBOM tooling (cyclonedx-bom or Syft in CI/CD)
☐ Create Technical Documentation per product (Annex VII)
☐ Write EU Declaration of Conformity (Default class: self-declaration)
☐ Notified Body certification if any product is Class I/II
☐ Define and publish End-of-Life dates (5-year minimum support)
☐ Affix CE marking to product documentation
☐ Register with EU MSA national contact points
Step 5 — Ongoing Dual Compliance (Continuous)
☐ Update SBOM on every release
☐ Run quarterly vulnerability scans
☐ Annual penetration test (NIS2 Art.21(f) / CRA Annex I §1)
☐ 24h ENISA + CSIRT notification on actively exploited vulns (CRA Art.14 + NIS2 Art.23)
☐ Annual DR test
☐ Refresh technical documentation on major version changes
Compliance Stack Recommendation
The most efficient dual-compliance tech stack for SaaS developers in 2026:
Vulnerability Management
- Grype (Anchore) — open-source container + dependency scanner, SBOM-aware
- Dependency-Track — SBOM-native platform for component risk tracking
- OpenVAS / Greenbone — network vulnerability scanner (EU-based Greenbone GmbH, Osnabrück)
SBOM Generation
- Syft (Anchore) — generates CycloneDX or SPDX SBOMs from containers, source code, filesystems
- cdxgen — supports 20+ language ecosystems, CycloneDX native
SAST / SCA
- Semgrep CE (open-source) — static analysis
- CodeQL (GitHub Actions) — semantic code analysis
- OWASP Dependency-Check — known vulnerability detection in dependencies
SIEM / Log Management
- Wazuh — open-source SIEM + XDR (Spain-based, EU GDPR-aligned)
- OpenSearch — AWS-donated, self-hosted on EU infrastructure
Incident Response
- TheHive — EU-born security incident response platform (TheHive Project)
- MISP — open-source threat intelligence sharing (CIRCL Luxembourg)
Hosting Considerations
Both CRA and NIS2 create incentives for EU-sovereign infrastructure:
- CRA Art.13 §3: Products must protect confidentiality/integrity of data processed — US-based hosting introduces CLOUD Act jurisdiction risk that must be documented as a residual risk
- NIS2 Art.21(2)(h): Encryption requirements are easier to meet when infrastructure providers don't have US government access rights
- NIS2 Supply Chain (Art.21(2)(d)): Your hosting provider is a critical supplier — their NIS2 compliance posture matters
Running on EU-native PaaS infrastructure like sota.io eliminates the CLOUD Act vector entirely: no US parent, no US government subpoena risk, Hetzner Germany compute. This simplifies your NIS2 supply chain risk assessment (hosting = EU-compliant, no carve-outs needed) and your CRA technical documentation (jurisdiction = EU, no CLOUD Act residual risk to document).
Enforcement Comparison
Knowing who enforces what — and what penalties apply — helps prioritize:
NIS2 Enforcement
- Authority: National competent authorities (Germany: BSI; France: ANSSI; Netherlands: NCSC-NL)
- Fines (important entities): Up to €10M or 2% global annual turnover (higher applies)
- Fines (essential entities): Up to €20M or 4% global annual turnover
- Personal liability: Management can be made personally liable and suspended
- Status: Live enforcement now; most national authorities have begun notifying entities
CRA Enforcement
- Authority: Market Surveillance Authorities (MSAs) — same bodies as for product safety (Germany: Bundesnetzagentur; France: ANSSI; others TBD)
- Fines: Up to €15M or 2.5% global annual turnover for Annex I violations; €10M or 2% for other violations; €5M or 1% for procedural violations
- Status: Art.14 enforcement from June 2026; full enforcement from December 2027
Key difference: NIS2 fines are organizational. CRA fines are product-level. If you have multiple products, each product is a separate CRA enforcement surface.
Common Mistakes in Dual Compliance Programs
Mistake 1 — Running two separate programs. Many teams build a "CRA workstream" and a "NIS2 workstream" that duplicate effort. Map overlapping controls first; run separate tracks only for divergence points.
Mistake 2 — Treating SBOM as a checkbox. An SBOM that isn't updated on release is worse than useless — it creates false assurance. Automate SBOM generation in CI/CD from day one.
Mistake 3 — Waiting until December 2027 for CRA. Article 14 (vulnerability disclosure) applies from June 2026. If you don't have a VDP by then, you're already non-compliant.
Mistake 4 — Confusing "pure SaaS = no CRA" with total CRA exemption. If you ship any installable component, SDK, or CLI, CRA applies to that component. Audit your distribution model carefully.
Mistake 5 — No board-level NIS2 governance. NIS2 personal liability for management bodies is not theoretical. Regulators in Germany and France have already begun sending notification letters to C-level executives of in-scope entities.
Mistake 6 — Underestimating supply chain scope. Both CRA and NIS2 extend compliance obligations upstream. Your top 10 critical suppliers each need a security assessment. Cloud providers, CI/CD vendors, and CDN services are all in scope.
Dual Compliance Checklist — Quick Reference
=== IMMEDIATE (NIS2 live now + CRA Art.14 June 2026) ===
☐ Confirm NIS2 entity category and register with national authority
☐ Deploy MFA on all privileged access
☐ Write and publish Vulnerability Disclosure Policy
☐ Set up CSIRT notification pathway (national + ENISA)
☐ Establish 24h incident response readiness
☐ Document board-approved information security policy
☐ Conduct annual management security training
☐ Assess top 10 supplier security posture
=== SHORT-TERM (by end of 2026) ===
☐ Generate SBOM for all in-scope products (automate in CI/CD)
☐ Integrate SAST + SCA in all product pipelines
☐ Complete supply chain risk assessment for all critical vendors
☐ Write Incident Response Plan with dual CSIRT/ENISA routing
☐ Establish Business Continuity + Disaster Recovery plans
☐ Confirm CRA product class for all distributed components
=== PRE-DECEMBER 2027 (full CRA applicability) ===
☐ Complete Technical Documentation (Annex VII) per product
☐ Write EU Declaration of Conformity per product
☐ Notified Body assessment if any product is Class I/II
☐ Affix CE marking, ensure it appears in documentation
☐ Publish End-of-Life dates (≥5 years from market placement)
☐ Deploy secure-by-default configuration for all products
☐ Complete vulnerability handling procedure documentation
Key Takeaways
-
70–80% overlap: Vulnerability management, access control, encryption, logging, supply chain, and IR controls satisfy both frameworks through the same technical implementations.
-
CRA adds product-level obligations: Technical documentation, CE marking, SBOM, and secure-by-default are CRA-specific requirements with no NIS2 equivalent.
-
NIS2 adds organizational obligations: Board governance, personal liability, BCM/DRP, and entity registration are NIS2-specific with no CRA equivalent.
-
Timelines differ critically: NIS2 is live now. CRA Art.14 June 2026. Full CRA December 2027. Prioritize accordingly.
-
Notification targets differ: CRA → ENISA single reporting platform. NIS2 → national CSIRT. One incident, two authorities. Build dual-routing into your IR playbook.
-
EU-sovereign infrastructure simplifies both: No CLOUD Act residual risk to document (CRA), no US supplier carve-outs in supply chain assessment (NIS2).
Next in the EU CRA 2026 Series
This is Post #4 of 5 in the EU CRA 2026 Update Series:
- EU CRA Vulnerability Disclosure June 2026: What Developers Must Do Now — Article 14 obligations live in weeks
- EU CRA Art.13 Security Requirements: SBOM + Secure-by-Default for SaaS Developers — Full technical requirements breakdown
- EU CRA Product Classes 2026: Which Rules Apply to Your SaaS — Default, Class I, Class II classification guide
- EU CRA vs NIS2 Dual Compliance Stack ← You are here
- EU CRA Compliance Finale: Complete SaaS Developer Toolkit 2026 (coming next)
sota.io is EU-native managed PaaS — 100% GDPR, no US parent, no CLOUD Act exposure, deployed on Hetzner Germany. Start building on EU infrastructure →
EU-Native Hosting
Ready to move to EU-sovereign infrastructure?
sota.io is a German-hosted PaaS — no CLOUD Act exposure, no US jurisdiction, full GDPR compliance by design. Deploy your first app in minutes.