The compliance product is now the regulated product

Almost every renewable site we survey now has one of these on it. A single box at the edge of the site network, replacing whatever router the EPC left behind, carrying a private cellular bearer, terminating VPNs, running a next-generation firewall, and administered centrally from a vendor operations centre. It exists because the alternative was indefensible: a drawer of contractor-installed 4G routers, a public IP on the CCTV recorder, three overlapping VPNs of unknown provenance, and no reliable answer to the question of which historic O&M contractor still holds a working credential.

These products are sold, correctly, as an answer to a governance problem. NIS2 obliges the asset owner to control third-party access into its operational estate. The box gives it one front door with policy attached, no inbound path from the public internet, and a record of who reached what. That is a genuinely good product and a large improvement on what it replaces.

The observation in this note is that the regulatory position of the box has changed, and the market around it has not caught up. Under the Cyber Resilience Act the appliance is no longer only the instrument by which a customer meets its own obligations. It is a product with digital elements, placed on the EU market, with a manufacturer who now carries statutory duties for its design, its components, its vulnerabilities, its updates and the length of its supported life.

We spent research time this quarter reading the CRA, the 2025 implementing regulation defining important products, the Commission's guidance and FAQ published this month, and the public technical material of several vendors in this category. What follows is a reading of the regulation against a product pattern. It is deliberately not a finding about any one product, and where the analysis depends on facts that are not public, we say so rather than assuming.

Reporting came first

The CRA's substantive product requirements apply from 11 December 2027, which is distant enough that most product teams have filed the whole regulation under next year's problem. The reporting obligations in Article 14 did not wait that long. They took effect on 11 September 2026, and they are in force now.

From that date, a manufacturer of an in-scope product must report actively exploited vulnerabilities and severe incidents affecting the security of its products, through the single reporting platform, with an early warning inside 24 hours, a fuller notification inside 72 hours, and a final report after that. The Commission has been explicit that this applies to products already on the market, not only to those placed on it after December 2027.

So the installed base of these appliances, sitting on solar and wind sites across Europe today, is inside the reporting regime before the product requirements arrive. That inverts the usual compliance sequence. The obligation to report arrives before the obligation to be demonstrably secure, which means the first thing a manufacturer needs is not a technical file. It is the ability to answer, quickly, whether a CVE in a third-party firewall firmware is exploitable in its own product, on its own installed base, right now.

The product pattern

The pattern is consistent enough across vendors to describe generically. The appliance sits at the site boundary and replaces the site router. It bundles a cellular modem, routing, a next-generation firewall and VPN termination. Access policy is authored centrally by the vendor, by user class rather than by individual rule, and pushed to the fleet. Monitoring, intrusion prevention and event visibility are delivered as a managed service. A higher tier adds a second bearer, satellite or microwave or fibre, for resilience. A lighter tier drops the firewall and offers modem-plus-IPsec connectivity only.

The questions under that boundary line are the whole exercise. Which firewall platform and which firmware branch, which modem module and how long it is supported, where the VPN actually terminates, which identity provider backs authentication, what the cryptographic configuration is, how firmware reaches the field, and how the central management plane is itself protected. None of it is inferable from a datasheet, and every later determination in this note depends on the answers.

Start with the boundary, not Annex I

The instinct on reading the CRA is to open Annex I and start mapping controls. That is the wrong first move, and it is the most useful thing we learned. Everything downstream, the conformity route, the supplier obligations, the documentation set, the cost, depends on two questions that Annex I does not answer.

• What is the product: is it one integrated appliance placed on the market under the vendor's own name, or a bundle of separately CE-marked components that the vendor installs and configures as a service? Those are different regulatory objects with different obligations.
• Who is the manufacturer: the CRA defines a manufacturer as a party who develops a product, or has it developed, and markets it under its own name or trademark. Distributors, importers and parties who substantially modify a product can also acquire manufacturer obligations.

This is where a lot of vendors in this category are going to be surprised. The commercial story they tell is that the appliance was designed by them, engineered for renewable assets, and sold under their own product name. The internal story is often that they integrate somebody else's firewall and somebody else's modem, configure them well, and wrap a managed service around the result. Those two stories are both true and they point at different regulatory outcomes, so the question cannot be settled from marketing material. It is settled by the bill of materials, the supply and OEM contracts, the product labelling, and what the customer is actually invoiced for.

Our conclusion is that this determination is the single highest-value piece of work available to any vendor in this category right now, and that it is a week or two of careful document review rather than a programme.

Class I, Class II, and core functionality

