Low-Cost OT & IoT Security Guide for Small and Mid-Sized Businesses

If you run a grocery store, a restaurant group, a warehouse, a small manufacturing line, a commercial building or a clinic, you almost certainly have connected equipment nobody treats as a computer. Refrigeration controllers. A rooftop HVAC unit with a web interface. Cameras. Door controllers. An energy meter the utility can read. Each was installed by the contractor who supplied the equipment, and each probably got whatever network connection was convenient on the day.

That category of equipment is operational technology — OT — along with the IoT devices that have crept in beside it. The French supermarket refrigeration attack of October 2026 is what happens when nobody owns it: around 700 stores lost their chilled and frozen stock because controllers were reachable from the internet with a guessable password.

This guide is the cheap version of fixing that. It is written for an organisation with one firewall, maybe a managed switch or two, and no security team. Most of what follows is configuration rather than purchasing. If you run many sites, or you have a formal risk programme and auditors to satisfy, read the enterprise OT security architecture guide instead — the principles are the same, but the depth and the governance are different.

The one thing that matters most

If you do nothing else from this guide, do this: put the operational equipment on its own network, and do not let it start conversations with your business systems.

Segmentation is the highest-value control available to a small organisation, for three reasons. It is usually free, because the firewall and switches you already own support it. It limits damage in both directions — a compromised camera cannot reach the server, and ransomware on an office PC cannot reach the refrigeration. And it does not depend on the device being secure, which matters enormously when half of this equipment cannot be patched and some of it cannot even be given a real password.

Everything else in this guide is worth doing. None of it is worth as much as this.

The target architecture

                          Internet
                             |
                    Firewall / router
                             |
   ┌──────────┬──────────────┼──────────────┬──────────────┐
   │          │              │              │              │
Business   POS /         OT / IoT        Cameras       Guest Wi-Fi
  LAN      payment      refrigeration                 (internet only)
           systems         HVAC
 PCs                    building controls
 servers                 IoT devices
                             
                    Management network
              (switch, firewall and AP admin)

Five or six networks, carved out of equipment you probably already have. A worked example with VLAN numbers:

VLAN 10   Business computers      staff PCs, printers, file server
VLAN 20   POS / payment systems   tills, payment terminals
VLAN 30   OT / IoT                refrigeration, HVAC, BMS, sensors
VLAN 40   Cameras                 NVR and IP cameras
VLAN 50   Guest Wi-Fi             customers, personal phones
VLAN 99   Network management      switch, firewall and AP interfaces

Why cameras get their own VLAN rather than sitting in VLAN 30: a camera estate is usually the largest group of identical embedded devices in the building, it talks to a recorder constantly, and it is the group most likely to be running old firmware. Keeping it separate means a camera problem stays a camera problem.

Why payment gets its own: if you take cards, PCI DSS expects the cardholder environment to be separated from everything else, and the scope of your annual assessment is smaller when it is. That is a compliance benefit on top of the security one.

If your switch cannot do six VLANs, three gets you most of the value: business, OT/IoT, and guest.

The firewall rules

VLANs alone do nothing. A VLAN is just a separate broadcast domain; what makes it a security boundary is the policy between them. Written as rules:

Two rules in that table are worth dwelling on.

OT/IoT to Business LAN, blocked by default. This is the direction attackers travel after they land on a device. A refrigeration controller has no reason to open a connection to your file server. If something does need to cross — a temperature log written to an on-premises share, say — allow that one host, port and direction, not the subnet.

Internet to OT/IoT, blocked completely. This is the rule whose absence caused the French incident. There is almost never a legitimate reason for an inbound connection from the internet to a controller. "The vendor needs to dial in" is not a reason to open a port; see below for what to do instead.

Note that the direction of a rule matters more than people expect. Allowing the business LAN to reach the OT VLAN does not let the OT VLAN reach back, because the firewall only permits the return traffic of connections that started on the allowed side. That asymmetry is most of the value.

Remote access without exposing anything

Direct internet exposure is the thing to eliminate. The replacements, in rough order of how much work they are:

• Client VPN. Your firewall almost certainly has one. An engineer connects to the VPN, lands in a restricted group, and reaches only what that group is permitted to reach. Add multi-factor authentication — most firewalls support it natively now.
• Site-to-site VPN. For a vendor who manages your equipment continuously, a tunnel between their network and yours, restricted to the specific devices they maintain.
• Zero-trust remote access. A broker that authenticates the user, checks the device, and connects them to one application rather than to the network. More licensing cost, considerably less standing exposure.
• Vendor portal or jump host. A single hardened machine in the OT VLAN that vendors connect to and work from. Everything they do happens there, and it is the only thing they can reach.

