Skip to content

// analysis

Who actually controls the machines?

Illustration for the analysis: Who actually controls the machines?
Sources and reading context

Topics

dated revision: November 03, 2026primary sourcesno tracker
Contents10 sections

The war on ordinary machines · Part 2 of 7

A screen displays a temperature. A controller acts on a target. A technician can change the settings. Between those actions, authority passes through several hands. Industrial manuals reveal where decisions take effect, which configuration becomes authoritative and what may keep working when a connection fails.

Page 55 of Danfoss’s June 2026 manual describes a choice with consequences beyond commissioning. The AK-SM 800A supervisor can retrieve settings from field controllers. It can also send the settings held in its own database back to them. Configuration can travel in either direction. 1

For the operator, the question is which version should prevail. When equipment is replaced, adopting the settings already in the field and applying a previously prepared configuration lead from different starting points. An older backup, a recent adjustment and a commissioning record may describe different states. Someone must establish which one is appropriate before copying it across.

That movement of settings offers a useful way into the refrigeration incidents reported in October 2026. France’s CERT-FR called for the entire configuration to be checked, including defrost schedules. Its alert addresses exposed management interfaces across several equipment families. The alert leaves the detailed architecture of each affected shop unspecified. 2

This investigation therefore follows the documented functions rather than inventing a reconstruction of a victim’s network. Manufacturer manuals, read alongside security-agency guidance, show how a request becomes a decision. Danfoss and Siemens provide separate examples in the account that follows. Their inclusion makes no claim that the products were installed together at any affected site.

Decisions take shape close to the process

A sensor measures a physical condition. A controller combines the measurement with settings and operating logic to determine an action. An actuator turns the instruction into a physical effect, such as moving a valve or varying a drive. That effect changes the condition being measured, closing the feedback loop. NIST describes this relationship as a basic building block of operational technology. 3

Operational technology, usually shortened to OT, covers digital systems that monitor or control physical processes, meaning material operations such as producing refrigeration. A programmable logic controller, or PLC, can run logic tailored by a system integrator. A specialised controller, including a refrigeration regulator, organises its functions around a more specific application. Their interfaces, programmability and safeguards differ. Treating them all as the shop’s “computers” would obscure the differences that determine what happens when something fails. 3

The Siemens S7-1200 manual supplies a concrete example of local execution. In RUN mode, the CPU executes the user program and handles inputs and outputs. STOP mode retains some functions, including communications, while user-program execution stops. A device that still answers over the network may therefore have entered a different operating state. 4

Above local control there is often a human-machine interface: the display through which someone observes the process or intervenes. Supervisory systems provide a broader view, bringing together states, alarms and control functions. SCADA stands for supervisory control and data acquisition. These roles may be distributed across several devices or combined in one product. 3

The distinction matters when interpreting an outage. In a design with all necessary control functions local, losing a display can remove visibility while the loop continues. Where an essential function depends on the supervisor, the outcome changes. A useful architecture diagram therefore needs to show what the connections do, not simply which boxes are connected.

Commands travel. The loop acts.Generic functional architecture. An authorised operator accesses supervision. Requests reach the local controller; measurements and states return. The loop connects sensor, controller, actuator and process; the physical state returns to the sensor. No victim architecture.l0g / MACHINES01Commands travel. The loop acts.Functions may be combined or distributedOperatorAccess andrightsSupervisionSensorControllerActuatorProcessRequests / settingsMeasurements / statesPhysical-state feedbackLogical roles: one device may combine several functions.[03, 04, 05]
Commands travel. The loop acts.Generic functional architecture. An authorised operator accesses supervision. Requests reach the local controller; measurements and states return. The loop connects sensor, controller, actuator and process; the physical state returns to the sensor. No victim architecture.l0g / MACHINES01Commands travel. Theloop acts.Functions may be combined ordistributedAuthorised operatorAccess and rightsSupervisionSensorControllerActuatorProcessRequestsStates / readingsThe physical state returns to thesensor.[03, 04, 05]
FIG. 01 Supervision exchanges requests and states with a local loop. One device may combine several functions.[3], [4], [5]
Method and scope

Generic functional architecture based on NIST, informed by a Siemens example of local execution. Amber: requests and actions. Turquoise: returning measurements and states. Rose: the physical state returning to the sensor. Functions may be combined or distributed. Victim topologies and dependencies remain unknown. Lines represent functional relationships, without prescribing wiring or protocols.

Observation and intervention carry different authority

