EU CRA Compliance Finale: Complete SaaS Developer Toolkit 2026

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

The EU Cyber Resilience Act is no longer hypothetical. With Article 14 vulnerability disclosure obligations live as of June 2026 and full compliance required by December 2027, SaaS developers distributing any installable component — SDK, CLI, agent, library — face a structured set of obligations that demand preparation now.

This is the final post in our five-part CRA Update Series. Here we consolidate everything: every deadline, every obligation mapped to your product type, implementation checklists, SBOM requirements, and a decision framework to reach December 2027 ready.

The CRA at a Glance (June 2026 Snapshot)

The CRA applies to "products with digital elements" — hardware or software that connects to networks or other devices. For SaaS developers, the in-scope trigger is almost always a distributed component: CLI tool, SDK, container image, on-premises agent, or desktop app.

Pure hosted SaaS with zero installable components is generally out of scope. If you ship a client library to npm or PyPI alongside your service, that library is in scope.

Deadline Timeline

Product Classification: Your Starting Point

Your compliance burden depends on how your product is classified. We covered product classes in detail in Post #1366 — here is the decision framework:

Is your product listed in Annex III or IV?
│
├─ YES → Is it in Annex IV? → CRITICAL (Class II) — mandatory notified body
│         Is it in Annex III? → IMPORTANT (Class I) — self-assessment OR notified body
│
└─ NO → DEFAULT category — self-assessment only (most SaaS SDKs/CLIs fall here)

Common SaaS developer examples:

The Full Obligation Map

1. Security Requirements (Art. 13 + Annex I)

All in-scope products must meet these during design and production:

Annex I, Part I — Essential Requirements:

• Design and develop with security from the outset (secure-by-design)
• Deliver without known exploitable vulnerabilities at time of placing on market
• Default configurations must be secure — no default passwords, no unnecessary open ports
• Protect confidentiality, integrity, and availability of data (in transit and at rest)
• Minimize attack surface — disable unused services, interfaces, ports
• Implement access controls: least privilege, authentication, authorization
• Maintain resilience against DoS attacks where relevant for the product category
• Provide mechanisms to securely update the product
• Collect only minimum necessary data (data minimisation)
• Support auditability — logging sufficient to detect security-relevant events

Annex I, Part II — Vulnerability Handling:

• Identify and document all components including third-party components (→ SBOM)
• Provide security updates free of charge throughout the support period
• Publish CVD policy (coordinated vulnerability disclosure process)
• Disclose actively exploited vulnerabilities to ENISA and national CSIRTs within 24 hours
• Notify ENISA of any security incidents that impact product security within 72 hours
• Set and communicate support period — users must know how long they will receive updates
• After end-of-life: notify users, provide migration guidance or extended support options

We covered SBOM requirements and Art.13 in depth in Post #1365.

2. Conformity Assessment (Art. 32)

Default category: Module A — internal production control. You self-assess, document, keep records for 10 years.

Class I (Important): Module A (self-assessment with stricter documentation) OR a notified body can optionally be engaged.

Class II (Critical): Mandatory notified body involvement. Either Module H (full quality assurance) or Module B+C (EU-type examination).

Notified bodies for CRA are being designated throughout 2026 — many certification bodies already offer early-adopter programs. The deadline for notified body designation at EU level passed in June 2026.

We covered conformity assessment in detail in Post #1366.

3. Technical Documentation (Art. 31 + Annex VII)

You must maintain and be able to produce on regulatory demand:

• General description of the product and its intended use
• Design and development documentation including architecture and security measures
• SBOM (Software Bill of Materials) listing all components and their origins
• Risk assessment and the security measures taken in response
• Information on the conformity assessment procedure followed
• Declaration of conformity (Art. 28)
• Instructions for secure configuration and use (for users)
• Vulnerability handling procedures

Retention period: 10 years after placing on market.

4. EU Declaration of Conformity (Art. 28)

Before CE marking your product for the EU market, you must produce a Declaration of Conformity containing:

• Product name, type, and version
• Your company name and address
• Statement that the product meets all applicable essential requirements of Annex I
• Reference to the conformity assessment procedure followed
• Reference to harmonised standards applied (when published by European Commission)
• Signature of authorised representative

CE marking is required on the product and its packaging. Digital products can place CE marking in documentation and digital interfaces.

