M1045 Code Signing: Code Signing as a Mapped ATT&CK Control

Code signing only stops attacks where something actually refuses to run unsigned or wrongly signed code, and M1045 Code Signing in MITRE ATT&CK is about that enforcement, not about owning certificates. ATT&CK v20 describes M1045 as using digital signatures to verify the authenticity and integrity of executables, scripts and other code, with enforced policy for unsigned code, vendor-signed driver enforcement, certificate revocation, third-party verification and signing in CI/CD pipelines. This guide maps the mitigation to the 22 active techniques ATT&CK links it to, shows which enforcement point covers each, explains the gaps, and treats the signing keys themselves as non-human identity credentials. It is for platform, endpoint and DevSecOps engineers and detection teams.

Key takeaways

• Signing without enforcement is not M1045. Every ATT&CK mapping depends on a verifier: PowerShell execution policy, driver signing, App Control, container admission, ESXi or network device image checks.
• The mapping spans five tactics. Execution, Persistence, Privilege Escalation, Stealth and Defense Impairment techniques are all in scope, from T1059.001 PowerShell to T1505.006 vSphere Installation Bundles.
• Some verifiers are defence in depth only. Microsoft states that PowerShell execution policy is not a security boundary, so enforcement for T1059.001 needs application control as well.
• Stolen keys turn the control against you. Malware signed with leaked certificates passes signature checks, so key protection and revocation planning are part of the mitigation.
• Signing keys are non-human identities. They need an owner, an inventory, hardware protection, scoped access for pipelines and a tested compromise playbook.

What M1045 asks a team to implement

For the signing process itself (certificate types, timestamping, HSMs, signing services) see the Code Signing Security Guide; this page stays on the ATT&CK mapping.

Techniques M1045 mitigates in ATT&CK v20

ATT&CK v20 has 22 active techniques and sub-techniques with a "mitigates" relationship from M1045. They are grouped below by tactic, with the substance of ATT&CK's usage text and the verifier that does the work.

Linked technique guides: T1059 Command and Scripting Interpreter Defensive Guide, T1036 Masquerading Defensive Guide, T1505 Server Software Component Defensive Guide, T1543 Create or Modify System Process Defensive Guide, MITRE ATT&CK T1525 Implant Internal Image and T1204 User Execution.

Enforcement points in detail

Windows scripts and binaries

• PowerShell execution policy: AllSigned requires all scripts and configuration files to be signed by a trusted publisher; RemoteSigned requires signatures only for scripts downloaded from the internet. Microsoft describes execution policy as defence in depth rather than a security boundary, because users can bypass it, for example by pasting script contents. Set it through Group Policy so local changes are overridden, and rely on App Control for real enforcement. See App Control for Business (WDAC).
• Signer rules over path rules: for T1036.005, path-based allow rules trust anything placed in the right folder; signer-based rules require the expected publisher.

Drivers and services

Microsoft's kernel-mode code signing policy says that from Windows 10 version 1607 new kernel-mode drivers must be signed through the Windows Hardware Dev Center portal, with exceptions for cross-signed drivers when Secure Boot is off, the PC was upgraded from an earlier release, or the driver was signed with an end-entity certificate issued before 29 July 2015. Those exceptions are why signature enforcement alone does not stop vulnerable or stolen-certificate drivers; pair it with a driver blocklist and the controls in the Bring Your Own Vulnerable Driver and EDR Killers Guide.

Containers and images

ATT&CK cites Docker Content Trust for T1204.003 and T1525. Docker's documentation now carries a notice that Docker Content Trust is being retired and that the Notary v1 service at notary.docker.io will shut down on 8 December 2026 (checked 12 November 2026). Teams relying on it should move to an alternative signature and admission approach, such as Sigstore-based signing with verification at admission. See the Sigstore Guide and SLSA and Build Provenance Guide.

Hypervisors and network devices

• ESXi (T1505.006): ATT&CK recommends enabling the execInstalledOnly feature, which prevents unsigned binaries from running on ESXi hosts.
• Network operating systems (T1601): use the vendor's signed image verification features at upgrade and at boot, and alert on verification failures.

