Who Can Change Your Process? Reviewing OT Command Paths

A historian, an operator station, and an engineering workstation may all communicate with the same programmable logic controller (PLC). Their capabilities can differ substantially. One reads measurements. Another changes setpoints or starts equipment. A third downloads logic that changes how the process runs.

OT control authority is the ability of a person, system, or application to issue commands or make changes that affect an operational process. It includes normal operation, configuration changes, and programming. Understanding that authority requires examining the specific actions each source can initiate and the controls that govern them.

Some consequential changes can be made through a device’s intended functionality. When a source has the necessary access and capability, a command to stop equipment or change a setpoint may require no software exploit. The security review needs to account for those legitimate functions and how they could be misused.

For asset owners, this creates a practical task: document who or what can change a critical process, establish why that capability is needed, and verify how it’s constrained.

Classify OT Control Authority by Capability

Start with four categories that operators and engineers can apply to the equipment they maintain.

Capability	What It Allows	Illustrative Example
Observe	Read measurements, status, alarms, or process values	A historian retrieves measurements from a controller
Operate	Issue operating commands or change process values	An HMI changes a setpoint or starts a pump
Configure	Change device, application, or communication parameters	A maintenance application changes device settings
Program	Change control logic or control strategy	An engineering workstation downloads modified PLC logic

These are working categories for a review and not a universal permission hierarchy. A device may support several categories, and the boundaries depend on its implementation. Controller mode changes, for example, should be recorded explicitly because their availability and consequences vary.

Classify the actual deployment. A historian’s intended job may be reading values, while its installed software, credentials, or communication path permit additional functions. Record the intended role and the verified capability separately.

The same applies to an HMI. Its operator interface may expose only approved setpoints, while an underlying application or service has broader write capability. Determine where that restriction is enforced and what could bypass it.

Map Command Paths for One Critical Process

Choose a process with a manageable boundary, such as a pumping station, treatment stage, or production cell. Include the people who operate and maintain it.

Identify the sources that can influence its controllers and process assets. These may include engineering workstations, HMIs, maintenance laptops, supervisory applications, vendor tools, scripts, gateways, and other controllers.

For each source, trace:

Source → Destination → Process Function → Specific Capability → Potential Consequence

An entry might describe an operator station that writes a pump-speed setpoint to a controller. Record the permitted range, the application role required, and any controller logic that limits the accepted value. Another entry might describe an engineering workstation capable of changing that limiting logic.

Include automated relationships. A peer controller may supply a value that changes another controller’s behavior. A gateway may translate an upstream request into a downstream write. A scheduled application may adjust operating parameters without an interactive login.

Indirect paths need the same attention. If vendor access ends at an engineering workstation, determine what that workstation can subsequently change. Record the intermediary and where restrictions apply.

Be specific about the action. “Communicates with PLC” leaves too much unanswered. Useful entries identify functions such as:

• Writing a particular setpoint or register
• Starting or stopping equipment
• Changing operating or controller mode
• Modifying device configuration
• Downloading logic or changing a control strategy

Where capability remains uncertain, mark it as requiring validation.

Identify What Actually Stops a Command

For each consequential action, identify the mechanism that prevents an unauthorized source or excessive request from succeeding.

Different controls act at different points. An application role can restrict the functions available to an operator. A device permission may reject a write. A controller key switch may restrict programming in a particular state. A network control may prevent a source from reaching the service.

Record what each control actually enforces. A firewall rule allowing a protocol may permit both reads and writes. A remote-access login may authenticate the vendor while leaving the downstream engineering application broadly capable.

Review four questions for each command path:

1. Who or what can initiate this action? Include the application, service, or automated device that originates it.
2. Where is the restriction enforced? Identify the relevant application, device, controller state, or boundary.
3. Under what conditions is the action available? Consider maintenance sessions, local access, operating modes, and temporary permissions.
4. What additional capability becomes available if that restriction is bypassed? Check whether another application or direct connection reaches the same function.

Keep approval procedures and technical enforcement distinct in the record. A maintenance procedure may require permission before a logic download, while the workstation remains technically capable of performing one at any time.

Process and safety interlocks also need precise descriptions. An interlock may prevent a physical action under certain conditions without authenticating the command source. Its protective role depends on its design, independence, and whether the source under review can modify or bypass it.

Some equipment relies heavily on trusted sources, physical controls, or network placement. Document those dependencies so the review reflects the protections actually available.

