CRA Art.8: Open-Source Software Steward Obligations — What Foundations and Maintainers Must Do (Developer Guide 2026)

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

The EU Cyber Resilience Act (Regulation (EU) 2024/2847, "CRA") entered into force on 10 December 2024. One of its most discussed design choices is how it treats the open-source ecosystem. A strict reading of "manufacturer" would capture every project that distributes software — including volunteer-maintained libraries that millions of commercial products depend on. The EU legislator chose a different path.

Article 8 creates an intermediate category: the open-source software steward. Stewards face lighter obligations than manufacturers — no conformity assessment, no CE marking, no full Annex I compliance burden. But they are not entirely exempt either. Article 8 sets out a targeted set of security-process obligations that apply specifically to organisations that systematically maintain open-source software used commercially.

This guide explains:

• The three-tier CRA structure for open-source (no obligations → steward → manufacturer)
• The legal definition of "open-source software steward" under Art.3(14)
• Every obligation Article 8 imposes, paragraph by paragraph
• How to determine whether your organisation is a steward or a manufacturer
• Practical implementation steps for foundations and maintainers

The Three-Tier Structure

The CRA does not treat all open-source actors equally. The regulation creates three distinct tiers with different obligations:

The key insight is that the CRA targets commercial activity. If your open-source project is used commercially by others but you yourself are not commercialising it, you may fall under the steward tier rather than full manufacturer obligations.

What Article 3(14) Says: The Legal Definition

Article 8 obligations apply to open-source software stewards as defined in Article 3(14) of the CRA:

"open-source software steward" means a legal person, other than a manufacturer, that has the purpose or objective to systematically provide support on a sustainable basis for the development of specific products with digital elements qualifying as free and open-source software that are not intended for commercial activities by the legal person, and that ensures the viability of those products.

Break down each element:

1. "Legal person, other than a manufacturer"

A steward must be a legal entity — a foundation, association, company, or other incorporated body. Individual developers are not stewards under this definition. If you contribute to open-source as a private individual, Article 8 does not apply to you at all.

The exclusion "other than a manufacturer" is critical: if your legal entity also places commercial products on the EU market, you are a manufacturer for those products — Article 8 applies only to your stewardship activities, not to your commercial products.

2. "Systematically provide support on a sustainable basis"

Ad-hoc or occasional involvement does not make you a steward. The CRA requires systematic support — structured, ongoing activity such as:

• Maintaining a project repository and release pipeline
• Publishing security advisories and coordinating vulnerability disclosure
• Managing contributor agreements and governance
• Providing infrastructure (CI/CD, registries, package distribution)

"On a sustainable basis" implies an organisational commitment rather than voluntary best-effort. A foundation with a board, a budget, and defined project governance meets this threshold. An informal GitHub organisation probably does not.

3. "Not intended for commercial activities by the legal person"

This is the bright-line test. The software must not be intended for the steward's own commercial activities. A Linux Foundation-style organisation that does not sell the software it stewards qualifies. A company that maintains an open-source project while also selling commercial extensions, support contracts, or SaaS based on it falls into the manufacturer tier for those commercial products.

Note: the fact that others commercialise the software does not disqualify the steward. The test is whether the steward itself engages in commercial activity with the specific software.

4. "Ensures the viability of those products"

The steward must take active responsibility for the project's continuity. This distinguishes stewards from mere distributors or mirrors. Viability encompasses:

• Long-term maintenance and security updates
• Governance structures that prevent single-point-of-failure abandonment
• Community management and contributor retention

Article 8 Obligations: Paragraph by Paragraph

Article 8(1) — Cybersecurity Policy

Open-source software stewards shall put in place and document a cybersecurity policy to foster the development of a secure product with digital elements, in particular by encouraging the reporting of vulnerabilities.

This is the core obligation. Stewards must create and maintain a written cybersecurity policy that covers:

Required elements of the cybersecurity policy:

Unlike the full Annex I obligations that apply to manufacturers, Article 8(1) does not specify technical security requirements for the software itself. It focuses on the process — how the steward manages security as an organisational activity.

Practical implementation: A documented security policy published on your project website or repository, combined with a SECURITY.md file in each maintained project, satisfies the documentation requirement in most cases. The policy must be genuine and followed — not a paper exercise.

Article 8(2) — Cooperation with Manufacturers

Open-source software stewards shall cooperate with the manufacturers integrating their software into products with digital elements, in order to enable those manufacturers to comply with their obligations under this Regulation.

Article 8(2) creates a cooperation duty: when a manufacturer integrates your open-source component into a commercial product and needs information to complete their conformity assessment, you must cooperate with them.

In practice, this means:

• Providing technical documentation about the component's security properties when requested
• Sharing information about known vulnerabilities or security limitations
• Participating in vulnerability coordination when a manufacturer discovers an issue in your component
• Providing or supporting SBOM generation for components you maintain

This is not a burden to create documentation proactively for every possible integrator — it activates when a manufacturer specifically requests information to support their CRA compliance.

What manufacturers can legitimately request: Security architecture documentation, list of known vulnerabilities, information about cryptographic implementations, dependency manifests. Manufacturers cannot demand that stewards create new documentation that did not previously exist, but stewards must share what they have.

Article 8(3) — Cooperation with Market Surveillance Authorities

Open-source software stewards shall, upon request, cooperate with the market surveillance authorities competent for their products with digital elements.

Market surveillance authorities (MSAs) — the national bodies responsible for CRA enforcement — can request information from stewards when investigating a product that incorporates their software. Article 8(3) establishes the steward's obligation to cooperate with those requests.

This is standard public law cooperation: regulatory bodies have investigative powers, and organisations operating in their jurisdiction must respond. The obligation mirrors what applies to manufacturers under Art.14 and distributors under Art.17.

Practical implication: Maintain records of your security decisions, vulnerability handling history, and communications with manufacturers. If an MSA investigates a product that uses your software, you should be able to respond to information requests within reasonable timeframes.

Article 8(4) — Reporting Actively Exploited Vulnerabilities

Open-source software stewards shall, without undue delay, inform the relevant national CSIRTs for the purposes of coordinated vulnerability disclosure... of any actively exploited vulnerability in a product with digital elements qualifying as free and open-source software that they maintain.

When a steward learns of an actively exploited vulnerability in software they maintain, they must report it to the relevant CSIRT (Computer Security Incident Response Team) for coordinated vulnerability disclosure. The CRA routes this reporting through ENISA's coordinated disclosure system.

Reporting threshold: The trigger is "actively exploited" — a vulnerability that is being used in real attacks, not merely a theoretical or disclosed-but-unexploited finding. This is a narrower trigger than the manufacturer's obligation under Art.14(3) which covers "severe incidents having an impact on the security."

Where to report: ENISA maintains a list of national CSIRTs. For Germany: BSI (Bundesamt für Sicherheit in der Informationstechnik). The CRA establishes a single-entry-point system via ENISA's European vulnerability database (EVD).

Timeline: "Without undue delay" — the CRA does not specify a fixed deadline for steward reporting in Article 8(4) (unlike the 24h/72h timelines for manufacturers under Art.14). Industry guidance generally treats "without undue delay" as requiring notification within 72 hours of becoming aware that exploitation is occurring.

What Stewards Are NOT Required to Do

Equally important as understanding Article 8 obligations is understanding what does not apply to stewards. Article 8(5) explicitly states:

Open-source software stewards shall not be subject to the obligations laid down in Articles 13, 14, 15, 16, 17, 18, 19, 21, 23 and 25 and Annex I.

This exclusion covers:

The key freedoms stewards retain: You can distribute open-source software without CE marking it. You do not need to run a formal conformity assessment. You do not need to prepare a Declaration of Conformity. These are obligations of the manufacturers who integrate your component into commercial products — not yours.

Steward vs. Manufacturer: The Critical Distinction