5. Importer and Distributor Obligations (Art. 19, 20)

If you resell or integrate third-party components in your product, you have due-diligence obligations:

• Verify the manufacturer has completed conformity assessment
• Do not distribute products you know to be non-compliant
• Report vulnerabilities in third-party components to the manufacturer and to ENISA
• Keep records of your supply chain and be able to trace component origins (→ SBOM again)

If you are an importer (bringing non-EU software to EU market): you take on additional responsibility for ensuring compliance, and must affix your name and contact details to the product.

The SBOM Toolkit

The CRA makes SBOM (Software Bill of Materials) mandatory but does not specify the format. In practice, two formats dominate:

SPDX 2.3+ (ISO/IEC 5962:2021)

SPDXVersion: SPDX-2.3
DataLicense: CC0-1.0
SPDXID: SPDXRef-DOCUMENT
DocumentName: myapp-sdk-2.1.0
DocumentNamespace: https://example.com/sbom/myapp-sdk-2.1.0

PackageName: myapp-sdk
SPDXID: SPDXRef-Package
PackageVersion: 2.1.0
PackageSupplier: Organization: Example GmbH
PackageDownloadLocation: https://github.com/example/myapp-sdk
PackageLicenseConcluded: Apache-2.0
PackageLicenseDeclared: Apache-2.0
PackageCopyrightText: 2024 Example GmbH
FilesAnalyzed: false
ExternalRef: SECURITY cpe23Type cpe:2.3:a:example:myapp-sdk:2.1.0:*:*:*:*:*:*:*

CycloneDX 1.5+

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.5",
  "version": 1,
  "metadata": {
    "timestamp": "2026-05-28T10:00:00Z",
    "component": {
      "type": "library",
      "name": "myapp-sdk",
      "version": "2.1.0",
      "purl": "pkg:npm/myapp-sdk@2.1.0"
    }
  },
  "components": [
    {
      "type": "library",
      "name": "express",
      "version": "4.18.2",
      "purl": "pkg:npm/express@4.18.2",
      "licenses": [{"license": {"id": "MIT"}}]
    }
  ],
  "vulnerabilities": []
}

Tooling recommendations (EU-hosted or open source):

CVD Policy Template (Art. 14)

You must publish a Coordinated Vulnerability Disclosure (CVD) policy before June 2026. Here is a compliant minimal template:

# Security Vulnerability Disclosure Policy

## Scope
This policy applies to [Product Name] version [X.Y+].

## Reporting
Report security vulnerabilities to: security@example.com
PGP key: [link to public key]
We accept encrypted and plaintext reports.

## Response Commitments
- Acknowledgement: within 72 hours
- Initial assessment: within 7 days
- Status updates: every 14 days until resolved
- CVE assignment: we will request a CVE ID for confirmed vulnerabilities

## Regulatory Notifications
In accordance with EU CRA Art.14, we will:
- Notify ENISA within 24 hours of discovering an actively exploited vulnerability
- Notify ENISA within 72 hours of security incidents affecting product integrity
- Coordinate public disclosure with reporters where feasible

## Safe Harbour
We will not pursue legal action against researchers who:
- Report in good faith under this policy
- Do not exploit vulnerabilities beyond confirming their existence
- Do not disclose publicly before we have had 90 days to respond

## Out of Scope
[List specific endpoints, versions, or environments not covered]

