Architecture

BAUER GROUP's CRA automation is split across two repositories:

• CRA-specific workflows and actions live in SEC-CRACompliance (this repo)
• Generic actions (VEX generation, SBOM attestation) live in automation-templates

Consumer repositories (your products) call the CRA release workflow with a single uses: line.

┌──────────────────────────────────────────┐
│            Consumer Repo (Product)        │
│                                          │
│  uses: bauer-group/SEC-CRACompliance/    │
│        .github/workflows/cra-release.yml │
└──────────────────┬───────────────────────┘
                   │
    ┌──────────────┼──────────────┐
    ▼              ▼              ▼
┌─────────┐  ┌──────────┐  ┌────────────┐
│ CRA-Repo│  │ CRA-Repo │  │ Automation │
│ Actions │  │ Actions  │  │ Templates  │
├─────────┤  ├──────────┤  ├────────────┤
│ SBOM    │  │Compliance│  │ VEX        │
│ Sign    │  │ Report   │  │ Attestation│
│ Scan    │  │          │  │            │
│ Hub     │  │          │  │            │
└─────────┘  └──────────┘  └────────────┘
CRA-specific  CRA-specific    Generic

Reusable Workflows

cra-release.yml — Release Artifacts

The primary workflow. Generates, signs, and archives all CRA artifacts for a release.

Usage (zero-config):

jobs:
  cra:
    uses: bauer-group/SEC-CRACompliance/.github/workflows/cra-release.yml@main
    permissions:
      contents: write
      id-token: write
      attestations: write
      security-events: write

Usage (customised):

jobs:
  cra:
    uses: bauer-group/SEC-CRACompliance/.github/workflows/cra-release.yml@main
    with:
      run-validation: true
      validation-command: 'npm run ci'
      sign-sbom: true
      attest-sbom: true
      generate-vex: true
      generate-compliance-report: true
      support-period-years: 5
      fail-on-critical: true
    permissions:
      contents: write
      id-token: write
      attestations: write
      security-events: write

Pipeline flow:

cra-scan.yml — Scheduled Vulnerability Scan

For continuous CVE monitoring (Art. 10 Abs. 8). Run daily via cron schedule.

on:
  schedule:
    - cron: '0 6 * * *'

jobs:
  scan:
    uses: bauer-group/SEC-CRACompliance/.github/workflows/cra-scan.yml@main
    with:
      severity-threshold: MEDIUM
      fail-on-critical: false
      create-issue: true
    permissions:
      contents: read
      security-events: write
      issues: write

Features:

• Multi-engine scanning (Trivy + Grype + OSV-Scanner)
• Automatic GitHub Issue creation for CRITICAL findings
• SARIF upload to GitHub Security tab
• Configurable severity thresholds

cra-report.yml — Hub API Report

Sends compliance data to the Software Security Hub API for centralised tracking.

jobs:
  report:
    uses: bauer-group/SEC-CRACompliance/.github/workflows/cra-report.yml@main
    with:
      send-sbom: true
      send-vulnerabilities: true
      send-release-info: true

Complete Consumer Workflow

Minimal (Zero-Config)

Works out of the box for any repository. All features enabled with defaults.

# .github/workflows/cra.yml
name: CRA Compliance

on:
  release:
    types: [published]
  schedule:
    - cron: '0 6 * * 1'  # Weekly Monday 06:00 UTC
  workflow_dispatch:

permissions:
  contents: write
  id-token: write
  attestations: write
  security-events: write
  issues: write

jobs:
  # On release: Full CRA pipeline
  cra-release:
    if: github.event_name == 'release'
    uses: bauer-group/SEC-CRACompliance/.github/workflows/cra-release.yml@main
    permissions:
      contents: write
      id-token: write
      attestations: write
      security-events: write

  # Weekly: CVE scan
  cra-scan:
    if: github.event_name == 'schedule' || github.event_name == 'workflow_dispatch'
    uses: bauer-group/SEC-CRACompliance/.github/workflows/cra-scan.yml@main
    permissions:
      contents: read
      security-events: write
      issues: write

Full Configuration (all parameters)

For products with specific requirements — Node.js validation, Class I classification, Grype scanning, etc.

# .github/workflows/cra.yml
name: CRA Compliance

on:
  release:
    types: [published]
  schedule:
    - cron: '0 6 * * 1'
  workflow_dispatch:

permissions:
  contents: write
  id-token: write
  attestations: write
  security-events: write
  issues: write

jobs:
  # ── Release: Full CRA pipeline ──
  cra-release:
    if: github.event_name == 'release'
    uses: bauer-group/SEC-CRACompliance/.github/workflows/cra-release.yml@main
    with:
      # Validation
      run-validation: true              # Run lint/build before CRA artifacts
      node-version: '24'                # Node.js version for validation
      validation-command: 'npm run ci'  # Your validation command

      # SBOM & Scanning
      scan-target: '.'                  # Directory, image ref, or SBOM path
      scan-type: 'auto'                 # auto | fs | image | sbom
      sign-sbom: true                   # Cosign keyless signing
      fail-on-critical: true            # Block release on CRITICAL CVEs
      enable-grype: true                # Additional Grype scan
      enable-osv: true                  # Additional OSV-Scanner

      # Attestation & VEX
      attest-sbom: true                 # GitHub-native SBOM attestation
      generate-vex: true                # OpenVEX document
      vex-overrides: 'security/vex-overrides.json'  # Manual triage file

      # Compliance Report
      generate-compliance-report: true
      support-period-years: 5           # Art. 13(8): minimum 5 years

      # EU Declaration of Conformity
      generate-eu-doc: true             # Annex V JSON
      render-pdfs: true                 # JSON → PDF rendering
      classification: 'important-class-1'  # standard | important-class-1 | important-class-2 | critical
      conformity-module: 'module-a'     # module-a | module-b-c | module-h | eucc
      manufacturer-name: 'BAUER GROUP GmbH'

      # Release
      upload-to-release: true           # Attach all artifacts to GitHub Release
      retention-days: 90                # Artifact retention
    permissions:
      contents: write
      id-token: write
      attestations: write
      security-events: write

  # ── Weekly: CVE Scan ──
  cra-scan:
    if: github.event_name == 'schedule' || github.event_name == 'workflow_dispatch'
    uses: bauer-group/SEC-CRACompliance/.github/workflows/cra-scan.yml@main
    with:
      severity-threshold: 'MEDIUM'      # UNKNOWN | LOW | MEDIUM | HIGH | CRITICAL
      fail-on-critical: false           # Don't fail scheduled scans
      create-issue: true                # Create GitHub Issue for CRITICAL CVEs
      enable-grype: true
      enable-osv: true
    permissions:
      contents: read
      security-events: write
      issues: write

  # ── After Release: Report to Hub ──
  cra-report:
    if: github.event_name == 'release'
    needs: [cra-release]
    uses: bauer-group/SEC-CRACompliance/.github/workflows/cra-report.yml@main
    with:
      dry-run: true                     # Set false when Hub is operational
    permissions:
      contents: read
      id-token: write

Docker / Container Image

For products that build container images — scan the image instead of the filesystem.