Remote access covers different kinds of work. French security agency ANSSI distinguishes remote diagnosis, which observes and analyses without changing parameters, from remote maintenance, which can change settings or programs. It treats remote operation as a separate activity. These definitions provide a practical basis for asking what a connection is for. 5

A service sold as “monitoring” consequently deserves a functional description. Can its operator only read a status? Can they acknowledge an alarm, change a schedule or alter the target supplied to the process? Each additional capability creates another trust relationship. An action may be appropriate during a planned intervention and unsuitable at another moment. The operator’s identity, the permission granted and the condition of the process all matter.

Siemens documents a particularly useful distinction. Web or OPC UA permissions may allow changes to data independently of the CPU access level. The manufacturer also recommends checking ranges and valid values in program logic. OPC UA is an industrial data-exchange service; its permissions are another access path to examine. 6

A broader analytical lesson follows. An access review should trace each service through to the operations it permits. Reading a value, writing a replacement and loading new logic are different powers. A named account says little about their boundaries until the permissions enforced at the receiving end are understood.

Encryption protects a different part of the chain. Modbus Security, for example, specifies TLS, a protective layer for network communications, and certificates to protect and authenticate exchanges. A secure variant exists; whether a particular connection supports and uses it requires evidence from that installation. 7

Consider a request that arrives exactly as it was sent but contains an unsuitable value. Protecting the channel preserves the request. Authorisation determines whether the sender is allowed to make it. The process logic must then decide under which conditions it should be accepted. These checks address successive questions, including in systems that have no Internet connection at all.

Two copies need an agreed source of truth

Danfoss’s documented transfer functions make this distribution of authority tangible. Settings are held both in the supervisor and in field devices, with a means of copying in either direction. Once settings have been retrieved, a setpoint change made through the supervisor is transmitted immediately to the controller, without a fresh explicit transfer. Those copies can therefore evolve during operation. 1

Now consider a hypothetical maintenance history. A team adjusts a configuration after commissioning while a copy kept elsewhere remains unchanged. Later, a replacement or restoration requires a reference version. Sending the older copy back may undo the adjustment. Adopting the field state without reviewing it may instead preserve an unwanted change. This is a scenario implied by the existence of independently changeable copies, not an account of any refrigeration attack.

A useful recovery plan therefore asks more than whether a backup exists. The copy needs an origin, a date, a defined scope and a known relationship to the equipment for which it is intended. Validation should make the changes since the previous approved state understandable. International OT security principles explicitly identify the difficulty of trusting backups after an environment has been compromised. 8

In this reasoning, an approved configuration resembles an accepted operating document. Approval concerns the settings and their suitability for the process. File integrity answers the narrower question of whether the copy has remained unchanged. A perfectly preserved file may describe a state that has become inappropriate. Keeping the history of decisions helps bridge that gap; a sequence of dated files alone may leave it unexplained.

There is a contractual dimension too. The owner needs to know who holds a usable configuration, who can explain its differences from earlier versions and who is authorised to bring it back into service. Owning the equipment can coexist with dependence on a third party for knowledge of its current operation. Delivery and maintenance documents are the place to establish that dependence before attempting to price it.

Two copies, one setting to validateTwo alternative operations in the Danfoss AK-SM 800A manual, June 2026, revision BC337629891709en-001101, section 5.13, page 55. Upload copies field-controller settings into the supervisor database. Download copies the database to controllers. Divergent copies are a conditional scenario.l0g / MACHINES02Two copies, one setting to validateCopy directions documented in the Danfoss manualARead field settingsUploadSupervisordatabaseFieldcontrollersBApply the database copyDownloadSupervisordatabaseFieldcontrollersIf the copies differValidate the reference before propagating settings.[01, 08]
Two copies, one setting to validateTwo alternative operations in the Danfoss AK-SM 800A manual, June 2026, revision BC337629891709en-001101, section 5.13, page 55. Upload copies field-controller settings into the supervisor database. Download copies the database to controllers. Divergent copies are a conditional scenario.l0g / MACHINES02Two copies, one settingto validateCopy directions documented in theDanfoss manualARead field settingsUploadSupervisordatabaseFieldcontrollersBApply the database copyDownloadSupervisordatabaseFieldcontrollersIf the copies differValidate the reference beforepropagating settings.[01, 08]
FIG. 02 Upload and Download copy settings in opposite directions. Divergent copies require validating the reference.[1], [8]
Method and scope

