Preparing an Open Source Project for CRA-Related Requests

Start With a Written CRA Role Statement

Before responding to CRA-related questions, the project should know which role it actually occupies. Record whether the software qualifies as free and open-source software, whether a legal person acts as an open-source software steward, whether any entity acts as manufacturer of the upstream product and whether commercial downstream manufacturers integrate the software. This short role statement prevents requests from being answered on the assumption that every maintainer, foundation or project has the same CRA obligations.

• Identify the FOSS product.
• Identify any responsible manufacturer.
• Identify any qualifying steward.
• Identify ordinary maintainers separately.
• Identify major downstream manufacturer relationships.

A Steward Should Keep Its Article 24 Cybersecurity Policy Ready

Article 24(1) requires an open-source software steward to put in place and document in a verifiable manner a cybersecurity policy. The policy should foster secure development and effective vulnerability handling and cover documenting, addressing and remediating vulnerabilities, voluntary vulnerability reporting and information sharing within the open-source community. Because this documentation can later be requested by a market surveillance authority, it should be maintained as operational evidence rather than drafted only after a request arrives.

• Maintain the cybersecurity policy.
• Keep it current.
• Make the documentation verifiable.
• Connect the policy to actual project processes.
• Assign organisational ownership.

Article 24(2) Creates a Specific Market-Surveillance Cooperation Duty

A qualifying steward must cooperate with market surveillance authorities at their request with a view to mitigating cybersecurity risks posed by qualifying free and open-source products. This is a specific statutory duty for stewards. The organisation should therefore identify who can receive authority correspondence, who can coordinate technical information from supported projects and who is authorised to provide the organisation's formal response.

• Identify an authority-contact owner.
• Create an internal escalation route.
• Know which supported project is affected.
• Coordinate technical and legal response functions.
• Preserve request and response records.

A Reasoned Request Can Require the Article 24 Policy Documentation

Article 24(2) states that following a reasoned request from a market surveillance authority, the open-source software steward must provide the authority with the documentation referred to in Article 24(1). The required material is therefore the steward's cybersecurity-policy documentation, not automatically the complete manufacturer technical file required from a product manufacturer. Keeping this distinction clear prevents a steward from confusing its tailored CRA role with the much broader manufacturer conformity framework.

• The authority request must be reasoned.
• Article 24(1) policy documentation is specifically referenced.
• Steward documentation is not automatically a manufacturer technical file.
• Role boundaries should remain explicit.

The Documentation Can Be Provided in Paper or Electronic Form

Article 24(2) expressly allows the cybersecurity-policy documentation to be provided in paper or electronic form. For most open-source organisations, electronic records will be operationally easier, particularly where governance, security procedures and project information are maintained collaboratively. The steward should still control versions so that it can identify which policy was in force when a request or cybersecurity event occurred.

• Paper form is permitted.
• Electronic form is permitted.
• Maintain version history.
• Preserve approval and ownership information.
• Avoid relying on undocumented informal practice.

Use a Language the Requesting Authority Can Easily Understand

Article 24(2) also requires the documentation to be provided in a language that can be easily understood by the requesting market surveillance authority. A globally distributed foundation or steward should therefore know how it would produce an understandable version of the relevant policy when required. This does not mean translating every project document pre-emptively into every Union language, but the organisation should have a practical process for satisfying the language requirement when a request is received.

• The authority must be able to understand the documentation.
• Prepare a translation or localisation process where needed.
• Identify authoritative source documents.
• Keep translated material consistent with approved policy.

Maintain a Clear Vulnerability Reporting Contact

CRA-related communication is easier when a project already has a maintained vulnerability-reporting route. Article 24 policies should foster voluntary vulnerability reporting, and downstream manufacturers can also need to report component vulnerabilities upstream under Article 13(6). Projects should therefore provide a security contact or documented reporting method that remains usable when maintainers change. The contact can route reports to the appropriate project without making the person receiving the message personally responsible for the CRA obligations.

Requests From Downstream Manufacturers Are Different From Authority Requests

A downstream manufacturer may ask an open-source project for vulnerability information, supported versions, security practices, dependency information or other evidence as part of its Article 13(5) due diligence. That request is not automatically an Article 24(2) market-surveillance request. The downstream manufacturer remains responsible for deciding whether the component is suitable for its own product. An upstream project can provide useful information voluntarily without accepting manufacturer responsibility for the downstream product.