Validate Capability and Observed Activity Separately

A command-path review needs evidence of both potential capability and actual use.

Capability evidence can include device configuration, application roles, engineering project settings, controller state, vendor documentation, and the controls along the path.

Activity evidence can include network observations, device and application logs, engineering change records, remote-session records, and maintenance documentation.

Keep the evidence types separate. Routine polling establishes that reads occurred during the observation period. It doesn’t establish that the source is incapable of writing. Programming capability may remain dormant until an outage or vendor visit.

Likewise, a configured permission does not establish that anyone used it. The review should reconcile capability with activity and explain any differences.

For example, a maintenance workstation may have programming capability but no observed downloads. That could be expected because no approved work occurred during the capture period. It could also reflect incomplete monitoring. Record the observation window and coverage before drawing a conclusion.

Useful evidence notes include:

• The configuration or document reviewed, its date, and the applicable device or software version
• The activity observation period and collection location
• Whether commands and outcomes are visible, or only connections
• Known gaps, including encrypted traffic, missing logs, or local maintenance interfaces
• The person or team that confirmed the operational purpose

Use approved review methods suited to the equipment. Functional testing that could issue commands or alter controller state requires an agreed test plan, appropriate conditions, and operational approval.

Reduce Unnecessary Process-Changing Capability

Once authority is documented, review whether each capability is needed for the source’s assigned task.

Start with concrete mismatches. A system used only to retrieve measurements may retain write capability. An operator station may expose configuration functions that belong to engineering. Vendor programming access may remain enabled after maintenance is complete.

NIST’s OT security guidance recommends disabling functions and services that are unnecessary for proper operation. Apply that principle with the equipment’s operational requirements in view.

Possible changes include:

• Restricting configuration and programming functions to approved engineering systems
• Removing unused write functions where the application or device supports that restriction
• Limiting command-capable communications to justified sources
• Enabling vendor maintenance capability for an approved period and verifying its removal afterward
• Using controller states or physical restrictions appropriate to normal operation
• Retaining required recovery capability through an approved, documented procedure

Review each change with operations, engineering, and relevant vendors. Include safety personnel when the change affects protective functions. Check routine operation, startup, shutdown, troubleshooting, and recovery before removing a capability.

For capabilities that remain necessary, define observable expectations. A useful monitoring rule identifies the source, destination, command or change type, and circumstances that warrant review. Examples include a logic download from an unexpected workstation or a mode change outside approved maintenance.

Detection depends on available protocol visibility and logs. Record those limitations alongside the rule.

Build a Command-Path Register

Bring the review into a register that operations and engineering can maintain. Use separate entries when a source has materially different capabilities or enforcement conditions.

Field	What to Record
Source	System, application, user class, or automated device originating the action
Responsible Owner	Team responsible for the source and its operational use
Destination	Controller or other process asset
Process Function	Equipment or physical operation affected
Authority Category	Observe, operate, configure, program, or a defined local category
Specific Capability	Exact command, parameter change, mode change, or programming function
Path	Direct connection, intermediary, remote session, or local maintenance interface
Enforcement	Mechanisms restricting the action and conditions under which it is available
Evidence	Configuration references, documentation, logs, and observations
Status or Gap	Verified and expected, excessive, uncertain, dormant, or requiring investigation
Follow-Up and Owner	Specific validation or authority change required and the responsible team
Last Reviewed	Date the capability and supporting evidence were checked

An illustrative pump-control review might begin with these entries:

Source	Destination	Capability to Validate	Evidence to Seek
Historian	Pump controller	Measurement reads; any additional write capability	Acquisition configuration, applicable device documentation, traffic observations
Operator HMI	Pump controller	Start/stop and approved setpoint changes	Application roles, controller limits, command logs
Engineering workstation	Pump controller	Configuration changes and logic downloads	Engineering permissions, controller mode, change records
Peer controller	Pump controller	Values or requests that influence pump operation	Approved logic, communication configuration, observed exchanges

These examples describe review questions. The installed configuration determines the capabilities and protections.

Complete the register with the people who know the process. Confirm why each action is needed, what constrains it, and what evidence remains missing. Choose a specific improvement, such as validating a supposedly read-only source, removing persistent programming capability, or establishing visibility for controller mode changes.

Review the affected entries when engineering tools, vendor arrangements, controller logic, or operating requirements change. 

Maintaining OT control authority records gives the team a practical reference for approving changes and investigating unexpected commands.