jobs:
  cra-release:
    if: github.event_name == 'release'
    uses: bauer-group/SEC-CRACompliance/.github/workflows/cra-release.yml@main
    with:
      scan-target: 'ghcr.io/bauer-group/my-app:${{ github.ref_name }}'
      scan-type: 'image'
      classification: 'important-class-2'
    permissions:
      contents: write
      id-token: write
      attestations: write
      security-events: write

Product Config File (recommended)

Instead of passing all parameters in the workflow, create a cra-product.json in your repository root. The cra-eu-doc action reads it automatically:

{
  "$schema": "https://cra.docs.bauer-group.com/schemas/cra-product/v1.0.0",
  "product": {
    "name": "API-Gateway",
    "description": "REST API Gateway for BAUER GROUP services",
    "classification": "important-class-1",
    "conformityModule": "module-a"
  },
  "manufacturer": {
    "name": "BAUER GROUP GmbH",
    "address": "Street, City, Country"
  },
  "support": {
    "periodYears": 5,
    "until": "2031-12-31"
  },
  "contacts": {
    "securityEmail": "disclosure@bauer-group.com",
    "productOwner": "team@bauer-group.com"
  }
}

Parameter Reference

cra-release.yml

cra-scan.yml

Required Permissions

Release Artifacts

A fully configured CRA release produces:

# Cosign
cosign verify-blob --signature sbom.cdx.json.sig --certificate sbom.cdx.json.cert sbom.cdx.json

# GitHub Attestation
gh attestation verify sbom.cdx.json --repo owner/repo

VEX Triage

The VEX document auto-generates under_investigation statements for all found CVEs. To triage:

1. Create security/vex-overrides.json in your product repo
2. Add manual decisions for each CVE

{
  "@context": "https://openvex.dev/ns/v0.2.0",
  "statements": [
    {
      "vulnerability": { "@id": "CVE-2024-1234" },
      "products": [{ "@id": "pkg:github/your-org/your-repo" }],
      "status": "not_affected",
      "justification": "vulnerable_code_not_in_execute_path",
      "impact_statement": "Dependency imported but affected function never called."
    }
  ]
}

Compliance Scoring

The compliance report assigns a score out of 100:

8.1.1 Tool → CRA Compliance Matrix

This mapping shows which tool covers which CRA requirements.

8.1.2 GitHub Ecosystem

Dependabot

GitHub Security Advisories

GitHub Actions (Automation Templates)

8.1.3 Security Scanning

Trivy (Aqua Security)

Grype (Anchore)

OSV-Scanner (Google)

Snyk

Gitleaks + GitGuardian

8.1.4 SBOM & Compliance

Syft (Anchore)

FOSSA / License Compliance

8.1.5 Signing, Attestation & Integrity

Cosign (Sigstore)

GitHub Attestation (Sigstore via GitHub)

8.1.6 CRA Compliance Workflows (this repository)

In addition to the automation templates, this repository provides dedicated CRA workflows that can be reused in every source code repository. See 8.2 Automation Workflows for detailed usage.

Composite Actions (CRA-specific)

Composite Actions (Generic, in automation-templates)

Reusable Workflows

CLI Tool

8.1.7 Planned Extensions

8.1.8 Summary: CRA Coverage through Tooling

                         CRA Requirement
                    ┌─────────────────────────┐
                    │  Art. 10 (Manufacturer)   │
                    │  ├── (1) Security         │──→ Trivy, Gitleaks, Code Review
                    │  ├── (2) Risk             │──→ Manual + Template
                    │  ├── (4) 3rd Party        │──→ FOSSA, License Compliance
                    │  ├── (6) Vulnerabilities  │──→ CVE-Monitor, Dependabot
                    │  ├── (7) Updates          │──→ Dependabot, CI/CD
                    │  ├── (8) No CVEs          │──→ CVE-Monitor, Trivy
                    │  ├── (9) CVD              │──→ GitHub Advisories
                    │  ├── (12) Integrity       │──→ Cosign + Attestation
                    │  └── (16) Support         │──→ SECURITY.md
                    ├─────────────────────────┤
                    │  Art. 13 (Information)     │
                    │  ├── (6) CVD Policy        │──→ SECURITY.md
                    │  └── (23) SBOM            │──→ Trivy/Syft
                    ├─────────────────────────┤
                    │  Art. 14 (Reporting)       │
                    │  ├── 24h Early Warning     │──→ ENISA SRP + Teams
                    │  ├── 72h Notification      │──→ ENISA SRP
                    │  └── User Info            │──→ GitHub Advisory
                    └─────────────────────────┘

Overview

cra-check is a zero-dependency Node.js CLI tool that verifies whether a product meets CRA compliance requirements. It checks for the presence and quality of compliance artifacts — SBOM, VEX, vulnerability scans, security policies, and support period definitions.

Installation

No installation required. Run directly via npx:

npx @bauer-group/cra-check

Or install globally:

npm install -g @bauer-group/cra-check

Usage

# Check current directory
cra-check

# Check a specific directory
cra-check /path/to/project

# Check a GitHub repository (latest release)
cra-check bauer-group/my-product

# Check a specific release
cra-check bauer-group/my-product --release v2.0.0

# JSON output for automation
cra-check --format json

# CI mode (exit code 1 if below threshold)
cra-check --ci --min-score 70

Modes

Local Mode

Scans the filesystem for CRA artifacts:

Remote Mode

Fetches data from GitHub API:

• Downloads release assets (SBOM, VEX, vulnerability report)
• Checks for signature files in release
• Verifies SECURITY.md exists in repository
• Extracts support period from compliance report

export GITHUB_TOKEN=ghp_...
cra-check bauer-group/private-repo

Output

Terminal (default)

  CRA Compliance: my-product v2.3.1
  ══════════════════════════════════════════

  SBOM                ✅ PASS  CycloneDX, 142 components
  SBOM Signed         ✅ PASS  Cosign signature + certificate present
  VEX Document        ✅ PASS  15 statements (3 triaged)
  Vulnerabilities     ⚠️ WARN  0 critical, 2 high, 5 medium, 3 low
  Security Policy     ✅ PASS  SECURITY.md present with CVD process
  Support Period      ✅ PASS  5 years

  Score: 85/100 ████████████████░░░░ PASS

JSON (--format json)

{
  "$schema": "https://cra.docs.bauer-group.com/schemas/cra-check/v1.0.0",
  "product": { "name": "my-product", "version": "2.3.1" },
  "checks": [
    { "name": "SBOM", "status": "pass", "details": "CycloneDX, 142 components" }
  ],
  "complianceScore": {
    "score": 85,
    "maxScore": 100,
    "passed": true
  }
}

CI/CD Integration

GitHub Actions

- name: 🔍 CRA Compliance Check
  run: npx @bauer-group/cra-check --ci --min-score 70
  env:
    GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Exit Codes

Scoring

See Compliance Scoring for the full scoring algorithm.

Options

Requirements

• Node.js >= 20
• No npm dependencies (zero-dependency design)

Complete Mapping: CRA Article → Documentation → Tooling

This matrix maps each relevant CRA requirement to the corresponding documentation and implemented tooling. It serves as the central reference for audits and conformity assessments.

