Cybersecurity · October 13, 2026 · intSignal Security Team

Enterprise OT Security Architecture: How to Secure Connected Operational Systems at Scale

This is the architecture for organisations with many sites, many vendors and a risk programme that has to be evidenced: supermarket and retail chains, logistics operators, manufacturers, hospitals, universities, critical infrastructure and large commercial property portfolios.

It is the same five principles as the low-cost guide for smaller organisations — segmentation, controlled remote access, strong authentication, patching and monitoring — implemented with more depth, more zones and formal governance. If you run one site with one firewall, that guide is the better starting point, and there is no shame in it; a well-segmented single store is in better shape than a chain with a flat national network.

The October 2026 French supermarket refrigeration attack is the worked example throughout. Roughly 700 stores lost their chilled and frozen stock in a night because refrigeration controllers were reachable from the internet with a derivable password. What makes it instructive for an enterprise audience is not the vulnerability — it is that the same equipment, configured the same way, was deployed across hundreds of sites by contractors, and nobody centrally held a list.

Operational technology, for the avoidance of doubt, means the systems that control physical processes: programmable logic controllers (PLCs), refrigeration and building management, HVAC, cameras, access control, environmental sensors, production machinery. The distinction from IT is not the technology — much of it is ordinary Linux and web interfaces — but the consequence of failure and the constraints on maintenance.

1. Asset inventory and OT discovery

Everything downstream depends on knowing what you have, and in most enterprises the OT inventory does not exist. Equipment was specified by project teams, installed by contractors, and handed to facilities. It is on the fixed-asset register as a capital item, not on the CMDB as a networked device.

What you are looking for:

PLCs and their programming interfaces
refrigeration system managers and case controllers
HVAC and building management systems (BMS)
industrial gateways and protocol converters
cameras, NVRs and video management servers
environmental and energy sensors
vendor-supplied appliances
embedded systems inside larger plant
management interfaces of all of the above, which are often on a different address from the operational function

Prefer passive discovery. Active scanning is the default instinct from IT security, and on OT networks it is genuinely risky: older controllers and protocol stacks can be knocked over by a port scan, and a device that reboots during a scan is a production incident. Passive monitoring — a span or mirror port feeding a sensor that identifies devices from the traffic they already generate — is slower but does not touch the equipment. Where you do scan actively, do it in a maintenance window, with operations staff present, starting with a single device of each model.

Supplement the network view with records, because some equipment will never appear on your network at all. Service contracts, commissioning documents and the contractors' own remote-access lists are all sources. Ask every vendor directly whether any installed equipment has its own cellular connection — some of the French controllers were connected via 3G modems for remote monitoring, which means no site firewall ever saw them and no network-based inventory would have found them.

The inventory needs an owner, a review cadence and a field for support status. "Which of our sites have an AK-SM800" is the question an advisory forces, and the answer should take minutes.

2. Enterprise segmentation

The Purdue model is the usual reference here — a layered view running from enterprise business systems at the top, through a DMZ, down to supervisory systems, control systems and finally the sensors and actuators. It is worth knowing, and it is worth not being dogmatic about: modern environments have cloud services and remote vendors that the original model never contemplated.

The practical shape:

Enterprise IT
     ↓
IT / OT DMZ
     ↓
OT management and security services
     ↓
Site operational networks
     ↓
Controllers and devices

Segment along more than one axis:

Business function — refrigeration, HVAC, access control, production
Facility — each site, campus or building isolated from the others
Security zone — by trust level rather than by geography
Device type — cameras separated from controllers separated from gateways
Criticality — systems with safety or spoilage consequences separated from convenience systems

The anti-pattern is the single enterprise-wide OT VLAN. It appears because it is easy to manage: one address range, one set of rules, every site reachable from the central management server. It also means one compromised device at one site has a path to every controller in the estate, which is precisely the condition that turned a controller vulnerability into a national incident in France.

