Operations at our factory purchased and began deploying an IoT energy-monitoring system without involving IT. The project apparently has no agreed plan for device connectivity across the site, switches or cabling, VLANs, OT/IT segmentation, servers or virtual machines, databases, backups, monitoring, internet access, vendor remote access, firewall rules, or cybersecurity responsibilities.
Now that implementation is underway, the vendor has asked for "access to the router" to bring everything online. I'm not comfortable giving a third party administrative access to our corporate router or connecting unknown industrial devices directly to the production network. IT and OT should remain appropriately separated, and we need to understand the architecture, required protocols and ports, hosting model, support boundaries, and security implications first.
How would you handle this both technically and organizationally? I want to help the project move forward without simply becoming the person who says no, but I also don't want IT to inherit responsibility for an unsafe or unsupported design.
4 Answers
The technical solution depends on what the system actually is. Energy meters may connect to local gateways or a building-management headend rather than needing every device on the corporate LAN. A safer pattern is devices on non-routed OT segments, a controlled application tier or collector, and access to the management interface through an approved jump host or remote-access platform.
Ask the vendor to provide a network diagram and implementation guide before opening anything. Confirm whether the system requires inbound connections, whether outbound-only communication works, where data is stored, how backups and updates work, and how vendor support is authenticated and logged. “Access to the router” is not a technical requirement until they can specify exactly what changes are needed and why.
For a small or poorly integrated deployment, a separate physical internet connection and vendor-managed router can keep the equipment completely off the corporate network. That can be a practical containment measure when the vendor cannot provide a suitable architecture quickly.
It is not automatically a good long-term design, though. Make sure ownership, patching, monitoring, remote access, incident handling, and contract responsibilities are documented. If the system must exchange data with corporate systems, don’t casually bridge the networks later; design a controlled application or DMZ connection instead.
Do not give the vendor administrative access to the corporate router or firewall. Start by getting a proper requirements document from the vendor: device and server locations, communication flows, protocols, ports, cloud dependencies, remote-support method, authentication, logging, patching, and ownership.
A reasonable interim design is a dedicated, isolated IoT or OT segment with only the explicitly required traffic allowed. Keep it separate from production and corporate networks, use least privilege, and make sure any vendor access goes through an approved, monitored access path. Document that the design is provisional and that IT will support only the components it has reviewed and accepted.
An isolated VLAN is useful, but it should not automatically mean unrestricted internet access. In a properly segmented factory, the device network may need to communicate only with a local application server or a tightly controlled intermediary.
Treat this as a management and risk-acceptance issue, not just a technical ticket. Put the concerns in writing and involve your manager, security, legal or compliance, the project owner, and whoever accepts operational risk. Ask for an approved change request and a named business owner for the system.
Be clear about the red lines: no third-party firewall administration, no direct connection to production, no undocumented ports, and no assumption that IT supports infrastructure it never approved. Then offer a path forward instead of just refusing: a requirements meeting, a security review, an isolated network design, and a documented support and ownership model. If leadership chooses to accept residual risk, that decision should come from an authorized executive rather than being silently transferred to IT.
Keep the whole discussion in writing. If the project later fails or causes an incident, the record should show that IT was excluded initially, identified the risks, and proposed controlled alternatives.
This approach can reduce immediate exposure, but it should not be used to avoid all oversight. A separate connection still needs security review, especially if the vendor has remote access or the devices can affect physical operations.