Terminology from the Danfoss AK-SM 800A manual, SW 5.1.x, revision BC337629891709en-001101, June 2026, section 5.13, printed page 55. Upload: field controllers to the supervisor database. Download: database to controllers. The manual also states that a setpoint changed through the supervisor is sent immediately to the field. A and B are alternative explicit operations. Divergent copies are an analytical scenario; no victim configuration or recovery is reconstructed. Backup validation follows the cited ASD / ACSC guidance.

Disconnection needs a defined boundary

“Disconnect it” leaves an essential question unanswered: which connection, carrying which functions? The UK’s National Cyber Security Centre recommends an isolation plan built around dependencies, continuity and the scope for autonomous operation. Depending on the architecture, isolation can target particular services or routes rather than an entire site. 9

Losing an external connection is one case. In the autonomous example drawn here, the controller retains power, sensors, actuators and all the logic needed for local regulation. The loop can continue while services using the failed connection become unavailable. That result follows from the stated assumptions. Any additional dependency, such as a required exchange with another device, changes the assessment.

Losing the supervisor is a second case. Displays or central alarm handling may become unavailable. Further consequences depend on the functions that the supervisor actually performs. The useful distinction is between observing the process and supplying services that the process needs to run. One console can do both, which is why appearances are unreliable.

A PLC entering STOP mode is a third case, documented by the S7-1200 V20 manual. Depending on configuration, the outputs covered by the manual can retain their last value or take a substitute value. Some distributed I/O modules provide other responses. Behaviour on power-up is another distinct case. 10

The word STOP is therefore an insufficient description of the plant’s physical condition. An output value has to be interpreted alongside the wiring, the actuator and the process safeguards. Holding a command and substituting another both have specific consequences. Selecting an appropriate fallback state requires system engineering and validation under controlled conditions. 3

CERT-FR’s refrigeration alert adds a practical constraint: before interrupting data sent to the refrigeration contractor, operators should check contractual insurance terms. 2 An operational question sits alongside it: who will still receive an alarm, and who can respond? A single connection may support several services with different continuity needs. Identifying them makes it possible to plan selective isolation and an appropriate human fallback.

Three failures, three outcomesThree explanatory cases with power maintained. A: external link lost. B: supervision lost. A and B assume an autonomous local loop. C: S7-1200 V20 RUN-to-STOP transition; outputs hold a value or use a substitute according to configuration, with module-specific variants. No universal safe state.l0g / MACHINES03Three failures, three outcomesPower maintained · dependencies to examineALink lostExternal linkSupervisionLocal controlProcessLocal loop maycontinue. Remoteservices lost.BSupervision lostExternal linkSupervisionLocal controlProcessLocal loop maycontinue. Centralvisibility lost.CProgram stoppedExternal linkSupervisionLocal controlProcessValue held or asubstitute valueused.A/B: assumed local autonomy.[03, 04, 09, 10]
Three failures, three outcomesThree explanatory cases with power maintained. A: external link lost. B: supervision lost. A and B assume an autonomous local loop. C: S7-1200 V20 RUN-to-STOP transition; outputs hold a value or use a substitute according to configuration, with module-specific variants. No universal safe state.l0g / MACHINES03Three failures, threeoutcomesPower maintained · dependencies toexamineALink lostRemoteSupervisionLocal controlProcessLocal loop maycontinue.Remote serviceslost.Assumedautonomousloop.BSupervision lostRemoteSupervisionLocal controlProcessLocal loop maycontinue.Central visibilitylost.Assumedautonomousloop.CProgram stoppedRemoteSupervisionLocal controlProcessValue held or asubstitute valueused.S7-1200 V20Power maintained in these cases.[03, 04, 09, 10]
FIG. 03 Losing a link, losing supervision and stopping a program affect different functions.[3], [4], [9], [10]
Method and scope

All three explanatory cases assume maintained power. A and B also assume an autonomous local loop: sensors, actuators, logic and essential local links remain available. Other dependencies may change the outcome. C illustrates an S7-1200 V20 RUN-to-STOP transition: the described outputs may hold their value or take a substitute according to configuration, with module-specific variations. Power-up is a separate case. No universal safe state, continuity duration or production-system test is inferred.

Physical protection has its own purpose

NIST describes safety instrumented systems, or SIS, as combinations of sensors, logic and final elements intended to bring a process to a safe state. Their relationship with normal process control varies by design. They are used in industrial settings where potential consequences require specific protective functions. Whether any particular food-retail installation has such a system must be established separately. 3