Where identity fits: signing keys as non-human credentials

A code signing private key is a credential that lets its holder speak as the organisation to every verifier that trusts it. The NVIDIA code signing certificate theft in 2022 shows the failure mode: two expired certificates and their private keys were leaked, malware signed with them appeared within days, and Windows still accepted them for driver signing because of the pre-2015 certificate exception. M1045 enforcement worked as designed and still let the malware through. NHI Mgmt Group recommends:

• Keep keys non-exportable: HSM or managed signing service, never files on build hosts or shares.
• Give pipelines scoped signing rights: only approved release jobs, authenticated with workload identity rather than long-lived secrets, can request a signature.
• Log and review every signing event against releases; an unmatched signature is an incident.
• Plan revocation in advance: separate certificates per product line and timestamp signatures so one key can be revoked without breaking past releases. See the Compromised Code Signing Certificate Playbook.

More cases are collected in Signing keys and certificates in breaches.

Gaps: what M1045 does not stop

See MITRE ATT&CK T1553 Subvert Trust Controls for the attacker side of these gaps.

Implementation priorities

The order and timings below are NHI Mgmt Group recommendations.

1. Inventory verifiers: list every place a signature is or could be checked (endpoints, servers, ESXi, container platforms, network devices) and whether it is enforcing, auditing or off.
2. Quick wins: enable execInstalledOnly on ESXi, signed image verification on network devices, and AllSigned or RemoteSigned via Group Policy for PowerShell.
3. Application control in audit: deploy signer-based App Control or AppLocker policies in audit mode on pilot rings, review blocks for two to four weeks, then enforce on servers that run few applications (web, SQL, Exchange-style transport roles) first.
4. Container admission: require signed images from approved builders at admission; replace Docker Content Trust where it is in use.
5. Protect the keys: move signing keys into HSM or a managed signing service, restrict callers to pipeline identities, and test the compromise playbook.
6. Rollback: keep the last known good policy versioned, use supplemental or exception policies with owners and expiry dates, and never disable enforcement estate-wide to fix one application.

Detection and measurement

• Policy blocks and audits: CodeIntegrity and AppLocker event logs for blocked or would-be-blocked unsigned files.
• Signer anomalies: files signed by certificates known to be compromised, or by your own certificate outside a release.
• Policy tampering: changes to execution policy GPOs, App Control policies, ESXi execInstalledOnly or admission controller configuration.

Framework mapping and related countermeasures

Common failure patterns

• Signing everything, enforcing nothing: releases are signed but no endpoint, cluster or host rejects unsigned code.
• Trusting execution policy as a control: RemoteSigned is treated as script control even though Microsoft describes it as defence in depth only.
• Publisher rules that are too broad: trusting a whole vendor certificate also trusts that vendor's signed but abusable utilities.
• Keys on build hosts: exportable keys on runners or shares turn a CI compromise into signed malware, as the NVIDIA case shows.
• No revocation path: one certificate signs every product, so revoking it after a leak would break legitimate software.
• Retired trust services left in place: verification depends on a service that is being shut down.

Practitioner checklist

• List every signature verifier and its mode (enforce, audit, off).
• Enable execInstalledOnly on all ESXi hosts.
• Set PowerShell execution policy by Group Policy and back it with App Control.
• Deploy signer-based application control on servers, audit first.
• Require signed images at Kubernetes or registry admission; plan the move off Docker Content Trust.
• Store signing keys in HSM or a managed signing service with pipeline-only access.
• Reconcile signing logs against releases weekly.
• Pre-build deny rules and a playbook for a compromised signing certificate.

Standards and references

• MITRE ATT&CK: M1045 Code Signing
• MITRE ATT&CK: T1553.002 Code Signing
• MITRE D3FEND: Executable Allowlisting
• Microsoft Learn: Driver signing policy
• Microsoft Learn: about_Execution_Policies
• Docker Docs: Content trust in Docker

Related NHI Mgmt Group resources: Code Signing Security Guide · Compromised Code Signing Certificate Playbook · App Control for Business (WDAC) · M1043 Credential Access Protection · M1044 Restrict Library Loading