Detailed mapping: 8.1 Tooling Map (Tool → CRA Requirement)

Obligations by Economic Operator Role

Estimated Effort by Product Class

* Class I: self-assessment if harmonised standards are applied in full; third-party assessment otherwise.

Art. 10 – Obligations of Manufacturers

Art. 13 – Information Obligations

Art. 14 – Reporting Obligations

Art. 16 – Authorised Representative (EU Authorized Representative)

Art. 28 – Declaration of Conformity & CE

Annex I, Part I – Security Requirements

Annex I, Part II – Vulnerability Handling

Annex II – User Information

Annex VII – Technical Documentation

Legend

7.1.1 Overview

Every product with digital elements must be classified into a CRA risk category under the Cyber Resilience Act (CRA). The classification determines the required conformity assessment procedure. The CRA distinguishes four categories: Standard, Class I (Important), Class II (Important), and Critical.

7.1.2 Classification Decision Tree

The following decision tree outlines the systematic approach to product classification:

Is the product listed in Annex IV?
├── Yes → CRITICAL (EUCC required)
└── No
    └── Is the product listed in Annex III?
        ├── Yes → Which class?
        │   ├── Class II → CLASS II (Module B+C or H)
        │   └── Class I → CLASS I (Module A* or B+C)
        └── No → STANDARD (Module A)

* Module A only where harmonised standards are applied in full

7.1.3 Product Categories

Category: Standard (Default)

Conformity assessment: Internal control (Module A) -- Self-assessment

The majority of products fall into this category. The manufacturer carries out the conformity assessment themselves.

Typical Products:

• Standard web applications
• Internal tools and utilities
• Non-critical container images
• Simple IoT sensors

Class I (Annex III)

Conformity assessment: Internal control (Module A) with application of harmonised standards OR EU type examination (Module B+C)

Examples from Annex III:

• Identity management systems and software for privileged access
• Browsers (standalone)
• Password managers
• Software for searching, removing, and quarantining malware
• VPN products
• Network management systems
• SIEM systems
• Boot managers
• Firewalls, IDS/IPS (non-industrial)
• Routers, modems (for internet access)
• Microcontrollers with security-relevant functions
• Operating systems (not for server/desktop Class II)

Class II (Annex III)

Conformity assessment: EU type examination (Module B+C) OR Comprehensive quality assurance (Module H)

Examples from Annex III:

• Hypervisors and container runtime environments
• Firewalls and IDS/IPS for industrial use
• Tamper-resistant microcontrollers/microprocessors
• Operating systems for servers, desktops, mobile
• Public key infrastructure and certificate issuers
• Industrial automation and control systems (IACS)
• Industrial IoT devices (not subject to other sectoral regulation)

Category: Critical (Annex IV)

Conformity assessment: European cybersecurity certificate (EUCC) at assurance level "substantial" or higher

Examples from Annex IV:

• Hardware security modules (HSM)
• Smart cards and similar devices (incl. secure elements)
• Smart card readers
• Sensors and actuators for robots and machine controllers
• Smart meter gateways

7.1.4 Conformity Assessment by Category

* Only when applying harmonised standards or when conforming with EU cybersecurity certification

7.1.5 Relevant Product Types for BAUER GROUP

Review against Annex III (Important Products)

Review against Annex IV (Critical Products)

Typical Classification for BAUER GROUP Products

7.1.6 Classification Process

The following process must be carried out for each product:

1. Functional Review

Verify whether the product fulfils one of the functions listed in Annex III or IV. Systematically compare against all categories.

2. Intended Purpose

Consider the intended purpose:

• Is the product used in critical infrastructure?
• Does it process sensitive/personal data?
• Does it have network functionality?
• Could a compromise cause physical damage?

3. Document the Classification

Use the template Risk Assessment to document the classification decision.

7.1.7 Documentation of the Classification

For each product, the classification is documented in the Product Description:

1. Review against Annex III and IV -- Systematic comparison against all categories
2. Rationale -- Why this classification applies (with reference to the Annex)
3. Conformity Assessment procedure -- Which module is applied
4. Date -- When the classification was carried out
5. Responsible person -- Who carried out the classification

4.3.1 Legal Basis

Pursuant to Art. 14 CRA, manufacturers are required to report certain security events to ENISA or the competent national CSIRT authority. The reporting obligation applies from 11 September 2026.

4.3.2 Reportable Events

Actively Exploited Vulnerability (Art. 14(1))

A vulnerability in a BAUER GROUP product is being actively exploited in the wild. Pursuant to Art. 3(42) CRA, active exploitation exists when reliable evidence shows that the vulnerability has been exploited by a malicious actor in a system without the permission of the owner.

Indicators of active exploitation:

• Inclusion in the KEV catalog (CISA Known Exploited Vulnerabilities)
• Threat intelligence feeds report exploitation activity
• Report by customers or security researchers with evidence of exploitation
• Own detection in logs, monitoring or incident response processes
• Public reports (vendor advisories, blogs, forums) about attacks

Severe Security Incident (Art. 14(3))

An incident that significantly affects the security of the product or its users (Art. 3(43) CRA).

Criteria for classification as a severe incident:

4.3.3 Roles and Responsibilities

4.3.4 Reporting Platform

ENISA Single Reporting Platform (SRP)

From 11 September 2026, the ENISA Single Reporting Platform is available as the central reporting point:

National CSIRTs of EU Member States

If the ENISA SRP is temporarily unavailable, the notification shall be submitted to the competent national CSIRT. Below is the complete directory of all 27 EU Member States:

Source: ENISA CSIRTs Network / ENISA CSIRT Inventory. As of: 2026-02. Verify current contact details before initial notification.

4.3.5 Reporting Process

Phase 1: Early Warning (≤ 24 hours)

Responsible: Security Lead

Actively exploited vulnerability / severe incident detected
    │
    ├── 1. Immediate notification
    │   ├── Alert Security Lead (immediately, any time of day)
    │   └── Create incident ticket (GitHub Issue, label: incident + enisa)
    │
    ├── 2. Initial assessment (≤ 2 hours)
    │   ├── Confirm vulnerability / incident
    │   ├── Identify affected products and versions
    │   ├── Verify active exploitation (KEV, threat intel)
    │   ├── Determine severity (CVSS)
    │   └── Confirm ENISA reporting obligation
    │
    ├── 3. Submit ENISA early warning (≤ 24h)
    │   ├── Template: /templates/enisa-early-warning
    │   ├── Platform: ENISA SRP (primary) or CSIRT (fallback)
    │   └── Minimum content per Art. 14(1):
    │       ├── Manufacturer identification
    │       ├── Affected product / affected versions
    │       ├── Nature of the vulnerability / incident
    │       ├── Severity (CVSS score + vector)
    │       ├── Confirmation of active exploitation
    │       ├── Initial assessment of impact
    │       └── Planned immediate measures
    │
    └── 4. Parallel measures
        ├── Activate communication plan (→ 5.4)
        ├── Inform management (for SEV-1/SEV-2)
        └── Initiate immediate measures (workaround, isolation)

Evidence: Screenshot of notification confirmation + timestamp in incident ticket

Phase 2: Vulnerability Notification (≤ 72 hours)

