T0843.003: Program Append
Adversaries may execute a program append to a PLC to update parts of an existing program. It may or may not require stopping the PLC which may allow it to continue running during transfer and reconfiguration without interruption to process control. Adversaries may leverage this approach to minimize downtime and evade detection.
The ability to perform a program append to the PLC typically relies on access to a workstation with the vendor-specific PLC programming software installed.
Analyst context for executives and security teams
Program Append matters because it allows changes to be added to controller logic without necessarily stopping the PLC or interrupting the physical process. For leaders, the risk is not just “code changed,” but that unauthorized or poorly governed logic changes may blend into normal engineering activity and avoid obvious downtime-based alarms. This is especially important in environments with PLCs, safety controllers, DCS controllers, or PACs where continuity and safety depend on trusted control logic.
Executive priority
Prioritize this as an ICS change-control and access-governance issue. Executives should ask whether only approved personnel and systems can perform controller program changes, whether append-style changes are logged and reviewed, and whether integrity baselines exist for controller logic. This behavior is material to operational resilience, audit evidence, safety assurance, and incident response because ATT&CK notes it may allow process control to continue during transfer and reconfiguration, reducing obvious operational signals.
Technical view
SOC, OT, and IR teams should validate visibility around vendor-specific PLC programming workstations and controller logic changes. ATT&CK provides no official detection text for this object, but it is related to DET0914, Detection of Program Append. Defensive validation should focus on whether append events can be distinguished from normal engineering work, whether controller program/configuration integrity checks are performed after downloads, restarts, or reboots, and whether access paths to PLCs, safety controllers, DCS controllers, and PACs are constrained by authentication, authorization, segmentation, allowlisting, and protocol-aware filtering.
Likely telemetry
- Engineering workstation activity involving vendor-specific PLC programming software
- Authentication and authorization records for users and systems allowed to manipulate controller logic
- Controller program, configuration, and integrity-check records, including known-good baselines where available
- ICS network traffic between programming workstations or gateways and controllers
- Network allowlist, segmentation, and protocol-filtering logs for controller access paths
Detection direction
- Validate whether DET0914 or equivalent local logic can identify program append activity specifically, not only full program downloads.
- Tune detections against approved engineering windows and authorized personnel to reduce false positives from legitimate maintenance.
- Look for controller logic changes that occur without matching change tickets, approved users, or expected engineering workstation sources.
- Confirm visibility is not limited to enterprise logs; the decisive evidence may reside on engineering workstations, controller management tooling, gateways, or OT network sensors.
- Account for the key blind spot described by ATT&CK: the PLC may continue running during transfer and reconfiguration, so absence of downtime is not evidence of absence.
Mitigation priorities
- Start with authorization enforcement and access management so only authenticated, approved users and systems can read, manipulate, or execute controller logic changes.
- Require human user authentication and, where appropriate, software process and device authentication for systems communicating with controllers.
- Use network segmentation, network allowlists, and protocol-aware traffic filtering to restrict which systems can reach controller programming interfaces.
- Use communication authenticity controls where controller communications traverse untrusted networks.
- Apply code signing or integrity verification where supported, and maintain audit/integrity checks of controller firmware, programs, and configurations against known valid states.
Analyst notes and limits
ATT&CK identifies Program Append as a sub-technique of Program Download and relates it to PLCs, safety controllers, DCS controllers, and PACs. The relationship context also shows use by the Triton Safety Instrumented System Attack campaign against Triconex safety controllers, but this should be treated as historical ATT&CK context, not evidence of current activity in any environment.
The ATT&CK object does not specify tactics, platforms, or official detection guidance. Local controller models, engineering tools, network architecture, and change-control processes determine what can actually be monitored or enforced. Do not assume coverage without testing against approved program append activity in the environment.
Program Append
Adversaries may execute a program append to a PLC to update parts of an existing program. It may or may not require stopping the PLC which may allow it to continue running during transfer and reconfiguration without interruption to process control. Adversaries may leverage this approach to minimize downtime and evade detection.
The ability to perform a program append to the PLC typically relies on access to a workstation with the vendor-specific PLC programming software installed.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
Related techniques
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| ICS | T0843 | Program Download | This object subtechnique of Program Download. |
Groups, software, and campaigns
C0030: Triton Safety Instrumented System Attack
Triton Safety Instrumented System Attack was a campaign employed by TEMP.Veles which leveraged the Triton malware framework against a petrochemical organization.[1] The malware and techniques used within this campaign targeted specific Triconex Safety Controllers within the environment.[2] The incident was eventually discovered due to a safety trip that occurred as a result of an issue in the malware.[3]
All related ATT&CK context
Mitigation direction
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | 8678f6e0eda1… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack T0843.003Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.