Annex III of the CRA lists important products in two classes. Class I includes VPN products, network management systems, physical and virtual network interfaces, and routers, modems intended for internet connection and switches. Class II includes firewalls and intrusion detection and prevention systems intended for industrial use.

A product of the pattern above describes itself, in public material, using almost exactly that vocabulary. It is a router. It is a modem. It is a VPN product. It is a next-generation firewall. It is centrally managed. And it is deployed on industrial sites, which is the qualifier that moves the firewall line from Class I to Class II.

This does not automatically make the appliance a Class II product. The Commission's guidance is clear that classification follows the product's core functionality, and it gives, almost pointedly, the example of a router that incorporates firewall functionality and remains a router. The serious question is therefore what the box is primarily for. A connectivity gateway that happens to filter is a different answer from a security gateway whose purpose is filtering, and the marketing language that positions it as a security product cuts against the classification that the vendor would rather have.

The consequence is commercial, not academic. For a Class I important product, manufacturer self-assessment is available where the applicable harmonised standard has been applied. For a Class II important product, third-party conformity assessment is mandatory. That is the difference between an internal engineering programme and a notified body in the critical path of every product release. The first harmonised standards under the CRA are only now being produced, with more through 2027, which is precisely why the conformity strategy has to be decided during this window rather than after it.

What the regulation asks the product to be

Once the boundary and the class are settled, Annex I becomes tractable. Read against this product pattern it is less abstract than it looks, because most of the requirements land on features the vendor already markets. The gap is rarely the control. It is the evidence.

Alongside those sit the obligations that are not about the box at all: a declared support period, a technical file capable of demonstrating conformity, user information covering secure installation, intended environment, the end of the support period, the vulnerability contact and the decommissioning procedure, and eventually CE marking and an EU declaration of conformity. Most of that is documentation, which is why it tends to be deferred, and why deferring it is how a December 2027 deadline becomes a December 2027 crisis.

The component you did not write

This is the part we expect to cause the most operational pain, and it is the part least visible from a datasheet. An integrated appliance of this kind is assembled from a cellular modem, a firewall appliance, a firewall operating system, a VPN implementation, cloud management software, an embedded Linux or RTOS, cryptographic libraries, LTE modules, possibly satellite or microwave equipment, and a dashboard stack.

The CRA does not permit an integrating manufacturer to route a vulnerability back to its supplier and stop there. The guidance expects due diligence over components: checking security update histories, vulnerability databases, support periods, SBOMs and software composition, assessing the supplier's own security posture, and carrying out additional testing such as penetration testing, firmware analysis and traffic analysis where the risk warrants it.

The harder clause is the one about time. If a component falls out of vendor support while the finished product is still inside its declared support period, the product manufacturer may have to mitigate the vulnerability itself, replace the component, or otherwise remediate. For a fleet of appliances distributed across hundreds of remote unmanned sites, that is not a procurement footnote. It is a field-replacement programme with a regulatory clock on it, and it converts ordinary purchasing into supply-chain governance with contractual lifecycle commitments attached.

Five years against twenty-five

The CRA sets a support period floor of five years, shorter only where the product's expected lifetime is shorter. The Commission has said specifically that five years is not necessarily sufficient for routers, modems and switches, or for products used in industrial settings where they are reasonably expected to remain operational for longer.

Set that against the economics of the assets these boxes are bolted to. A solar farm is financed over decades. The communications and security equipment inside it turns over on a commercial cycle a fraction of that length. The regulation forces the collision into the open and makes the vendor answer for it.

• Who sets the lifetime: the vendor declares it, and the declaration is a legal commitment rather than a marketing position.
• What happens at component end-of-support: when the modem loses vendor support in year seven and the declared product support period runs to year ten, who pays for the swap, and does the replacement preserve the conformity configuration?
• How is the fleet even identified: device and firmware inventory across hundreds of remote sites is a prerequisite for every one of these answers, and it is frequently the weakest record a vendor holds.
• Can the patch actually be applied: a security update that risks interrupting SCADA or CCTV during a dispatch window is not a decision engineering can take alone.

None of those are purely technical questions. They reach product management, procurement, contracts, customer SLAs and finance, which is exactly why they do not get answered by a security team acting alone.

The obligation that is already live

Return to the sequencing. These are questions a vendor in this category is already obliged to be able to answer, and none of them wait for the 2027 deadline.