Responsible: Security Lead + DevOps Lead

Detailed assessment in progress / completed
    │
    ├── 1. Deepen technical analysis
    │   ├── Complete version list of affected products
    │   ├── Assign CWE classification
    │   ├── Calculate complete CVSS v3.1 vector
    │   ├── Document attack vector and prerequisites
    │   └── Describe exploitation scenarios
    │
    ├── 2. Document measures
    │   ├── Mitigation measures already taken
    │   ├── Status of patch development
    │   ├── Available workarounds
    │   └── Recommended user measures
    │
    └── 3. Submit ENISA notification (≤ 72h)
        ├── Template: /templates/enisa-notification
        ├── Platform: ENISA SRP
        └── Minimum content per Art. 14(2):
            ├── Reference to early warning
            ├── Detailed vulnerability description
            ├── CVE-ID (if already assigned)
            ├── All affected product versions
            ├── CWE classification + CVSS vector
            ├── Technical details (attack vector, impact)
            ├── Status of mitigation measures taken
            ├── Available patch / workaround
            ├── Recommended user measures
            └── Estimated number of affected users / devices

Evidence: Notification confirmation + complete copy in incident ticket

Phase 3: Final Report (≤ 14 days)

Responsible: Security Lead

Remediation completed or well advanced
    │
    ├── 1. Prepare final documentation
    │   ├── Complete root cause analysis
    │   ├── Create complete incident timeline
    │   ├── List all measures taken
    │   ├── Identify patches / updates provided
    │   ├── Assess residual risks
    │   └── Formulate lessons learned
    │
    └── 2. Submit ENISA final report (≤ 14 days)
        ├── Template: /templates/enisa-final-report
        ├── Platform: ENISA SRP
        └── Minimum content per Art. 14(3):
            ├── Reference to early warning and notification
            ├── Detailed vulnerability description
            ├── Root cause analysis
            ├── Complete event timeline
            ├── All corrective measures taken
            ├── Patches / updates provided (with version numbers)
            ├── Residual risks and their mitigation
            ├── Indicators of compromise (IoC), if available
            ├── Lessons learned
            └── Measures to prevent future incidents

Evidence: Notification confirmation + complete copy in incident ticket + archiving

4.3.6 User Notification (Art. 14(8))

In parallel to the ENISA notification, affected users must be informed without delay about the vulnerability and available corrective measures.

4.3.7 Documentation and Record-Keeping

Each ENISA notification is fully documented. This documentation serves as evidence of compliance vis-a-vis market surveillance authorities (Art. 52 CRA).

Mandatory Documentation per Notification

Reference Numbering Scheme

All notifications use a uniform reference numbering scheme:

4.3.8 Preparatory Measures (before 11.09.2026)

The following measures must be completed before the reporting obligation enters into force:

4.3.9 Decision Tree: Reporting Obligation

Security event detected
    │
    ├── Is a vulnerability in our product affected?
    │   ├── No → No CRA reporting obligation (check NIS2 if applicable)
    │   └── Yes ↓
    │
    ├── Is the vulnerability being actively exploited?
    │   ├── Yes → REPORTABLE (Art. 14(1))
    │   │         → 24h early warning + 72h notification + 14d final report
    │   └── No ↓
    │
    ├── Is it a severe security incident?
    │   ├── Yes → REPORTABLE (Art. 14(3))
    │   │         → 24h early warning + 72h notification + 14d final report
    │   └── No ↓
    │
    └── Standard vulnerability handling
        → Vulnerability management (→ Chapter 3)
        → Patch management per SLA
        → No ENISA reporting obligation

Document Control

Note: This is the public version of this document. Personal data (names, contact details) are not included in this edition and are only available in the internal version.

Change History

Binding Nature

This handbook is binding for all employees of BAUER GROUP who are involved in the development, operation, distribution, or support of products with digital elements. Deviations from the processes described herein require written approval from the Security Lead and Management.

Regulation (EU) 2024/2847 – Cyber Resilience Act

The Cyber Resilience Act (CRA) is the EU regulation on horizontal cybersecurity requirements for products with digital elements. It was published in the Official Journal of the European Union on 20 November 2024 (OJ L, 2024/2847) and entered into force on 10 December 2024.

The CRA applies directly in all EU Member States and establishes binding obligations for manufacturers, importers, and distributors of products with digital elements.

Legal Characteristics

Purpose and Objectives

The CRA pursues two core objectives:

1. Security requirements for products (Annex I Part I) – Products with digital elements may only be made available on the EU market if they fulfil the essential cybersecurity requirements. This includes security-by-design, confidentiality, integrity, availability, and minimisation of the attack surface.

2. Vulnerability handling (Annex I Part II) – Manufacturers must systematically identify, document, assess, remediate, and report vulnerabilities to users and authorities throughout the entire support period (at least 5 years, Art. 13(8)).

Interplay with NIS2

The CRA complements the NIS2 Directive (Directive (EU) 2022/2555). While NIS2 governs the cybersecurity of operators of essential and important entities, the CRA addresses the security of the products used by those entities. The reporting obligations under the CRA (Art. 14) are modelled on the NIS2 reporting obligations (Art. 23 NIS2) and utilise the same ENISA reporting platform.

Scope

Pursuant to Art. 2 CRA, this regulation applies to products with digital elements whose intended or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network.

For BAUER GROUP, this concerns:

• Software – Standalone applications, microservices, APIs, container images
• Firmware – Embedded systems (ESP32, STM32, Zephyr RTOS)
• Libraries – Publicly published NPM and NuGet packages
• Hardware with Software – IoT devices, industrial controllers
• Remote Data Processing – Cloud components that are an integral part of a product

Detailed product categories and exemptions: see 1.1 Scope & Products.

Subpages of this Chapter

Structure of this Handbook

This handbook is structured according to the core processes of the CRA. Each chapter addresses a distinct compliance area with legal basis, process description, and operational implementation:

Toolchain

BAUER GROUP relies on a fully automated toolchain to ensure CRA conformity without additional manual effort:

Regulatory References

Terms and Definitions

Use this decision tree to determine whether the Cyber Resilience Act applies to your product and which conformity path to follow.

Decision Tree

Gate 1: Product with Digital Elements?

┌───────────────────────────────────────────────┐
│ Does the product contain digital elements?    │
│ (Software, firmware, or hardware with         │
│ logical data connection — Art. 3(1) CRA)      │
│                                               │
│   NO  → CRA not applicable → STOP            │
│   YES ↓                                      │
└───────────────────────────────────────────────┘

"Product with digital elements" means any software or hardware product and its remote data processing solutions, including software or hardware components being placed on the market separately (Art. 3(1) CRA).

Gate 2: Exemptions (Art. 2(2))

┌───────────────────────────────────────────────┐
│ Does any of the following exemptions apply?   │
│                                               │
│ ☐ Medical device (Reg. 2017/745, 2017/746)   │
│ ☐ Motor vehicle (Reg. 2019/2144)             │
│ ☐ Aviation (Reg. 2018/1139)                  │
│ ☐ Marine equipment (Dir. 2014/90/EU)         │
│ ☐ National security / military product       │
│ ☐ Pure SaaS without product component        │
│                                               │
│   YES → CRA not applicable (sector-specific  │
│          regulation applies) → STOP           │
│   NO  ↓                                      │
└───────────────────────────────────────────────┘

