The CRA does not give every open-source steward the manufacturer’s entire reporting surface. Article 14(1) vulnerability reporting applies to the extent the steward is involved in developing the product. Severe-incident reporting and user information apply to the extent a severe incident affects network and information systems the steward provides for developing those products.
That boundary needs a project-level map. A foundation or company can play different roles for different projects and provide different kinds of support.
Record development involvement
For each stewarded project, describe the legal entity, sustained support, decision rights, engineering contribution, release involvement, security coordination, and infrastructure supplied. Name the evidence and owner for each entry.
Avoid broad labels such as “we host the project” or “we fund maintainers.” Break the relationship into activities that can be tested against Article 24. Update the record when governance or support changes.
Build a project-by-project role matrix
Give each project a row for legal entity, product, development involvement, sustained support, viability activity, release authority, security coordination, infrastructure provided, commercial context, and evidence. The same foundation may have different results for two projects.
Separate personal maintainer activity from action taken for the legal person. Employment, a board role, or repository permissions may be relevant evidence, but none should stand alone as the role conclusion.
Separate the two occurrence routes
For an actively exploited vulnerability, identify whether the steward is involved in developing the affected product. For a severe incident, identify whether it affects development network or information systems the steward provides. Apply both analyses when a compromise crosses code and infrastructure.
Give each project a protected intake route and identify who can make the steward reportability decision. Link the project’s technical maintainers to the legal entity that can submit through the Single Reporting Platform.
For an infrastructure event, identify the network or information system, which development activity it supports, affected projects, product-security effect, and steward control. A compromise of unrelated corporate systems should not automatically become a project-wide severe-incident conclusion.
For a vulnerability event, trace the steward’s development involvement to the affected product and preserve the exploitation evidence separately. Keep both routes open until their distinct facts are resolved.
Coordinate without erasing roles
Manufacturers integrating the project may have their own Article 14 duties. A steward submission does not automatically complete a downstream manufacturer’s product-specific assessment, and a manufacturer report does not prove the steward’s infrastructure conclusion.
Use shared vulnerability facts where appropriate, then retain separate awareness times, scope decisions, user audiences, and submission evidence. The result should show exactly which steward activity creates which reporting route for which project.
Review the matrix after governance, sponsorship, infrastructure, or release-control changes. Preserve the effective period of each role decision so a later case is assessed against the facts that existed then, not only the current project website.
Continue this workflow with the maintainer-or-steward analysis and the component-maintainer handoff.