Live Active security incident? Get immediate response
MITRE ATT&CK® Mitigation

M0945: Code Signing

Enforce binary and application integrity with digital signature verification to prevent untrusted code from executing.

ICSM0945MitigationObject v1.1 Modified
Discuss defensive coverage Back to ATT&CK
Glexia's Take

Analyst context for executives and security teams

Analyst confidence Medium

Code signing is an ICS integrity control: only binaries, applications, firmware, or related control-system code that can be digitally verified should be allowed to run or be loaded. Its business value is reducing the chance that untrusted software, altered controller logic, infected project files, or unauthorized firmware changes become operational risk in a control environment.

Executive priority

Prioritize this where unauthorized code changes could affect production continuity, safety margins, or recovery confidence. The ATT&CK relationships tie this mitigation to controller tasking changes, PLC program downloads and edits, masqueraded executables, project file infection, firmware modification, supply chain compromise, and user-driven execution. It also maps to IEC 62443 SR/CR 3.4 and NIST SP 800-53 SI-7, making it useful evidence for integrity-control and compliance readiness discussions.

Technical view

SOC, OT engineering, and IR teams should validate whether signature verification is enforced at the points where code enters or changes the environment: engineering workstations, application execution paths, controller program download workflows, project files, and firmware update processes where supported. Because ATT&CK provides no official detection text and no specific platforms, coverage must be proven locally by testing whether unsigned or improperly signed items are blocked, logged, escalated, or allowed.

Likely telemetry

  • Application execution allow/deny events related to signature validation
  • Engineering workstation logs for project open, edit, and transfer activity
  • Controller or PLC change records for program download, download all, online edit, and program append events
  • Firmware update records, package validation results, and device maintenance logs
  • File integrity or hash/signature inventory for binaries, project files, and update packages

Detection direction

  • Confirm whether signature verification failures generate logs that reach the SOC or OT monitoring process.
  • Tune for high-risk events such as unsigned code execution, unexpected signed-code changes, firmware update attempts, and controller program changes outside approved maintenance windows.
  • Correlate code-signing failures with related ATT&CK behaviors: Program Download, Modify Program, Modify Firmware, Project File Infection, Masquerading, and User Execution.
  • Account for blind spots where legacy controllers, engineering tools, or firmware workflows may not support signature enforcement or centralized logging.
  • Treat successful signed execution as not automatically benign; code signing validates trust and integrity assumptions, not operational intent.

Mitigation priorities

  • Identify where binaries, applications, controller projects, and firmware can be introduced or changed in the ICS environment.
  • Enable or require digital signature verification for supported execution, download, project, and firmware update workflows.
  • Restrict acceptance to trusted publishers or approved internal signing paths where the environment supports it.
  • Integrate signature validation results into change management and incident response evidence collection.
  • Review gaps for assets or workflows that cannot enforce signatures and compensate with stronger change approval, monitoring, and access control.
Analyst notes and limits

This is a mitigation object, not a technique. Its decision value is highest when tied to engineering change control and firmware/software provenance. The strongest validation question is not whether code signing exists on paper, but whether unsigned or untrusted code is actually prevented from executing or being loaded into ICS assets.

ATT&CK does not provide detection guidance, tactics, or platform specificity for this object. The related techniques indicate where the mitigation is relevant, but local asset capabilities, vendor tooling, and logging determine whether enforcement and monitoring are practical.

Official MITRE ATT&CK definition

Code Signing

Enforce binary and application integrity with digital signature verification to prevent untrusted code from executing.

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

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.

ATT&CK relationship table

Techniques used

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.

15 rows
Domain ID Name Relationship / procedure
ICS T0873.001 Siemens Project File Format Sub-technique

Allow for code signing of any project files stored at rest to prevent unauthorized tampering. Ensure the signing keys are not easily accessible on the same system.
ICS T0843.001 Download All Sub-technique

Utilize code signatures to verify the integrity and authenticity of programs downloaded to the device.
ICS T0851 Rootkit

Digital signatures may be used to ensure application DLLs are authentic prior to execution.
ICS T1693 Modify Firmware

Devices should verify that firmware has been properly signed by the vendor before allowing installation.
ICS T0821 Modify Controller Tasking

Utilize code signatures to verify the integrity and authenticity of programs installed on safety or control assets, including the associated controller tasking.
ICS T1693.002 Module Firmware Sub-technique

Devices should verify that firmware has been properly signed by the vendor before allowing installation.
ICS T0889 Modify Program

Utilize code signatures to verify the integrity and authenticity of programs installed on safety or control assets.
ICS T0849 Masquerading

Require signed binaries.
ICS T0843.003 Program Append Sub-technique

Utilize code signatures to verify the integrity and authenticity of programs downloaded to the device.
ICS T0843 Program Download

Utilize code signatures to verify the integrity and authenticity of programs downloaded to the device.
ICS T0862 Supply Chain Compromise

When available utilize hardware and software root-of-trust to verify the authenticity of a system. This may be achieved through cryptographic means, such as digital signatures or hashes, of critical software and firmware throughout the supply chain.
ICS T0843.002 Online Edit Sub-technique

Utilize code signatures to verify the integrity and authenticity of programs downloaded to the device.
ICS T0863 User Execution

Prevent the use of unsigned executables, such as installers and scripts.
ICS T1693.001 System Firmware Sub-technique

Devices should verify that firmware has been properly signed by the vendor before allowing installation.
ICS T0873 Project File Infection

Allow for code signing of any project files stored at rest to prevent unauthorized tampering. Ensure the signing keys are not easily accessible on the same system.
Relationship explorer

All related ATT&CK context

mitigates · Technique T0873.001: Siemens Project File Format ICS mitigates · Technique T0843.001: Download All ICS mitigates · Technique T0851: Rootkit ICS mitigates · Technique T1693: Modify Firmware ICS mitigates · Technique T0821: Modify Controller Tasking ICS mitigates · Technique T1693.002: Module Firmware ICS mitigates · Technique T0889: Modify Program ICS mitigates · Technique T0849: Masquerading ICS mitigates · Technique T0843.003: Program Append ICS mitigates · Technique T0843: Program Download ICS mitigates · Technique T0862: Supply Chain Compromise ICS mitigates · Technique T0843.002: Online Edit ICS mitigates · Technique T0863: User Execution ICS mitigates · Technique T1693.001: System Firmware ICS mitigates · Technique T0873: Project File Infection ICS
Change history

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 .

ATT&CK release
19.1
Object version
1.1
Created
Modified
Raw hash
509ca92edd4aaa2d...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.1 Current bundle 509ca92edd4a…
Raw source

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.

Open mirrored raw JSON Open MITRE-hosted copy
Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [1]
    mitre-attack M0945
    Open source URL
Source and licensing

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.

Official MITRE ATT&CK site Official STIX data repository MITRE ATT&CK terms of use