Gate 3: Open-Source Assessment (Art. 18–19)

┌───────────────────────────────────────────────┐
│ Is this open-source software?                 │
│                                               │
│   NO  → Continue to Gate 4 ↓                 │
│   YES → Is there a commercial activity?       │
│         (sale, paid support, monetised         │
│          integration, SaaS offering)           │
│                                               │
│     NO  → CRA not applicable → STOP          │
│     YES → Open-Source Steward obligations     │
│           apply (Art. 18–19) → Continue ↓    │
└───────────────────────────────────────────────┘

Gate 4: Product Classification (Art. 6–7, Annex III & IV)

┌───────────────────────────────────────────────┐
│ Is the product listed in Annex IV?            │
│                                               │
│   YES → CRITICAL                              │
│         → EUCC certification required         │
│         → See: Conformity / EUCC              │
│   NO  ↓                                      │
├───────────────────────────────────────────────┤
│ Is the product listed in Annex III?           │
│                                               │
│   YES → Which class?                          │
│     Class II → Module B+C or Module H         │
│                → See: Conformity / Module B+C  │
│     Class I  → Module A (with hEN) or B+C     │
│                → See: Conformity / Module A    │
│   NO  ↓                                      │
├───────────────────────────────────────────────┤
│ STANDARD (Default Category)                   │
│ → Module A (Self-Assessment)                  │
│ → See: Conformity / Self-Assessment           │
└───────────────────────────────────────────────┘

Results Summary

Estimated Compliance Effort

* Class I only requires third-party assessment if harmonised standards are not applied in full.

Next Steps

Based on your classification result:

1. Document the decision → Product Classification Record
2. Start conformity process → Conformity Assessment Overview
3. Prepare documentation → Technical Documentation
4. Set up reporting → ENISA Reporting Process

1. Product Identification

2. Scope Assessment

Scope Result: [ ] CRA applicable / [ ] CRA not applicable

If not applicable, state reason: ___

3. Product Classification

3.1 Annex IV Check (Critical Products)

Annex IV Result: [ ] Listed (→ Critical) / [ ] Not listed (→ continue)

3.2 Annex III Check (Important Products)

Annex III Result: [ ] Class II / [ ] Class I / [ ] Not listed (→ Standard)

3.3 Classification Result

4. Conformity Assessment Path

5. Approval

Overview

The Incident Response Framework covers the complete CRA reporting obligations. From 11 September 2026, manufacturers are required to report actively exploited vulnerabilities and severe security incidents to ENISA or the competent national authority.

Reporting Obligations Overview

Chapter Structure

1.14.1 Overview

The Cyber Resilience Act (CRA) and the NIS2 Directive (Directive (EU) 2022/2555) are complementary EU cybersecurity regulations. While the CRA regulates products, NIS2 concerns operators (essential and important entities). Companies such as BAUER GROUP can be subject to both regulations simultaneously.

The full NIS2 compliance documentation for BAUER GROUP is available at nis2.docs.bauer-group.com.

1.14.2 Delineation CRA vs. NIS2

1.14.3 Decision Tree: Which Regulation Applies?

Does BAUER GROUP manufacture products with digital elements?
├── Yes → CRA applies (as manufacturer)
│   └── Are the products SaaS (purely cloud-based)?
│       ├── Yes → CRA does NOT apply to SaaS
│       │   └── Check NIS2 (as operator)
│       └── No → CRA applies
└── No → CRA does not apply as manufacturer

Is BAUER GROUP an essential or important entity?
├── Yes → NIS2 applies (as operator)
│   └── Check sector (Annex I/II of NIS2)
└── No → NIS2 does not apply

1.14.4 Overlapping Requirements

Vulnerability Management

Synergy: CRA-compliant vulnerability handling largely satisfies NIS2 Art. 21 para. 2 (e) as well.

Reporting Obligations

CRA reporting process: ENISA Reporting Process

Supply Chain Security

Synergy: CRA-compliant supply chain processes also satisfy NIS2 Art. 21 para. 2 (d) supply chain requirements.

Incident Response

Gap: NIS2 explicitly requires business continuity and crisis management, while the CRA focuses on product security.

1.14.5 Combined Compliance Strategy

Step 1: Determine Scope

Step 2: Leverage Synergies

The following processes cover both regulations:

1. Vulnerability Management → Vulnerability Management
2. Incident Response → Incident Response
3. Supply Chain Security → Supply Chain
4. SBOM Management → SBOM & Signing

Step 3: NIS2-Specific Additions

NIS2 requirements that go beyond the CRA:

Step 4: Unified Reporting Processes

For companies subject to both regulations:

1. Joint initial assessment process for incidents
2. Parallel reporting to CRA and NIS2 bodies (until a unified platform is available)
3. Unified templates (ENISA Early Warning)
4. Documented decision logic: Which incident triggers which reporting obligation

1.14.6 Timeline

Overview

Securing the software supply chain is a core CRA requirement. Manufacturers must exercise due diligence when integrating third-party components and ensure the integrity of the entire supply chain.

Security Measures

Implemented Measures

Chapter Structure

Overview

Vulnerability management is one of the core obligations under the CRA. Manufacturers must identify, assess, remediate, and report vulnerabilities in their products throughout the entire support period.

Process Architecture

                         +---------------------+
                         |  SBOM (per release)  |
                         +----------+----------+
                                    |
              +----------+----------+----------+----------+
              v          v          v          v          v
    +--------------+ +--------+ +--------+ +--------+ +--------+
    |CVE Monitoring| |Dependa-| | Trivy  | |  OSV-  | | Grype  |
    |(daily SBOM)  | |  bot   | | Scan   | |Scanner | |(option)|
    |              | |(PR)    | |(CI/CD) | |(CI/CD) | |        |
    +------+-------+ +---+----+ +---+----+ +---+----+ +---+----+
           |             |          |          |          |
           +-------------+----------+----------+----------+
                                    v
                         +----------------------+
                         |  Triage & Assessment  |
                         |  (CVSS / Severity)    |
                         +----------+-----------+
                                    |
                   +----------------+----------------+
                   v                v                 v
         +-----------------+ +--------------+ +--------------+
         |  CRITICAL/HIGH   | |  MEDIUM/LOW  | |  No CVEs     |
         |  -> Immediate    | |  -> Planned  | |  -> Continue  |
         |     patch        | |  -> Next     | |    monitoring |
         |  -> ENISA report | |    release   | |              |
         |     if required  | |              | |              |
         +-----------------+ +--------------+ +--------------+

Chapter Structure

Responsibilities

9.1.1 Purpose

The CRA Compliance Statement is the public summary of all CRA compliance artefacts for a product. It serves as a central point of reference for customers, market surveillance authorities, and internal audits.

9.1.2 Generation Principle

                    ┌──────────────────────────┐
                    │  .compliance/             │
                    │  cra-statement.json       │
                    │  (Single Source of Truth)  │
                    └─────────┬────────────────┘
                              │
          ┌───────────────────┼───────────────────┐
          │                   │                   │
          ▼                   ▼                   ▼
┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐
│ Compliance Page │ │ CE Marking      │ │ Container Labels│
│ (HTML/PDF)      │ │ (About dialog,  │ │ (OCI annotations│
│ on portal       │ │  README, footer)│ │  Dockerfile)    │
└─────────────────┘ └─────────────────┘ └─────────────────┘
          │                   │                   │
          ▼                   ▼                   ▼
┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐
│ API endpoint    │ │ Simplified DoC  │ │ Release notes   │
│ for authorities │ │ (Annex VI)      │ │ snippet         │
└─────────────────┘ └─────────────────┘ └─────────────────┘

Generated Artefacts

CE Marking from JSON

The CE marking is generated from JSON fields and automatically placed at the configured locations (→ 7.7 CE Marking):

Generated CE marking:

  CE [1234]                              ← notified_body (if applicable)
  BAUER GROUP                            ← manufacturer.name
  Musterstraße 1, 12345 Musterstadt     ← manufacturer.address
  MinIO Gateway v2.1.0                   ← product.name + product.version

For container images, OCI labels are additionally generated:

LABEL org.opencontainers.image.ce-marking="conformant"
LABEL eu.cra.doc.url="https://go.bauer-group.com/cra-minio-gateway"
LABEL eu.cra.doc.version="1.0"
LABEL eu.cra.support.end="2031-03-01"

9.1.3 Required Content

The following information must be publicly accessible under the CRA and is consolidated in the statement:

9.1.4 Recommended Structure

A CRA Compliance Statement should contain the following sections:

1. Product Identification

• Product name, version, type (software / container / firmware)
• CRA product category (Standard / Class I / Class II / Critical)
• Unique identifier (e.g. package URL, container image reference)

2. Manufacturer Information

• Company, address
• Security contact (e.g. disclosure@bauer-group.com)
• Authorised representative (if applicable)

3. Conformity Status

• Applied conformity assessment procedure (→ Chapter 7)
• Link to the EU Declaration of Conformity (Annex V)
• CE marking: status and placement
• Date of last assessment

4. Security Documentation

Links to:

• SBOM (CycloneDX JSON)
• Vulnerability Disclosure Policy / SECURITY.md
• User information (Annex II)
• Technical documentation (where publicly available)

5. Support Period

• Start and end of the support period
• Current phase (Active Support / Security Support)
• Reference to update mechanism (→ 6.3 Update Mechanism)

6. Harmonised Standards

• Applied harmonised standards and technical specifications
• SBOM format standard (e.g. CycloneDX v1.5)

7. Vulnerability Management

• Reference to Vulnerability Disclosure Policy
• CVE monitoring status
• Patch SLAs (→ 3.3 Patch Management)

9.1.5 Example

A CRA Compliance Statement for a fictional product might look like this:

CRA COMPLIANCE STATEMENT

MinIO Gateway — Version 2.1.0

Date: 2026-03-01 | Manufacturer: BAUER GROUP

---

Field	Value
Product type	Container Image
CRA category	Standard
Conformity module	Module A (Internal Control)
CE marking	✅ In About dialog and documentation
EU Declaration of Conformity	[Link to DoC]
SBOM	[CycloneDX JSON — GitHub Release]
SECURITY.md	[Link]
User information (Annex II)	[Link]
Support period	2026-03-01 to 2031-03-01
Vulnerability disclosure	disclosure@bauer-group.com

9.1.6 Placement

→ Publication strategy details: 9.2 Publication Strategy

9.1.7 Cross-References

9.2.1 Dual Publication Concept

Compliance data is maintained in exactly one place — the respective product's repository. From there, it is automatically published to a central compliance website.

┌────────────────────┐                ┌──────────────────────────┐
│  Product Repo      │     CI/CD      │  Generated Artefacts     │
│                    │                │                          │
│  .compliance/      │  Validation    │  ┌── Compliance Portal   │
│    cra-statement.  │──────────────→│  │   (HTML/PDF)           │
│    json            │  + Generation  │  ├── CE Marking          │
│                    │                │  │   (About, README)      │
│  (single source)   │                │  ├── Container Labels    │
│                    │                │  │   (OCI annotations)    │
│                    │                │  ├── Simplified DoC       │
│                    │                │  └── API Endpoint         │
└────────────────────┘                └──────────────────────────┘
        ↑                                       ↑
   Developers maintain                 Customers, authorities,
   only the JSON                       public

9.2.2 Benefits

9.2.3 Repository Structure

Each product repository contains a .compliance/ directory:

product-repo/
├── .compliance/
│   ├── cra-statement.json          # Machine-readable CRA statement
│   └── README.md                   # Brief note on compliance structure
├── SECURITY.md                     # Vulnerability Disclosure Policy
├── docs/
│   └── compliance/
│       ├── eu-declaration.pdf      # EU Declaration of Conformity (Annex V)
│       └── user-info.md            # User information (Annex II)
└── ...

Files in Detail

9.2.4 Website URL Scheme

The central compliance portal follows a uniform URL structure:

https://cra.app.bauer-group.com/
├── /products/                      # Product directory
│   ├── /products/{name}/           # Product compliance page
│   │   ├── /cra                    # CRA Compliance Statement
│   │   ├── /doc                    # EU Declaration of Conformity
│   │   └── /sbom                   # SBOM download
│   └── ...
└── /api/                           # (Optional) API access for authorities
    └── /api/products/{name}.json   # Machine-readable access

9.2.5 Accessibility

9.2.6 CI/CD Integration

Publication is integrated into the existing CI/CD pipeline:

Release tag created
    │
    ├── 1. JSON schema validation (.compliance/cra-statement.json)
    │       → Failure = release blocked
    │
    ├── 2. Completeness check
    │       → Are all required fields populated?
    │       → Do referenced documents (DoC, SBOM) exist?
    │
    ├── 3. Publication to compliance portal
    │       → Generate HTML
    │       → Generate PDF (optional)
    │
    └── 4. Notification
            → Slack/Teams: "Compliance statement for {product} v{version} published"

9.2.7 Cross-References

Reporting a Vulnerability

BAUER GROUP takes the security of our products seriously. If you believe you have found a security vulnerability, please report it to us as described below.

Preferred Method: GitHub Security Advisory

For each affected repository, use Security → Advisories → New Draft Advisory to report the vulnerability confidentially.

Email

Email: disclosure@bauer-group.com

Please include:

• Description of the vulnerability
• Steps to reproduce
• Affected product(s) and version(s)
• Impact assessment (if possible)
• Your contact information

What to Expect

Our Commitment

• We will not take legal action against researchers acting in good faith
• We will acknowledge your contribution (with your permission)
• We will coordinate the disclosure timeline with you
• We will provide regular status updates

Supported Versions

Please refer to the individual product documentation for supported versions and support periods.

Scope

This policy applies to all BAUER GROUP products with digital elements, including:

• Software products (web applications, APIs, libraries)
• Container images
• Firmware (ESP32, STM32, Zephyr)
• Published packages (NuGet, NPM)

Out of Scope

• Social engineering attacks
• Denial of service attacks
• Physical attacks against infrastructure
• Vulnerabilities in third-party products (report to the respective vendor)