• Installed base: what exactly counts as the product, and which devices and firmware versions are in the field under it?
• Ownership: who internally is the CRA product owner, and who is authorised to initiate a 24-hour report?
• Intake: which OEM advisory feeds arrive, to whom, and on what latency?
• Applicability: how does the team determine whether a CVE in an integrated firewall or modem is exploitable in this product, in its shipped configuration?
• Evidence of exploitation: what constitutes reliable evidence of active exploitation, and what does the operations centre contribute to that judgement?
• Customer path: who notifies affected asset owners, and how does that interact with those owners' own NIS2 incident-reporting duties?

There is also a live obligation predating the CRA that gets overlooked because it sits in a different regulatory file. Because these appliances rely on cellular radio, the Radio Equipment Directive's cybersecurity requirements have applied to covered radio equipment placed on the market since 1 August 2025, supported by the EN 18031 standards, until the CRA takes over in December 2027. Whether that bites on the appliance or only on an embedded module that arrives already CE-marked depends, again, on the product boundary. It is worth an explicit crossover analysis rather than an assumption.

Centralisation cuts both ways

The last observation is an engineering one rather than a legal one, and it is the reason a formal product risk assessment is more than a paperwork exercise here.

The value of this product class comes from centralisation. One policy author, one enforcement pattern, one fleet, one place to revoke a contractor's access across every site at once. That is the whole proposition and it is a sound one. The same property is a concentration of risk, and a CRA risk assessment has to say so out loud.

The scenarios worth modelling follow directly from the architecture. A compromise of the central management plane multiplies across the fleet. A stolen privileged credential reaches many sites rather than one. A faulty policy deployment affects availability everywhere simultaneously. A VPN vulnerability exposes the OT network the product exists to protect. A vulnerable modem or firmware component creates a path around the access control rather than through it. A bad remote update disconnects an unmanned plant. A certificate expiry causes an outage with no attacker involved at all. A compromise of a supplier or a management tool becomes a systemic supply-chain event.

Those are analytical scenarios, not allegations about any deployed product. They are also the scenarios a notified body or a serious procurement team will ask about, and the vendor that has already modelled them is in a very different conversation from the one that has not. This is the same control-concentration argument we made about plant controllers and DER aggregators in engineering cybersecurity into the smart grid, applied one layer out, to the access infrastructure itself.

How we would sequence it

The temptation with a regulation this broad is to start a compliance programme. We think that is the wrong shape of work, because the expensive decisions all sit behind two cheap ones.

• First, determine the object: product boundary, manufacturer status, preliminary classification, and the Article 14 readiness gap. Weeks, not months, and every later decision inherits from it.
• Second, build the baseline: architecture and component register, SBOM structure, the formal product risk assessment, Annex I mapped to control and evidence and owner, supplier due-diligence requirements, a support-period model, and a disclosure and product-incident capability.
• Third, wire it into engineering: supplier advisory to applicability assessment to lab test to deployment decision to evidence update to reporting decision. The gate belongs in the release process, not in a spreadsheet reviewed quarterly.
• Fourth, keep it current: a product can be conformant at launch and drift out of it when a component loses support, a firmware branch goes end-of-life, a cloud management dependency changes, or a feature addition amounts to a substantial modification.

Before any of that, there is a document request. The determination in step one cannot be made from public material, and we would not attempt it without a tightly controlled set of records.

• Product definition: bill of materials per variant, model numbers, OEM contracts, product labelling, and how the thing is described in quotations and on the customer's asset register.
• Architecture: network and data-flow diagrams, VPN topology, cryptographic configuration, identity and privileged-access model, and the central management and NOC architecture.
• Lifecycle: firmware update mechanism, patch SLAs, installed-base inventory by device and version, and the supported-life commitment actually written into contracts.
• Assurance: existing CE, RED and EMC documentation, penetration-test and firmware-analysis evidence, vulnerability-management procedure, OEM advisory feeds, and any existing disclosure arrangement.

The framing that we think matters most is this. NIS2 asks whether an organisation is managing cyber risk appropriately. The CRA asks whether a connected digital product has been made secure, maintainable and supportable across its life. Vendors in this category have built their proposition entirely on the first question, and their customers are about to start asking them the second one: can you demonstrate that the security product we depend on is itself conformant?

That question is coming from procurement, not from regulators, and it will arrive well before December 2027. A vendor who can answer it has a differentiator. A vendor who cannot has a credibility problem in the exact place their sales argument lives, because a box sold as the answer to a compliance obligation is a poor place to discover an unanswered compliance obligation.

Which is the general lesson we are taking from the exercise, and it is not confined to this product class. CRA readiness is not a certification you obtain. It is a product lifecycle operating model, and the parts of it that are hardest to retrofit are the parts that look like documentation: knowing what your product is made of, knowing where every unit of it is, and being able to show why the architecture is defensible rather than asserting that it is.