Whichever you choose, the rule is the same: administration happens over an authenticated tunnel, never over an open port.

Fifteen controls, in order of value for money

1. Change all default passwords. Including the ones on cameras, door controllers and the switch itself. This is the single cheapest control there is.
2. Use unique passwords per device or per system. One shared password across forty devices means one compromise is forty.
3. Enable MFA wherever it exists — the firewall, the VPN, any cloud dashboard, the NVR. Where it does not exist, that system needs to be behind something that has it.
4. Remove unnecessary internet exposure. Audit your firewall's inbound rules and port forwards and delete the ones nobody can justify. Expect to find at least one nobody remembers creating.
5. Segment OT/IoT onto their own VLANs — as above.
6. Write the firewall rules between VLANs, default-deny, and test them by trying to reach the business LAN from a device on the OT VLAN.
7. Keep firmware updated on anything that still receives updates, and make a list of the things that do not. Equipment out of support is not automatically a crisis, but it has to be somewhere an attacker cannot reach.
8. Keep an inventory of connected devices — make, model, firmware, IP, what it does, who maintains it, and how they get in. A spreadsheet is fine. The absence of this document is why most organisations cannot answer "are we affected?" when an advisory lands.
9. Disable unused services and ports. Many controllers ship with Telnet, FTP and an unauthenticated HTTP interface enabled. Turn off what you do not use, and shut down switch ports nothing is plugged into.
10. Restrict vendor remote access to named accounts, specific devices, and ideally specific times.
11. Back up device configurations. A controller's programming — setpoints, schedules, alarm thresholds — represents real commissioning effort. Export it and store it somewhere that is not the device.
12. Log remote access. Who connected, when, from where, to what. Your firewall or VPN already produces this; the task is keeping it and occasionally reading it.
13. Use DNS filtering where the device's traffic passes through a resolver you control. It is a cheap way to stop a compromised device reaching a command-and-control domain, and it generates a useful log.
14. Monitor outbound connections from the OT VLAN. This is the signal that matters most on networks full of devices you cannot install anything on: a controller that suddenly starts talking to a new country is the alert you want.
15. Alert on new or unrecognised devices joining the network. Most business firewalls and controller-based Wi-Fi systems can email you when an unknown MAC address appears.

Items 1 through 6 are the ones to do this month. The rest are a reasonable quarter's work.

Minimum secure configuration

If you want a single baseline to hold a site to, this is a defensible one:

• Separate OT/IoT VLAN, distinct from business and payment networks
• No inbound internet access to OT devices
• Strong, unique credentials on every device and interface
• MFA on all remote access
• Administration over VPN or a zero-trust broker only
• Firewall isolation between zones, default-deny from OT toward business systems
• Firmware current on everything still supported, and a written list of what is not
• Configuration backups for controllers and network equipment, stored off-device
• Logging enabled on firewall and remote access, and retained
• Vendor access disabled when not in use, and enabled deliberately

A site meeting that list is not invulnerable, and it would not have been caught by the French campaign.

What if the equipment requires cloud access?

Plenty of modern equipment genuinely needs to reach a vendor's cloud — for multi-site temperature reporting, for remote diagnostics, for firmware. That is fine, and it does not require giving the device free rein.

Segmentation still applies. Permit the device outbound to:

• DNS — ideally to your own resolver, not to whatever the device prefers
• NTP — controllers care about time, because schedules and logs depend on it
• The specific HTTPS endpoints the vendor documents, by hostname where your firewall can filter on it
• Nothing else

And keep the inbound side closed. Outbound access to a vendor cloud does not require any inbound rule — the device starts the connection, and the firewall permits the replies. A vendor who asks you to open an inbound port for a cloud-connected device should be asked why.

What this does not mean is granting the device access to your internal business network. Cloud access and internal access are separate questions, and the answer to the second one is almost always no.

One practical warning. Some equipment arrives with its own cellular modem so the vendor can monitor it without touching your network. That connection does not cross your firewall, so none of your rules apply to it and it will not appear in any inventory you build from network scans. Several of the French controllers were connected this way. Ask your refrigeration and HVAC contractors directly whether any installed equipment has a SIM in it, and if it does, treat it as a device on an untrusted network that happens to be bolted to your building.

What if the vendor says the device must be remotely accessible?

They are usually right that they need access. They are usually wrong that it requires a port open to the internet.

Safer alternatives, any of which a competent service organisation will accept:

• Site-to-site VPN between their network and yours
• Client VPN with individual accounts for their engineers
• Zero-trust remote access scoped to the specific device interface
• A vendor jump host inside the OT VLAN that they work from
• Time-limited access enabled for a maintenance window and disabled afterwards
• IP allowlisting of their published source addresses, where they have stable ones — useful as an extra layer, though not sufficient on its own

Two things to insist on regardless of mechanism: named accounts rather than a shared vendor login, so you can tell which engineer did what; and no inbound port forwards, because that is the configuration that was swept up at scale in France.

If a vendor will not work with any of these, that is worth knowing about them before you sign the next service agreement. It is also a reasonable thing to raise at renewal: the market has moved, and asking for authenticated remote access is no longer unusual.

Estimated cost

It depends almost entirely on what you already own, and the honest answer for most sites is "less than you think".

If you already have a business-grade firewall and managed switches — which covers most organisations that have had any IT work done in the last decade — the cost is configuration labour. VLANs, inter-VLAN rules, a VPN, MFA and some logging is typically a day or two of engineering for a single site, plus an hour or two of discovery with your facilities contractor. There is no new hardware.

If your network is a consumer router and unmanaged switches, you need a modest upgrade: a small business firewall and one or two managed switches. That is a real but unremarkable capital cost, and it is the same equipment you would buy anyway for guest Wi-Fi isolation or PCI scope reduction.

If you have many sites, the per-site cost falls but the coordination cost rises, and that is the point at which the enterprise architecture guide becomes the right reference — central management, consistent policy and site isolation are what stop a per-store fix from being redone forty times.

We are deliberately not quoting fixed prices. Anyone who quotes you a number for "OT security" without seeing your switch stack is guessing.

Equipment that already does this

You very likely do not need to buy a security product. VLAN support and inter-VLAN firewalling are standard features of business networking equipment, including UniFi, Fortinet, Sophos, OPNsense, pfSense, Cisco and Aruba, among others. We are not recommending a platform here — the right one is usually the one you already have and your engineer knows. The relevant question is not which brand but whether the features are turned on, and in most environments we look at, they are not.

Two capability checks before you plan the work: can the switch tag VLANs on a port, and can the firewall write rules between internal interfaces rather than only between inside and outside. If both are yes, you have everything you need.

Checklist

Discovery

• Walk the site with facilities and list every connected device
• Ask each contractor what they maintain and how they connect
• Ask specifically about equipment with its own cellular modem
• Record make, model, firmware version and support status
• Review every inbound firewall rule and port forward

Segmentation

• Create VLANs for business, payment, OT/IoT, cameras, guest and management
• Move devices onto the correct VLAN
• Apply default-deny from OT/IoT toward business and payment
• Block guest Wi-Fi from all internal networks
• Remove all inbound internet access to OT devices
• Test the rules from a device on the OT VLAN

Access

• Change every default password
• Give each device or system a unique credential
• Enable MFA on firewall, VPN and any cloud dashboard
• Move all administration behind VPN or zero-trust access
• Replace shared vendor logins with named accounts
• Disable vendor access when not in use

Maintenance

• Update firmware on everything still supported
• List what is out of support and plan its replacement
• Disable unused services and shut unused switch ports
• Export and store configuration backups off-device

Visibility

• Enable logging on firewall and remote access, and retain it
• Alert on new or unrecognised devices
• Review outbound connections from the OT VLAN
• Add independent temperature or environmental monitoring where loss is expensive

That last item deserves a note. Because a compromised controller can be made to report normal temperatures while cooling is off, the monitoring that protects inventory is monitoring that does not come from the controller. A standalone sensor with its own alerting is inexpensive and it is what gets somebody out of bed at midnight instead of at six.

Further reading

• French Grocery Store Refrigeration Hack Shows the Growing Risk of OT Cyberattacks — the incident that makes this concrete
• Fixing the Refrigeration Attack: a remediation plan for Danfoss AK-SM and AK-SC sites — the specific fix if you run the equipment involved
• Enterprise OT Security Architecture — the same principles with zones, an OT DMZ, privileged access management and central monitoring
• Network Segmentation: Shrinking the Blast Radius — segmentation as a general discipline
• IoT Networking: Connecting Devices Without Opening Holes — getting devices connected without creating paths

If you would rather not do this yourself, our managed network operations and OT and ICS security teams do exactly this work. You can also check one thing yourself in the next five minutes: our free port scanner tests the connection you run it from and reports which service ports are reachable from outside. It only ever scans the address it is called from, which is yours.