IoT and OT: Matter, Thread and industrial segmentation

Almost everything this course has taught so far quietly assumes a device that can look after itself. It runs an operating system somebody maintains. It accepts a patch when one is published. It carries software that reports what it is doing. Somebody is signed in to it, and that somebody can be asked a question. Strip those four assumptions away and most of the security advice written for office networks stops working, because every one of those pieces was doing part of the job.

The growth in connected things is precisely in hardware with none of them. A door sensor has no user. A temperature probe has no spare memory for monitoring software. A lighting controller fitted during a building refurbishment has a service life matched to the building rather than to a three-year refresh cycle, and the supplier who wrote its firmware may not exist by the time it needs attention. These are not edge cases at the margin of a network. In many estates they are already the majority of the things holding an address.

None of the networking changes, and that is the encouraging half of the story. The sensor still gets an address. It still resolves a name or is handed one. It still opens a transport connection that behaves exactly as the applied stage described, and it is still reached across routed paths whose forwarding decisions you already know how to read. Nothing in this module asks you to learn a second internet. It asks you to apply the first one where the usual safety nets are missing.

What does change is where a control can be placed. On a laptop you have three positions available: the endpoint itself, the identity system that decides who the user is, and the network in between. On a door sensor you have one. When the endpoint cannot carry a control and no user exists to authenticate, the network stops being plumbing and becomes the control surface. Addressing, segmentation, evidence and blast radius all have to bear more weight, because nothing else is standing behind them.

The population splits into two halves that look unrelated and are not. One half sits in homes and buildings: cheap radios, battery-powered devices, a hub bought in a shop. The other sits in plants, substations, pipelines and hospitals: controllers that open valves, start motors and stop machinery when a person gets too close. Both halves are hardware that cannot defend itself, and both push the same work onto the network. They are worth taking in that order, because the consumer half standardised recently and in public, and it happens to be the clearest working demonstration of something the foundations stage spent a whole module on.

For most of the smart home's history the problem was not radio range or battery life. It was that every manufacturer shipped its own protocol and its own hub, so a light and a lock from different suppliers could only meet inside an application that somebody had written to translate between them. Interoperability was a bridging exercise repeated per pair of vendors, which is the least durable arrangement in networking and the one this course has watched fail at several layers already.

Matter, from the Connectivity Standards Alliance, answers that by standardising at the top rather than at the bottom. It is an application-layer standard: a shared vocabulary for what a lock, a light or a sensor is and what you may ask it to do. It does not replace the network underneath. It runs over IP, on Wi-Fi, Ethernet and Thread. One language, several roads. A controller that speaks Matter can command a device on any of those roads without knowing or caring which one the device took.

Threadis one of those roads, and it is the one worth a networker's attention because of what it carries. It is a low-power wireless mesh for devices in homes and buildings, and it carries IPv6 all the way to the device. Not IPv6 translated at a gateway, not a proprietary frame lifted into IP at a hub, but an address on the device itself. Mains-powered members of the mesh relay for battery-powered ones, so the mesh heals around a device that has been unplugged, and the sensors on it can sleep almost all of the time.

The piece that joins the two worlds is the border router. It routes packets into and out of the mesh, most often between the Thread mesh and Wi-Fi or Ethernet. The verb matters: it routes rather than translates. Because the mesh already speaks IPv6, the border router is doing the ordinary job any router does at a boundary. Without one, the devices in the mesh can talk to each other perfectly well and nothing else on the network can reach them at all, which is a useful thing to know when a newly installed sensor is invisible to the hub two rooms away.

Put those three pieces together and the result is quietly significant. Households and offices are now running IPv6 segments that nobody consciously chose, designed, or wrote down. Everything the foundations module established about IPv6 applies to them without amendment: the device holds a global address, nothing rewrites that address in flight, and what decides whether a packet from outside reaches the lock is a stateful firewall applying a written policy. If no policy was ever written, the honest description of the boundary is that there is not one.

The map above is worth reading upwards, because that is the direction the exposure runs. At the bottom, sensors, a lock and lights speak Matter over Thread on the low-power mesh. Mesh hops carry their traffic to the border router, which joins them to the home network by routing IPv6. Above that sits the ordinary local network, with a Wi-Fi access point, a Matter device that took the Wi-Fi road because it wanted more bandwidth, and the controller that commissioned every one of them. Above that again is the IPv6 internet, reached with a global address and no translation.

For a professional, the useful transfer is not the smart home. It is buildings. Lighting, access control, occupancy sensing and metering are arriving in commercial estates on exactly this pattern, usually procured by a facilities team rather than by the people who run the network. The design questions are the ones you would ask about any new segment: where does the border router sit, which network does it join, what is the mesh permitted to reach, and who finds out when a device that has been quiet for a year starts talking to something new.

The consumer half of the story is comfortable because the devices are cheap, the stakes are a light that will not turn on, and a device that misbehaves can be unplugged. The industrial half shares the hardware constraints and shares almost none of that comfort, and the difference is not a matter of degree. It changes which property you are protecting first.

