What "Read-Only" Buys You, and the Twelve Questions It Leaves Open
Read-only bounds what software can write. It says nothing about where the component runs, which zone it sits in, who opens the connection, or what an attacker reaches if the vendor is breached. Twelve questions, and get the answers in writing.
Working on a live operating problem? Book Your 20-Minute Assessment
A read-only commitment says what a software product may write. It says nothing about where the component runs, which network zone it sits in, which side opens the connection, what credentials it holds, or what an attacker gets if the vendor is breached. NIST Special Publication 800-82r3, published September 2023, notes in Section 5.2.3.1 that allowing outbound connections from lower levels, tiers or zones “could represent a significant risk if unmanaged”, and that organisations should consider making outbound firewall rules as stringent as inbound ones.
Key takeaways
- Read-only is a commitment about authority, not about architecture. It bounds the write. Placement, direction, protocol, identity, retention and blast radius all stay open.
- NIST SP 800-82r3 costs nothing to read, is not subject to copyright in the United States, and asks the harder questions. Sections 5.2.3.1, 6.1.1.1, 6.2.1.3 and 6.2.10 are organised around zones, mapped data flows, isolation devices and remote access, not around vendor promises.
- Outbound-initiated is not the same as physically one way. NIST describes unidirectional gateways in Appendix E.1.2 as hardware that cannot be programmed to pass data in both directions. A TCP session opened outbound still carries traffic both ways.
- A historian can itself sit inside the OT zone. NIST lists the data historian among control-centre components in Section 2.3.2, so “we read the historian” locates nothing until the buyer knows which historian, and which zone it sits in.
- A system with no control-system write path can still move steel. A wrong recommendation, dispatch, permit status, part number or closeout record all move human hands. The write boundary bounds the software’s authority. It does not bound its influence, and a vendor whose security story ends at the write boundary has stopped halfway.
- CISA and eleven partner organisations published the direction test in January 2025. Their joint guide advises buyers to seek manufacturers that rely on data pushed out of the OT network rather than pulling data out of it, and, where a two-way connection is required, products that need an operator’s approval to establish it.
- This piece describes no vendor’s deployment, EQUA’s included. Every answer below belongs in a contract or an architecture document, not in a sales call.
What does a read-only commitment actually cover?
One thing, and it covers it well. It says the software holds no path by which it can change the state of a control system: no setpoint, no restart, no interlock, no actuator command. That is a real and checkable property. Hold every vendor to it in writing, at every permission level, under every configuration.
Here is that answer in the form you should demand. EQUA AIMMS connects read-only to SCADA, historians and IoT sensor sources. It holds no write path to a PLC, DCS or SCADA system at any permission level, and that is a property of the design rather than a setting a support engineer can change. Detection is a read. Control is a write. The boundary is on the write.
One question answered. Twelve still open, and a buyer who stops there has bought a single guarantee and left the rest of the attack surface undescribed. Placement, direction, protocol, identity, revocation, read scope, load, residency, blast radius, link loss, logging and exit are all untouched by it, and several of them are what a real incident turns on. The table further down is that list in full.
Everything about EQUA’s own deployment topology beyond the read-only statement above is out of scope for this article. Where components sit, what sits between them and a customer network, and how any given installation would be arranged are project facts. They belong in a project document that names the customer’s own zones, signed by the people who own those zones. Nothing here should be read as a description of them.
What does NIST SP 800-82r3 ask instead?
NIST SP 800-82r3, Guide to Operational Technology (OT) Security, September 2023, is a US government publication that NIST states is not subject to copyright in the United States. It costs nothing, it can be quoted, and every party in the conversation can read the same sentence at the same time, which is more than can be said for the paid standards it is usually cited alongside.
It is organised around segmentation, zones, communication flows, access control and component protection, not around what a vendor promises. Four sections carry most of this conversation.
Section 5.2.3.1, Network Architecture. This is where the outbound argument sits. NIST notes that firewall rulesets “should be established to only permit connections between adjacent levels, tiers, or zones”, and then makes the point that most vendor conversations skip:
One area of considerable variation in practice associated with firewall rules is the control of outbound traffic from the control network. Allowing outbound connections from lower levels, tiers, or zones could represent a significant risk if unmanaged. Organizations should consider making outbound rules as stringent as inbound rules to reduce these risks.
Put that sentence in front of anyone who treats “we only make outbound connections” as the end of the security discussion. It is the beginning of it.
Section 6.1.1.1, Mapping Data Flows. NIST’s position is that documenting data flows “enables organizations to understand the expected behavior of their networks”. Section 6.2.1.3 closes the loop: for network isolation, organisations “typically utilize their mapped data flows to identify required communications between segments”, and the isolation devices are then configured to permit only what those flows say is authorised. A vendor who cannot describe its own flows in the form your network team draws them cannot be placed in your diagram, so the isolation rule written for it gets written to a guess.
Section 6.2.1.3, Network Segmentation and Isolation. NIST advises organisations to “enforce a deny-all, permit-by-exception policy where possible”, and adds a caution worth quoting to anyone who thinks a firewall rule closes the matter: network isolation “does not mitigate risks associated with lateral movement within a network segment”. A component placed inside a zone is inside that zone with everything else in it.
Section 6.2.10, Remote Access. NIST is direct that remote access “should be provided only if justified and limited to what is required for the business need”, that it “should not circumvent or negate safety or security controls”, and that access should be removed when no longer required, with automatic timers or a managed change process to confirm the removal. The same section’s list of considerations for temporary vendor access includes “initiating the connection from the OT environment” and labelling the connection device so operations can disconnect it quickly. Vendor connectivity is remote access, whatever the sales deck calls it.
ISA/IEC 62443 is the other framework your reviewer may cite. It is a paid standard and this article has not read it, so it is named here by number and title only, both of which are public. NIST SP 800-82r3, Appendix D, enumerates the series, and two parts are the ones a vendor conversation tends to land on: ISA-62443-3-2, Security risk assessment for system design, and ISA-62443-2-4, Security Program requirements for IACS service providers, whose title alone tells you it is the part written about service providers rather than about asset owners. NIST points readers to the first of those in Section 6.1.3, for guidance on assessing cyber risk in an environment where the potential consequences include loss of power, loss of control and major equipment failure. Ask which parts a vendor claims alignment with, ask what evidence backs the claim, and read the parts yourself rather than accepting anyone’s summary of them.
Why is outbound-initiated not the same as one way?
These get conflated constantly, and the difference is physical.
NIST describes a unidirectional gateway in Appendix E.1.2 as a device that, unlike a firewall, “cannot be programmed to allow data to flow in both directions because the hardware is incapable”. That is one way. It is a property of the silicon, and no misconfiguration reverses it.
An outbound-initiated connection is a different animal. A TCP session opened from inside a zone to an outside endpoint is a bidirectional channel from the moment it is established. Initiation direction is a genuine and useful security property, because the outside party then needs no open inbound port and cannot start the conversation. It does not mean data travels only one way once the conversation is open.
CISA and eleven partner organisations, including the EPA and the FBI, set out the useful ordering in Secure by Demand: Priority Considerations for Operational Technology Owners and Operators when Selecting Digital Products, 13 January 2025. Under “Protection of Data” the guide advises buyers to seek out “manufacturers that rely on data pushed out of the OT network as necessary, rather than pulling data out of the OT network”, because that shift “enables the buyer to maintain control over their data and restricts any external connections into the OT network”. It goes on: “If two-way connections are required, buyers should seek out products that require an operator’s approval to establish a connection.”
| Connection shape | Who can start a conversation | What reverses it |
|---|---|---|
| Unidirectional gateway or data diode | Nobody, in the return direction | Nothing in software. The hardware cannot pass it. |
| Data pushed out by a customer-controlled component | The customer side only | A change to the pushing component |
| Outbound session opened to a vendor endpoint | The customer side opens it; both sides then talk | A change to the firewall rule, the endpoint, or the code that dials out |
| Inbound connection from vendor to customer | The vendor side | A firewall rule, and whoever holds it |
Ask which row a vendor is in. The answer is a one-line fact and it should come back as one.
Why is “we read the historian” not an architectural answer?
Because the historian has a location, and the sentence does not say what it is.
NIST SP 800-82r3, Section 2.3.2, lists the data historian among control-centre components alongside the HMI and the engineering workstations, all connected by a local area network. Section 2.3.4 describes a PLC control system in which the PLC, an engineering workstation and a data historian are likewise all connected on one LAN. So in the reference architectures the historian is an OT-zone asset. A site may also run a replica or a mirrored instance in a boundary segment or an enterprise segment, which is a different machine with a different owner, a different patch cadence and a different set of accounts. NIST notes the underlying mechanism in passing, in its warning that database links allowing historian data to be replicated onto other databases can create a vulnerability if they are not properly configured.
So “we read the historian” says nothing about placement until it is followed by: which historian, in which zone, on which side of which isolation device, reached by a component that itself sits where.
Load is the second half of the question, and it gets skipped because it is an operations concern rather than a security one. A historian serving the control room is a production system. Continuous tag queries, backfill requests and reprocessing runs are load on it. NIST’s explicit warnings here are about scanning rather than querying and should not be stretched past what they say: Appendix E.2.3 warns that active scans “may cause device instability or interfere with the device process state, potentially impacting safety and integrity”, and Section 6.3.2.4 advises considering how such tools may affect OT components “by testing them in an offline environment prior to implementing them in production”. The principle transfers cleanly. Anything new that generates load against an OT or OT-adjacent component gets characterised and tested before it points at production. Ask for the query pattern, polling interval, tag count and peak, in numbers.
What can a system with no write path still cause to happen?
Most vendor security conversations stop at the write boundary. That is where the harder half starts, and it is the half that decides whether anyone gets hurt.
A system with no control-system write path can still change what happens to physical equipment, because it changes what a person does. A wrong probable cause sends a crew to the wrong pump. A wrong dispatch puts the wrong two people in a wet well at two in the morning. A wrong permit or isolation status tells someone a valve is locked out when it is not, and they put a hand where the hand should not go. A wrong part identification puts an impeller with the wrong clearance into a machine that will run on it for a year. A wrong closeout record removes a fault from the history the next diagnosis will be built on, so the same failure comes back and nobody can see why.
None of that requires a write to a PLC. All of it moves steel.
The distinction worth holding is between authority and influence. The write boundary bounds authority: the set of actions the software may take by itself. It does not bound influence: the set of outcomes the software brings about through the people who read it. In maintenance the second set is far larger than the first, and it is the set safety cases are actually about.
So the controls that matter for this class of software are the ones governing what happens between a machine-produced conclusion and a human action. We build to that standard, and you should hold us to it:
- Which classes of output require a named person’s approval before they reach a work queue, and which do not.
- Whether the evidence behind a recommendation is recorded and readable afterwards, or whether only the conclusion survives.
- Whether an action is reversible, and how.
- Who is accountable when it is wrong, and whether that is written down.
Detection takes the same treatment. Anomaly detection on process and sensor data is a read, and the read boundary is genuine, but reading historian tags is not a condition monitoring programme and nobody should sell it as one. Vibration analysis, infrared thermography, oil and wear debris analysis and motor current signature analysis are a separate discipline, with their own instrumentation, their own standards and their own specialists. If a vendor’s deck blurs the two, that is a question for the vendor.
What a system reading plant data may do, and where that stops
Scroll sideways to see the whole drawing.
Figure 1. What a system reading plant data may do, and where that stops. A ladder of action classes for software connected to plant data. Reading process and event history is held by the system itself. Concluding that a deviation exists and raising a fault is held by the system. Recommending a course of action is held by the system, with the decision held by a named human. Writing to a business system such as a maintenance, inventory or procurement record is held by the customer through configured permissions and approval gates. Issuing a setpoint, restart, interlock or actuator command to a control system sits outside the ladder entirely and is marked as never held, at any permission level.
The question set
Run these in order. Send them before the demonstration, not after. Every answer belongs in an architecture document or a contract clause, and a good vendor hands them over in writing without being pushed.
| Question | Why it matters | What a good answer looks like |
|---|---|---|
| Which component reads our data, where does it run, and in which zone of our own architecture does it sit? | Placement decides what the component can reach if it is compromised. NIST 6.2.1.3 notes isolation does not stop lateral movement inside a segment. | A named component, a named zone in the buyer’s own diagram, and the isolation device on each side of it. |
| Which side initiates the connection, and can the vendor side ever initiate? | Initiation direction decides whether an inbound path has to exist at all. See NIST 5.2.3.1 on outbound rules. | One sentence naming the initiating side, plus a statement of whether the vendor can initiate under any support scenario. |
| Which protocols and ports, in which direction, and are the versions current? | This is the firewall rule your network team will actually write. Deny-all, permit-by-exception needs an exact list. | An enumerated flow table. TLS 1.2 or above, which is the floor NIST 6.2.10 states. No legacy protocols enabled by default. |
| Whose identities are used, how are they issued, and are any shared or service accounts involved? | A shared account cannot be attributed to a person, which breaks both least privilege and the audit trail. | Named identities, role-based access, multi-factor authentication for any remote path, and no shared role passwords. |
| How do we revoke access, how fast, and can we do it without the vendor? | NIST 6.2.10 advises removing access when no longer required, with timers or a managed change. Revocation you must request is not revocation. | A customer-side control that cuts the path immediately, a stated maximum revocation time, and time-bounded support access by default. |
| What exactly is in the read scope, and who can widen it? | A scope nobody can enumerate is not a boundary. Tag-level scope is checkable; “the historian” is not. | A tag, table and system list, a named change process to alter it, and a log entry when it changes. |
| What load does the read place on the historian or source system, at peak? | The source is a production system. Load is an availability question and it belongs to operations. | Polling interval, tag count, query pattern, peak concurrency, and a test in a non-production instance first. |
| Where does our data come to rest, in which jurisdiction, and for how long? | Process data is durable and valuable to an attacker. CISA’s guide states that OT data underpins the engineering of the system. | Named storage locations, a retention period per data class, encryption at rest, deletion on request, and a written statement on sharing or resale. |
| If the vendor is compromised, what can the attacker reach in our environment? | This is the blast radius question, and it is the one the read-only claim is most often used to avoid. | A written scenario: what credentials exist, what they open, what they cannot open, and what the customer would have to do. |
| What happens on our side when the connection is lost? | Loss of a vendor link must not affect control, alarming or safety functions. | A stated behaviour: control and alarming unaffected, buffering behaviour defined, and a documented catch-up on reconnect. |
| What is logged, in what format, and can we read our own logs without asking? | CISA’s guide puts logging in the baseline product using open standard formats, and states that logging should not be an add-on or paid feature. | Customer-readable access, change and query logs, exportable in an open format, retained for a stated period. |
| How do we leave, and what do we take with us? | CISA’s “Ownership” element is about operators controlling and recovering their systems without unintended or unnecessary dependencies on a vendor. | A written exit path: full data export in an open format, a defined notice period, deletion certification, and no configuration held only in the vendor’s environment. |
Two follow-ups apply to every row. Ask for the answer in writing, in the contract or an architecture document the contract references. And ask what would have to change for the answer to stop being true, because an answer that is a configuration setting is a different thing from an answer that is a property of the design.
What this article does not tell you
It does not describe any particular vendor’s deployment, EQUA’s included. It does not tell you whether a given product sits in a boundary segment, reads a replica, uses a broker, or does anything else, because those are facts about a specific installation in a specific network. They can only be established for your network, by your people, in your documents.
The questions above are what produce those facts. Ask them of everyone reading your plant data, and take the answers in writing.
Sources
- National Institute of Standards and Technology, NIST SP 800-82r3, Guide to Operational Technology (OT) Security, September 2023. NIST states the publication is not subject to copyright in the United States. Sections cited: 2.3.2 and 2.3.4 (control-centre components including the data historian, and the PLC topology example), 5.2.3.1 (network architecture, firewall rules and the control of outbound traffic), 6.1.1.1 (mapping data flows), 6.1.3 (risk assessment, and the pointer to ISA 62443-3-2), 6.2.1.3 (network segmentation and isolation, deny-all permit-by-exception, mapped flows as the input to isolation rules, lateral movement), 6.2.10 (remote access, TLS 1.2 or above, removal of access, initiating the connection from the OT environment), 6.3.2.4 (vulnerability scanning, testing in an offline environment), Appendix C (database links replicating historian data), Appendix D (the ISA/IEC 62443 part list), Appendix E.1.2 (unidirectional gateways) and Appendix E.2.3 (active scanning). https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-82r3.pdf
- Cybersecurity and Infrastructure Security Agency, with the National Security Agency, Federal Bureau of Investigation, Environmental Protection Agency, Transportation Security Administration and seven international partners, Secure by Demand: Priority Considerations for Operational Technology Owners and Operators when Selecting Digital Products, 13 January 2025. TLP:CLEAR. Elements cited: Logging in the Baseline Product, Ownership, Protection of Data. https://www.cisa.gov/sites/default/files/2025-01/joint-guide-secure-by-demand-priority-considerations-for-ot-owners-and-operators-508c_0.pdf
- International Electrotechnical Commission, IEC 62443-3-2:2020, Security for industrial automation and control systems, Part 3-2: Security risk assessment for system design, Edition 1.0, published 24 June 2020. Cited by number, title, edition and publication date only; the standard is paid and has not been read for this article. https://webstore.iec.ch/en/publication/30727
- ISA-62443-2-4, Security Program requirements for IACS service providers, cited by number and title as enumerated in NIST SP 800-82r3, Appendix D, Section D.1.5.2. The standard is paid and has not been read for this article.
Who wrote this
EQUA AI builds EQUA AIMMS. It reads SCADA, historians and IoT sensor sources, spots the deviation, raises the fault and alerts whoever owns it, then carries the digital work through to a closed work order: evidence, parts, suppliers, approvals, writeback into the systems you already run.
It does all of that with no write path to any control system, which is the whole point of the twelve questions above. Reading plant data is only worth the review it costs you if what comes out of the other side is work that actually moved.