3. The OT DMZ

Between enterprise IT and the operational networks sits a demilitarised zone that both sides can reach and neither side passes through. Direct IT-to-OT communication should be the rare, documented exception.

Services that typically live there:

Jump servers that administrators and vendors work from
Update and patch repositories, so controllers never reach the internet for firmware
Historians collecting process and temperature data for business reporting
Remote access gateways
Proxy services for the cloud endpoints OT equipment needs
Security monitoring collectors aggregating passive sensor data
File transfer systems for moving configurations and reports between zones

The reason to minimise direct IT-to-OT traffic is blunt: enterprise IT is where phishing lands. An office laptop is the most likely initial foothold in almost every incident, and the DMZ is what stops that foothold becoming a path to a refrigeration controller. Data flows up through the DMZ; control flows down through authenticated gateways; nothing flows straight across.

4. Firewall policy

Default-deny between every zone. Permit by explicit rule only, specifying:

source — a host or small group, not a subnet
destination — likewise
port and protocol
direction

Avoid broad any-to-any rules, and avoid the "temporary" rule written during commissioning that nobody removed. In practice, firewall rule review finds more risk than any other single exercise we run: the rules accumulate, the projects that needed them finish, and nothing deletes them.

Two policies worth stating explicitly, because they are the ones that fail:

No inbound internet access to any OT zone. Vendor access is provided through the remote access gateway, never by a port forward.
Egress from OT is allowlisted, not open. A controller that needs a vendor cloud gets DNS, NTP and the documented endpoints. Open outbound access is how a compromised device reaches its operator, and it is far more common than open inbound.

Document each rule with a business justification and an owner, and review them on a schedule. A rule nobody will claim is a rule to remove.

5. Secure remote access

Remote access is the control that most needs centralising, because the alternative is dozens of arrangements made independently by vendors and project teams.

A mature arrangement provides:

A centralised remote-access gateway — one documented way in, for staff and vendors alike
Multi-factor authentication on every account, no exceptions for service organisations
Privileged access management (PAM) brokering credentials, so the engineer never knows the device password
Session recording for privileged OT sessions, which is as valuable for diagnosing what a vendor changed as it is for security
Approval workflows for access to critical systems
Temporary credentials and just-in-time access, so standing access is the exception
Vendor-specific scoping — each vendor reaches only the equipment they maintain, at the sites they maintain it at
Automatic session expiration, so nobody is logged in for three weeks

The test of this design is whether you can answer, within a few minutes, who connected to a given controller in the last ninety days. If the answer requires asking the vendor, the architecture is not finished.

6. Vendor risk

At enterprise scale, OT security is mostly vendor governance. The equipment is installed, maintained and remotely accessed by other companies, and the contract is where your requirements become real.

Require, in writing:

Named individual accounts, never a shared vendor login
MFA for all access to your environment
No shared credentials between customers — the "code-of-the-day" scheme in the French incident was effectively a shared credential across every installation worldwide
Documented remote access: what they connect to, how, from where, and which of their staff are authorised
Vulnerability management commitments — how they notify you of flaws in their products and how quickly they ship fixes
Breach notification requirements, with a timeframe
Lifecycle and update commitments: how long the product receives security updates, and what the migration path is at end of life

That last point is the one the French incident turned on. The affected controllers were end-of-life products that will not be patched. That is a legitimate commercial position for a manufacturer, but it has to be a known position, with a replacement programme behind it, rather than something you discover from the news. Ask for the support end date of every model you operate, and put it on the asset inventory.

7. Identity and privileged access

PAM for OT administrative credentials, with check-out, rotation and recording
Least privilege by role — a refrigeration technician does not need access to access control
Separate OT administrative accounts, distinct from IT domain admin and from daily-use accounts
No daily-use credentials with administrative rights — the account that reads email should not be able to reprogram a controller
Service account management: inventoried, scoped, documented, and owned by a person
Credential rotation on a defined cycle, and immediately when a vendor engineer leaves their firm