Operational technology is the family of programmable systems and devices that interact with the physical world: industrial control systems, building automation, transport systems. The defining feature is not that the equipment is old or the protocols unfamiliar. It is that these systems detect or cause physical change. A misconfiguration does not leak a spreadsheet. It stops a line, spoils a batch, floods a chamber or moves something heavy while a person is standing next to it.

That consequence inverts the priority order the rest of this course has assumed. Office networking puts confidentiality first by habit: the worst outcome is data reaching somebody it should not. In operational technology, availability and safety outrank confidentiality. The plant would rather an unauthorised person read a temperature reading than have the reading arrive late, and it would rather everything in the building read the reading than have the safety system unable to act on it. That is not carelessness about security. It is a correct assessment of which failure hurts somebody.

The second difference is time. In an office estate a patch window is measured in weeks, and an urgent one in hours. In operational technology, patch windows are measured in years. A controller running a continuous process cannot be restarted because a supplier published an update; the window is a planned shutdown, and planned shutdowns may come round annually or less. Some equipment is under a safety certification that a firmware change invalidates until the certification is redone. None of that is negligence, and telling the plant to patch faster is advice that cannot be taken.

Both differences point the same way. Controls that assume patching, an agent, a reboot or an aggressive probe do not transfer. A scan that an office team runs weekly without a second thought asks unusual questions of devices that were built when nobody was asking questions at all, and equipment built to answer one protocol predictably is not always built to shrug off traffic it does not recognise. The safest general rule is that anything relying on the endpoint tolerating surprise is not available to you here.

What does transfer is everything this course has taught about the network itself: segmentation, evidence gathered by watching rather than by probing, controlled crossings, and a clear view of blast radius. If a compromised laptop in the accounts office can reach a controller, that is a network design decision, and it is one that can be revisited without touching a single piece of certified equipment. This is the reason segmentation carries a heavier load in operational technology than anywhere else in the course: it is often the only control that can be strengthened without asking the plant to change.

There is a matching failure in the other direction, and it is worth naming because this material tends to be taught from one side only. An IT team that arrives with the office playbook, scans everything and mandates a patch cycle will be shown the door, correctly. An operational team that treats every change as unacceptable ends up with a network that cannot be observed, cannot be evidenced and cannot be defended when a regulator asks. The honest position is that the constraints are real and the network work is still possible, because the network is the layer that can be changed while the plant keeps running.

Accepting that the network carries the load raises the design question directly. If segmentation is the control that has to work, what decides where the boundaries go? The industry has one very famous answer to that question, and it is the wrong tool for the job, for reasons that are more interesting than the usual complaint that it is old.

The Purdue model is a layered picture of an industrial control network. It numbers levels from the field devices at the bottom up to enterprise systems at the top, with a demilitarised zone sitting between the plant and the office. It is genuinely useful. Hand it to somebody who has never seen a plant network and they will understand, in about a minute, that a sensor and a payroll system are not neighbours and that something ought to sit between them. NIST presents it as one way to think about segmenting operational technology, alongside other reference pictures, rather than as a deployment blueprint.

The trouble starts when the picture is handed to an engineer as a target state. A modern plant sends telemetry to a supplier's analytics service, takes remote diagnostics from a manufacturer, and runs industrial IoT sensors that report to something the plant does not own. Those data paths do not climb the levels one at a time and were never intended to. They cross the ordering by design. Insist that the levels are the rule and you get an architecture that either cannot be built or is quietly bypassed by every project that needed a cloud endpoint, which is the worse of the two outcomes because the bypass is undocumented.

Zones and conduitsis the IEC 62443 way of describing the same network, and it asks a different opening question. Not "which level is this at?" but "which assets share a security requirement, and what would it mean if this group were compromised?" Assets with a common requirement are grouped into a zone. Every permitted path between zones is a named conduit that carries its own requirements. The rule that gives the method its force is the negative one: a path that is not expressed as a conduit is not allowed.

The zone board at the top of this module is that method drawn out. The enterprise zone holds business applications, corporate laptops and the open internet: the ordinary estate, patched by an IT team on an ordinary cycle. The DMZ zone, the demilitarised zone in the middle of the board, holds a historian replica, which is a copy the enterprise may read rather than the running source, and a brokered jump host whose sessions are recorded and bounded in time. The control zone holds SCADA servers, operator screens, controllers and safety instruments, and the board says plainly why it is treated differently: availability and safety outrank confidentiality there, and patch windows are measured in years.

The two conduits are the whole point of the drawing. Between the enterprise zone and the DMZ, one named protocol, authenticated at the boundary and logged, and everything else denied. Between the DMZ and the control zone, a brokered session only, so no enterprise host ever reaches a controller directly. Notice how little the diagram contains. Three zones, two crossings, and the Purdue levels reduced to grey context tags in the corner of each zone so that a reader can still place themselves. That sparseness is the design working: the crossings are few enough to be named, reviewed and defended one at a time.