The meaning of “safe” deserves attention. A protective function may address injury, equipment integrity or a particular hazard. Its action can interrupt a service on which another asset depends. As a reasoned example, stopping refrigeration equipment to protect the machine can leave the preservation of its contents unresolved. Engineering decisions have to be related to operational consequences, with no assumption that every objective will coincide.

The diagram below places process-value checks separately from authentication and permissions. A distinct protective function can provide an additional barrier. Its effectiveness depends on its design and its actual dependencies. Two separate boxes on a drawing may share power, a sensor or an administrative path. Examining shared dependencies, the architecture and applicable verification establishes how independent the protective functions really are. 3 8

For the owner, the question becomes specific: which function should continue imposing a limit if the ordinary control path fails? Answering it requires process knowledge. General cybersecurity guidance can organise access and accountability. Determining acceptable values and fallback states belongs to the engineering of the system itself.

From a request to physical actionIdentity and session, permissions, values checked in logic, then process action. A distinct protection function exists only if the design provides it. Logs connect access, changes and measurements; coverage and integrity remain to be established.l0g / MACHINES04From a request to physical actionCheck access, bound the effect, connect the evidenceIdentitySessionPermissionsAllowedoperationValuesChecks in logicProcessPhysical actionProcess protectionIf provided by the designObserveLimitAct towards safetyConnect access, changes and measurements.Coverage and integrity to establish.[03, 05, 06, 11]
From a request to physical actionIdentity and session, permissions, values checked in logic, then process action. A distinct protection function exists only if the design provides it. Logs connect access, changes and measurements; coverage and integrity remain to be established.l0g / MACHINES04From a request tophysical actionCheck access, bound the effect,connect the evidenceIdentitySessionPermissionsAllowed operationValuesChecks in logicProcessPhysical actionProcess protectionIf provided by the designObserveLimitAct towards safetyConnect access, changes andmeasurements.Coverage and integrity to establish.[03, 05, 06, 11]
FIG. 04 Identity, permissions and value validation govern different stages. Separate protection depends on the design.[3], [5], [6], [11]
Method and scope

Identity and session, permissions and value validation are functional checks, without prescribing a device count. The process-protection branch exists only if the design provides it. Establishing effective separation requires examining shared dependencies. No victim is assumed to have a safety instrumented system. Logs connect access, changes and measurements; their coverage and integrity remain to be established.

A decision leaves more than one kind of trace

A measurement history describes part of the observed behaviour. Explaining a change requires connecting that record with configuration activity and access events. NCSC guidance calls for logs that can be used effectively, paying particular attention to maintenance periods and the return to normal monitoring afterwards. 11

An investigation can separate the questions. An authentication log records the use of an account. A change record identifies the object affected and, where sufficiently detailed, the previous and new values. A process measurement captures an observed effect. Bringing them together allows an explanation to be tested. Each retains its limits: account use does not by itself identify a person, and events occurring close together still need a plausible mechanism linking them.

The quality of that comparison also depends on timestamps, logging coverage and retention. Those properties must be understood before claiming to reconstruct a sequence. Where one technical chain both controls and records, confidence in the history depends on how far a compromise could have reached. An independent observation can offer corroboration, provided its measurement, timing and coverage are known. These are investigative criteria, not claims about evidence actually available from the affected shops.

Even an acknowledged alarm needs careful interpretation. Acknowledgement may indicate that someone has registered a signal in an interface; its exact meaning depends on the product and the organisation. Establishing that the physical problem was resolved requires evidence about that problem. The documentary chain must ultimately reach the service that was restored.

Buying equipment and retaining the ability to operate it

Procurement guidance treats autonomy as a product characteristic. Secure by Demand, an international publication released in January 2025, highlights configuration management, usable logs and the owner’s ability to maintain and change systems. 12 The economic value of those capabilities can be examined without inventing a return on cybersecurity investment.

Consider a change of maintenance provider. A documented, usable configuration gives the incoming contractor an explainable starting point. If knowledge of the installation remains with the outgoing supplier, that knowledge must be obtained, transferred or reconstructed. The costs and delays depend on the contract and the system. No amount can be inferred here; the analysis identifies additional work that a dependency may create.

Isolation planning has a similar economic dimension. NCSC guidance suggests that contracts should address the transition from remote support to onsite assistance when a connection is unavailable. 9 Continuity then depends on an organisation: someone competent who can attend, accessible documentation and a way to establish the condition of the process. A promise of permanent remote maintenance should be read alongside its failure scenario.