Shared local accounts on devices are the hardest part of this, because much OT equipment supports only one. Where a device cannot do named accounts, the named account lives on the jump host in front of it, and the device credential is brokered by PAM so no human holds it.

8. OT monitoring

Most OT devices cannot run an agent, so monitoring is network-based.

Passive network monitoring on span or mirror ports, identifying devices and baselining normal traffic
Anomaly detection tuned to OT, where normal is far more predictable than on an IT network — which makes deviation easier to spot
Intrusion detection with signatures for industrial protocols
Centralised logging from firewalls, gateways, jump hosts and anything else that will produce a log
SIEM integration, so OT events sit alongside IT events and a correlated attack is visible as one thing

What to alert on, in rough priority:

Unusual outbound connections from an OT zone — the single highest-value signal available on networks of unpatched devices
Unauthorised configuration changes to controllers, setpoints or schedules
New devices appearing in an OT zone
Unexpected protocols, particularly management protocols where only operational traffic belongs
Authentication failures on gateways and jump hosts

One lesson from France deserves its own place in the monitoring design. Researchers demonstrated that a compromised controller could be made to disable cooling while continuing to report normal temperatures. Safety and loss monitoring must be independent of the control system it monitors. Independent environmental sensors, on a separate path, with their own alerting, are inexpensive relative to a store's frozen inventory and they are not subject to the same compromise.

9. Network access control

Device identification before network access, by certificate where the device supports it and by MAC with profiling where it does not
Port security on access switches: limit MAC addresses, shut unused ports
NAC to place devices into the correct zone automatically based on identity or profile, which also prevents the commonest segmentation failure — a device patched into the wrong port
Authentication where appropriate: 802.1X on ports serving equipment that supports it, MAC authentication bypass with profiling for equipment that does not
Quarantine for unknown devices, into a zone with no access to anything, with an alert

Be realistic about coverage. A large estate will have equipment that cannot authenticate at all, and the answer for those is a dedicated zone and tight firewall policy rather than forcing a technology the device cannot support.

10. Endpoint and device security

Where the platform supports it:

EDR on OT servers, engineering workstations, historians and jump hosts — these are ordinary computers and should be treated as such
Application allowlisting on engineering workstations, which change rarely and are therefore good candidates
Secure configuration baselines per device type, with drift detection
Firmware validation — signed images, verified before deployment
Patch management integrated with the maintenance calendar

Be clear-eyed that many embedded OT devices cannot run an endpoint agent at all, and never will. There is no EDR for a case controller. Those devices are protected by the network around them, the access controls in front of them and the monitoring watching them — which is why the architecture carries the weight rather than the endpoint.

11. Patch and vulnerability management

OT patching is a scheduling problem more than a technical one.

Test patches before deployment, on a representative bench or a single low-criticality site
Coordinate maintenance windows with operations — a refrigeration controller reboot in a stocked store is an operational decision, not an IT one
Prioritise externally exposed vulnerabilities first, then internet-adjacent, then internal. CVE severity alone is a poor ranking; a medium-severity flaw on an internet-reachable controller outranks a critical on an isolated one
Isolate what cannot be patched. End-of-life equipment is a fact of OT life. The response is a tighter zone, stricter firewall policy, no remote access and closer monitoring
Use compensating controls and document them, so the risk register reflects reality rather than an aspiration to patch

A note on timelines. One of the flaws involved in the French incident carries a 2023 identifier. Several carried 2025 identifiers. The gap between disclosure and mass exploitation was years, not days, which is encouraging — it means a functioning vulnerability management process had time to work. The stores that suffered did not have one looking at refrigeration.

12. Redundancy and operational resilience

Security controls fail; the business still has to run.