This gives you a clean division of labour worth committing to memory. The zone decides the blast radius, because it defines what shares a fate. The conduit decides the crossings, because it defines what may move between fates and under what conditions. Get the zone wrong and a single compromise reaches further than you expected. Get the conduit wrong and it reaches somewhere it was never supposed to go at all. Most arguments about industrial segmentation turn out, on inspection, to be one of those two questions wearing the other one's clothes.

The logic will feel familiar from the practice stage, and it should. Default deny with named exceptions is the same instinct as zero trust, arriving from a different tradition and carrying a different priority order. Where a zero trust design starts from the identity of a user or workload and authorises per request, a zone design starts from the physical consequence of a compromise and authorises per crossing. They are not rivals. The conduit is where per-request authorisation belongs in a plant, and the brokered jump host on the board is exactly that idea in equipment you can buy.

Two documents sit behind this work and they bind in different ways, which is worth being precise about because the two are often quoted in one breath. NIST SP 800-82r3, the guide to operational technology security, is the engineering reference. It is guidance rather than law: it binds by adoption, through contracts that name it, through auditors who expect it, and through your own decision to design against something defensible. The NIS2 Directive is the other kind. It is European law.

The European Commission's account of the directive is short and worth taking at face value. Directive (EU) 2022/2555 requires medium and large entities across a wide list of critical sectors to put cybersecurity risk management measures in place and to report significant incidents to their national authority, and member states had to write it into national law by 17 October 2024.

The list of sectors is what makes this bind on people who never thought of themselves as critical national infrastructure: energy, transport, water, waste, manufacturing, digital infrastructure and more, at medium size and above. For a network professional the practical effect is that a segmentation design stops being an internal engineering preference and becomes something a regulator may ask to see, which changes who has to be able to explain the zone boundaries and why they sit where they do.

The pairing is a useful one to hold. NIS2 tells you that you are answerable and that incidents have to be reported. SP 800-82r3 and IEC 62443 tell you what a defensible answer looks like when somebody asks how the plant is segmented. Neither document draws your zones for you, and neither will accept a picture of the Purdue levels as evidence that the work was done.

One question is still open, and it is the one the opening case answers. Zones and conduits describe the traffic that carries the work. They say nothing yet about the equipment that configures the zones, watches the conduits and holds the credentials for both. That equipment turned out to be where a very capable adversary chose to spend its time.

Every network runs two kinds of traffic that this course has mostly treated as one. There is the traffic that does the work: your web requests, the sensor readings, the historian replicating. And there is the traffic that decides how the first kind behaves: the sessions that push configuration to a router, the telemetry coming back from it, the accounts that authorise both. The first is the data plane. The second is the management plane, and it is a much smaller and much more valuable thing.

Salt Typhoon went after the second. A People's Republic of China state actor was inside major United States telecommunications operators from October 2024. CISA published hardening guidance for communications infrastructure in December 2024, and the joint advisory AA25-239A followed in August 2025. The reason this belongs in a networking course rather than only in a security one is the choice of objective. An intruder who holds the management plane does not need to defeat encryption or tap a cable. They can use the network's own interfaces to change what it does and to read what it knows, and the network will comply, because complying is what those interfaces are for.

CISA now advises high-risk users to prefer end-to-end encrypted messaging. Read that slowly, because it is a stronger statement than it first appears. It is an acknowledgement that the confidentiality of a communication cannot be assumed from the trustworthiness of the network carrying it. That is not a new idea in this course. It is the argument the TLS module made in the applied stage, that what protects a conversation is the encryption held at both ends and not the reputation of the path in between. What is new is that the advice is being given about carrier infrastructure by the agency responsible for defending it.

The generalisation is uncomfortable and useful in equal measure. Carrier infrastructure is contested ground rather than neutral plumbing. Buying transit, broadband or mobile connectivity does not move the risk to somebody else's books; it means part of your path is maintained by an organisation that is itself a target of national-level actors. Practically, that argues for the discipline this course has taught throughout: encrypt what matters end to end, know which properties your encryption actually gives you, and design as though the path is observed rather than hoping it is not.

That is where the two halves of this module meet, and it is the most valuable thing in it. The method the industrial world worked out for protecting equipment that cannot defend itself is exactly the method an IT estate should apply to the equipment that controls everything else. Put the management systems in their own zone. Allow one named crossing into it. Make that crossing a brokered session that is authenticated, recorded and bounded in time, which is precisely what the jump host in the DMZ zone of the figure is doing for the plant. The vocabulary was built for a refinery and it works, without amendment, for a network operations centre.

It also puts a healthy question next to the automation this course turns to next. Model-driven configuration and streaming telemetry make the management plane larger, busier and far more capable, because a single change can now reach every device in minutes rather than one router in an evening. That capability is the point of the work, and it is also a change in blast radius. A pipeline that can configure the whole estate is a control-zone asset by any honest reading of this module, however comfortable the office it happens to live in.