Regulatory Framework

This security policy complies with:

• Cyber Resilience Act (EU) 2024/2847 – Art. 13 (6) & (8)
• ISO/IEC 29147:2018 – Vulnerability Disclosure
• ISO/IEC 30111:2019 – Vulnerability Handling Processes

7.10.1 Overview

Annex II of the CRA defines the mandatory information that the manufacturer must provide to users of the product. This information must be clear, comprehensible, and made available in a manner that is easily accessible to the user.

7.10.2 Mandatory Content

No. 1 – Manufacturer Information

Requirement: Name, registered trade name or registered trade mark and postal address of the manufacturer.

Implementation at BAUER GROUP:

• In every product repository: README.md with manufacturer details
• On the product website: Legal notice / Imprint
• In the software: About dialog or footer
• In the documentation: Title page

Template specification:

Manufacturer: BAUER GROUP
Address:      [Company address]
E-Mail:       [Contact e-mail]
Web:          [Product URL]

No. 2 – Contact Point

Requirement: Single point of contact through which vulnerabilities can be reported, and the manufacturer's vulnerability handling policy.

Implementation at BAUER GROUP:

• SECURITY.md in every repository (Template)
• Contact: disclosure@bauer-group.com
• GitHub Security Advisories enabled
• Reference to Disclosure Policy

No. 3 – Product Identification

Requirement: Unique identification of the product: name, type, version, batch/serial number.

Implementation at BAUER GROUP:

• Semantic Versioning (SemVer) for all software
• Container image tags with SHA digest
• Release notes with version, date, and changelog
• SBOM contains unique product identification (CPE/PURL)

No. 4 – Intended Use

Requirement: Intended use of the product, including the security environment.

Implementation at BAUER GROUP:

• Product description (Reference): Purpose, target audience, deployment environment
• Operating conditions: Operating system, network, hardware requirements
• Security environment: Prerequisites (firewall, VPN, network segmentation)
• Limitations: Explicitly document what the product is NOT intended for

Example:

Intended use: Internal enterprise application for managing
[function]. Designed for operation behind a corporate
firewall with authenticated access.

NOT intended: Public-facing operation without network
protection, use in critical infrastructure (CRITIS).

No. 5 – Foreseeable Misuse

Requirement: Description of foreseeable misuse scenarios.

Implementation at BAUER GROUP:

• Identification of typical misuse scenarios per product type
• Warning notices in the documentation
• Technical safeguards against misuse

Typical misuse scenarios:

No. 6 – SBOM Reference

Requirement: Notice of the availability of the SBOM (or URL for retrieval).

Implementation at BAUER GROUP:

• SBOM published as a release asset
• URL to the SBOM in the product documentation
• SBOM in machine-readable format (CycloneDX JSON)

Template specification:

SBOM: Available at [Release-URL]/sbom.cdx.json
Format: CycloneDX JSON v1.6
Signed: Yes (Cosign)

Details: SBOM & Signing

No. 7 – Support Period

Requirement: Period during which security updates will be provided, at least 5 years or the expected product lifetime.

Implementation at BAUER GROUP:

• Support period documented in the product documentation
• In SECURITY.md per repository
• On the product website
• In the release notes

Details: Support & Lifecycle

No. 8 – Installation Guide and Secure Configuration

Requirement: Instructions for secure installation, configuration, commissioning, and use of the product.

Implementation at BAUER GROUP:

• Installation guide: Step-by-step with security notes
• Hardening guide: Recommended security configuration
• Checklist: Post-installation security checklist
• Minimum requirements: Documented system prerequisites

Contents of the installation guide:

1. System prerequisites (including security requirements)
2. Installation steps with integrity verification
3. Initial setup (password, MFA, network)
4. Recommended security configuration (hardening)
5. Update configuration (automatic/manual)
6. Backup setup

No. 9 – EU Declaration of Conformity

Requirement: Reference to the EU Declaration of Conformity or simplified version with URL.

Implementation at BAUER GROUP:

• URL to the EU Declaration of Conformity in the product documentation
• Simplified version according to Annex VI (-> Simplified DoC)

No. 10 – Update Information

Requirement: Information about the type and location of security updates.

Implementation at BAUER GROUP:

• Release channel documented (GitHub Releases, Container Registry, OTA)
• Notification channel (GitHub Watch, e-mail, RSS)
• Update instructions in the documentation

7.10.3 Template: User Information

Fillable template: User Information / Product Security Info

7.10.4 Checklist: Annex II

• [ ] Manufacturer details in the product and documentation
• [ ] SECURITY.md with contact point and CVD policy
• [ ] Unique product identification (SemVer, digest)
• [ ] Intended use documented
• [ ] Foreseeable misuse scenarios identified and addressed
• [ ] SBOM reference in the product documentation
• [ ] Support period defined and communicated
• [ ] Installation guide with security notes
• [ ] Reference to EU Declaration of Conformity
• [ ] Update information (channel, notification, instructions)

7.9.1 Overview

In addition to the full EU Declaration of Conformity (Annex V), the CRA permits a simplified version in accordance with Annex VI. This may accompany the product, provided the full version is available online.

7.9.2 When to Use the Simplified Version?

7.9.3 Mandatory Content (Annex VI)

The simplified EU Declaration of Conformity must contain at least:

1. Manufacturer Information

[Name of the manufacturer]
declares that the product with digital elements

2. Product Identification

[Product name, type, version]

3. Conformity Statement

is in conformity with the provisions of Regulation (EU) 2024/2847
(Cyber Resilience Act).

4. URL to the Full Declaration

The full EU Declaration of Conformity is available at:
[URL]

7.9.4 Template: Simplified EU Declaration of Conformity

## EU Declaration of Conformity (simplified)

**BAUER GROUP** hereby declares that the product

**[Product name] v[Version]**

is in conformity with the provisions of Regulation (EU) 2024/2847
(Cyber Resilience Act).

The full EU Declaration of Conformity is available at:
> [URL to full DoC]

Support period: [Date] to [Date]
Contact: [E-mail]

7.9.5 Placement

For Software Products

• README.md in the repository
• About dialog or footer in the application
• Release notes per version
• Product website
• Container image labels (OCI Annotations)

For Firmware / Hardware

• Packaging (print or insert)
• Quick Start Guide
• Product label (QR code with URL)

7.9.6 Example for Container Image Label

LABEL eu.cra.doc.url="https://go.bauer-group.com/cra-[product]"
LABEL eu.cra.doc.version="1.0"
LABEL eu.cra.support.end="2031-12-31"

7.9.7 Relationship to Annex V

Full version: EU Declaration of Conformity (Annex V)

Fillable template: EU Declaration of Conformity Template

4.4.1 Overview

The communication plan defines the internal and external communication channels for security incidents. The objective is rapid, consistent and legally compliant information sharing.

4.4.2 Communication Matrix

Internal Communication

External Communication

4.4.3 Communication Templates

Internal Initial Notification (Teams)

🚨 SECURITY INCIDENT – SEV-[1/2/3/4]

