EU CRA Security Requirements Art.13 2026: SBOM, Secure-by-Default and What Every SaaS Developer Must Implement

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

The EU Cyber Resilience Act's Article 13 contains the essential cybersecurity requirements that manufacturers must satisfy before placing products with digital elements on the EU market. With the 11 June 2026 vulnerability reporting obligation now two weeks away, many SaaS developers are scrambling to understand exactly what these requirements mean in practice — and, crucially, whether their product is even in scope.

This guide dissects the Art.13 / Annex I requirements, explains the SBOM mandate, unpacks the secure-by-default rules, and gives you a concrete 30-day implementation checklist.

Is Your SaaS Product in Scope for CRA Art.13?

This is the most misunderstood aspect of the CRA. The regulation covers products with digital elements — a defined term that includes both hardware and standalone software. Pure SaaS services (software delivered as a cloud service where the customer only interacts via a browser) are expressly excluded from CRA product requirements.

However, you are in scope if your business ships any of the following:

The CRA uses a functional test: if end users download, install, or run a software artefact on their own hardware or infrastructure, that artefact is a "product with digital elements" subject to Annex I requirements.

The SaaS grey zone: Many modern SaaS companies ship both — a cloud service (excluded) and a CLI, Docker image, or SDK that customers use to interact with that service (included). The downloadable artefact alone triggers CRA obligations even if the underlying cloud service does not.

CRA Annex I — The Two Parts

Article 13 mandates compliance with Annex I, which is divided into two parts:

Annex I, Part I — Security properties of the product itself (the "essential requirements")
Annex I, Part II — Vulnerability handling requirements (the "essential requirements for vulnerability management")

Annex I Part I: Essential Product Security Requirements

These are the baseline security properties your product must embody:

1. No Known Exploitable Vulnerabilities at Release

Products must be placed on the market without known exploitable vulnerabilities. This is a conformity obligation, not just a best-efforts target. Practically, it requires:

• Automated SAST scanning integrated into CI/CD (SonarQube, Semgrep, CodeQL)
• SCA scanning for dependency vulnerabilities (OWASP Dependency-Check, Snyk, Trivy)
• Passing a defined vulnerability threshold as a release gate
• Documented evidence of scanning results retained for the conformity assessment file

2. Secure by Default Configuration

This is one of the CRA's most actionable requirements. Products must ship in a secure configuration by default. Specific prohibitions include:

• No hardcoded credentials — no default usernames/passwords, API keys, or secrets baked into the product
• No unnecessary services or features enabled by default — principle of minimal functionality
• No insecure network protocols enabled by default — Telnet, FTP, HTTP (without TLS) must be disabled
• Privileged access must require explicit user action to enable

For CLI tools and SDKs this means: no DEBUG=true defaults, no telemetry enabled by default without opt-in, no insecure TLS verification disabled by default.

3. Confidentiality and Integrity Protection

Products must protect confidentiality and integrity of data they process or transmit:

• Data at rest: encryption requirements for sensitive data stored by the product
• Data in transit: TLS 1.2+ mandatory, TLS 1.3 strongly recommended
• Authentication: multi-factor authentication support where technically appropriate
• Session management: secure token storage, session expiry, replay protection

4. Minimal Attack Surface

The principle of "minimisation of attack surface" requires:

• Only expose interfaces and functions necessary for the product's intended purpose
• Disable unused ports, protocols, and services
• Principle of least privilege for all product components and service accounts
• Regular review and reduction of exposed functionality

5. Data Minimisation

Products must collect and process only the data necessary for the intended purpose. This aligns with GDPR's data minimisation principle and extends it to security requirements:

• Telemetry must be minimal by default
• Logs must not capture sensitive user data beyond operational necessity
• Retention periods for collected data must be defined and enforced

6. Resilience and Availability

Products must be designed to limit the impact of security incidents:

• Graceful degradation when components fail
• Denial-of-service resilience (rate limiting, resource quotas)
• Recovery procedures documented and tested

7. Integrity Monitoring and Tamper Evidence

Products must be able to detect when their security-relevant data has been tampered with:

• Code signing for software artefacts (binaries, packages, container images)
• Signature verification before execution or installation
• Audit logging for security-relevant events (immutable, tamper-evident)

8. Security Updates Without Delay

Products must be capable of receiving security patches and manufacturers must provide them "without delay" when vulnerabilities are discovered. The CRA does not define a specific maximum patching timeframe, but ENISA guidance suggests 14 days for critical vulnerabilities as a reference point.

Annex I Part II: Vulnerability Handling Requirements

Part II operationalises the vulnerability management obligations:

1. SBOM — Software Bill of Materials

This is the most technically specific requirement in Annex I. Manufacturers must identify and document vulnerabilities in components included in the product. The SBOM requirement (Art.13(6)) specifies:

Manufacturers shall identify and document components contained in the product with digital elements, including by drawing up a software bill of materials in a commonly used and machine-readable format covering at minimum the top-level dependencies of the products.

What "top-level dependencies" means in practice:

• Your direct dependencies (what you import directly), not transitive dependencies
• For a Node.js CLI: everything in dependencies and devDependencies used at runtime
• For a Docker image: all packages installed in the final layer
• For a Python SDK: everything in install_requires

Accepted SBOM formats:

Most build tools now support SBOM generation natively:

# Docker — generate CycloneDX SBOM for an image
docker sbom my-image:latest --format cyclonedx > sbom.json

# Node.js — generate SBOM using @cyclonedx/cyclonedx-npm
npx @cyclonedx/cyclonedx-npm --output-format JSON --output-file sbom.json

# Python — generate using cyclonedx-py
pip install cyclonedx-bom
cyclonedx-bom analyse -r -e requirements.txt -o sbom.json

# Go — generate using syft
syft packages dir:. -o cyclonedx-json > sbom.json

# Generic — using syft (works for most languages)
syft scan path/to/source -o cyclonedx-json=sbom.cyclonedx.json

Where to publish the SBOM:

The CRA does not require public disclosure of the SBOM (that would create security risks by advertising exploitable components). Requirements:

• Include with product documentation delivered to customers
• Make available to market surveillance authorities on request
• Include in the technical documentation file for conformity assessment
• Keep updated with each new product version

2. Address Vulnerabilities Without Delay

When a vulnerability is identified in a product already on the market, the manufacturer must:

• Remediate the vulnerability
• Release a security patch
• Communicate the fix to users through the established disclosure channel

The timeline obligation is "without undue delay" — interpreted as proportional to severity. Critical (CVSS 9+): 24–72 hours for interim mitigation, patch within 14 days. High (CVSS 7–8.9): patch within 30 days. Medium/Low: patch within 90 days.

3. Coordinated Vulnerability Disclosure Policy

Manufacturers must establish a coordinated vulnerability disclosure policy (security.txt at minimum) and have processes to:

• Receive vulnerability reports from third parties
• Acknowledge receipt within 72 hours
• Provide status updates to reporters
• Give credit to reporters (unless they request anonymity)

As covered in detail in EU CRA Vulnerability Disclosure June 2026, this also includes the 24h/72h mandatory reporting to ENISA's EUVDB portal.

4. Security Updates Post-End-of-Support

The CRA requires manufacturers to provide security updates for a period at least equal to the product's expected useful life, or for 5 years (whichever is shorter). After end-of-support, the product must clearly communicate that security updates are no longer available.

Implementing SBOM in CI/CD

Integrating SBOM generation into your pipeline:

# GitHub Actions — SBOM generation on every release
name: Generate SBOM on Release

on:
  release:
    types: [published]

jobs:
  sbom:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Install Syft
        uses: anchore/sbom-action/install-syft@v0
      
      - name: Generate SBOM
        run: |
          syft scan . \
            -o cyclonedx-json=sbom.cyclonedx.json \
            -o spdx-json=sbom.spdx.json
      
      - name: Upload SBOM to Release
        uses: softprops/action-gh-release@v1
        with:
          files: |
            sbom.cyclonedx.json
            sbom.spdx.json
      
      - name: Archive SBOM for Compliance
        uses: actions/upload-artifact@v4
        with:
          name: sbom-${{ github.sha }}
          path: sbom.*.json
          retention-days: 2190  # 6 years (CRA retention)

Secure-by-Default Checklist for SaaS Developers

# Check 1: No default credentials in your Docker image
docker run --rm your-image printenv | grep -iE "password|secret|key|token" 
# Should return nothing sensitive

# Check 2: No hardcoded secrets in code
grep -rE "(password|secret|api_key|token)\s*=\s*['\"][^'\"]{8,}" src/
# Should return nothing

# Check 3: TLS enforced in default config
grep -rE "http://" config/
# Should only show non-production URLs

# Check 4: Minimal ports exposed in Docker
docker inspect your-image | jq '.[0].Config.ExposedPorts'
# Should only show required ports

# Check 5: Non-root user in container
docker inspect your-image | jq '.[0].Config.User'
# Should not be "root" or ""

# Check 6: Read-only filesystem where possible
grep -E "ReadonlyRootfs" docker-compose.yml
# Best practice: ReadonlyRootfs: true

The CRA Technical Documentation File

Beyond SBOM and secure-by-default, Art.13 requires manufacturers to maintain a technical documentation file that includes:

• General description of the product and its intended purpose
• Design and development documentation (architecture, data flows)
• Information on vulnerabilities discovered and addressed
• Test results (including penetration test summaries for Class II products)
• EU Declaration of Conformity
• SBOM (current version)
• Security update procedures and end-of-support commitment

This file must be kept for 10 years after the product is placed on the market and made available to market surveillance authorities within 10 working days of a request.

