"Read-Only" Is Not a Security Architecture
A path that cannot write reduces a defined class of write-path risk, and that reduction is real. It still establishes no secure architecture — because "no inbound session" is a property of a connection, not a property of a system.
Someone proposes a condition-monitoring gateway. Someone else asks whether it is safe. A third person says the connection is read-only, and the conversation ends there.
It should not. A path constrained so that it cannot write does reduce a defined class of write-path risk, and that reduction is real rather than rhetorical — a path that cannot write is a narrower problem than one that can. What the label does not do is establish a secure architecture.
The gap between those two sentences is where most monitoring estates live.
A narrower problem is not a solved one
“Read-only,” “write-blocked,” “unidirectional,” “outbound,” “brokered,” “segmented,” “DMZ,” “encrypted” and “air gapped” describe intended or observed properties. Most of them describe something worth having. All of them describe an intent about direction and exposure; none of them describes what the implementation does on a bad day.
What stays unexamined after the label is applied: the effective privileges, the reachable paths, the implementation and its defects, the configuration as deployed rather than as drawn, the shared dependencies, the maintenance and update paths, the human access that keeps the thing running, the failure behaviour, and the bypasses that appear the first time something breaks at two in the morning.
And the sentence worth keeping: “No inbound session” is a property of a connection, not a property of a system. An outbound-only connection still terminates somewhere. It still carries software back the other way. It still hands whoever owns the far end a position in the flow. A monitoring estate does not hear everything and touch nothing because a credential says read-only.
The same applies to the names on either side of the connection. A vendor, protocol or security-product name selects no control and proves no applicability. One protocol label covers different versions, profiles, roles, functions, security configurations, data models, timing behaviours, implementations and support conditions, and what a given deployment actually has enabled is a separate configuration question from what the product supports. “It speaks OPC UA” answers neither. Modbus, published in 1979, carries no authentication or encryption in its original specification and no units, type, quality flag or timestamp on a register — everything that makes a value interpretable lives in a map maintained somewhere else. None of that is an argument against any of them. It is an argument against treating the name as the answer.
The gateway is plant
The reason a passive-sounding interface changes an OT risk proposition is mundane: a monitoring gateway is a computer.
It has an operating system, credentials, certificates, a firmware supply chain, a support contract and an end-of-support date. Once it is on the wall it is plant — carrying every vulnerability, patch, backup and obsolescence obligation that word implies, and earning its own row in the asset register alongside the machines it watches.
New devices, software, identities, suppliers, support paths and data stores can all affect control performance, availability, safety, privacy, supportability and incident response. No protocol or topology label decides whether that change is acceptable.
The work that actually carries the risk
It is unglamorous and continuous, and none of it is selected by a label:
- A risk-based OT architecture with a named owner — a person, not a diagram
- Identity and key lifecycle, including what happens when the integrator's engineer moves on
- Firmware provenance and update integrity
- Vulnerability and end-of-life management for devices bought on a maintenance budget and expected to last fifteen years
- Backup and tested restore — the test is the part that gets skipped
- Isolation that survives contact with operations
- An incident-response path that names people rather than roles
That is competent, governed engineering work, and it is the thing a read-only label is usually standing in for.
IEC 62443 is the standards series a site’s OT-security review is most likely to work within, and it is named here for orientation only. No part, edition, method, requirement, security level, zone or conduit design is reproduced or adopted, and applying the series requires the licensed text and competent review. Naming a standard is not a conformity claim, and this article does not interpret one.
”Vendor access” is not one function
A monitoring supplier arrives with more than a product: people, software, services, identities, update mechanisms, support dependencies, data transfers and contract terms. A record that treats all of that as one thing will authorise a great deal more than anybody intended.
Routine support, emergency access, software delivery, telemetry, licensing, administration and incident response are different activities. They carry different exposure, occur at different frequencies, and have different owners. Whether any of them may happen, and under what conditions, is defined and approved by the site’s own risk, controls, operations, safety, cybersecurity, privacy, procurement, legal and supplier-management authorities — not by a monitoring project and not by this article.
A new tag is engineering change
Three questions collapse into one whenever somebody says a tag exists.
Availability means only that a value can be retrieved — a tag responds, an export runs. Measurement fitness asks whether that value means what the condition question needs it to mean. Decision fitness asks whether the value, with its uncertainty and its confirmation path, can carry the decision someone intends to take on it. A tag named for a bearing temperature might be a thermocouple on the housing, a value the drive estimates from a motor model, or the last good reading from a channel that died some years ago. All three are equally available; exactly one answers a bearing question, and the tag name does not say which.
A fourth question sits alongside all three and is decided by different people: whether anyone may connect to the source at all. Any change to a controls estate — a new poll, an added tag, an altered scan, a spare channel put to work — is engineering change and belongs in the site’s own management-of-change process, whoever proposed it and however small it looks.
An existing path is also not an approved path. That an interface is already installed makes a new use cheaper to start, not cheaper to own, and not authorised.
An exercise that costs an afternoon
Take one monitoring path into your plant — installed or proposed, it works either way. On a single page, write down:
- 01 What the label claims
Write the exact words used to describe the path in the last review — read-only, outbound, through the historian — and who first used them.
- 02 What has been demonstrated rather than named
For direction, reachability, identity, privilege, logging, time integrity, configuration state and version: which of these has evidence from the actual implementation, and which has only an intent?
- 03 Who owns the identity, and what happens when they leave
Name the human, device, service and supplier identities on the path, the functions and periods authorised, and the revocation route.
- 04 The two dates
When the device's support ends, and when its restore was last tested. Not backed up — restored.
- 05 Who alone may accept, reject or retire the proposition
One named seat with the authority to say no, plus what change invalidates the assessment and who records it.
Then mark the lines you could not fill from records rather than from memory.
What usually happens is that the first line fills instantly and the rest do not. That result is the finding. It is also a legitimate one: where scope, risk, architecture, authority, validation, degraded behaviour or lifecycle evidence is inadequate, NOT DEMONSTRATED stays available as the honest answer, and it is a verdict rather than a failure of nerve. Nothing on that page authorises a connection, a control or a change; it produces a reviewable record for the people who do hold that authority.
Which of the paths into your plant is described by a word rather than by a record?
The architecture-label boundary, the governed work list, and the separation of data fitness from connection authority are from Predictive Maintenance: Practitioner Reference Frameworks and Planning Guide (Part 6: Sensors, Data Acquisition, and IIoT Architecture).
Lokesh Chennuru writes Industry Digits field notes for industrial decision makers, focused on automation, IIoT, condition monitoring, predictive maintenance, and industrial AI.
Connect on LinkedInQuestions industrial leaders ask about this
Is a read-only connection secure?
A path constrained so that it cannot write does reduce a defined class of write-path risk, and that reduction is real rather than rhetorical. It does not establish a secure architecture. The effective privileges, the reachable paths, the implementation and its defects, the configuration as deployed rather than as drawn, the shared dependencies, the maintenance and update paths, the human access that keeps the system running, and its failure behaviour are all still unexamined.
What does "no inbound session" actually prove?
That is a property of a connection, not a property of a system. An outbound-only connection still terminates somewhere, still carries software back the other way, and still hands whoever owns the far end a position in the flow. Outbound, brokered, northbound and through-the-historian all describe an intent about direction, which is worth having and is not a conclusion about the architecture.
Does adding a condition-monitoring tag need management of change?
Any change to a controls estate is engineering change and belongs in the site's own management-of-change process, whoever proposed it and however small it looks. A new poll, an added tag, an altered scan and a spare channel put to work all qualify. A monitoring gateway is also plant once it is on the wall, carrying vulnerability, patch, backup and obsolescence obligations like any other asset register row.
Does citing IEC 62443 make a monitoring architecture compliant?
No. The series is named for orientation only: it is the standards series a site's OT-security review is most likely to work within. Naming it reproduces or adopts no part, edition, method, requirement, security level, zone or conduit design, and applying the series requires the licensed text and competent review. Citing a standard is not a conformity claim.
What does this article deliberately not conclude?
It selects no architecture, protocol, product, credential, topology or remote-access pattern, and it does not say whether any specific path is acceptable. That decision belongs to the site's own risk, controls, operations, safety and cybersecurity authorities. Where scope, architecture, authority, validation, degraded behaviour or lifecycle evidence is inadequate, the honest result is not demonstrated.
Predictive Maintenance — Practitioner Reference Frameworks and Planning Guide
The twelve-part reference this series draws on: foundations and the value case, asset criticality and strategy, failure modes and degradation, the monitoring technologies, asset-class playbooks, sensors and IIoT architecture, data foundations, signal processing, analytics and prediction models, alerts and diagnosis, work management and CMMS integration, and pilot execution through rollout and governance — 126 sections with 46 technical figures.