Redundant controllers for critical processes
Network redundancy so a switch failure does not blind a site
Fail-safe states — know what the equipment does when it loses its controller or its network, and make sure the answer is safe. Refrigeration that holds its last setpoint when the manager is unreachable is better than refrigeration that defaults to defrost
Manual operating procedures so a site can run while systems are isolated, including who is allowed to force a compressor on
Configuration backups for every controller, stored centrally and tested by restoring one
Disaster recovery covering OT, not only data centre systems
Spare equipment on the shelf for long-lead controllers

The French stores that recovered fastest were the ones that could restore a controller configuration and get cooling back. Commissioning data represents days of engineering; losing it turns a security incident into a two-week outage.

13. Zero trust concepts for OT

Zero trust is worth applying carefully and describing honestly. The marketing version — verify every device, authenticate every connection — assumes endpoints that can hold an identity and run an agent. A twelve-year-old refrigeration controller can do neither, and pretending otherwise produces an architecture nobody can implement.

The principles that do transfer:

Verify users strongly, every time, at the gateway in front of the equipment
Restrict paths so each identity reaches only the specific systems it needs
Least privilege by role and by site
Authenticate management access even when the operational protocol cannot be authenticated
Monitor continuously, and treat the network as the enforcement point for devices that cannot enforce anything themselves
Minimise trust between zones — no zone is trusted because it is internal

In short: apply zero trust to the humans and the management plane, where it works well, and use segmentation and monitoring for the devices, where it does not. Our general treatment of zero trust in practice covers the IT side of the same programme.

14. Multi-site architecture

For a chain of stores, depots or branches:

Store / site
     ↓
Local OT firewall
     ↓
Secure WAN / SD-WAN
     ↓
Enterprise OT security zone
     ↓
Central management

The design requirement that matters most: each site stays segmented even if corporate systems are compromised. A store should not be reachable from another store, and compromise of the central management platform should not hand an attacker every controller in the estate.

That means a local enforcement point at each site rather than relying on policy at the core, site-to-core connectivity that is authenticated and encrypted, and central management that reaches sites through a gateway rather than by flat routing. SD-WAN makes this considerably easier to operate at scale, because the segmentation policy travels with the overlay instead of being rebuilt per site.

Avoid flat nationwide OT networks. They are the architecture that makes a single controller vulnerability into a national news story.

15. Cloud-connected OT

Modern OT genuinely needs cloud connectivity — multi-site temperature compliance reporting, vendor diagnostics, fleet firmware management. Permit it deliberately.

Controlled egress through a known path, not direct internet access from the device
Proxying in the OT DMZ, so the controller talks to your proxy and the proxy talks to the vendor
Allowlists by hostname and destination, reviewed when the vendor changes endpoints
Secure APIs with authentication and transport security, and a documented data flow
Private connectivity — dedicated interconnect or private endpoints — where the data volume or sensitivity justifies the cost
Cloud identity controls on the vendor's portal: your organisation's MFA, named accounts, and offboarding that actually happens

The governance question to answer before any of the technical ones: what data leaves, where does it go, who at the vendor can see it, and what happens to it when the contract ends.

16. Incident response

An OT incident response plan is not the IT plan with different hostnames. The default IT reflex — isolate and power down — can be the wrong move when the equipment is holding a physical process in a safe state.

Identify affected systems using the asset inventory, by model and site
Preserve safe operation as the first priority. Keeping product cold, or a process stable, usually outranks forensic purity
Isolate compromised segments at the local firewall rather than unplugging controllers
Coordinate with operations staff, who understand what the plant will do when you change something. The decision to stop equipment is theirs
Do not blindly shut down safety-critical equipment. Some processes are more dangerous stopped than running
Preserve logs and evidence early, because OT devices have small buffers and overwrite quickly
Recover from trusted configurations — the backups from section 12, verified before they are pushed back

Rehearse it. An OT incident involves facilities, operations, IT, security, the equipment vendor and possibly a regulator, and the first time those people speak to each other should not be at two in the morning with the freezers warming.

