Remove the cellular modem. Not disable — remove
Factory Acceptance Test, day three. The asset owner's commissioning engineer is walking around an open cabinet containing the wind turbine main controller, comparing what is in front of them with the manufacturer's documentation. The cabinet is clean, well-laid out, professionally built. The documentation is complete and accurate.
Then the engineer notices something the documentation does not mention. A small SMA connector on one edge of the main control board, and, threaded behind a cable bundle, a coaxial pigtail leading to a small antenna mounted on the inside of the cabinet door.
They follow the pigtail back. A daughter card plugged into a mezzanine connector on the main board, carrying an LTE modem module of a type commonly used in industrial routers.
The manufacturer's engineer is called over. They confirm the modem is present. They confirm it is disabled in firmware. They offer to demonstrate that no traffic flows through it under normal conditions. They explain that the modem is fitted "for emergency support, in case site connectivity is unavailable during commissioning".
The asset owner's engineer makes a note in the FAT report. The note is brief: the modem must be physically removed. Not disabled. Removed.
The principle is short. Hardware that is present is a capability that exists. Hardware that is absent is a capability that does not. The two states are not interchangeable, and the difference between them is the difference between a controlled architecture and an uncontrolled one. Out-of-band channels — cellular modems, Bluetooth interfaces, Wi-Fi adapters, hidden USB management ports, undocumented serial consoles, baseboard management controllers, NFC tags, proprietary radio links — are the single most common architectural surprise in OT acceptance testing. The remedy is not configuration. It is removal.
Why "disabled" is not enough
A disabled component can be re-enabled. Firmware is not immutable. A future firmware update — including one applied through the legitimate patch process — may re-enable the modem, either intentionally because a feature has been reinstated, or unintentionally because a regression has slipped past testing. The manufacturer's commitment that no future firmware will re-enable a particular capability is not enforceable across firmware versions, vendor mergers, changes of product strategy, or human error in a release branch. Five years into a twenty-five-year asset life, the people who made that commitment are no longer at the company, and the commitment is no longer in the change log.
Disabled does not mean inert. A cellular modem chip on the board, even with its firmware disabling the radio, still has physical RF capability if its antenna remains connected. It still has power and clock signals. It still appears in the vulnerability landscape — CVEs targeting that modem chipset still apply to the device that ships with it, whether the radio is in use or not. If the device has a SIM, the SIM may still respond to certain commands. A maintenance technician, a turbine climber, or any contractor with physical access in a cabinet has more options for reactivating a disabled radio than for installing one that was never there.
Verification is not feasible. The asset owner cannot prove a negative through inspection of a black-box device. They cannot verify that firmware actually disables the modem under all conditions and across all maintenance modes. They cannot verify that no specific UART command, no specific GPIO sequence, no specific debug build, no specific recovery procedure will reactivate the radio. The only verifiable state is physical absence.
This is the defence-in-depth principle applied at the hardware layer: remove the capability that is not needed, rather than configure it suppressed. The capability that is not on the board cannot be enabled, cannot be exploited, cannot be re-enabled by a future firmware version, cannot appear in a future CVE, and cannot be reactivated by an attacker with physical access. The capability that is on the board, regardless of configuration, can be all of these things.
The components that arrive uninvited
The inventory is consistent across the industry.
Cellular radios — often 4G or LTE, sometimes 5G — frequently described in datasheets as "optional" or "for service support". Bluetooth, frequently positioned as a diagnostic or configuration interface, increasingly paired with a manufacturer's mobile application. Wi-Fi, sometimes for service engineer convenience, sometimes for asset tracking, sometimes for the manufacturer's cloud connectivity. Hidden USB management ports on managed switches, RTUs and HMIs, labelled "service only", typically exposing console access that bypasses every network control. Debug serial consoles on PCBs — UART headers exposed on the board, sometimes documented, sometimes not, sometimes with default credentials. Baseboard management controllers and out-of-band management interfaces on industrial PCs and SCADA servers, running their own embedded operating systems with their own attack surfaces. Proprietary radio links to weather stations, condition monitoring sensors, or vendor "ecosystem" devices. NFC tags for configuration by phone. ZigBee or LoRaWAN for low-power sensor meshes.
Two further categories deserve specific mention.
Mezzanine connectors and expansion slots are themselves a problem, separate from any card that may populate them. A controller delivered without a cellular modem but with the mezzanine connector intact, the antenna routing fitted and the power rail provisioned is a controller into which a cellular modem can be installed in fifteen minutes by anyone with physical access. A managed switch with an empty SFP cage that the asset owner does not need is a switch with an installation path for an unexpected uplink. The procurement specification should exclude the slot, not only the card.
"Out-of-band" is a term that needs careful handling. In network engineering, an out-of-band management network is generally a good thing — a separate, controlled path for managing infrastructure that survives failure of the production network. In OT security, "out-of-band" describes anything that bypasses the controlled access architecture, and is generally a bad thing. The same word, used in two communities, points in opposite directions. When a manufacturer's datasheet describes a feature as "out-of-band management" or "out-of-band diagnostic", the asset owner reads that as a defect rather than a benefit, and asks for it to be removed.
Where this conversation belongs
Three stages, three very different costs.
At specification stage, the conversation costs almost nothing. The procurement specification explicitly excludes cellular, Bluetooth, Wi-Fi, NFC and proprietary radio. It excludes hidden USB management interfaces. It excludes optional expansion slots that could host such components later. It requires the manufacturer to declare every wireless capability — present, absent, populated, unpopulated — in the compliance documentation. The manufacturer's product variant for the project is configured accordingly at the factory, and the variant appears in the bill of materials.
At factory acceptance test, the conversation gets expensive. The asset owner's commissioning engineer physically inspects every product variant. A spectrum analyser is used to detect active radios in the laboratory. PCBs are inspected for daughter cards, populated chips, RF traces and antenna connections. Findings result in a non-conformance, the equipment is returned to the manufacturing line, and the schedule slips while modifications are made. The cost is measured in weeks of programme delay and sometimes in re-certification of the modified equipment under the manufacturer's quality system.
At site acceptance test, the conversation is the most expensive. Equipment is on site. Sometimes there are hundreds of units installed. Retrofit means either returning units to the factory at significant logistics cost, or sending factory engineers to the site to perform modifications under field conditions, with all the quality control implications that field rework brings. Programme impact is severe; commercial impact can be severe enough to threaten financing milestones.
The pattern is consistent across many of the topics in this series, but it is starkest here. Specification is cheap, FAT is costly, SAT is painful. The discipline of moving the conversation to the cheapest stage is, in many ways, the entire procurement learning for non-EU manufacturers selling into EU-financed projects.
At proposal stage
A manufacturer's bid that arrives with a wireless-and-out-of-band capability matrix already attached — declaring every chip on the board with any RF capability, every connector that could host one, every management interface, every debug port, with a clear statement of which are populated, which are not, which can be removed for the project variant, and which cannot — is a bid that has saved everyone several months. The conversation that follows is whether the manufacturer's standard variant can be supplied or whether a project-specific build is needed, and if the latter, what the schedule and cost implications are.
A manufacturer's bid that does not mention any of this, on the basis that the equipment "supports" remote management or diagnostic access, is a bid that signals an architectural assumption — that the manufacturer's idea of a complete delivery includes capabilities the asset owner will need to subtract. That subtraction will happen at the worst possible point in the programme.
The principle is one the manufacturer's own product engineering team will recognise on reflection. Every chip on the board is a maintenance liability, a CVE exposure, a power draw, a thermal load, a regulatory burden, a supply chain dependency. Removing the ones that the deployment does not need is not a concession. It is sound engineering. The asset owner asking for the modem to be removed is asking for the same kind of discipline the manufacturer's own value engineering team would apply for a different reason.
The next article picks up a topic the manufacturer's procurement team will recognise immediately, even if their security organisation has not yet brought it to them: the IEC 62443-3-2 zone and conduit risk assessment that the L0/L1 system integrator is expected to produce for the project, and what it actually contains.
This article reflects the engineering and procurement practices common in EU-financed renewable energy projects at publication. Specific examples of components and interfaces are illustrative; the principle of physical removal over firmware disablement applies regardless of which particular technologies appear in any given product. If a citation has rotted or a clause has moved, LinkedIn is the way to flag it.