CRA Product Classes and Conformity Assessment

Not all products face the same conformity assessment route:

Default Products (unlisted in Annex III):

Most CLI tools, SDKs, and developer-facing software fall here. Conformity assessment can be done via self-assessment (EU Declaration of Conformity) without involving a notified body. You assess your own compliance against Annex I and sign the declaration.

Important Class I Products (Annex III Part I):

Includes identity management software, password managers, VPNs, network monitoring tools, firewalls, operating systems, hypervisors, containers. These require either third-party audit (notified body) OR self-assessment using a harmonised EU standard (EN 18045 / Common Criteria).

Critical Class II Products (Annex III Part II):

Includes hardware security modules, secure elements, routers/switches at critical infrastructure level, industrial control software. These always require assessment by a notified body — self-assessment is not permitted. The notified body market becomes active from 11 June 2026.

30-Day CRA Art.13 Implementation Roadmap

Week 1 (Days 1–7): Scope and Inventory

• Audit all artefacts your company ships: CLI tools, SDKs, mobile apps, Docker images, desktop apps
• Determine which are "products with digital elements" under CRA
• Classify each product against Annex III (default / Class I / Class II)
• Identify the "manufacturer" legal entity for each product (EU-based entity or EU authorised representative)
• Map the expected support lifecycle for each product (for end-of-support commitments)

Week 2 (Days 8–14): SBOM and Vulnerability Baseline

• Select SBOM tooling (Syft, CycloneDX, SPDX)
• Integrate SBOM generation into CI/CD pipeline for each in-scope product
• Run SCA scan on all products, document all known vulnerabilities
• Triage known vulnerabilities: fix critical/high before next release, document medium/low with remediation timeline
• Create initial SBOM for current released version of each product

Week 3 (Days 15–21): Secure-by-Default Audit

• Audit all default configurations: disable any insecure defaults
• Rotate or remove any hardcoded credentials
• Enforce non-root container execution
• Enable TLS-only for all network interfaces by default
• Implement code signing for distributed artefacts (GPG, cosign for containers)
• Add security.txt to all product documentation sites

Week 4 (Days 22–30): Documentation and Processes

• Draft EU Declaration of Conformity for each product (template available from EU Commission)
• Compile technical documentation file for each product
• Establish vulnerability disclosure process (intake, acknowledgment, timeline SLAs)
• Register on ENISA EUVDB portal for the 11 June 2026 reporting obligation
• Brief engineering team on Art.13 obligations and new CI/CD gates
• Schedule quarterly compliance reviews

What Happens If You Are Non-Compliant?

The CRA enforcement framework is still being implemented at national level, but the penalty regime is clear:

Market withdrawal: Non-compliant products can be withdrawn from the EU market by national market surveillance authorities without compensation.

Administrative fines:

• Non-compliance with essential requirements (Annex I): up to €15,000,000 or 2.5% of global annual turnover (whichever is higher)
• Non-compliance with vulnerability reporting (Art.14/11 June 2026 obligation): up to €10,000,000 or 2% of global annual turnover
• Providing false information to authorities: up to €5,000,000 or 1% of global annual turnover

Fines are levied per infringement, not per product. Repeated violations attract multiplied penalties.

sota.io: EU-Sovereign Deployment for CRA-Compliant Products

When you deploy your CRA-compliant product, the hosting infrastructure matters too. sota.io gives you:

• Hetzner Germany infrastructure — no US parent, no CLOUD Act exposure
• Git-push deploys — your CI/CD pipeline including SBOM generation integrates seamlessly
• Container-native — Docker images deployed directly, your security controls preserved
• EU GDPR baseline — DPA in Germany, standard contractual clauses included
• No vendor lock-in — your artefacts, your SBOM, your deployment

Start deploying EU-compliant →

Key Takeaways

1. Scope check first: Pure SaaS is likely out of CRA scope, but any downloadable artefact (CLI, SDK, Docker image, mobile app) triggers Art.13 obligations.

2. SBOM is mandatory for in-scope products, in CycloneDX or SPDX format, covering at minimum top-level dependencies. Integrate SBOM generation into your release pipeline now.

3. Secure-by-default prohibits hardcoded credentials, insecure defaults, and unnecessary exposed services. Audit your default configurations before your next release.

4. Technical documentation file must be maintained for 10 years and be available to authorities within 10 working days.

5. Classification matters: Most developer tools self-assess. Identity, security, and network tools may require third-party audit from a notified body active from 11 June 2026.

6. The June 2026 deadline (Art.14 vulnerability reporting) is already here — your EUVDB registration and reporting process must be live regardless of your Annex I compliance status.

Next in the EU-CRA-2026-UPDATE Series: EU CRA Product Classes Explained: Which CRA Rules Apply to Your SaaS in 2026 — a decision-tree guide to navigating Annex III classification.