CRA compliance for npm libraries and SDKs

Components are software intended for integration into an electronic information system (Art. 3(6)), and a component placed on the market separately is a product with digital elements in its own right (Art. 3(1)), connected at least indirectly through the product that uses it (FAQ 1.3). A library that only ships inside your own product is assessed as part of it.

The decisive question is whether you supply the package in the course of a commercial activity (Art. 3(22)). Publishing on a registry is not commercial by itself, nor are donations, sponsorship or contributions from companies that use it (Recitals 18 and 20). An open-source component intended for integration by other manufacturers is on the market only if its original manufacturer monetises it (Recital 18): charging for it, selling paid support tied to it, gating features behind a paid tier or shipping it inside a commercial product of yours (FAQ 4.5.2). Merely contributing code to a project you are not responsible for is not covered (Recital 18).

A legal person that sustainably supports the development of open-source software intended for commercial activities, without marketing it, may be an open-source software steward: a light-touch regime under Article 24 instead of the manufacturer obligations, with reporting duties from 11 December 2027 (Art. 24(3); Art. 3(14); Recital 19). Which role you are in is worth recording.

Even when the package is out of scope for you, its commercial users are in scope: they must exercise due diligence on the components they integrate (Art. 13(5)), report vulnerabilities in your package to you (Art. 13(6)) and list it in their SBOMs (Annex I, Part II, point (1)). Expect questions about your security contact and disclosure policy.

Class is rarely an issue for libraries, but it follows core functionality (Implementing Regulation (EU) 2025/2392): an SDK for authentication, a VPN, PKI or a password manager would be class I (Annex III, class I, points 1, 5, 9 and 3). An important open-source product may self-assess if its technical documentation is public (Art. 32(5)).

Reporting is already live. Since 11 September 2026, every manufacturer of an in-scope product, including products already on the market, must notify actively exploited vulnerabilities and severe incidents through ENISA’s Single Reporting Platform (Art. 14; Art. 69(3); Art. 71(2)): early warning within 24 hours of becoming aware, notification within 72 hours, final report within 14 days of a corrective measure or one month for an incident (Art. 14(2), (4)), all to the CSIRT coordinator of your main establishment (Art. 14(7)); impacted users must be informed (Art. 14(8)).

From 11 December 2027 the rest of the Regulation applies to products placed on the market from then: Annex I essential requirements, Annex VII technical documentation, Annex V declaration of conformity, CE marking and Annex II user information (Art. 71(2)). Earlier products stay under Article 14 alone unless substantially modified (Art. 69(2)–(3); Art. 3(30)); placing on the market is counted per unit and per version (FAQ 7.2). No harmonised standard has been cited in the Official Journal yet, so there is no presumption of conformity to rely on (Art. 27).

1. 1. Write down which side of the line you are on

   For each package, record whether it is monetised, supported by a steward, or only for your own use, and keep the reasoning. Revisit it whenever the monetisation model changes.

2. 2. Publish a security contact and a disclosure policy

   Provide a contact address for vulnerability reports and a coordinated disclosure policy (Art. 13(17); Annex I, Part II, points (5) and (6)): a security policy file in the repository, security.txt on your domain, and a mailbox a person reads.

3. 3. Ship an SBOM and keep dependencies watched

   A lockfile is not an SBOM. Produce a machine-readable SBOM per release covering at least the top-level dependencies (Annex I, Part II, point (1)), watch it against vulnerability feeds, and report a dependency vulnerability to its maintainer while you fix your own package (Art. 13(6)).

4. 4. Prepare Article 14 if you are in scope

   Arrange Single Reporting Platform access, identify your coordinator CSIRT and rehearse the 24-hour early warning. Plan how to inform impacted users (Art. 14(8)), for example through an advisory and a deprecation notice, and publicly disclose fixed vulnerabilities once the update is available (Annex I, Part II, point (4)).

5. 5. Define a support period and the update rules

   Set a support period of at least five years (Art. 13(8)). If you fix only the latest major version, earlier users must be able to move to it free of charge without changing their environment (Art. 13(10)); archives of old versions must warn about unsupported software (Art. 13(11)); security updates are free and stay available for ten years (Art. 13(9)). Start the Annex VII technical file, public for an important open-source product that self-assesses (Art. 32(5)).

Permenta records the scope decision for each package with its reasoning, including the honest “uncertain, seek advice” outcome the steward question often deserves, generates security.txt and the disclosure policy, keeps an SBOM per release matched against vulnerability feeds, and gives commercial users of your package a trust page that answers their due-diligence questions. In scope, the Article 14 desk runs the clocks and the ledger keeps the record.

• Art. 2(1)
• Art. 3(1), (6), (14), (22), (30)
• Art. 13(5), (6), (8), (9), (10), (11), (17)
• Art. 14
• Art. 24
• Art. 27
• Art. 32(5)
• Art. 69(2), (3)
• Art. 71(2)
• Annex I, Part II
• Annex III, class I
• Annex VII
• Implementing Regulation (EU) 2025/2392
• Commission FAQ v1.4: 1.3, 4.5.2, 7.2
• Recitals 18, 19, 20