CRA compliance for self-hosted software

Self-hosted software is supplied to the customer as a product they run. Unlike a standalone online service, which is generally outside the Regulation (Recital 12; FAQ 1.2), it is a product with digital elements in the plain sense of Article 3(1), and server software is connected by design (Art. 2(1)).

Commercial licensing settles the market question, and so does open core: a community edition offered free of charge next to a paid enterprise edition, paid support or hosting is monetised (Recital 18; FAQ 4.5.2), so the free edition is on the market too (Art. 3(22)). Only open-source software that is not monetised by its manufacturer stays outside (Recitals 18 and 20); a legal person that supports it without marketing it may be an open-source software steward under Article 24 (Art. 3(14); Recital 19).

Your own cloud is in scope only as remote data processing: a licence server, update service or telemetry endpoint without which the product cannot perform one of its functions is part of the product (Art. 3(2)).

Class follows core functionality under Implementing Regulation (EU) 2025/2392. Identity and access management, PKI, network management systems, SIEMs, VPN servers and operating systems are class I (Annex III, class I, points 1, 9, 6, 7, 5 and 11); firewalls, intrusion detection and prevention systems, hypervisors and container runtimes are class II (points 2 and 1), which brings in a notified body or a certification scheme (Art. 32(3)). An important open-source product may still self-assess if its technical documentation is public (Art. 32(5)). Everything else is a default product (Art. 32(1)).

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). Notified bodies have been designated since 11 June 2026 (Art. 71(2)); class I and II products should plan the conformity route early.

1. 1. Register each edition and decide scope and class

   Treat the community and the enterprise edition as separate entries, note which of your services are remote data processing, and determine the class from the core functionality; a class I or II result changes the conformity route and the lead time.

2. 2. Fix the update model now

   Distribute updates over an authenticated, integrity-protected channel (Annex I, Part II, point (7)); ship security updates without delay, free of charge and with an advisory (point (8); Art. 13(9)), separately from feature updates where feasible (point (2)). If you remediate only the latest 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)).

3. 3. Publish a contact, a disclosure policy and advisories

   Provide a vulnerability reporting address and a coordinated disclosure policy (Art. 13(17); Annex I, Part II, points (5) and (6)). Once a security update is available, publicly disclose the fixed vulnerability with its description, impact, severity and remediation (Annex I, Part II, point (4)); machine-readable advisories such as CSAF let customers automate intake.

4. 4. Ship an SBOM with every release and keep it current

   Keep a machine-readable SBOM per release covering at least the top-level dependencies (Annex I, Part II, point (1)), tell users where to find it if you share it (Annex II), be ready to hand it to an authority on reasoned request (Art. 13(25)), and report component vulnerabilities upstream (Art. 13(6)).

5. 5. Prepare Article 14 and the technical file

   Rehearse the reporting routine with your coordinator CSIRT. Set a support period of at least five years (Art. 13(8)) and state its end date at purchase (Art. 13(19)). Start the Annex VII technical file with the risk assessment and test reports (Art. 13(2)–(3); Art. 31), keep it and the declaration for ten years (Art. 13(13)), and plan the Annex V declaration and the CE marking, for software on the declaration or the website (Art. 28; Art. 30).

Permenta registers each edition with its scope reasoning and class, keeps the SBOM per release matched against vulnerability feeds daily, publishes CSAF advisories with a human-readable page and a discovery index, and runs the Article 14 desk with the clocks and the field list. The Annex VII workspace collects the technical file section by section, every generated document marked as a draft until reviewed, and the ledger keeps the record for ten years.

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