The most important practical question for any open-source organisation is: which tier do we fall into?

The Commercial Activity Test

The decisive factor is whether your organisation engages in commercial activity with the software in question. The CRA defines "commercial activity" broadly — it is not limited to direct sales. Commercial activity includes:

• Selling the software or subscriptions
• Charging for support contracts or professional services related to the software
• Operating a SaaS platform built on the software
• Licensing commercial extensions or plugins

Grey areas that require legal analysis:

The "Intended for Commercial Activity" Test

The Art.3(14) definition asks whether the software is "not intended for commercial activities by the legal person." This is a purpose test applied to the steward, not a use test applied to the software's downstream consumers.

If you are an NPO whose sole purpose is maintaining open-source projects, and those projects are used commercially by third parties (but not by you), you satisfy this test. If your organisation's commercial products depend on the very software you maintain as "steward," regulatory scrutiny will focus on whether the stewardship and commercial activities are genuinely separated.

Practical Checklist: Are You a Steward?

□ Your organisation is a registered legal entity (foundation, association, company)
□ You systematically maintain one or more open-source projects
□ Your maintenance activities are structured and ongoing (not ad-hoc)
□ The maintained software is freely available under OSI-approved license
□ Your organisation does not sell the software itself
□ Your organisation does not operate commercial services primarily based on the software
□ Your organisation's revenues come from donations, grants, membership fees — not product sales
□ The software is intended to remain open-source with no commercial exclusivity

If all boxes are checked: you are likely a steward under Art.8. If some boxes are checked: you need legal analysis of the mixed-activity scenario. If you sell products that incorporate your maintained software: you are a manufacturer for those products.

Implementation Guide for Open-Source Stewards

Step 1: Document Your Cybersecurity Policy

Create a security policy document — this is the primary obligation under Art.8(1). The document should live in an accessible location (project website, repository).

Template structure:

# Security Policy — [Project Name]

## Scope
This policy covers security for [Project Name] maintained by [Organisation].

## Secure Development Practices
- Code review required for all pull requests
- Automated dependency vulnerability scanning via [tool]
- Regular security-focused releases for [LTS branches]

## Vulnerability Reporting
Security vulnerabilities should be reported to: security@yourorg.org
PGP Key: [fingerprint] available at [URL]
We acknowledge reports within 48 hours.

## Disclosure Timeline
- Day 0: Report received, acknowledgement sent
- Day 1-14: Initial triage and severity assessment
- Day 14-90: Fix development (timeline depends on severity)
- Day 90: Public disclosure if fix is ready; coordinated extension if not

## Dependency Management
We monitor dependencies via [tool/process].
Critical CVEs in dependencies trigger [response process].

## CVE Assignment
[Organisation] is a CNA (CVE Numbering Authority) for [scope].
OR: We coordinate CVE assignment through [CERT-CC / national CERT].

Step 2: Set Up Vulnerability Disclosure Infrastructure

Each maintained project should have:

• A SECURITY.md file at the repository root
• A security contact email address (monitored, not auto-replied)
• A clear disclosure policy with timeline commitments
• A process for coordinating with downstream manufacturers

# Security Policy

## Reporting a Vulnerability

Please report security vulnerabilities to **security@yourproject.org**.

Do **not** use GitHub Issues for security reports.

We aim to respond within **48 hours** and to provide a fix within **90 days**
for critical vulnerabilities. We practice coordinated vulnerability disclosure.

## Supported Versions

| Version | Supported |
|---------|-----------|
| 3.x     | ✅ Security updates |
| 2.x LTS | ✅ Critical security only |
| < 2.0   | ❌ End of life |

Step 3: Implement SBOM Generation for Maintained Components

While stewards are not required to produce SBOMs for conformity assessment, providing SBOM data helps manufacturers fulfil their Art.13 obligations — and satisfies your Art.8(2) cooperation duty proactively.