Publish this at a stable URL (e.g. https://yourdomain.com/security or via your GitHub SECURITY.md). Register it with ENISA's CVD database once the registry is operational.

NIS2 Cross-Reference

If you are also subject to NIS2 (as a cloud service provider above NIS2 size thresholds), many CRA controls satisfy NIS2 Article 21 simultaneously. We mapped this in full in Post #1367. Key overlaps:

Build a single security program that tags controls by framework. The incremental cost of NIS2 compliance on top of CRA is modest if the CRA program is designed correctly from the start.

18-Month Implementation Roadmap (Now → December 2027)

Phase 1: June 2026 (Immediate — Required Now)

• CVD policy live at stable public URL
• ENISA notification process documented and tested (who sends, what channel, what template)
• Incident response runbook includes regulatory notification steps
• Asset inventory of all distributed components (SDKs, CLIs, agents, packages) completed

Phase 2: Q3–Q4 2026 (Foundation)

• SBOM generation integrated into CI/CD pipeline (auto-generated on every release)
• Product classification confirmed (Default / Class I / Class II)
• Secure-by-design audit of existing products — gap analysis against Annex I Part I
• Support period defined and communicated to users for each product
• Third-party component risk assessment — are your dependencies CRA-compliant?

Phase 3: Q1–Q2 2027 (Compliance Build-Out)

• Technical documentation completed (Annex VII format)
• Conformity assessment procedure selected and initiated
• Security test suite covering Annex I Part I requirements automated
• User documentation updated with secure configuration instructions
• Supply chain due diligence — contracts with component suppliers updated

Phase 4: H2 2027 (Certification and CE Marking)

• Declaration of Conformity drafted and signed
• CE marking applied to product and documentation
• Notified body engagement completed (Class I/II) or self-assessment finalized (Default)
• 10-year record retention system in place
• Market surveillance readiness — ready to respond to regulator requests within 10 days

Common Mistakes to Avoid

1. Assuming pure SaaS is always out of scope Any npm package, pip library, Docker image, or CLI you distribute can pull you in scope. Audit your distribution channels.

2. Treating SBOM as a one-time artifact The CRA requires SBOM to reflect the current state of your product. Manual SBOMs become stale immediately. Integrate SBOM generation into CI/CD.

3. Missing the June 2026 CVD deadline Many developers are focused on the December 2027 full compliance deadline and have not published a CVD policy. The Art.14 vulnerability disclosure obligations are already in effect.

4. Conflating NIS2 and CRA reporting channels NIS2 security incidents go through national competent authorities (your country's NIS2 authority). CRA vulnerability notifications go to ENISA and CSIRTs. These are separate channels with different timelines.

5. Not communicating support periods The CRA requires you to tell users how long they will receive security updates. If you have no defined EOL policy, create one before December 2027.

6. Ignoring the import/distributor chain If you build on third-party SDKs or ship others' components, you have due-diligence obligations. Verify your upstream suppliers' compliance posture now — waiting until 2027 may leave you exposed if they are non-compliant.

EU Cloud Sovereignty Note

If your product stores or processes customer data — which most SaaS-adjacent tools do — consider a EU-hosted deployment to eliminate CLOUD Act exposure. Regulators have started asking about data flows in conformity assessments, particularly for Class I products in regulated sectors.

EU-sovereign infrastructure options such as Hetzner, Scaleway, and IONOS provide compliant hosting with no US parent company exposure. We covered this in our EU Cloud Infrastructure Guide.

For a full sovereign SaaS deployment platform, sota.io provides EU-only infrastructure with GDPR, NIS2, and CRA-aligned data residency out of the box.

Key Resources

• EUR-Lex: CRA Full Text — Official regulation text
• ENISA CRA Implementation Guide — Practical guidance
• ENISA SBOM Good Practices — SBOM lifecycle documentation
• CycloneDX Standard — SBOM format specification
• SPDX Standard — SPDX 2.3 specification
• European Commission Notified Bodies Database (NANDO) — Find notified bodies for conformity assessment

Summary Checklist (Print Version)

By June 2026 (Required Now)

• CVD policy published at stable URL
• ENISA/CSIRT notification process defined and tested
• All distributed components identified (SDK, CLI, packages, agents)

By December 2027 (Full Compliance)

• Product classification confirmed (Default / Class I / Class II)
• Annex I Part I security requirements implemented
• SBOM generated and maintained per release
• Vulnerability updates committed for defined support period
• Technical documentation complete (Annex VII)
• Conformity assessment complete (self or notified body)
• Declaration of Conformity signed
• CE marking applied
• User documentation includes secure configuration instructions
• 10-year record retention system in place

This is the final post in our five-part EU CRA 2026 Update Series. For the full series:

1. EU CRA Vulnerability Disclosure June 2026
2. EU CRA Art.13 SBOM and Secure-by-Default
3. EU CRA Product Classes: Default, Class I and Class II
4. EU CRA vs NIS2 Dual Compliance Stack
5. EU CRA Compliance Finale: Complete SaaS Developer Toolkit 2026 (this post)

Next series: EU AI Act GPAI Developer Guide — Art.50 watermarking obligations effective 2 August 2026.