• Manufacturer due-diligence requests are distinct from authority requests.
• The downstream manufacturer owns its product decision.
• Upstream projects can provide factual security information.
• Do not imply responsibility for the downstream product.

Article 13(6) Can Bring Vulnerability Reports From Downstream Manufacturers

Article 13(6) requires a manufacturer that identifies a vulnerability in an integrated component, including an open-source component, to report it to the person or entity manufacturing or maintaining the component. Open-source projects should therefore expect that downstream companies may contact maintainers with vulnerability details because those companies are fulfilling their own CRA duties. A project should have a secure intake path capable of distinguishing a security report from a general support request.

• Downstream manufacturers can report component vulnerabilities upstream.
• Open-source maintainers may receive those reports.
• Create a secure vulnerability intake route.
• Route reports to the appropriate project security owner.
• Coordinate remediation where appropriate.

Do Not Promise Manufacturer Documentation the Project Does Not Owe

A community project, maintainer or steward can receive questionnaires asking for CE declarations, conformity assessments, manufacturer technical documentation or other evidence designed for commercial suppliers. The project should not manufacture documents or accept a legal role simply to satisfy a generic vendor questionnaire. Instead, respond from the project's actual CRA position. A steward can explain its Article 24 role and provide applicable documentation where legally required, while the downstream manufacturer remains responsible for its own conformity assessment and technical file.

• Do not invent a CE declaration.
• Do not claim manufacturer status without basis.
• Do not create false conformity evidence.
• Explain the project's actual role.
• Direct downstream product questions to the downstream manufacturer.

Prepare a Small Factual Project Information Pack

Even where no statutory duty requires a full upstream technical file, a project can make downstream due diligence easier by maintaining factual information. Useful material can include the project licence, authoritative repository, release policy, supported versions, security contact, vulnerability-disclosure policy, security advisories, update mechanism, governance organisation and any steward cybersecurity-policy information that is appropriate to share. This material should describe the project accurately without presenting it as manufacturer conformity documentation unless that role genuinely applies.

• Licence and authoritative repository.
• Supported versions.
• Release and update policy.
• Security contact.
• Vulnerability disclosure policy.
• Security advisories.
• Governance and steward information.

Separate Public Information From Authority-Request Documentation

Not every document maintained for CRA readiness needs to be published publicly. A project may publish general security policies and vulnerability-reporting information while retaining internal operational evidence, authority correspondence and sensitive vulnerability records under appropriate access controls. The Article 24(2) requirement concerns providing specified documentation to the requesting authority following a reasoned request. It does not itself require unrestricted publication of all steward security documentation.

• Identify information suitable for public release.
• Protect sensitive vulnerability details.
• Maintain authority-response records separately.
• Control access to internal operational evidence.

Prepare for Steward Reporting From 11 December 2027

A qualifying steward should also connect request readiness with the Article 24(3) reporting regime that applies from 11 December 2027. The European Commission confirms that steward reporting obligations begin on that date. The organisation should know which supported products it is involved in developing, which development network and information systems it provides and who will coordinate notifications through the CRA reporting process when the Article 24(3) conditions are met.

• Use 11 December 2027 as the steward reporting application date.
• Identify supported products.
• Identify steward-provided development systems.
• Assign reporting ownership.
• Connect vulnerability and incident processes to reporting escalation.

Article 25 Attestations May Become Another Source of Requests

Article 25 allows the Commission to establish voluntary security attestation programmes for qualifying FOSS. If such a programme is available and relevant, project developers, users or third parties may seek information needed to assess conformity with selected cybersecurity requirements or CRA obligations. Participation is not the same as becoming the manufacturer. Projects should evaluate any future attestation programme according to its own rules and decide how it fits their governance and security processes.

• Article 25 programmes are voluntary.
• Developers, users and other third parties can be involved.
• Attestation can support downstream due diligence.
• Participation does not automatically create manufacturer status.

Use a Repeatable CRA Request Workflow

A simple request workflow can prevent confusion. Record who sent the request, which project it concerns, whether the sender is a market surveillance authority, downstream manufacturer, researcher or other party, what legal role the project has, what information is actually requested and which documents can appropriately be provided. Route authority requests to the steward's formal response owner, vulnerability reports to the security process and ordinary due-diligence questions to a factual project-information process. Preserve the final response so later requests can be handled consistently.

• Identify the requester.
• Identify the affected project.
• Classify the request type.
• Confirm the project's CRA role.
• Provide only applicable information.
• Preserve the response record.
• Review the workflow when CRA guidance changes.