The Cyber Resilience Act for Home Assistant integration and add-on authors
You publish a Home Assistant integration, a HACS repository or an add-on. Since 11 September 2026 the EU Cyber Resilience Act asks some of you to report actively exploited vulnerabilities within 24 hours. Here is how to know whether that is you, what the platform already expects, and what to put in place this week.
Are you a "manufacturer"?
The regulation applies to any product with digital elements made available on the EU market in the course of a commercial activity (Regulation (EU) 2024/2847, Article 2(1) and Article 3(1)). An integration is software. So is an add-on. The only real question is the commercial activity.
The recitals give the test. Free and open-source software that is not monetised by its manufacturer is outside the regulation (recital 18). Monetised means, in practice: you charge a price, you sell a paid tier or paid support, you accept donations that go beyond covering your costs, or you process personal data beyond what security requires (recitals 18 and 19).
- Custom integration on HACS, written by an individual, no revenue: outside the regulation. This is the dominant model; HACS has no payment mechanism. Keep it that way to stay outside.
- Custom integration with a GitHub Sponsors or Buy Me a Coffee link: it depends on the facts. Donations that cover hosting and test devices are not a commercial activity (recital 18). A regular income that funds your time starts to look like one.
- Integration maintained by the manufacturer of a device, core or custom: the device is the product, the integration is part of it, and the company is its manufacturer (Article 13). The "Works with Home Assistant" partners (500 CHF a year, gold-level core integration, CE or FCC certification) are all here.
- Paid add-on, or add-on that fronts a paid service: manufacturer. Same for a free add-on maintained by a company as part of its business.
- Nabu Casa sells Home Assistant Cloud subscriptions and is hiring an engineer to prepare for the CRA: manufacturer for what it sells. HACS belongs to the Open Home Foundation since 2025, the profile Article 24 calls an open-source steward. Neither has published a position on the CRA.
An installer who configures integrations for a client is a user, not a distributor. A company that forks an integration and ships it under its own name becomes its manufacturer (Article 22).
What applies now, what applies in 2027
| From | Obligation | Article |
|---|---|---|
| 11 September 2026 | Report an actively exploited vulnerability in your integration or add-on: early warning within 24 hours, notification within 72 hours, final report within 14 days, through the ENISA single reporting platform. Same clock for a severe incident affecting the product's security. | Article 14 |
| 11 December 2027 | Everything else: secure-by-design requirements, vulnerability handling (SBOM, coordinated disclosure policy, security updates for the support period), technical documentation, EU declaration of conformity, CE marking, and the fines. | Articles 13, 64, 71; Annexes I, V, VII |
"Actively exploited" means someone is using the flaw against real installations, not that a scanner found it. When an advisory says "exploited in the wild" for your code, your 24 hours have started, or started earlier if you knew before.
The recent cases come from the core, the companion app and a popular add-on, not from a HACS integration. Frigate NVR, CVE-2026-25643: command injection via the go2rtc configuration, CVSS 9.1, 6 February 2026. Frigate, CVE-2026-54652: viewer accounts could read logs holding admin passwords, CVSS 8.1, 8 July 2026. Core Downloader integration, CVE-2025-65713: path traversal, fixed in 2025.8.0, 23 December 2025. Companion app, CVE-2026-44698: OAuth token exfiltration, CVSS 8.3, 29 May 2026. No CVE was found for a custom integration in 2025 or 2026; the precedent is the 22 January 2021 disclosure covering six custom integrations at once.
What the platform already asks
- Core integrations go through review and a quality scale, bronze to platinum. Security reports go through GitHub Security Advisories, answer aimed within 7 days, 90-day embargo, no bug bounty.
- Custom integrations are not reviewed, audited or maintained by the project. HACS checks a manifest, a
hacs.json, an active repository and a GitHub release. No human reads the code. - Add-ons publish through a
repository.yamlwhere the maintainer field is optional. The project's security policy does not cover custom integrations, and HACS has no central reporting channel. Nobody files your Article 14 report for you.
Which class is your product?
Most integrations are "default" products: self-assessment, no notified body. Annex III lists "important" products where a third-party assessment can be required unless you apply a harmonised standard. Two entries matter here: smart home products with security functionalities (smart door locks, security cameras, baby monitors, alarm systems), and smart home general purpose virtual assistants. The class attaches to the product sold, so a lock or camera vendor carries it with the device. An integration on its own is first a software component. If your code is the only way the device is controlled, read Annex III, Class I, before assuming self-assessment.
This week, in order
- Decide your status with the free scope test. Eight questions, a written result with the article references. Free integration with no commercial activity: stop here, and write that decision down.
- Publish a security contact: a
SECURITY.mdin the repository and a one-paragraph coordinated vulnerability disclosure policy. Annex I, Part II, point 5 will require it in 2027; today it is what brings a researcher to you before the forum. - Write the 24 h / 72 h procedure on one page: who watches GitHub advisories, who decides "exploited or not", who files on the ENISA platform, where the log is.
- Generate your SBOM. For an integration, the pinned
requirementslist inmanifest.json; for an add-on, the packages in the container image. Export it as a requirements file so the free scanner can flag anything on the CISA KEV list. - Fix the support period question. Article 13(8) asks for at least five years unless the product is expected to be used for less. Write the date in your README and, for a device, on the product page.
The kit generates the thirteen documents behind these steps from one form, in English or French: CVD policy, security.txt, reporting procedure with ENISA-style templates, support statement, Annex I risk assessment, Annex VII skeleton. Preview three of them in full before paying.
Where to ask
The official forum has a "Share your Projects!" category with a "Custom Integrations" subcategory. Its terms of service forbid spam and unwanted commercial content that drives traffic to third-party sites; no written rule on self-promotion of integrations was found. No CRA thread exists there yet, nor on GitHub. Discord and Reddit rules could not be checked. The Eclipse ORC working group maintains a public CRA FAQ that covers the open-source questions.
Sources: Regulation (EU) 2024/2847 as published in the Official Journal; Home Assistant Developer Docs, HACS docs, security policy and terms of service (15 September 2026); Home Assistant blog (22 January 2021, 21 August 2024, 16 April 2025); Works with Home Assistant (15 September 2026); Nabu Casa job posting (26 August 2026); OSV on CVE-2026-25643 (6 February 2026); SentinelOne on CVE-2026-54652 (July 2026); GitHub Advisory Database on CVE-2025-65713 (23 December 2025); ZeroPath on CVE-2026-44698 (29 May 2026). Not legal advice.