The Cyber Resilience Act bans no lighting protocol. Art-Net and sACN can stay on fixtures and consoles placed on the EU market from 11 December 2027 when the risk assessment justifies the protocol and the manufacturer addresses the remaining risk.
Key takeaways
- Article 14 reporting of actively exploited vulnerabilities has applied since 11 September 2026, and Article 69(3) extends Article 14 to lighting products placed on the market before 11 December 2027.
- The Annex I essential requirements apply to each unit placed on the market from 11 December 2027, so a fixture model that still ships in 2028 must comply for every unit first placed on the market from that date.
- Recital 55 of the Cyber Resilience Act allows a justified exception where the intended purpose of a product requires a widely recognised interoperability standard with weak security, provided the manufacturer addresses the risk by other means.
- A firmware update that adds a new network protocol to an older fixture can be a substantial modification, which brings the updated fixture under the full Regulation.
- Sig-Net addresses part of Annex I Part I, product security. Sig-Net does not address Annex I Part II, which requires a vulnerability disclosure policy, an SBOM, security advisories and free security updates.
What are lighting users asking about the CRA?
In October 2026 a user on the ETC Community networking forum asked four questions that many lighting professionals share. Will manufacturers adopt Sig-Net? Will older devices get firmware updates? Can Sig-Net coexist with sACN and Art-Net? How will a venue console accept the fixtures of a touring company?
The protocol questions belong to the manufacturers and the protocol teams. The regulatory questions have answers in the text of Regulation (EU) 2024/2847 (CELEX 32024R2847). The table below gives those answers. The sections after the table give the detail.
| Question | Short answer | Legal anchor |
|---|---|---|
| Is everything due by December 2027? | No. Article 14 reporting applies now, to old and new products. | Art. 71(2), Art. 69(3) |
| Must older fixtures get new firmware? | No retrofit duty for units already placed on the market. A new protocol added by update can be a substantial modification. | Art. 69(2), Art. 3, Recital 39 |
| Can sACN and Art-Net stay? | Yes, with a documented justification and compensating measures. Secure by default still applies. | Art. 13(3)–(4), Recital 55, Annex I Part I(2)(b) |
| How do touring fixtures join a console? | The CRA requires access control but does not prescribe the method. | Annex I Part I(2)(d) |
| Does Sig-Net make a product compliant? | No. Compliance is assessed on the final product and its processes. | Annex I Part II |
When do CRA obligations apply to lighting products?
Two dates apply. Article 14 reporting started on 11 September 2026. The rest of the Regulation, including the Annex I essential requirements, applies from 11 December 2027, as Article 71(2) states.
The first date is the one most often missed. Article 69(3) says that the Article 14 obligations "shall apply to all products with digital elements that fall within the scope of this Regulation that have been placed on the market before 11 December 2027". A networked moving head placed on the market in 2019 is in that population. When the manufacturer becomes aware of an actively exploited vulnerability in that fixture, Article 14 requires an early warning to the coordinating CSIRT and ENISA within 24 hours, and a vulnerability notification within 72 hours.
| Obligation | Applies from | Products covered |
|---|---|---|
| Article 14 reporting (exploited vulnerabilities, severe incidents) | 11 September 2026 | All in-scope products, including products placed on the market before 11 December 2027 |
| Annex I Part I and Part II, CE marking, technical documentation | 11 December 2027 | Each unit placed on the market from that date |
| Full Regulation for older products | 11 December 2027 | Units placed before that date, only after a substantial modification |
Does every fixture unit count, or only new models?
Every unit counts. Article 3 defines placing on the market as "the first making available" of a product on the Union market. Recital 38 states that the essential requirements apply to each individual product when placed on the market, whether the product is made as a single unit or in series.
The consequence is direct. A console or fixture model that was launched in 2022 and still ships in 2028 must meet Annex I for each unit first placed on the market from 11 December 2027. A unit that a distributor received before that date stays under Article 69(2), even when the end user buys the unit later. The model launch date is not relevant. This explains why lighting manufacturers prioritise products that are still in production.
Must manufacturers update the firmware of older fixtures?
No. Article 69(2) states that products placed on the market before 11 December 2027 are subject to the Regulation "only if, from that date, those products are subject to a substantial modification". The CRA contains no duty to retrofit units already placed on the market.
A retrofit has its own risk. Recital 39 says that a security update which decreases risk and does not change the intended purpose is not a substantial modification. Recital 39 also says that a feature update which adds a new input element typically broadens the attack surface. The Commission guidance C(2026) 5252 asks whether an update introduces new threat vectors, and names additional interfaces and communication channels as examples. A new network protocol is a new communication channel.
Thus a Sig-Net firmware update for a fixture placed on the market in 2024, released after 11 December 2027, can make that fixture a substantially modified product. The manufacturer then carries the full obligations for the updated version, including conformity assessment and CE marking under the CRA. The Commission guidance is not binding, and the answer depends on what the original risk assessment foresaw. Manufacturers that plan retrofits should record the decision in the risk assessment before the update ships. Our reading of the four-factor test gives the Commission's worked examples.
Can Sig-Net coexist with sACN and Art-Net under the CRA?
Yes, when the risk assessment justifies the legacy protocols. The CRA is risk-based and names no protocol. Article 13(3) requires the risk assessment to state whether and how each Annex I Part I point (2) requirement applies. Article 13(4) requires a clear justification in the technical documentation for each requirement that does not apply.
Recital 55 covers this case almost exactly. The intended purpose of a product "may require the manufacturer to follow widely recognised interoperability standards even if its security features are no longer considered to be state of the art". Recital 55 then sets a condition. Where the manufacturer has identified risks, the manufacturer must address them by other means, "for instance by limiting the intended purpose of the product to trusted environments or by informing the users about those risks".
For a hybrid fixture or console, a defensible file usually contains four elements.
- A risk assessment entry that names Art-Net and sACN, states the interoperability need, and records which Annex I points the protocols cannot meet.
- Compensating measures, such as an isolated control network, documented VLAN guidance, and an option to disable each legacy protocol.
- User information under Annex II that states the risk and the safe network configuration.
- A decision on the default state. Annex I Part I(2)(b) requires a secure by default configuration. An unauthenticated protocol that is on when the product leaves the box needs a strong justification.
The Sig-Net framework applies the same logic to its own unauthenticated "Open Mode". According to the Sig-Net Protocol Framework, section 7.2.4, devices "shall not be shipped with Open Mode enabled", and Open Mode is enabled only through a physical action on the device or an authenticated channel. A manufacturer can use the same pattern for Art-Net and sACN.
How can a venue console accept a touring company's fixtures?
The CRA requires the control, not the method. Annex I Part I(2)(d) requires protection from unauthorised access "by appropriate control mechanisms, including but not limited to authentication, identity or access management systems". The Regulation does not specify how a fixture from one owner joins a network controlled by another owner.
The onboarding design therefore belongs to the protocol teams and the manufacturers. Whatever the method, the risk assessment of the console and of the fixture must cover the touring case, because a touring rig is a reasonably foreseeable use of professional lighting equipment under Article 13(3). Key handover, key revocation after the show, and the fallback when onboarding fails all need a documented answer.
What does Sig-Net not cover?
Sig-Net is a transport protocol. Sig-Net adds message authentication with HMAC and does not encrypt DMX levels, a choice the framework justifies with the Article 13(2) risk assessment. The framework also states that "use of this protocol does not guarantee compliance" with the CRA, and that each manufacturer must establish its own vulnerability handling processes.
Those processes are Annex I Part II. The table gives the full text of each point. No transport protocol satisfies more than a part of point (7).
| Annex I Part II point | Text of the Regulation | Can a secure transport protocol satisfy the point? |
|---|---|---|
| (1) | "identify and document vulnerabilities and components contained in products with digital elements, including by drawing up a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies of the products;" | No |
| (2) | "in relation to the risks posed to products with digital elements, address and remediate vulnerabilities without delay, including by providing security updates; where technically feasible, new security updates shall be provided separately from functionality updates;" | No |
| (3) | "apply effective and regular tests and reviews of the security of the product with digital elements;" | No |
| (4) | "once a security update has been made available, share and publicly disclose information about fixed vulnerabilities, including a description of the vulnerabilities, information allowing users to identify the product with digital elements affected, the impacts of the vulnerabilities, their severity and clear and accessible information helping users to remediate the vulnerabilities; in duly justified cases, where manufacturers consider the security risks of publication to outweigh the security benefits, they may delay making public information regarding a fixed vulnerability until after users have been given the possibility to apply the relevant patch;" | No |
| (5) | "put in place and enforce a policy on coordinated vulnerability disclosure;" | No |
| (6) | "take measures to facilitate the sharing of information about potential vulnerabilities in their product with digital elements as well as in third-party components contained in that product, including by providing a contact address for the reporting of the vulnerabilities discovered in the product with digital elements;" | No |
| (7) | "provide for mechanisms to securely distribute updates for products with digital elements to ensure that vulnerabilities are fixed or mitigated in a timely manner and, where applicable for security updates, in an automatic manner;" | Partly, if the protocol carries signed firmware |
| (8) | "ensure that, where security updates are available to address identified security issues, they are disseminated without delay and, unless otherwise agreed between a manufacturer and a business user in relation to a tailor-made product with digital elements, free of charge, accompanied by advisory messages providing users with the relevant information, including on potential action to be taken." | No |
Article 13(8) requires these processes for the whole support period, which is at least five years unless the product is expected to be in use for less time. For lighting equipment that stays in rental stock for a decade, the support period decision is a real cost decision.
How can lighting manufacturers start before December 2027?
Start with the obligations that already apply. Article 14 reporting needs a way to receive vulnerability reports, a way to decide quickly whether a vulnerability is actively exploited, and a route to the coordinating CSIRT and ENISA. Annex II point 2 requires a single point of contact for vulnerability reports on every product.
CVD Portal gives a lighting manufacturer the Annex I Part II layer that a protocol does not provide. The platform includes a branded vulnerability intake portal, a generated security.txt file, Article 14 deadline tracking, SBOM management and CSAF advisories. The free CRA classification tool shows whether a fixture, console or node falls in the default category or an important product class.
Frequently asked questions
Does the Cyber Resilience Act ban Art-Net or sACN?
No. The Cyber Resilience Act names no protocol. A manufacturer may keep Art-Net or sACN on a product when the cybersecurity risk assessment justifies the protocol and the manufacturer addresses the remaining risk, for example by limiting use to trusted networks and informing users.
Do CRA obligations apply to lighting fixtures placed on the market before December 2027?
Article 14 reporting applies to all in-scope products placed on the EU market before 11 December 2027, per Article 69(3). The other requirements apply to those older products only after a substantial modification on or after that date.
Must a manufacturer update the firmware of fixtures already on the market?
The CRA does not require a retrofit of units placed on the market before 11 December 2027. A firmware update that adds a new network interface can be a substantial modification, which brings the updated product under the full Regulation.
Does using Sig-Net make a lighting product CRA compliant?
No. The Sig-Net framework states that use of the protocol does not guarantee CRA compliance. Compliance is assessed on the final product, including the risk assessment and the Annex I Part II vulnerability handling processes.