At acceptance or contract review, the evidence to request becomes tangible: permissions mapped to functions, an approved reference configuration, indispensable dependencies and expected behaviour when services are lost. Validation belongs to authorised teams using an appropriate environment and agreed procedure. Random disconnections during production would put the process being protected at risk.

Practical authority passes through the authorised person, the software accepting the request, the configuration treated as authoritative and the function imposing the final limit. Practical control becomes possible when the owner can connect those layers, explain their dependencies and demonstrate what remains available in degraded operation. Manuals begin that work. Evidence from the installation must complete it.

Scope of the investigation

This analysis uses public documents checked on 3 November 2026. No industrial network was queried, no victim logs were obtained and no interviews are presented as having taken place. The figures are explanatory reconstructions with explicit assumptions; none represents a particular victim. Functions from two manufacturers are used as separate examples. Prices, the prevalence of configurations and continuity durations are outside the available evidence.

The NIST reference used here is the final revision 3, published in September 2023. Revision 4 was a public draft at the time of the investigation; its status is specified in the references. 13 Agency recommendations retain their original scope and are not presented as universal legal requirements. References identify the versions reviewed and any access limitations.

Continue reading

Sources

Documents checked on 3 November 2026. The references identify the versions reviewed and the scope of the examples.

  1. [1] · Danfoss · June 2026, printed document date · Checked on 3 November 2026AK-SM 800A user guide, SW 5.1.x, BC337629891709en-001101

    Settings can be copied from field controllers into the supervisor database or sent in the other direction. After upload, subsequent setpoint changes through the supervisor are transmitted immediately to the field device.

    Passages and scope

    Section 5.13, Device Upload / Download, printed page 55; software version on the cover. Documented product functions. Their use and the configuration states at affected stores remain unknown. Official PDF downloaded; cover and page 55 extracted, with page 55 rendered and inspected. The supplied April link redirects to this June revision.

  2. [2] · CERT-FR / ANSSI · 12 October 2026; latest revision 16 October 2026 · Checked on 3 November 2026CERTFR-2026-ALE-012: incidents targeting refrigeration controllers

    Compromises across several controller families, exposed-interface risks, configuration checks and contractual insurance terms to review before interrupting reporting to the refrigeration contractor.

    Passages and scope

    Summary and Solutions; configuration checks in the uncompromised-equipment section; revision history for 12, 13 and 16 October. An aggregated alert. Detailed victim architectures, effective permissions and site-specific logs require further evidence. The complete official alert and revision history were read online.

  3. [3] · NIST · September 2023, final publication · Checked on 3 November 2026SP 800-82 Revision 3: Guide to Operational Technology Security

    Operational technology definitions, control loops, human-machine interfaces and safety systems. Functions and dependencies determine process behaviour.

    Passages and scope

    Chapter 2, printed pages 8–11; section 2.3.7, pages 25–26; Chapter 5 on separation of safety functions. Architectural examples require system-specific adaptation. Victim safeguards and dependencies remain to be documented. Official PDF downloaded and relevant passages extracted; reference pages checked. Final status confirmed on the NIST publication page.

  4. [4] · Siemens · November 2024, V20 documentation · Checked on 3 November 2026S7-1200 Programmable controller · V20 · Execution of the user program

    For the S7-1200 V20, STOP retains appropriate communications and self-diagnostics while user-program execution and automatic process-image updates stop. RUN executes the program and handles inputs and outputs.

    Passages and scope

    Execution of the user program, Operating modes section. A product- and version-specific example. Available communications establish neither active regulation nor a physically safe state. No S7-1200 installation is inferred at a victim site. Official page and V20 metadata reviewed; complete relevant passages read. The received body is in English despite the es-ES path code.

  5. [5] · ANSSI, France’s national cybersecurity agency · 27 November 2025, version 2.0 · Checked on 3 November 2026Cybersecurity for industrial systems: detailed measures, ANSSI-PA-108 v2.0

    Remote diagnosis, maintenance and operation are distinguished; access and logging recommendations vary with system class.

    Passages and scope

    Section 4.2.5.1, printed pages 73–74; recommendations R129–R133 and definitions of the three remote activities. Recommendations require adaptation to system constraints and classification. The affected stores’ system classes remain unknown. Official PDF downloaded; printed pages 73 and 74 extracted, rendered and inspected.

  6. [6] · Siemens · November 2024, V20 documentation · Checked on 3 November 2026S7-1200 Programmable controller · V20 · User Management & Access Control (UMAC)

    The UMAC notice says Web or OPC UA users may have permission to change PLC data and execute functions regardless of the CPU access level. Siemens recommends checking variable validity and ranges in program logic.

    Passages and scope

    User Management & Access Control, Unauthorized access to a CPU warning. The notice describes service-specific permissions; it is not evidence of an authentication bypass. No victim access, operational setting or behaviour is established. Official page and V20 metadata reviewed; complete relevant passages read. The received body is in English despite the es-ES path code.

  7. [7] · Modbus Organization · 29 October 2018 · Checked on 3 November 2026Modbus Security: New Protocol to Improve Control System Security

    Modbus Security combines TLS, certificate-based authentication and message-integrity protection.

    Passages and scope

    Protocol announcement, paragraphs on TLS and X.509v3 certificates. The specification describes a technical capability; support and activation on a particular connection require local evidence. The protocol organisation’s original announcement was read online.

  8. [8] · ASD / ACSC and international partners · 2 October 2024 · Checked on 3 November 2026Principles of Operational Technology Cyber Security

    Physical safety, essential dependencies and the need to reassess trust in backups after a compromise.

    Passages and scope

    Principles 1 and 2, particularly backup-validation questions and dependencies required for operation. A general decision-making framework. Victim backups and actual recovery capabilities are outside the available evidence. The official HTML edition was read. The associated direct PDF download timed out.

  9. [9] · UK National Cyber Security Centre · 14 January 2026, Published field · Checked on 3 November 2026Secure OT connectivity, Principle 8: establish an isolation plan

    Plan isolation around dependencies, continuity and autonomous functions; address third-party obligations, including a switch from remote support to on-site attendance.

    Passages and scope

    Opening guidance and contractual note; site, service-specific and hardware-protected-communication isolation strategies. The Reviewed field says 18 March 2024, before Published; this inconsistency establishes no revision chronology. Strategies depend on system architecture. The complete official page and metadata were read online.

  10. [10] · Siemens · November 2024, V20 documentation · Checked on 3 November 2026S7-1200 Programmable controller · V20 · Configuring the outputs on a RUN-to-STOP transition

    For the documented CPU, SB and SM outputs, a RUN-to-STOP transition can retain the present value or apply a substitute, according to configuration. Power-up has separate behaviour, and some distributed modules offer additional responses.

    Passages and scope

    Configuring the outputs on a RUN-to-STOP transition, complete section. Limited to the S7-1200 V20 and the outputs described. It implies no universally safe state, continued regulation, production test or recommended setting. Official page, V20 metadata and complete section read online.

  11. [11] · UK National Cyber Security Centre · 14 January 2026, Published field · Checked on 3 November 2026Secure OT connectivity, Principle 7: log and monitor all connectivity

    Design useful logging, verify maintenance legitimacy and re-enable alerts outside planned maintenance windows.

    Passages and scope

    Opening guidance, Unauthorised activity and Data flow monitoring. The Reviewed field says 18 March 2024. The article uses the displayed guidance; victim logs and alerting arrangements remain unknown. The complete official page and metadata were read online.

  12. [12] · CISA and international partners; ASD / ACSC HTML edition · Guide dated 13 January 2025; HTML page published 14 January 2025 · Checked on 3 November 2026Secure by Demand: priority considerations for selecting OT products

    Procurement criteria covering configuration management, baseline logging and owner autonomy over maintenance and changes.

    Passages and scope

    Summary; Configuration management, Logging in the baseline product and Ownership sections. Selection criteria to assess with manufacturers. Applying them to a product, contract or installation requires specific evidence. Official HTML text read; the guide date was cross-checked in the indexed CISA PDF excerpt. Direct PDFs encountered access limits.

  13. [13] · NIST · 21 September 2026; comments due 30 November 2026 · Checked on 3 November 2026SP 800-82 Revision 4: initial public draft of the OT security guide

    Revision 4 remains open for public comment on 3 November 2026. The final Revision 3 is the technical reference used in this analysis.

    Passages and scope

    Draft heading: Date Published and Comments Due; 21 September 2026 planning note on the Revision 3 page. Only publication-status metadata is used; the draft is not treated as a final publication. The official Revision 4 and Revision 3 pages were read directly online.

This analysis is not investment advice.

// cite this analysis

l0g, “Who actually controls the machines?”, l0g.fr, published November 03, 2026, updated November 03, 2026, https://l0g.fr/en/analysis/ordinary-machines-02-who-controls/


$ cd ../analysis