#!/usr/bin/env python3
"""
steward_sbom.py — Generate SPDX 2.3 SBOM for open-source component.
Satisfies CRA Art.8(2) cooperation duty by providing manufacturers
with dependency information for their conformity assessment.
"""

import json
import subprocess
import datetime
from pathlib import Path


def get_python_dependencies():
    """Extract installed packages with versions."""
    result = subprocess.run(
        ["pip", "list", "--format=json"],
        capture_output=True, text=True
    )
    return json.loads(result.stdout)


def generate_steward_sbom(
    package_name: str,
    package_version: str,
    organisation: str,
    output_path: str = "sbom.spdx.json"
) -> dict:
    """
    Generate SPDX 2.3 SBOM for a maintained open-source component.

    Args:
        package_name: Name of the maintained package
        package_version: Current version being documented
        organisation: Steward organisation name
        output_path: Where to write the SBOM file

    Returns:
        SBOM document as dict
    """
    timestamp = datetime.datetime.utcnow().strftime("%Y-%m-%dT%H:%M:%SZ")
    doc_namespace = f"https://yourorg.org/sbom/{package_name}-{package_version}"

    deps = get_python_dependencies()

    sbom = {
        "spdxVersion": "SPDX-2.3",
        "dataLicense": "CC0-1.0",
        "SPDXID": "SPDXRef-DOCUMENT",
        "name": f"{package_name}-{package_version}-sbom",
        "documentNamespace": doc_namespace,
        "creationInfo": {
            "created": timestamp,
            "creators": [
                f"Organization: {organisation}",
                "Tool: steward_sbom.py",
                "Tool: CRA Art.8(2) compliance"
            ],
            "comment": (
                f"SBOM generated by {organisation} as open-source software steward "
                f"under CRA Article 8(2). Manufacturers integrating {package_name} "
                "into commercial products may use this document to support their "
                "CRA conformity assessment obligations."
            )
        },
        "packages": [
            {
                "SPDXID": "SPDXRef-Package",
                "name": package_name,
                "versionInfo": package_version,
                "downloadLocation": f"https://pypi.org/project/{package_name}/",
                "filesAnalyzed": False,
                "licenseConcluded": "MIT",
                "licenseDeclared": "MIT",
                "copyrightText": f"Copyright {datetime.date.today().year} {organisation}",
            }
        ] + [
            {
                "SPDXID": f"SPDXRef-{dep['name'].replace('-', '_')}",
                "name": dep["name"],
                "versionInfo": dep["version"],
                "downloadLocation": f"https://pypi.org/project/{dep['name']}/",
                "filesAnalyzed": False,
                "licenseConcluded": "NOASSERTION",
                "licenseDeclared": "NOASSERTION",
                "copyrightText": "NOASSERTION",
            }
            for dep in deps
        ],
        "relationships": [
            {
                "spdxElementId": "SPDXRef-DOCUMENT",
                "relationshipType": "DESCRIBES",
                "relatedSpdxElement": "SPDXRef-Package",
            }
        ] + [
            {
                "spdxElementId": "SPDXRef-Package",
                "relationshipType": "DEPENDS_ON",
                "relatedSpdxElement": f"SPDXRef-{dep['name'].replace('-', '_')}",
            }
            for dep in deps
        ]
    }

    Path(output_path).write_text(json.dumps(sbom, indent=2))
    print(f"SBOM written to {output_path}")
    print(f"  Packages documented: {len(deps) + 1}")
    print(f"  CRA Art.8(2) cooperation: READY")
    return sbom


if __name__ == "__main__":
    sbom = generate_steward_sbom(
        package_name="your-oss-project",
        package_version="3.2.1",
        organisation="Your Foundation e.V.",
        output_path="sbom.spdx.json"
    )

Step 4: Establish CSIRT Reporting Procedure

Article 8(4) requires reporting actively exploited vulnerabilities to CSIRTs. Set up a documented procedure before it's needed.

Reporting procedure template:

When an actively exploited vulnerability is identified:

1. INTERNAL TRIAGE (immediate, <4 hours)
   - Confirm exploitation evidence (threat intel, CVE feeds, CERT reports)
   - Assess affected versions and scope
   - Assign incident commander

2. CSIRT NOTIFICATION (within 24 hours of confirming active exploitation)
   National CSIRT contacts:
   - DE: BSI Meldestelle — https://www.bsi.bund.de/meldestelle
   - EU: ENISA coordination — cert-eu@cert.europa.eu
   - ENISA EUVD submission form for coordinated disclosure

3. COORDINATED DISCLOSURE
   - Coordinate fix timeline with CSIRT
   - Notify downstream manufacturers who have requested vulnerability notifications
   - Publish security advisory when fix is ready or 90-day deadline reached

4. POST-INCIDENT
   - Document the incident in security log
   - Update security policy if process gaps identified

The Art.8(2) Cooperation Duty in Practice

One of the most practically significant obligations is the cooperation duty with manufacturers. As more companies build commercial products on open-source foundations, stewards will increasingly receive CRA-related information requests.

What manufacturers will ask for:

What you do not have to do:

• Create documentation from scratch for every manufacturer request
• Conduct security testing to produce test results
• Certify or validate the manufacturer's use of your component
• Sign contractual security assurances

The cooperation duty is about information sharing, not liability transfer. Your liability remains governed by open-source license terms and applicable law — not by Article 8.

Relationship to Manufacturer Obligations

Understanding Article 8 in context requires understanding how steward and manufacturer obligations interact when your open-source software is integrated into a commercial product.

Open-Source Steward                   Manufacturer
(Art.8 applies)                       (Art.13, Annex I apply)
      │                                      │
      │   maintains                          │   places product on market
      │                                      │
   [OSS Component] ─────────────────> [Commercial Product]
      │                                      │
      │   Art.8(2): cooperate when           │   Must assess component
      │   manufacturer requests info   ←─────│   security for their DoC
      │                                      │
      │   Art.8(4): report to CSIRT if       │   Art.14: 24h/72h reporting
      │   actively exploited                 │   for incidents affecting
                                             │   their product

The manufacturer cannot offload their conformity assessment burden to the steward. The manufacturer must assess whether the open-source component they integrate meets their product's security requirements. The steward's Art.8(2) cooperation duty supports this assessment — it does not replace it.

Recital 19 of the CRA clarifies this relationship: "manufacturers that incorporate open-source software components into their products remain responsible for compliance with this Regulation."

Transition Timeline

For stewards: The September 2026 date is particularly important. By that date, the vulnerability reporting ecosystem under Art.14 (for manufacturers) must be operational. Your Art.8(4) reporting infrastructure should be ready before manufacturers start relying on it for their Art.14 compliance.

Key Takeaways

1. Article 8 is a lighter tier — not an exemption. Stewards have real, enforceable obligations. They are just significantly less burdensome than full manufacturer requirements.

2. The commercial activity test is decisive. If your organisation sells products or services built on the software you maintain, you may be a manufacturer for those products regardless of your steward status for the OSS activities.

3. The cybersecurity policy must be genuine. Article 8(1) requires a documented, implemented policy — not a legal disclaimer. It must cover vulnerability reporting mechanisms.

4. Cooperation with manufacturers is mandatory. When a manufacturer asks for security information about your component, you must provide it. This is not optional.

5. Art.8(4) requires CSIRT reporting for actively exploited vulnerabilities. This is a lower threshold than theoretical disclosure — it activates when exploitation is happening in the wild.

6. Individual contributors remain fully outside the CRA. Nothing in Article 8 changes the status of individual developers who contribute to projects maintained by stewards.

Article 8 is part of the sota.io CRA series. Related posts:

• CRA Art.2: Scope and Product Coverage
• CRA Art.3: Definitions
• CRA Art.6: Essential Requirements and Annex I
• CRA Art.7: Presumption of Conformity
• CRA Art.13: Manufacturer Obligations
• CRA Art.16: Vulnerability Reporting