Product: [Product name] v[Version]
Vulnerability: [CVE-ID or brief description]
Severity: [CRITICAL/HIGH/MEDIUM/LOW]
Actively exploited: [Yes/No/Unknown]
ENISA reportable: [Yes/No]

Status: [Triage/Containment/Remediation/Closed]
Next steps: [Description]
Responsible: [Name]

Incident ticket: [Link to GitHub Issue]

External User Notification

Security Notice – [Product name]

Dear user,

we have identified and remediated a security vulnerability
in [Product name].

Affected versions: [Versions]
Fixed version: [Version]
Severity: [CRITICAL/HIGH]
CVE: [CVE-ID]

Recommended action:
Please update to version [X.Y.Z].

Details: [Link to Security Advisory]

For questions, please contact: disclosure@bauer-group.com

4.4.4 Escalation Paths

SEV-1 (Critical):
Developer → Security Lead → Management → ENISA (24h)
                                       → Users (without delay)

SEV-2 (High):
Developer → Security Lead → Management (info)
                          → Users (after fix)

SEV-3 (Medium):
Developer → Security Lead → Patch in next release

SEV-4 (Low):
Developer → Backlog → Regular release

4.4.5 Teams Integration

The existing Teams notification (teams-notifications.yml) is extended for security incidents:

• Incident Channel: Dedicated Teams channel for security incidents
• Automatic Alerts: For CRITICAL/HIGH CVE findings from the CVE monitor
• Status Updates: Automatic updates on status changes of the incident ticket

4.4.6 Documentation Requirement

All communication in the context of a security incident is documented:

• Timestamp of each communication
• Recipient and channel
• Content (summary)
• Confirmation of receipt

This documentation is part of the incident ticket and serves as evidence vis-a-vis supervisory authorities.

4.2.1 Coordinated Vulnerability Disclosure (CVD)

This policy defines the process for Coordinated Vulnerability Disclosure pursuant to CRA Art. 13(6) and ISO/IEC 29147:2018.

4.2.2 Scope

This policy applies to all products with digital elements of BAUER GROUP, including:

• Software products (web applications, APIs, libraries)
• Container images
• Firmware (ESP32, STM32, Zephyr)
• Publicly accessible services

4.2.3 Reporting Channels

1. GitHub Security Advisories (preferred)

For each repository: Security → Advisories → New Draft Advisory

Advantages:

• Confidential communication
• Integrated CVE assignment
• Patch coordination in private fork
• Structured capture

2. Email

Address: disclosure@bauer-group.com

• Encryption: PGP key in the repository (SECURITY.md)
• Language: German or English

3. SECURITY.md

Each repository contains a SECURITY.md with:

• Reporting channels
• PGP key (or link)
• Supported versions
• Response times

4.2.4 Process for External Reporters

What We Expect

Security researchers reporting vulnerabilities are asked to:

• Not disclose the vulnerability publicly before a fix is available
• Not exfiltrate or destroy any data
• Not conduct denial-of-service attacks
• Allow a reasonable timeframe for remediation

What We Commit To

Disclosure Timeline

Day 0:   Vulnerability reported
Day 2:   Acknowledgement of receipt
Day 7:   Initial assessment and severity classification
Day 14:  Status update to reporter
Day 28:  Status update to reporter
Day 60:  Patch should be developed
Day 90:  Coordinated Vulnerability Disclosure (default deadline)
         ├── Publish security advisory
         ├── Assign CVE-ID
         ├── Publish patch release
         └── Reporter credited in advisory (upon request)

4.2.5 Internal Process for Incoming Reports

External vulnerability report
    │
    ├── 1. Confirm receipt (≤ 48h)
    │   └── Automatically or by Security Lead
    │
    ├── 2. Triage (≤ 7 days)
    │   ├── Reproduce vulnerability
    │   ├── Assess severity (CVSS)
    │   ├── Identify affected products
    │   └── Check: Actively exploited?
    │       └── Yes → ENISA reporting obligation + accelerated fix
    │
    ├── 3. Patch development
    │   ├── Develop fix (if applicable in private fork)
    │   ├── Conduct tests
    │   └── Security review
    │
    ├── 4. Coordinated Vulnerability Disclosure
    │   ├── Agree on timing with reporter
    │   ├── Prepare security advisory
    │   ├── Request CVE-ID (via GitHub or MITRE)
    │   └── Prepare patch release
    │
    └── 5. Publication
        ├── Publish security advisory
        ├── Publish patch release
        ├── Update SBOM
        ├── Inform users
        └── Thank and credit reporter

4.2.6 Safe Harbor

BAUER GROUP will not take legal action against security researchers who:

• Act in good faith
• Comply with this Disclosure Policy
• Do not access, copy or destroy data without authorisation
• Do not impair services through denial-of-service
• Do not endanger affected third parties

4.2.7 Compliance References

9.3.1 Purpose

Machine-readable compliance data enables:

• Automated publication on the compliance portal (→ 9.2)
• Programmatic validation in CI/CD pipelines
• Aggregation across all products in a central dashboard
• Authority access via API for market surveillance authorities

9.3.2 JSON Schema

The CRA Compliance Statement follows a defined JSON schema:

{
  "$schema": "https://cra.app.bauer-group.com/schemas/cra-statement/v1.json",
  "schema_version": "1.0.0",

  "manufacturer": {
    "name": "BAUER GROUP",
    "address": "[Full postal address]",
    "contact_email": "disclosure@bauer-group.com",
    "website": "[URL]"
  },

  "product": {
    "name": "[Product name]",
    "version": "[X.Y.Z]",
    "type": "[software|container|firmware|embedded]",
    "description": "[Brief description]",
    "identifier": "[Package URL or container image reference]"
  },

  "cra_classification": {
    "category": "[standard|class_i|class_ii|critical]",
    "conformity_module": "[module_a|module_bc|module_h|eucc]",
    "notified_body": "[Name and identification number, or null]"
  },

  "conformity": {
    "declaration_url": "[URL to full DoC (Annex V)]",
    "declaration_date": "[YYYY-MM-DD]",
    "ce_marking": true,
    "ce_marking_placement": "[about_dialog|documentation|website|container_label]",
    "last_assessment_date": "[YYYY-MM-DD]"
  },

  "security_documentation": {
    "sbom_url": "[URL to SBOM (CycloneDX JSON)]",
    "sbom_format": "CycloneDX",
    "sbom_version": "1.5",
    "security_policy_url": "[URL to SECURITY.md]",
    "user_info_url": "[URL to user information (Annex II)]",
    "disclosure_contact": "disclosure@bauer-group.com"
  },

  "support_period": {
    "start_date": "[YYYY-MM-DD]",
    "end_date": "[YYYY-MM-DD]",
    "phase": "[active|security|eol]",
    "update_mechanism": "[auto|manual|notification]"
  },

  "harmonised_standards": [
    {
      "identifier": "[e.g. EN XXXXX:YYYY]",
      "description": "[Description]"
    }
  ],

  "metadata": {
    "generated_at": "[ISO 8601 timestamp]",
    "generator": "[Tool or manual]",
    "statement_version": "[Version of the statement]"
  }
}

9.3.3 Field Overview

Required Fields

Optional Fields

9.3.4 Validation

CI/CD Pipeline