17. Security testing

Architecture reviews against this sort of reference design, repeated when the estate changes
Firewall rule reviews, which reliably find the most risk per hour spent
Configuration assessments of controllers, gateways and jump hosts against your baselines
Controlled penetration testing, scoped and scheduled with operations
Tabletop exercises covering the incident response plan above
Vendor-access testing — try to use a vendor's path and see what it actually reaches, which is frequently more than the contract describes

OT penetration testing must be coordinated carefully. Techniques that are routine on an IT network can disrupt fragile controllers, and an unannounced test that stops a production line destroys the programme's credibility. Test on a bench or a non-production site where possible, keep operations in the room, and agree stop conditions in advance. Our penetration testing practice runs OT engagements this way for exactly this reason.

18. Enterprise reference architecture

              Internet / Vendors
                      |
             Remote Access Gateway
                   (MFA, PAM)
                      |
              Enterprise Firewall
                      |
                  IT / OT DMZ
       (jump hosts, repositories, historians,
            proxies, monitoring collectors)
                      |
               OT Core Firewall
                      |
    ----------------------------------------
    |               |                      |
Store / Site A  Store / Site B      Store / Site C
    |               |                      |
Local OT FW     Local OT FW          Local OT FW
    |               |                      |
  HVAC            HVAC                   HVAC
  Refrigeration   Refrigeration          Refrigeration
  BMS             BMS                    BMS

Read it as a set of chokepoints. Every path from outside passes the remote access gateway. Every path from enterprise IT passes the DMZ. Every path to a device passes that site's local firewall. No two sites are adjacent.

19. Enterprise minimum standard

A baseline to hold the estate to, and to audit against:

Complete OT asset inventory, owned and reviewed, including support end dates
IT/OT segmentation with no direct enterprise-to-controller paths
An OT DMZ carrying the services both sides need
Default-deny firewall policy between all zones, reviewed on a schedule
Centralised secure remote access as the only way in
MFA on all remote and administrative access
PAM for OT administrative credentials
Passive network monitoring in every OT zone
Centralised logging with SIEM integration
Vendor access governance in contracts and enforced technically
Vulnerability management covering OT, with compensating controls documented
Configuration backups for all controllers, restore-tested
An OT-specific incident response plan, exercised
Annual architecture review

Meeting that list does not make an estate impregnable, and no architecture does. What it does is remove the paths that get swept up in opportunistic campaigns, and make the remaining paths observable — which is the realistic goal. Defence in depth is not a promise that nothing gets through; it is an arrangement where several independent controls each have to fail before the consequence is physical.

20. Why this matters: the French supermarket incident

It is worth closing on the incident, because it is the clearest recent demonstration that routine building technology is now both a cybersecurity and an operational risk.

Nothing exotic was involved. The refrigeration controllers at roughly 700 French supermarkets were reachable from the public internet, their authentication was derivable from the date, several models were past end of life, and the vulnerabilities had been publicly documented for as long as three years. A scheduled defrost cycle — a maintenance function, not an attack tool — was turned into a heater, and stores lost whole aisles of stock, with some equipment catching fire.

Every control in this guide addresses some part of that chain. Asset inventory would have identified the end-of-life controllers. Segmentation and default-deny firewall policy would have taken them off the internet. Centralised remote access with MFA would have removed the need for direct exposure. Vendor governance would have surfaced the support end dates. Passive monitoring would have flagged the connections. Independent temperature monitoring would have raised an alarm while the product was still cold. Site isolation would have kept it to a handful of stores rather than hundreds.

None of those controls is novel, and none is expensive relative to the loss. The reason they were absent is that refrigeration was nobody's security responsibility — it belonged to facilities, the contractor and a service agreement, and the asset register had it down as a capital item rather than a networked computer with a web server on it.

That is the gap worth closing, and it starts with a list of what you own.