Cyber Resilience

← ISO 27001 Annex A

A.8.19 Technological

Installation of software on operational systems

AttributesPreventive C·I·A Protect Secure configuration Application security Protection

Structured attributes from ISO/IEC 27002:2022 — control type · CIA properties · cybersecurity concept · operational capability · security domain. What do these mean?

The implementation guidance for this control is published in ISO/IEC 27002:2022 and is not reproduced here. The structured attributes and the cross-walk rationales below are derived facts and our own AI-authored analysis.

Mapped NIST 800-53 r5 controls (21)

Our AI-authored reading (authority llm_unverified, under review) of how this ISO control and each NIST 800-53 control relate. Not an ISO or NIST product.

Direction: ← other covers this; → this covers other (F/M/P = full / mostly / partial). gov = governs / implements (a mandate, not coverage).

AC-6←P AU-2→P CM-11←F CM-2→P CM-3←M →M CM-5←M CM-6→P CM-7←P SA-22←M SI-2←P →P SI-7←P

Why these map — AI rationale (under review)

CM-3mostlyaligns with — Both controls establish formal change-control procedures for software on operational systems, including authorization, testing, rollback planning, and audit logging of updates.
CM-5mostlyaligns with — Both controls restrict who may install or modify software on operational systems and enforce least-privilege principles for those changes.
AU-2partialaligns with — Both controls require logging of software installation and update events to support accountability and post-change review.
CM-2partialaligns with — Both controls require maintaining an authoritative, version-controlled baseline of approved operational software and associated documentation.
CM-2partialcovers — A.8.19's narrow procedural rules for approving and controlling software installation on live systems address only the final 'when components are installed or upgraded' trigger in CM-2; they do not develop, document, or maintain the baseline itself nor address the other review/update triggers.
CM-6partialaligns with — Both controls ensure that only approved, hardened configurations and executables are deployed and that deviations are prevented or detected.
CM-6partialcovers — A.8.19's focus on controlling software installation (including baselines, approvals, and integrity checks) accounts for the bulk of CM-6's configuration-settings establishment, implementation, and deviation-approval requirements, but leaves a residual of non-installation component settings (e.g., runtime parameters, registry values) uncovered.
SI-2partialaligns with — Both controls mandate timely application of security patches and updates after testing, while tracking vulnerabilities that the patches address.
SI-2partialcovers — A.8.19's narrow procedural requirement to control and approve software installation on operational systems addresses only the 'install updates' and configuration-management slices of SI-2; it does not address identifying, reporting, testing-before-install, or the broader flaw-correction obligations.
CM-5covers — Assessed as NOT holding by the authoring instrument at v1.22-2026-08-29. This row records a tested non-relation; it is not a graded claim and carries no rationale, because the instrument produced none when the verb did not hold.

Aligned NIST CSF 2.0 outcomes (20)

NIST CSF 2.0 outcomes this ISO control aligns with — our AI-authored analysis (authority llm_unverified, under review).

Direction: ← other covers this; → this covers other (F/M/P = full / mostly / partial). gov = governs / implements (a mandate, not coverage).

PR.AA-05←M PR.PS-01←M →M PR.PS-02←F →F DE.CM-09gov GV.SC-05gov ID.RA-07gov ID.RA-09gov PR.AT-02gov PR.PS-04gov PR.PS-05gov

Why these map — AI rationale (under review)

PR.PS-02fullcovers — The ISO control's emphasis on authorized, tested, and logged software updates directly fulfills the CSF outcome of maintaining, replacing, and removing software commensurate with risk.
PR.PS-01mostlycovers — Requiring configuration control systems, rollback strategies, and audit logs for operational software changes implements the CSF outcome of establishing and applying configuration management practices.
PR.PS-05mostlyaligns with — Enforcing strict rules on permitted versus prohibited software installations and applying least privilege prevents unauthorized software execution on operational systems.
DE.CM-09partialaligns with — Maintaining audit logs of software updates and monitoring externally supplied software supports continuous monitoring of computing environments for adverse events.
GV.SC-05partialaligns with — Requiring authorization and monitoring when suppliers install or update software integrates cybersecurity requirements into third-party contracts and activities.
ID.RA-07partialaligns with — Assessing the security impact of new releases and patches before deployment aligns with managing changes and exceptions for risk impact.
DE.CM-09implements — Assessed as NOT holding by the authoring instrument at v1.22-2026-08-29. This row records a tested non-relation; it is not a graded claim and carries no rationale, because the instrument produced none when the verb did not hold.
GV.SC-05implements — Assessed as NOT holding by the authoring instrument at v1.22-2026-08-29. This row records a tested non-relation; it is not a graded claim and carries no rationale, because the instrument produced none when the verb did not hold.
ID.RA-07implements — Assessed as NOT holding by the authoring instrument at v1.22-2026-08-29. This row records a tested non-relation; it is not a graded claim and carries no rationale, because the instrument produced none when the verb did not hold.
PR.PS-05implements — A.8.19 directly operationalizes the prevention of unauthorized software installation that PR.PS-05 requires

Related OWASP ASVS 5.0 requirements (10)

Application-security verification requirements (OWASP ASVS 5.0) this ISO control aligns with; links open the ASVS chapter. Our AI-authored analysis (authority llm_unverified, under review) — many ISO controls have no ASVS counterpart.

Direction: ← other covers this; → this covers other (F/M/P = full / mostly / partial). gov = governs / implements (a mandate, not coverage).

V13.3.4→P V13.4.2←P →P V15.1.2←M V15.2.1←M →M V15.2.4←M →P V15.2.5→P V16.2.1←P

Why these map — AI rationale (under review)

V15.2.1mostlyaligns with — The ISO control's requirement to apply only tested, approved updates and patches to operational systems directly supports the ASVS rule that production components must remain within documented remediation timeframes and not contain known vulnerable versions.
V13.3.4partialaligns with — Mandating a rollback strategy, audit logging, and archiving of prior versions before changes are applied corresponds to the ASVS requirement that secrets and critical configuration items be rotated and version-controlled according to documented schedules.
V13.4.2partialaligns with — The prohibition on installing development code or compilers on operational systems and the insistence on least-privilege installation rights help ensure that debug or extraneous functionality is not present in production, matching the ASVS control that debug modes must be disabled.
V15.2.4partialaligns with — Requiring that vendor and open-source software be maintained at supported releases and monitored for unauthorized changes aligns with the ASVS expectation that third-party components and transitive dependencies come from expected, controlled repositories.
V15.2.5partialaligns with — Defining strict rules on permitted versus prohibited software types and applying least privilege to installation activities aligns with the ASVS requirement to implement additional protections around documented dangerous functionality.

Related weaknesses / CWE (27)

Weakness classes this ISO control helps prevent or mitigate — our AI-authored analysis (authority llm_unverified, under review).

Direction: ← other covers this; → this covers other (F/M/P = full / mostly / partial). gov = governs / implements (a mandate, not coverage).

CWE-114←P →P CWE-1269←P CWE-1328←P CWE-1342→P CWE-1357→P CWE-1394→P CWE-15←P →P CWE-284→P CWE-426←P CWE-427←P →P CWE-428←P CWE-507←P →P CWE-508←P →P CWE-509←P →P CWE-553←P →P CWE-623←P CWE-646←P CWE-732→P

Why these map — AI rationale (under review)

CWE-1328nonemitigates — Controlled software installation procedures can block unauthorized or older firmware versions from being loaded.
CWE-250noneprevents — Restricting installation privileges to trained administrators and denying them to ordinary users prevents processes from executing with unnecessary elevated rights.
CWE-114prevents — Restricting software installation prevents loading untrusted libraries or executing commands from unknown sources.
CWE-1342mitigates — Software installation control can ensure only patched microcode or firmware is deployed.
CWE-1357mitigates — Software-installation controls reduce risk of introducing untrusted components into production.
CWE-1394prevents — Controls software installation and configuration, reducing risk of default keys being left in place.
CWE-15mitigates — Restricting software installation limits unauthorized changes to configuration.
CWE-284prevents — Requiring management authorization and least-privilege assignment for software installation directly blocks unauthorized actors from placing or altering code on operational systems.
CWE-427mitigates — Restricting software installation reduces the chance that an attacker-controlled path element is introduced into the search path.
CWE-507prevents — Controlling software installation prevents covert insertion of Trojan Horse payloads.
CWE-508prevents — Restricting software installation reduces the chance of introducing non-replicating malicious code.
CWE-509prevents — Restricts unauthorized software installation that could introduce replicating malware.
CWE-553prevents — Restricting software installation prevents unauthorized shell scripts from being placed in web-accessible directories.
CWE-732prevents — Enforcing strict rules on permitted software types and applying least privilege limits the permissions granted to users or processes that could otherwise modify critical resources.

Mitigated MITRE ATT&CK techniques (527)

Adversary techniques (MITRE ATT&CK Enterprise) this ISO control helps mitigate; links open attack.mitre.org. Our AI-authored analysis (authority llm_unverified, under review).

Direction: ← other covers this; → this covers other (F/M/P = full / mostly / partial). gov = governs / implements (a mandate, not coverage).

T1001.003←M T1006←F T1014←M T1027.001←M T1027.002←M T1027.004←M →P T1027.005←M T1027.006←M T1027.007←M T1027.008←M T1027.009←M T1027.010←M T1027.011←M T1027.014←M T1027.016←M T1027.018←M T1036←M T1036.003←M T1036.004←M T1036.005←M T1036.006←M T1036.007←M T1036.008←M T1036.009←M T1037→P T1037.001→P T1037.002→P T1037.003→P T1037.004→P T1037.005→P T1047→P T1053→P T1053.002→P T1053.003→P T1053.005←M →P T1053.006→P T1053.007→P T1055←M T1055.001←M →P T1055.002←M T1055.003←M →P T1055.004←M T1055.005←M T1055.008←M T1055.009←M T1055.011←M T1055.012←M T1055.013←M T1055.014←M T1055.015←M T1056.003←M →P T1059←M →P T1059.001→P T1059.005→P T1059.006→P T1059.007→P T1059.008←M →P T1059.010→P T1059.011→P T1059.012→P T1059.013→P T1068←M →P T1070.006←M T1070.010←M T1071←M T1071.001←M T1071.004←M T1072←M →P T1078←P T1078.004←M T1080←M T1091→P T1098.004→P T1098.005←M T1105←M →P T1110.001→M T1112←M T1127←M →P T1127.001←M →P T1127.002←M →P T1127.003←M →P T1129→P T1133←M T1134←M T1134.004←M T1137→P T1137.001←M →P T1137.002→P T1137.003→P T1137.004→P T1137.006←M →P T1176←M →P T1176.001←M →P T1176.002←M →P T1185→P T1189←M →P T1190→P T1195←M →P T1195.001←M →P T1195.002←M →P T1199←M →P T1202←M T1203←M →P T1204←M →P T1204.002←M →P T1204.003←M →P T1204.005←M →P T1207←M T1210←M →P T1211←M →P T1212→P T1216←M →P T1216.001←M →P T1216.002←M →P T1218←M →P T1218.001←M →P T1218.002←M →P T1218.003←M →P T1218.004←M →P T1218.005←M →P T1218.007←M →P T1218.008←M →P T1218.009←M →P T1218.010←M →P T1218.011←M →P T1218.012←M →P T1218.013←M →P T1218.014→P T1219←M →P T1219.001←M →P T1219.002←M →P T1219.003←M T1220←M →P T1221←M T1222←M T1222.001←M T1222.002←M →P T1480.001←M T1484←M T1484.001←P →P T1484.002←M T1485→M T1486→M T1489←P T1490←M →M T1495→P T1496.001→P T1497←M T1499→P T1499.004←P →P T1505←M →M T1505.001→P T1505.002←M →P T1505.003←M →P T1505.004←M →P T1505.005←M →P T1505.006←M →P T1525←M →P T1535←M T1537←M T1539←F T1542←M T1542.001←P T1542.002←M T1542.003←M →P T1542.004←M →P T1542.005←M →P T1543←M →P T1543.001←M →P T1543.002←M →P T1543.003←M →P T1543.004←M →P T1543.005←P →P T1546→P T1546.001←M →P T1546.002→P T1546.003→P T1546.004←M →P T1546.006←P →P T1546.007→P T1546.008←M →P T1546.009→P T1546.010→P T1546.011←M →P T1546.012←M →P T1546.013→P T1546.014→P T1546.015←P →P T1546.016←M →P T1546.017→P T1546.018→P T1547←M →P T1547.001←P →P T1547.002←M T1547.003→P T1547.004←P →P T1547.005←M →P T1547.006←M →P T1547.007→P T1547.008←M →P T1547.010→P T1547.012←M →P T1547.013→P T1547.014→P T1547.015←P →P T1548←P →P T1548.001←P →P T1548.002←M →P T1548.003←P →P T1548.004←M →P T1548.005→P T1548.006←M T1550←F T1550.001←F T1550.002←F T1550.003←M T1550.004←F T1552.001→P T1553←M →P T1553.001←M →P T1553.002←M T1553.003←M T1553.004←P →P T1553.005←M T1553.006←M →P T1554←M →P T1556←M →P T1556.001←M →P T1556.002←M →P T1556.003←M →P T1556.004←M →P T1556.007←M →P T1556.008←M →P T1556.009←M T1561→M T1561.001→M T1561.002→M T1565.003→P T1566.002←M T1566.003←M T1569→P T1569.002→P T1569.003→P T1571←M T1572←M T1574←M →P T1574.001←M →P T1574.004←M →P T1574.005←M →P T1574.006←M →P T1574.007←M →P T1574.008←M →P T1574.009→P T1574.010←P →P T1574.011→P T1574.012←P T1574.013←M T1574.014→P T1578←M T1578.001←M T1578.002←M T1578.003←M T1578.004←M T1578.005←M T1587.001←M T1588.001←M T1599←M T1600←M T1600.001←P T1601←M →P T1601.001←M →P T1601.002←M →P T1606←M T1606.001←F T1610←P →P T1611←M →P T1612←M →P T1620←M →P T1622←M T1647←M T1665←P T1666←M T1668←P T1677←M →P T1684←M T1685←M →P T1685.002←M →P T1685.003←M T1685.004←M T1685.005←M T1686←F →P T1686.001←M T1686.002←M T1686.003←M T1687←M →P T1688←M T1689←M →P

Why these map — AI rationale (under review)

T1027.004prevents — A.8.19 explicitly prohibits development code/compilers on operational systems, requires approval/testing/authorization for all installs, and enforces least-privilege rules on what users may install; this stops the technique's required compilation step (and the delivery of uncompiled source) on managed operational systems, but leaves open delivery/compilation during initial build, in dev environments, or via unmonitored external packages.
T1037prevents — A.8.19's rules on approved code only, admin-only updates after testing, least-privilege installation rights, and monitoring of external/supplier changes directly stop adversaries from placing or altering malicious boot/logon scripts on operational systems, but do not reach every platform or every local/remote vector in the class.
T1037.001prevents — A.8.19's rules on approved code only, admin-only updates after testing, least-privilege installation rights, and no untrusted/externally-sourced software directly block adversaries from placing or modifying the logon script that T1037.001 relies on; the remainder is that the technique can still be introduced by an already-privileged admin or via approved-but-malicious updates.
T1037.002prevents — A.8.19's rules on approved code only, admin-only updates with authorization, least-privilege installation, testing before install, and monitoring of external/supplier changes directly stop adversaries from inserting a malicious LoginHook plist or script on operational macOS systems; the deprecation note and residual user-install vectors keep it from mostly/full.
T1037.003prevents — A.8.19's rules on approved code only, admin-only installation with authorization, testing before deployment, least-privilege installation rights, and monitoring of supplier changes directly block adversaries from pushing malicious network logon scripts via AD/GPO or operational installs, but do not reach every possible vector (e.g. already-privileged insiders or pre-existing approved scripts that are later altered).
T1037.004prevents — A.8.19's rules on approved code only, admin-only installation with authorization, least-privilege installation rights, testing before deployment, and monitoring of supplier changes directly stop adversaries from modifying RC scripts with malicious content on operational systems, but the control is silent on the initial presence of writable RC files, runtime file-permission bypasses, and non-installation vectors such as direct root shell access that the technique can also exploit.
T1037.005prevents — A.8.19's rules on approved code only, admin-only installation with authorization, least-privilege installation rights, testing before deployment, and monitoring of external/supplier changes directly stop adversaries from placing unauthorized startup-item executables or plists into /Library/StartupItems; the remainder is that the control is silent on the already-installed baseline items that ship with the OS and on post-install runtime tampering of the boot process itself.
T1047prevents — A.8.19's rules on approved code only, least-privilege installation rights, administrator-only updates, and testing of changes can block many malicious WMI-abusing payloads from reaching operational systems, but the technique can still be used via built-in WMI interfaces, PowerShell, or COM APIs that are part of the approved OS and not removed by the control.
T1053prevents — A.8.19's rules on approved code only, admin-only updates after testing, least-privilege installation rights, and monitoring of external/supplier changes directly stop adversaries from installing a malicious scheduled task or job on operational systems; the remainder is pre-installed tasks, remote scheduling that bypasses the rules, or tasks created via already-approved but still-abusable utilities.
T1053.002prevents — A.8.19's rules on approved code only, least-privilege installation rights, trained admins, testing before install, and no unvetted external packages directly block many vectors for introducing and scheduling malicious at-based binaries or tasks, but the control is silent on the at utility itself, on runtime privilege checks for already-installed schedulers, and on non-installation abuse paths such as sudo-enabled at or WMI Win32_ScheduledJob, leaving a genuine minority slice prevented.
T1053.003prevents — A.8.19's rules on approved code only, admin-only updates after testing, least-privilege installation rights, and monitoring of external packages constrain which scheduled tasks can be installed via cron, but do not stop an already-authorized admin (or a compromised admin account) from adding a malicious crontab entry.
T1053.005prevents — A.8.19's rules on least-privilege software installation, approved code only, admin authorization, and prohibiting untrusted/unknown software constrain many vectors for installing a malicious scheduled-task binary or script, but do not block all creation methods (e.g. direct schtasks.exe or WMI from already-approved admin contexts, hidden-task registry edits, or post-install abuse of legitimate tasks).
T1053.006prevents — A.8.19's rules on approved code only, admin-only installation with authorization, least-privilege installation rights, and testing before deployment on operational systems block many (but not all) paths for writing a malicious .timer/.service pair, especially user-level or unvetted third-party cases; the technique can still be introduced via approved updates or privileged admin actions that the control does not universally stop.
T1053.007prevents — A.8.19's rules on approved code only, admin-only updates after testing, least-privilege installation rights, and monitoring of external/supplier changes constrain what can be scheduled via orchestration jobs, but do not block an already-authorized admin or compromised account from deploying a malicious container job.
T1055.001detects — A.8.19 requires audit logging of all updates plus monitoring of supplier activities and externally supplied packages, which can surface anomalous software installation that precedes or enables DLL injection, but the clause does not mandate host/process behavioral monitoring that would catch the injection technique itself once underway.
T1055.003detects — A.8.19 requires maintaining an audit log of all updates to operational software and monitoring of supplier activities plus externally supplied packages, which can surface anomalous software changes that enable thread hijacking, but this is limited to installation/update events and does not broadly detect in-process memory manipulation or hijacking techniques once running.
T1056.003prevents — A.8.19's rules on approved code only, admin-only updates after testing, least-privilege installation rights, and monitoring of external/supplier changes directly stop adversaries from installing the credential-capturing portal code on operational systems; the remainder is the initial-compromise vector that bypasses these rules before the code is 'operational'.
T1059prevents — A.8.19's rules on approved code only, least-privilege installation rights, testing before deployment, and prohibiting untrusted/unauthorized software on operational systems stop many interpreter-abuse vectors at the source (no malicious scripts or interpreters can be installed), but built-in platform interpreters required for normal operation remain available for abuse, matching the cm-7 vs T1059 partial anchor.
T1059.001prevents — A.8.19's rules on approved code only, admin-only updates after testing, least-privilege installation rights, and monitoring of external packages directly stop many (but not all) ways PowerShell can be installed, invoked, or abused for execution on operational systems.
T1059.005prevents — A.8.19's rules on approved code only, least-privilege installation rights, testing before deployment, and prohibiting untrusted/unauthorized software on operational systems block many VB/VBA/VBScript execution vectors (especially unauthorized payloads or unvetted macros), but cannot stop built-in, vendor-supported interpreters or approved Office macros that adversaries still abuse.
T1059.006prevents — A.8.19's rules on approved code only, tested updates, least-privilege installation rights, and no development tools/compilers on operational systems stop many (but not all) ways an adversary can introduce and then abuse a Python interpreter or malicious .py payload
T1059.007prevents — A.8.19's rules on approved code only, admin-only updates after testing, least-privilege installation rights, and monitoring of external packages directly stop many vectors for introducing and executing malicious JS/JScript/JXA interpreters or payloads on operational systems; residual coverage gaps remain for browser-hosted JS, drive-by delivery, and in-memory OSAKit execution that the clause does not reach.
T1059.008prevents — A.8.19's rules on approved code only, admin-only updates after testing, least-privilege installation rights, and monitoring of external/supplier changes constrain what can be installed or executed via network-device CLI, blocking many abuse vectors; it does not reach all CLI scripting, remote-access methods, or post-install configuration changes on the device.
T1059.010prevents — A.8.19's rules on approved executables only, least-privilege installation, trained admins, testing before deployment, and monitoring of external packages directly stop many AHK/AutoIT script and compiled-payload installation vectors on operational Windows systems; residual coverage remains for user-installed interpreters, permitted personal-use tools, and post-install runtime abuse of already-present legitimate automation packages.
T1059.011prevents — A.8.19's rules on approved code only, testing before install, least-privilege installation rights, and no unvetted external packages on operational systems stop many (but not all) ways an adversary can introduce or replace a Lua interpreter or malicious .lua payload
T1059.012prevents — A.8.19's rules on approved code only, least-privilege installation rights, administrator-only updates, and monitoring of external/supplier changes constrain which hypervisor CLIs can be present or invoked on operational systems, but do not eliminate the legitimate administrative use of esxcli/vim-cmd that adversaries abuse.
T1059.013prevents — A.8.19's rules on approved code only, admin-only updates after testing, least-privilege installation rights, and monitoring of external packages directly constrain the ability to introduce and run unapproved container images or CLI/SDK commands that realize T1059.013; the remainder is legitimate admin use of the same tools for approved containers.
T1068prevents — A.8.19's rules on approved code only, tested patches, least-privilege installation rights, and avoiding unsupported/vulnerable releases stop many exploitable vulnerabilities from reaching operational systems, but do not guarantee the absence of 0-days or logic errors in otherwise-approved software that can still be exploited for privilege escalation.
T1072prevents — A.8.19's rules on approved code only, admin-only updates with authorization, least-privilege installation rights, testing before deployment, and monitoring of external/supplier changes directly constrain abuse of deployment tools by limiting who can install/run them and what can be pushed, but leave open adversary abuse of already-approved legitimate deployment tools via stolen admin credentials or supply-chain compromise of the tool itself.
T1091prevents — A.8.19's rules on approved code only, testing before install, least-privilege installation rights, and no untrusted/unsigned executables on operational systems stop many (but not all) forms of malicious software being written to or executed from removable media that reaches an operational system.
T1098.004prevents — A.8.19's rules on least-privilege software installation, approved code only, admin authorization, and prohibiting untrusted installs constrain the shell/command/API methods adversaries use to write authorized_keys, but do not reach config-file edits, network-device CLI commands, or already-installed malicious tools that can still modify the file.
T1105prevents — A.8.19's rules on approved code only, admin-only updates after testing, least-privilege installation rights, and monitoring of external/supplier packages directly block many of the technique's download vectors (e.g. unapproved utilities, package-manager abuse, unsanctioned user installs), but leave open vectors that use already-permitted tools or occur before the control applies (e.g. initial C2 channel, web-service sync, or lateral transfer of already-present tools).
T1110.001prevents — A.8.19 requires strict rules, least-privilege installation rights, approved code only, trained admins, testing before deployment, and monitoring of external packages; this directly stops installation of guessing tools, custom brute-forcers, or unvetted credential-stuffing utilities on operational systems, preventing the technique from running there (mirroring the A.8.5->T1110.001 mostly anchor).
T1127prevents — A.8.19's rules on approved code only, no dev tools/compilers on ops systems, least-privilege install rights, and testing before install directly stop many signed trusted-developer utilities (MSBuild, csc, etc.) from being present or runnable, preventing the proxy technique; partial because the control is silent on utilities already baked into the OS image or approved for dev-tooling roles, which attackers still abuse.
T1127.001prevents — A.8.19's rules on approved executable code only, administrator-only updates after testing, least-privilege installation rights, and monitoring of external/supplier packages directly constrain the ability to introduce and run unapproved inline-task XML that abuses a trusted build utility, but do not reach every vector (e.g. already-permitted developer tools or sanctioned use of MSBuild itself).
T1127.002detects — A.8.19 requires audit logging of all updates to operational software plus monitoring of supplier activities and externally supplied packages; this can surface anomalous or unauthorized ClickOnce-based installation/execution events on Windows operational systems, but only a minority slice of the technique (e.g. not the rundll32 proxy, startup-folder persistence, or non-update abuse paths).
T1127.002prevents — A.8.19's rules on approved code only, admin-only updates, testing before install, least-privilege installation rights, and monitoring of external/supplier packages directly constrain several abuse vectors (unapproved malicious ClickOnce payloads, user-driven installs, unvetted external .NET components), but leave open the remainder where a seemingly-approved or disguised ClickOnce package is delivered via user execution or startup-folder persistence without violating the stated installation rules.
T1127.003prevents — A.8.19's rules on approved executables only, no development code/compilers on operational systems, least-privilege installation, and testing of updates directly block many ways an adversary could introduce and run JamPlus (or a .jam build file) on production Windows systems, but the control is silent on developer workstations, build/CI environments, and sanctioned use of build utilities, leaving a genuine slice of the technique unaddressed.
T1129prevents — A.8.19's rules on approved code only, testing before install, least-privilege installation rights, and monitoring of external/supplier modules constrain which shared modules can be introduced and loaded on operational systems, stopping many T1129 abuse paths; it leaves open runtime loading of already-present approved modules or unmonitored external ones.
T1137prevents — A.8.19's rules on approved code only, admin-only updates after testing, least-privilege installation rights, and monitoring of external packages directly block many Office add-in/macro/template persistence vectors at install time; residual coverage exists for mechanisms that abuse already-installed Office features without new code (e.g. rules, forms, Home Page).
T1137.001prevents — A.8.19's rules on approved code only, admin-only updates, least-privilege installation rights, testing before deployment, and monitoring of external packages constrain the ability to place or modify a malicious Office template/macro on operational systems, but do not stop an already-privileged user or bypassed approval path from doing so, and the technique can still target user-writable locations without installing new software.
T1137.002prevents — A.8.19's rules on approved code only, admin-only updates after testing, least-privilege installation rights, and monitoring of external/supplier changes directly stop the addition of an unapproved malicious DLL via the Office Test registry key on operational systems; the remainder is that the control does not reach every possible vector (e.g. already-installed Office apps on unmanaged endpoints or pre-existing registry abuse before the rules are enforced).
T1137.003prevents — A.8.19's rules on approved code only, admin-only updates after testing, least-privilege install rights, and monitoring of external/supplier changes constrain the ability to introduce and persist a malicious Outlook form on an operational system; the remainder is user-context or already-installed Outlook customizations that bypass those gates.
T1137.004prevents — A.8.19's rules on approved code only, admin-only updates, testing before install, least-privilege installation rights, and monitoring of external/supplier changes directly stop the introduction of the malicious HTML/URL that realizes this persistence technique on operational Outlook systems; the remainder is user-installed client-side changes or already-compromised mailboxes that bypass the operational-install gates.
T1137.006prevents — A.8.19's rules on approved code only, admin-only updates after testing, least-privilege installation rights, and monitoring of external/supplier changes directly stop many add-in persistence vectors (especially unapproved or user-installed ones), but do not reach all Office add-in types or every deployment path, leaving a genuine minority slice unaddressed.
T1176prevents — A.8.19's rules on approved code only, admin-only installation with authorization, least-privilege restrictions on what users may install, and monitoring of supplier-driven changes directly block many vectors for installing malicious or unvetted extensions on operational systems, but leave open social-engineering of approved users, compromised marketplaces that still pass approval, and abuse of already-installed benign extensions.
T1176.001prevents — A.8.19's rules on approved code only, least-privilege installation rights, trained admins, testing before install, and monitoring of external packages directly stop many installation vectors for malicious browser extensions on operational systems, but leave open social-engineering consent, unpatched browser stores, and post-compromise file manipulation that the control does not address.
T1176.002prevents — A.8.19's rules on approved code only, admin-only installation, least-privilege install rights, testing before deployment, and monitoring of external packages directly constrain side-loading or marketplace installation of malicious IDE extensions on operational systems, but do not reach benign-extension abuse, developer workstation exemptions, or pre-installed marketplace supply-chain compromise (T1195.001).
T1185prevents — A.8.19's rules on approved code only, tested updates, least-privilege installation rights, and avoiding unmaintained/vulnerable software on operational systems stop many malicious browser injections and unpatched-vulnerability hijacks before they can be installed; residual attack surface remains for in-memory injection into already-running approved browsers and for zero-days not caught by the approval/testing gates.
T1189prevents — A.8.19's rules on approved code only, tested updates/patches, least-privilege installation rights, and avoiding unsupported software on operational systems stop many client-side vulnerable components (and thus the browser/plugin exploitation step) from being present, but leave open the initial web visit, watering-hole compromise of the site itself, and any unpatched browser that still satisfies the rules.
T1190prevents — A.8.19's rules on approved code only, tested patches, least-privilege installation, and avoiding unmaintained/vendor-unsupported software stop many classes of public-facing bugs and misconfigurations from reaching production, but leave residual exposure to 0-days, unpatched supported software, and configuration errors outside the installation process itself.
T1195prevents — Requiring management authorization, trained administrators, and testing before software is installed on operational systems reduces the likelihood that an adversary can introduce malicious code through a compromised supply chain or vendor update.
T1195.001prevents — A.8.19 explicitly requires monitoring and control of externally supplied software/packages (including open-source dependencies), maintaining them to latest supported releases, considering risks of unmaintained/abandoned ones, enforcing approval/testing rules before installation, and applying least-privilege rules on what users can install — all of which stop many (but not all) pre-receipt manipulations of dependencies and dev tools from reaching operational systems.
T1195.002prevents — A.8.19's rules on approved code only, tested updates, supplier monitoring, least-privilege installation, and avoiding unmaintained OSS directly block several supply-chain manipulation vectors (update mechanisms, unauthorized installs, unvetted external modules) before they reach operational systems, but leave source-code manipulation upstream of the organization and broad pre-compromise distribution untouched.
T1199prevents — A.8.19 explicitly requires limiting supplier access to only when necessary with authorization, monitoring their activities, enforcing strict rules on permitted software/installations, and applying least privilege to installation — directly constraining the elevated/trusted third-party access that T1199 abuses, though this is only one slice of the technique (e.g. does not address compromise of the third party's own accounts or all relationship leverage vectors).
T1203prevents — A.8.19's rules on approved code only, tested patches, least-privilege installation, and avoiding unsupported software stop many client-application vulnerabilities from reaching operational systems, but do not address the unsecure coding practices that create the vulnerabilities themselves nor block all third-party or externally supplied components.
T1204prevents — A.8.19's rules on approved code only, least-privilege installation rights, testing before deployment, and blocking untrusted/unsigned executables on operational systems stop many user-execution vectors that rely on installing or running unapproved malware, but leave social-engineering tricks that trick already-permitted actions (e.g. opening documents, enabling RATs, running browser JS, or copy-paste) untouched.
T1204.002prevents — A.8.19's rules on approved code only, admin-only updates, testing before install, least-privilege installation rights, and monitoring of external/supplier packages directly stop many malicious files from reaching and executing on operational systems; the remainder is user-launched files that never transit the approved-install path (e.g. email attachments opened directly).
T1204.003prevents — A.8.19's rules on approved code only, testing before install, least-privilege installation rights, monitoring of external packages, and avoiding unmaintained software directly stop many malicious-image deployments on operational systems; residual exposure remains for social-engineering tricks that cause users to pull and run unvetted images outside those enforced gates.
T1204.005prevents — A.8.19's rules on approved code only, testing before install, least-privilege installation rights, monitoring of external packages, and avoiding unmaintained software constrain many vectors for malicious libraries reaching operational systems, but do not stop all (e.g. approved-but-later-backdoored dependencies, typosquatting that evades pedigree checks, or user-installed dev tools outside the operational boundary).
T1210prevents — A.8.19 requires approved, tested, patched, and least-privilege-managed software installation plus monitoring of external dependencies and unsupported versions, which stops many exploitable remote-service vulnerabilities from being present; it leaves a slice (0-days, unpatched supported software, and configuration errors in permitted services) untouched.
T1211prevents — A.8.19's rules on approved/tested updates, least-privilege installation, no dev tools/compilers, and vendor/open-source maintenance directly stop many exploitable flaws from reaching operational systems, but leave residual unpatched or zero-day vulnerabilities that T1211 can still leverage for stealth.
T1212prevents — A.8.19's rules on approved/tested updates, patch application to remove vulnerabilities, least-privilege installation, and avoiding unmaintained software stop many exploitable credential-handling flaws from reaching operational systems, but leave residual cases (e.g., zero-days, unpatched supplier code, or logic errors not caught in testing) that the technique can still target.
T1216prevents — A.8.19's rules on approved code only, least-privilege installation, testing before deployment, and no untrusted/externally-sourced packages on operational systems stop many proxy-script bypass vectors at install time; residual remains for default/trusted Microsoft-signed scripts already present on the platform.
T1216.001prevents — A.8.19's rules on approved code only, testing before install, least-privilege installation rights, and monitoring of supplier/external packages directly constrain the ability to introduce or run the abused PubPrn.vbs proxy on operational systems, but the control does not reach the built-in signed script already present on Windows or the bypass technique itself.
T1216.002detects — A.8.19 requires maintaining an audit log of all updates to operational software and monitoring of supplier activities plus externally supplied packages; this can surface anomalous or unauthorized use of SyncAppvPublishingServer.vbs (a signed living-off-the-land binary) when it deviates from approved installation/update patterns, but the clause does not mandate runtime process/command monitoring that would catch most proxy executions.
T1216.002prevents — A.8.19's rules on approved executables only, least-privilege installation, trained admins, testing before install, and monitoring of external packages constrain which signed living-off-the-land binaries (including SyncAppvPublishingServer.vbs) can be present or invoked on operational systems, but do not block all possible abuse vectors or removal of already-installed legitimate components.
T1218prevents — A.8.19's rules on approved executables only, least-privilege installation, trained admins, testing before install, and no untrusted/externally-sourced code on operational systems stop many proxy binaries from being introduced or used as LOLBINs; the native/trusted ones already present on the OS remain reachable, so the slice prevented is genuine but not the bulk of the class.
T1218.001prevents — A.8.19's rules on approved code only, admin-only updates after testing, least-privilege installation rights, and monitoring of external packages directly stop unapproved or malicious .chm payloads from being installed and executed on operational systems, but leave open user-delivered .chm files triggered via T1204 on unpatched systems or those outside strict operational controls.
T1218.002prevents — A.8.19's rules on approved executables only, least-privilege installation rights, testing before deployment, and monitoring of external/supplier packages constrain which .cpl/.dll payloads can reach and be executed by control.exe, but do not stop an already-permitted or renamed malicious CPL from being introduced via phishing or registry manipulation.
T1218.003detects — A.8.19 requires audit logging of all updates to operational software plus monitoring of supplier activities and externally supplied packages, which can surface anomalous or unauthorized CMSTP/INF-based execution on Windows operational systems, but this is only a slice of the technique's possible abuse vectors (e.g. non-update, non-supplier, non-external cases).
T1218.003prevents — A.8.19's rules on approved code only, admin-only updates after testing, least-privilege install rights, and monitoring of external/supplier changes directly stop many CMSTP abuse paths that rely on unapproved/malicious INF files or unauthorized execution, but leave open paths that still satisfy the approved-change and testing gates (e.g. signed legitimate CMSTP with crafted-but-tested INF).
T1218.004detects — A.8.19 requires audit logging of all updates to operational software plus monitoring of supplier activities and externally supplied packages, which can surface anomalous or unauthorized InstallUtil executions as part of change/installation events, but does not mandate detection of the technique itself when used by an adversary outside approved processes.
T1218.004prevents — A.8.19's rules on approved code only, admin-only updates after testing, least-privilege installation rights, and monitoring of external/supplier changes directly stop many (but not all) ways an adversary can obtain and run a malicious .NET binary through InstallUtil on operational systems; the remainder is attacker-controlled code that satisfies the approval/testing gates or uses already-permitted vectors.
T1218.005detects — A.8.19 requires audit logging of all updates plus monitoring of supplier activities and externally supplied packages, which can surface anomalous or unauthorized mshta.exe usage when it involves software installation or updates, but the clause does not mandate detection of standalone mshta abuse for proxy execution outside those scopes
T1218.005prevents — A.8.19's rules on approved executable code only, least-privilege installation rights, trained admins, testing before install, and monitoring of external/supplier packages directly stop many mshta.exe abuse vectors that rely on unapproved or user-installed HTA payloads, but cannot prevent all signed/trusted Windows-utility abuse or cases where the HTA is already present via approved channels.
T1218.007prevents — A.8.19's rules on approved code only, admin authorization, testing before install, least-privilege installation rights, and monitoring of supplier changes directly constrain abuse of a native installer like msiexec to run unapproved/malicious payloads, but only for the subset of organizations that enforce those rules on Windows systems; the technique remains available where those controls are absent or bypassed.
T1218.008detects — A.8.19 requires audit logging of all updates to operational software plus monitoring of supplier activities and externally supplied packages, which can surface anomalous or unauthorized use of odbcconf.exe for DLL execution; this is a genuine but minority slice of the technique (most instances are not tied to approved updates or supplier actions).
T1218.008prevents — A.8.19's rules on approved executables only, least-privilege installation, trained admins, testing before deployment, and monitoring of external/supplier changes directly block unauthorized or unvetted binaries (including signed living-off-the-land binaries like odbcconf.exe used for proxy execution) from reaching operational systems, but cannot stop abuse of already-approved system utilities that ship with the OS.
T1218.009prevents — A.8.19's rules on approved executable code only, administrator-only updates after testing, least-privilege installation rights, and monitoring of external packages constrain the introduction or use of malicious .NET assemblies that could be registered via Regsvcs/Regasm, but do not block the technique when the signed Microsoft utilities are already present on the operational system and the adversary supplies only the attribute-bearing assembly
T1218.010prevents — A.8.19's rules on approved executables only, least-privilege installation rights, trained admins, testing before deployment, and monitoring of supplier changes directly stop many unauthorized or unvetted DLL/scriptlet loads that enable Regsvr32 abuse, but leave open user-permitted benign tools, legacy signed binaries, and post-install runtime abuse vectors.
T1218.011prevents — A.8.19's rules on approved executables only, least-privilege installation rights, trained admins, testing before install, and no untrusted/externally-sourced code on operational systems stop many malicious DLLs or scripts from being placed where rundll32 could load them, but do not block abuse of already-present legitimate signed system DLLs (zipfldr.dll, ieframe.dll, etc.) or the proxying/obfuscation techniques themselves.
T1218.012prevents — A.8.19's rules on approved executable code only, least-privilege installation rights, trained admins, testing before install, and monitoring of supplier changes constrain which signed binaries and COM objects can be present or executed on operational systems, so the verclsid.exe abuse vector is blocked where those rules are enforced; the remainder is that the technique can still be used with already-approved native binaries whose abuse potential was not identified during testing or configuration control.
T1218.013prevents — A.8.19's rules on approved executables only, least-privilege installation rights, trained admins, testing before deployment, and monitoring of external/supplier changes constrain which signed binaries like mavinject.exe can be present or invoked on operational systems, but do not eliminate all legitimate App-V usage or block post-install abuse of an already-approved binary.
T1218.014detects — A.8.19 requires audit logging of all updates plus monitoring of supplier activities and externally supplied packages, which can surface anomalous or unauthorized MMC/.msc usage after the fact; this is a genuine but minority slice of the full technique (which also includes direct proxy execution and registry abuse without any update or supplier involvement).
T1218.014prevents — A.8.19's rules on approved executables only, admin-only installation after testing, least-privilege restrictions on what users may install, and monitoring of supplier changes directly block many vectors for introducing and executing malicious .msc files via mmc.exe; residual paths remain via already-installed legitimate snap-ins, registry manipulation by other means, or approved-but-malicious updates.
T1219prevents — A.8.19's rules on approved code only, admin-only installation after testing, least-privilege installation rights, and monitoring of externally supplied packages directly stop many post-compromise or unauthorized RAT installs; the remainder is pre-installed legitimate tools, built-in modules (e.g. Chrome Remote Desktop), or adversary abuse of already-permitted remote-management features that the clause does not block.
T1219.001prevents — A.8.19's rules on approving only vetted executables, restricting user-installed software via least privilege, and requiring admin authorization/testing directly block unauthorized IDE tunneling tools or extensions from reaching operational systems, but built-in IDE features, developer-authorized workflows, and post-install abuse for C2/persistence remain unaddressed.
T1219.002prevents — A.8.19's rules on approved executables only, least-privilege installation, trained admins, testing before deployment, and monitoring of external/supplier packages directly block unauthorized or unvetted remote-desktop tools from reaching operational systems, but the technique can still succeed with pre-installed legitimate RMM software that is already approved or bundled (e.g. in Zoom/Chrome).
T1220prevents — A.8.19's rules on approved executable code only, least-privilege installation rights, testing before deployment, and no untrusted/externally-sourced packages directly block the msxsl.exe drop, arbitrary-extension XSL abuse, and WMI /FORMAT abuse on operational systems; the remainder is the built-in wmic.exe vector that needs no new software install.
T1222.002prevents — A.8.19's rules on least-privilege software installation, approved code only, trained admins, and monitoring of supplier changes constrain who can run chown/chmod on operational systems and what binaries they may introduce, thereby stopping many (but not all) permission-modification paths that rely on unapproved or user-installed tools.
T1484.001prevents — A.8.19's rules on approved code only, admin-only updates with authorization, least-privilege installation rights, testing before install, and configuration control on operational systems constrain who and what can write to SYSVOL\Policies (the GPO storage), blocking many unauthorized modification paths; it does not reach delegated AD permissions, insider abuse of approved channels, or all supply-chain vectors, leaving a genuine minority slice prevented.
T1485recovers — A.8.19 explicitly requires defining a rollback strategy, archiving old versions with all parameters/procedures/configs as a contingency measure, and maintaining supported software releases, which directly enables recovery of destroyed or corrupted operational data and systems after a T1485 event.
T1486recovers — A.8.19 explicitly requires defining a rollback strategy, archiving old versions with all parameters/procedures/configs as a contingency measure, and maintaining supported software levels, which enables recovery of availability after T1486's encryption impact (as in the explicit EVENT-LANE anchor for A.8.13 vs T1486).
T1490recovers — A.8.19 explicitly requires defining a rollback strategy, archiving old versions with all parameters/procedures/configs as a contingency measure, and maintaining supported software releases (including open-source to latest), directly enabling recovery of operational state after T1490 has deleted/disabled recovery features or backups.
T1495prevents — A.8.19's rules on approved code only, admin-only updates after testing, least-privilege installation rights, and monitoring of external/supplier changes directly stop many vectors that would let an adversary (or malicious code) reach and corrupt firmware; the remainder is firmware-updating code already resident with privileges, supply-chain firmware images that pass approval, and direct hardware attacks outside the software-install boundary.
T1496.001detects — A.8.19 requires audit logging of all updates plus monitoring of supplier activities and externally supplied packages, which can surface anomalous compute-consuming software (especially in approved-update or container paths), but does not mandate resource-monitoring, process-behavior detection, or coverage of unapproved mining installs that bypass the change process.
T1496.001prevents — A.8.19's rules on approved code only, admin-only updates after testing, least-privilege install rights, and monitoring of external/supplier packages block many installation vectors for cryptomining malware, but do not stop all post-compromise execution paths, privilege escalations, or already-resident malware that then consumes compute.
T1499recovers — A.8.19's rollback strategy, archiving of old versions, and contingency measures enable restoration of service availability after an endpoint DoS triggered by a bad update or vulnerable software installation, but this is only one narrow slice of the many resource-exhaustion and crash techniques described in T1499.
T1499.004prevents — A.8.19's rules on approved/tested updates, patch application to remove vulnerabilities, least-privilege installation, and avoiding unmaintained software stop many exploitable vulnerabilities from reaching operational systems, but do not cover zero-days, all testing gaps, or non-installation vectors such as runtime memory corruption.
T1505prevents — Enforcing strict rules on permitted software types and prohibiting unapproved or unknown software reduces the chance that an adversary can install web shells or other server software components for persistence.
T1505.001prevents — A.8.19's rules on approved code only, admin-only installation after testing, least-privilege installation rights, and monitoring of supplier changes constrain how malicious stored procedures or CLR assemblies can be introduced to operational database systems, but do not reach the dominant case of an already-authenticated database user or developer legitimately creating/altering a stored procedure that is later abused for persistence.
T1505.002prevents — A.8.19's rules on approved code only, admin-only installation after testing, least-privilege install rights, and monitoring of supplier changes directly block registration of an unapproved malicious .NET transport agent on operational Exchange systems; the remainder is developer-written agents that pass testing/approval or non-Exchange platforms.
T1505.003detects — A.8.19 requires audit logging of all updates to operational software plus monitoring of supplier activities and externally supplied packages, which can surface anomalous or unauthorized web shell installation after the fact; this is genuine but limited to change events and does not broadly instrument for web shell presence or runtime indicators across all platforms and vectors.
T1505.003prevents — A.8.19's rules on approved code only, admin-only updates after testing, least-privilege installation rights, and monitoring of external/supplier changes directly stop many (but not all) vectors for placing an unauthorized web shell script on an operational web server.
T1505.004prevents — A.8.19's rules on approved code only, admin-only installation with authorization, testing before install, least-privilege installation rights, and monitoring of supplier changes directly stop many malicious IIS component installs on operational systems; residual paths remain via approved-but-malicious updates, unmonitored external dependencies, or pre-existing compromised admin sessions.
T1505.005prevents — A.8.19's rules on approved code only, admin-only updates after testing, configuration control, least-privilege installation rights, and monitoring of supplier changes directly block unauthorized replacement or patching of termsrv.dll on operational systems, but do not reach every vector (e.g. supply-chain compromise of an approved DLL or pre-installed vulnerable versions).
T1505.006prevents — A.8.19's rules on approved code only, admin authorization, testing before install, least-privilege installation rights, and monitoring of supplier changes directly stop malicious or unvetted VIBs from being loaded on operational ESXi systems, but the technique can still succeed via force-install, acceptance-level changes, or masquerading that bypass the approval/testing gates.
T1525detects — A.8.19 requires audit logging of all updates to operational software plus monitoring of externally supplied packages and supplier activities, which can surface anomalous or unauthorized image implants in operational/container environments; this is genuine but only a minority slice of the full technique (e.g. does not address pre-implant discovery, non-update vectors, or unmonitored registries).
T1525prevents — A.8.19's rules on approved code only, tested updates by authorized admins, least-privilege installation rights, and monitoring of external/supplier changes directly stop malicious implants into operational/container images; the remainder is that the control is silent on the initial compromise that grants the adversary the permissions needed to perform the implant.
T1542.003prevents — A.8.19's rules on approved code only, tested updates by admins, least-privilege installation rights, and monitoring of external/supplier changes stop many vectors that would let an adversary reach raw boot-sector/ESP write access, but the control is silent on boot-sector integrity checks, firmware/UEFI lockdown, or runtime protection of the MBR/VBR/ESP themselves, leaving a genuine slice of the technique unaddressed.
T1542.004prevents — A.8.19's rules on approved code only, admin-only updates with authorization/testing, configuration control, supplier monitoring, and least-privilege installation directly block unauthorized ROMMON firmware loads on supported operational network devices; partial because the control is silent on boot-time ROMMON abuse vectors, legacy/unsupported devices, and physical/local attacks outside its change-management scope.
T1542.005prevents — A.8.19's rules on approved code only, tested updates, configuration control, least-privilege installation rights, and monitoring of external/supplier changes constrain the ability to load an unauthorized TFTP-sourced image on operational network devices, but leave residual paths (e.g., initial device compromise to alter boot config, unpatched legacy devices, or approved but vulnerable images).
T1543prevents — A.8.19's rules on approved code only, admin-only installation with authorization, least-privilege installation rights, testing before deployment, and monitoring of supplier changes directly stop adversaries from installing or modifying unauthorized system services/daemons/agents on operational systems, but leave open modification paths that do not involve new software installation (e.g. direct registry edits or in-memory changes) and do not reach every platform slice uniformly.
T1543.001prevents — A.8.19's rules on approved code only, admin-only installation with authorization, least-privilege installation rights, testing before deployment, and monitoring of external/supplier changes directly stop adversaries from placing malicious .plist Launch Agents on operational macOS systems; the remainder is user-installed agents outside those enforced rules or pre-existing approved software that is later subverted.
T1543.002prevents — A.8.19's rules on approved code only, admin-only authorized installs, testing before deployment, least-privilege installation rights, and monitoring of supplier changes directly stop adversaries from creating or modifying systemd .service files with malicious payloads on operational Linux systems; the remainder is user-level unit files, generators, and symbolic links that can still be planted by a compromised user or during boot without violating the clause.
T1543.003prevents — A.8.19's rules on approved code only, admin-only installation with authorization, least-privilege installation rights, testing before deployment, and monitoring of external/supplier changes directly stop many (but not all) of the technique's vectors for creating or modifying Windows services with malicious payloads.
T1543.004detects — A.8.19 requires audit logging of all updates to operational software plus monitoring of supplier activities and externally supplied packages, which can surface anomalous Launch Daemon installations or modifications on macOS; this is a genuine but minority slice of the technique (most variants use no update channel, no supplier, and no external package).
T1543.004prevents — A.8.19's rules on approved code only, admin-only installation with authorization, least-privilege installation rights, testing before install, and monitoring of external/supplier changes directly stop adversaries from installing or modifying unauthorized Launch Daemons on operational macOS systems; the remainder is poor configurations or already-installed benign daemons that an adversary can still hijack.
T1543.005prevents — A.8.19's rules on approved code only, admin-only authorized updates, least-privilege installation rights, testing before install, and monitoring of external/supplier changes directly stop many unauthorized container-service modifications (e.g. rogue docker/podman/k8s installs or DaemonSets), but leave open vectors such as approved-but-compromised updates, insider admins, and post-install runtime abuse of legitimate services.
T1546prevents — A.8.19's rules on approved code only, admin-only updates after testing, least-privilege installation rights, and monitoring of supplier changes constrain the introduction or modification of malicious event-trigger mechanisms on operational systems, but leave open many post-compromise abuse paths (e.g. in-memory trigger changes, unpatched OS mechanisms, or approved-but-malicious content) that do not involve new software installation.
T1546.001prevents — A.8.19's rules on approved code only, admin-only updates after testing, least-privilege installation rights, and monitoring of external packages constrain who and what can alter file associations on operational systems, but do not reach user/admin Registry edits or assoc utility use on already-installed software.
T1546.002detects — A.8.19 requires audit logging of all updates to operational software plus monitoring of supplier activities and externally supplied packages, which can surface anomalous screensaver changes or unauthorized .scr/PE installs on Windows endpoints; this is a genuine but minority slice of the technique (registry manipulation of SCRNSAVE.exe etc. by any means, not limited to software installation events).
T1546.002prevents — A.8.19's rules on approved code only, admin-only updates after testing, least-privilege installation rights, and monitoring of external/supplier changes directly stop malicious .scr PE files and registry manipulation from being introduced on operational systems; the remainder is user-context or already-installed malicious screensavers that the control does not reach.
T1546.003detects — A.8.19 requires audit logging of all updates to operational software plus monitoring of supplier activities and externally supplied packages; these surface anomalous or unauthorized WMI/MOF activity after the fact on a slice of the technique (install/update events) but do not broadly instrument or detect runtime subscription execution or persistence.
T1546.003prevents — A.8.19's rules on approved code only, admin-only updates after testing, least-privilege installation rights, and monitoring of supplier changes constrain the installation of malicious WMI subscriptions/MOFs on operational systems, but do not block the technique when performed by an already-authorized admin or via in-memory WMI API calls that never touch the approved-install path.
T1546.004prevents — A.8.19's rules on approved code only, admin-only updates with authorization, least-privilege installation, testing before install, and monitoring of external packages directly stop adversaries from inserting malicious commands into shell config files on operational systems; the remainder is user-writable dotfiles that can still be modified without violating the control.
T1546.006detects — A.8.19 requires audit logging of all updates to operational software plus monitoring of supplier activities and externally supplied packages, which can surface anomalous LC_LOAD_DYLIB modifications when they occur via approved change processes, but does not mandate runtime or integrity monitoring that would catch ad-hoc binary header tampering outside those processes.
T1546.006prevents — A.8.19's rules on approved code only, tested updates by admins, least-privilege install rights, and monitoring of external/supplier changes stop many (but not all) ways an adversary can introduce or taint a Mach-O binary with an added LC_LOAD_DYLIB on an operational macOS system.
T1546.007detects — A.8.19 requires audit logging of all updates to operational software plus monitoring of supplier activities and externally supplied packages, which can surface anomalous or unauthorized Netsh helper DLL registrations after the fact; this is genuine but limited to change events rather than runtime execution or registry anomalies, leaving most of the technique's persistence footprint unreached.
T1546.007prevents — A.8.19's rules on approved code only, admin-only updates after testing, least-privilege installation rights, and monitoring of external/supplier changes directly stop untrusted or malicious Netsh helper DLLs from being registered on operational systems; the remainder is that the control does not reach already-installed malicious helpers or non-installation vectors that could still trigger them.
T1546.008prevents — A.8.19's rules on approved code only, admin-only updates after testing, least-privilege installation rights, and monitoring of external packages directly stop most binary-replacement and unauthorized-install vectors that T1546.008 relies on; the remainder is Registry-pointer or IFEO-injection methods that do not involve installing new executables.
T1546.009detects — A.8.19 requires audit logging of all updates plus monitoring of supplier activities and externally supplied packages, which can surface anomalous or unauthorized DLL/registry changes associated with this technique; this is genuine detection but only a minority slice of the class (no requirement for process, API, or registry monitoring of AppCertDLLs themselves).
T1546.009prevents — A.8.19's rules on approved executables only, least-privilege installation rights, trained admins, testing before install, and monitoring of external packages block many malicious DLLs from reaching operational systems, but do not address already-installed malicious AppCertDLLs or registry tampering that does not involve new software installation.
T1546.010prevents — A.8.19's rules on approved code only, admin-only updates after testing, least-privilege installation rights, and monitoring of external packages directly block unauthorized/malicious DLLs from being installed into the AppInit_DLLs registry value on operational systems; the remainder is that the control does not reach already-installed malicious entries, non-install vectors, or systems where the rules are not enforced.
T1546.011prevents — A.8.19's rules on approved code only, admin-only installation after testing, least-privilege installation rights, and monitoring of external packages directly block unauthorized shim installation and malicious shim databases on operational systems; the remainder is that the control does not reach pre-existing shims, shim abuse inside approved software, or non-installation vectors such as registry manipulation of already-installed shims.
T1546.012prevents — A.8.19's rules on approved code only, admin-only updates after testing, least-privilege installation rights, and monitoring of external packages block many routes that would let an adversary or malicious package install a rogue IFEO debugger, but do not reach every vector (e.g., direct Registry edits by already-privileged code or abuse of permitted tools like GFlags).
T1546.013detects — A.8.19 requires audit logging of all updates to operational software plus monitoring of supplier activities and externally supplied packages, which can surface unauthorized profile modifications after the fact; this is a genuine but minority slice of the technique (most profile abuse is not tied to approved updates or external packages).
T1546.013prevents — A.8.19's rules on approved code only, admin-only updates after testing, least-privilege installation rights, and monitoring of external/supplier changes directly stop malicious profile.ps1 content from being introduced on operational Windows systems; the remainder is user-writable profile locations outside enforced baselines or pre-existing profiles altered before the control is applied.
T1546.014prevents — A.8.19's rules on approved code only, admin-only updates after testing, least-privilege installation rights, and monitoring of external/supplier changes directly stop adversaries from writing malicious emond rules or installing the triggering plist on operational macOS systems; the remainder is post-compromise or non-install vectors (e.g. already-present rules or in-memory abuse) that the clause does not reach.
T1546.015prevents — A.8.19's rules on approved code only, admin-only updates after testing, least-privilege installation rights, and monitoring of external/supplier changes directly stop many unauthorized Registry-altering installs that enable COM hijacking, but leave open vectors such as supply-chain-compromised approved packages, unpatched vendor software containing the hijack, or admin-level abuse that still satisfies the clause.
T1546.016prevents — A.8.19's rules on approved code only, admin-only updates, testing before install, least-privilege installation rights, and monitoring of supplier changes directly stop many installer-script abuse paths (especially untrusted or modified packages), but cannot block all adversary-modified legitimate installers that still pass approval and testing.
T1546.017detects — A.8.19 requires audit logging of all updates to operational software plus monitoring of supplier activities and externally supplied packages, which can surface unauthorized udev rule changes on Linux operational systems; this is genuine detection of the technique but only a slice because the control is scoped to software installation/change events rather than continuous behavioral monitoring of udev rule execution or runtime anomalies.
T1546.017prevents — A.8.19's rules on approved code only, admin-only installation with authorization, least-privilege installation rights, testing before deployment, and monitoring of external/supplier changes directly stop adversaries from adding or modifying udev rules (a form of unauthorized operational software change), but the control is silent on runtime udev behavior, non-install vectors, and does not reach every possible rule placement or unmaintained component risk.
T1546.018prevents — A.8.19's rules on approved code only, tested updates by admins, least-privilege install rights, and monitoring of external packages constrain where and how a malicious .pth / sitecustomize.py can be introduced on operational systems, but do not stop an adversary who already has write access inside site-packages or the Python path from planting the hook.
T1547prevents — A.8.19's rules on approved code only, admin-only updates after testing, least-privilege installation rights, and monitoring of external packages directly stop many unauthorized autostart mechanisms from being introduced on operational systems, but leave kernel modifications, pre-installed vendor autostart features, and approved-but-malicious updates as residual.
T1547.001prevents — A.8.19's rules on approved code only, admin-only installation with authorization, least-privilege installation rights, testing before deployment, and monitoring of external packages directly stop many unauthorized persistence entries from reaching operational run keys or startup folders; the remainder is user-context malware that an authorized admin or permitted user can still legitimately install.
T1547.003detects — A.8.19 requires audit logging of all updates to operational software plus monitoring of supplier activities and externally supplied packages, which can surface anomalous or unauthorized time-provider DLL registrations after the fact; this is genuine detection of a slice of the technique but leaves the bulk (stealthy admin-privileged registration without an accompanying 'update') unreached.
T1547.003prevents — A.8.19's rules on approved code only, admin-only updates with authorization, testing before install, least-privilege installation rights, and monitoring of external/supplier changes directly block registration of an unapproved malicious time-provider DLL on operational systems; the remainder is that the control does not reach every possible pre-install vector or non-operational development-time abuse of the same registry path.
T1547.004prevents — A.8.19's rules on approved code only, admin-only updates after testing, least-privilege installation rights, and monitoring of supplier changes directly stop many malicious DLL/executable insertions into Winlogon registry keys on operational systems, but leave open vectors such as initial compromise of an approved admin account or supply-chain compromise of a tested vendor package.
T1547.005prevents — A.8.19's rules on approved code only, admin-only updates after testing, least-privilege installation rights, and monitoring of external/supplier changes directly stop unauthorized SSP DLLs from being added to the Registry keys at install time; the remainder is post-boot API abuse or already-installed malicious SSPs that the clause does not address.
T1547.006prevents — A.8.19's rules on approved code only, admin-only installation after testing, least-privilege install rights, and monitoring of external/supplier changes stop many malicious LKMs/kexts from reaching operational systems, but do not block all signed/approved-looking kernel modules or post-install kernel modification paths.
T1547.007prevents — A.8.19's rules on approved code only, admin-only installation with authorization, least-privilege installation rights, testing before deployment, and monitoring of external packages directly block unauthorized malicious additions to the plist (a form of operational software change), but the control is silent on the specific macOS plist mechanism and on user-initiated legitimate reopen flows that an adversary can hijack.
T1547.008prevents — A.8.19's rules on approved code only, admin-only updates after testing, least-privilege install rights, and monitoring of external/supplier changes directly stop addition or replacement of illegitimate LSASS drivers on operational systems; the remainder is post-compromise in-memory or non-install techniques that bypass the install gate.
T1547.010detects — A.8.19 requires audit logging of all updates to operational software plus monitoring of supplier activities and externally supplied packages, which can surface anomalous port-monitor changes or unauthorized DLL installations after the fact; this is genuine but only a minority slice of the full technique surface (registry writes, boot-time loading, arbitrary named subkeys).
T1547.010prevents — A.8.19's rules on approved code only, admin-only updates after testing, least-privilege installation rights, and monitoring of supplier changes directly block adversary-supplied DLLs from being written to System32 or the Monitors registry key on operational systems; the remainder is non-update vectors such as initial compromised build or already-installed malicious code that survives a later update.
T1547.012detects — A.8.19 requires audit logging of all updates to operational software plus monitoring of supplier-driven changes and externally supplied packages, which can surface anomalous or unauthorized print-processor installations after the fact; this is genuine detection of a subset of the technique but leaves the bulk (direct registry edits, non-update paths, or unmonitored local installs) unreached.
T1547.012prevents — A.8.19's rules on approved code only, admin-only installation with authorization, least-privilege installation rights, testing before install, and monitoring of external/supplier changes block many vectors for adding a malicious print processor DLL, but do not reach the full technique (e.g. SeLoadDriverPrivilege abuse, direct registry edits, or post-install spooler restart remain possible under permitted admin roles).
T1547.013prevents — A.8.19's rules on approved code only, admin-only installation with authorization, least-privilege installation rights, and testing before changes on operational systems prevent many malicious autostart .desktop entries from being written, but do not block all vectors (e.g. user-writable ~/.config/autostart paths or post-install modification of approved entries).
T1547.014detects — A.8.19 requires audit logging of all updates to operational software plus monitoring of supplier activities and externally supplied packages, which can surface anomalous or unauthorized Registry changes to Active Setup components after the fact; this is a genuine but minority slice of the technique's full execution surface (most instances occur without an accompanying 'update' event).
T1547.015prevents — A.8.19's rules on approved code only, least-privilege installation rights, administrator-only changes with authorization, and testing of updates directly constrain the ability to add unapproved malicious login items via AppleScript/Native API on operational macOS systems; the remainder is user-approved or pre-installed legitimate login items that can still be abused.
T1548prevents — A.8.19's rules on approved code only, admin-only updates, least-privilege installation rights, testing before install, and monitoring of external/supplier changes directly stop several T1548 vectors that rely on installing or running unapproved elevation tools, but leave native mechanisms (UAC/sudo bypasses, misconfigurations) untouched.
T1548.001prevents — A.8.19's rules on approved code only, least-privilege installation rights, trained admins, and testing of changes stop many user-level or unvetted setuid/setgid creations on operational systems, but do not block the technique's core (finding and abusing already-present vulnerable setuid binaries or approved software that legitimately carries the bits).
T1548.002prevents — A.8.19's rules on approved code only, admin-only updates after testing, least-privilege installation rights, and monitoring of supplier changes constrain several UAC-bypass vectors that rely on installing or running unapproved/malicious code or DLLs, but leave many other documented bypasses (auto-elevation of signed binaries, COM hijacks, registry tricks, lateral-movement credential abuse) untouched.
T1548.003prevents — A.8.19 requires strict rules on permitted software/installations, least-privilege for install rights, approved code only, and trained/admin-authorized changes; this directly stops adversaries from writing malicious lines to /etc/sudoers or altering sudo caching files, but leaves the abuse of already-poor legitimate sudoers configurations (e.g. existing NOPASSWD entries) untouched.
T1548.004prevents — A.8.19's rules on approved code only, admin authorization, testing before install, least-privilege installation rights, and monitoring of supplier changes directly stop many (but not all) abuse paths of the deprecated API for malicious elevation and install
T1548.005prevents — A.8.19's rules on least-privilege software installation, approved code only, trained admins, and strict user-install policies constrain misconfigurations that enable temporary elevation paths (e.g., overly permissive JIT/impersonation/pass-role grants during software or role provisioning), but do not reach the bulk of the technique (runtime abuse of already-misconfigured cloud permission structures, impersonation tokens, or domain-wide delegation).
T1552.001prevents — A.8.19's rules on approved code only, tested updates, least-privilege installation, and monitoring of external/supplier packages reduce the chance that credential-storing files or insecure configs are introduced to operational systems, but do not stop users or admins from creating/storing them in files, nor block the search technique itself.
T1553prevents — A.8.19's rules on approved code only, testing before install, least-privilege installation rights, and avoiding unmaintained/external software directly stop many ways an adversary could introduce or execute untrusted programs that subvert trust controls, but do not address subverting already-installed trust mechanisms such as stealing code-signing certs or modifying permissions/registry.
T1553.001prevents — A.8.19's rules on approved code only, tested updates by admins, least-privilege install rights, and monitoring of external packages directly constrain installation vectors that would let adversaries introduce and run untrusted binaries, but the technique can still succeed via non-install paths (USB, curl, drive-by, post-first-launch bundle manipulation) that the control does not address.
T1553.004prevents — A.8.19's rules on approved code only, admin-only installation after testing, least-privilege restrictions on what users may install, and monitoring of supplier changes directly block many vectors for installing a malicious root certificate (including post-compromise user/admin actions and supply-chain insertion), but do not address pre-installed manufacturer certificates, cloned/reinstalled certs that mimic legitimate ones, or all possible bypasses of the approval/testing gates.
T1553.006prevents — A.8.19's rules on approved executable code only, least-privilege installation, trained admins, testing before install, and monitoring of external/supplier changes constrain the ability to introduce or enable unsigned/self-signed code via policy modification on operational systems, but do not block all vectors (e.g., kernel-memory alteration or debug-mode reboots by already-privileged actors).
T1554prevents — Controlling which software may be installed and maintaining an audit log of changes hinders an adversary’s ability to compromise host software binaries without leaving detectable traces.
T1554detects — A.8.19 requires audit logging of all updates to operational software plus monitoring of supplier activities and externally supplied packages, which can surface unauthorized binary modifications after the fact; this is genuine but only a slice of the technique (no requirement for integrity checking, file monitoring, or runtime detection of patches/hooks).
T1556prevents — A.8.19's rules on approved code only, admin-only updates after testing, least-privilege installation rights, and monitoring of supplier changes directly block many malicious modifications of auth mechanisms (e.g. unauthorized binaries replacing PAM/LSASS components), but leave open vectors such as supply-chain compromise of approved updates, in-memory patching, or approved-but-vulnerable releases that still allow the technique.
T1556.001detects — A.8.19 requires audit logging of all updates to operational software plus monitoring of supplier activities and externally supplied packages, which can surface anomalous patching of LSASS on a domain controller; this is a genuine but minority slice of the technique (most in-memory patches by malware leave no update trail and fall outside the clause's change-management focus).
T1556.001prevents — A.8.19's rules on approved code only, admin-only updates after testing, least-privilege installation rights, and monitoring of external/supplier changes directly stop unapproved patching of LSASS on a domain controller; the remainder is in-memory runtime injection or supply-chain malware that evades those gates.
T1556.002prevents — A.8.19's rules on approved code only, admin-only installation after testing, least-privilege installation rights, and monitoring of external/supplier changes directly block registration of an unapproved malicious DLL on operational systems; the remainder is post-compromise or insider-administrator abuse that bypasses those gates.
T1556.003detects — A.8.19 requires audit logging of all updates to operational software plus monitoring of supplier activities and externally supplied packages, which can surface unauthorized PAM modifications after the fact; this is genuine detection of a slice of the technique but leaves most in-process or stealthy modifications (no update involved) unreached.
T1556.003prevents — A.8.19's rules on approved code only, admin-only updates after testing, least-privilege installation rights, and monitoring of supplier changes directly stop many malicious PAM modifications on operational systems, but leave open vectors such as supply-chain compromise of approved modules, unpatched vendor code, and post-install runtime patching that the clause does not address.
T1556.004prevents — A.8.19's rules on approved code only, tested updates by authorized admins, configuration control, supplier monitoring and least-privilege installation directly stop unvetted patches that implant backdoor passwords in network-device OS images; the remainder is that the control does not reach every supply-chain or insider vector that could still deliver a malicious patch.
T1556.007detects — A.8.19 requires audit logging of all updates to operational software plus monitoring of supplier activities and externally supplied packages, which can surface unauthorized modifications to on-premises PTA/AD FS processes or agents, but does not require detection of the cloud-side registration of a malicious PTA agent or of the resulting authentication bypass itself.
T1556.007prevents — A.8.19's rules on approved code only, admin-only updates after testing, configuration control, least-privilege installation rights, and monitoring of supplier changes directly constrain the on-premises modification vectors (PTA agent DLL injection, AD FS config edits) that require installing or altering operational software, but do not address cloud-side registration of a malicious PTA agent or the initial privileged compromise that enables the technique.
T1556.008prevents — A.8.19's rules on approved code only, admin-only installation with authorization, testing before install, least-privilege installation rights, and monitoring of supplier changes directly stop adversaries from registering a malicious network provider DLL on operational Windows systems; the remainder is that the control does not reach already-installed malicious DLLs or non-installation vectors such as direct Registry manipulation outside the approved change process.
T1561recovers — A.8.19 explicitly requires defining a rollback strategy, archiving old versions with all parameters/procedures/configs as a contingency measure, and maintaining supported software levels, which directly enables recovery from a disk-wipe event that destroys availability.
T1561.001recovers — A.8.19 explicitly requires defining a rollback strategy, archiving old versions with all configuration and supporting software as a contingency measure, and maintaining supported releases so that wiped systems or data can be restored from known-good states.
T1561.002recovers — A.8.19 explicitly requires defining a rollback strategy before changes, archiving old versions with all parameters/procedures/configs as a contingency measure, and maintaining supported software levels, which directly enables restoration of bootable disk structures after a wipe (the core impact of T1561.002).
T1565.003prevents — A.8.19's rules on approved code only, admin-only updates after testing, least-privilege installation rights, and monitoring of supplier changes directly block many forms of unauthorized binary alteration that enable runtime data manipulation, but leave open adversary techniques that use already-approved channels, insider admins, or non-installation vectors such as memory-only hooks or post-install configuration changes.
T1569prevents — A.8.19's rules on approved code only, admin-only updates after testing, least-privilege installation rights, and monitoring of external/supplier changes directly stop many malicious service creations or modifications on operational systems, but leave open vectors such as already-installed legitimate services being abused at runtime or unpatched service-handling flaws.
T1569.002detects — A.8.19 requires audit logging of all updates to operational software plus monitoring of supplier activities and externally supplied packages, which can surface anomalous or unauthorized service installations that realize T1569.002; this is genuine detection of a slice of the technique but leaves the bulk (normal sc.exe/PsExec use, non-update service execution) unreached.
T1569.002prevents — A.8.19's rules on approved code only, admin-only updates with authorization, least-privilege installation rights, testing before install, and monitoring of external/supplier changes directly stop many paths that would let an adversary introduce and then execute a malicious service via the service control manager; the remainder is that the control does not reach every possible abuse vector (e.g., already-present admin rights or in-memory service manipulation).
T1569.003prevents — A.8.19's rules on approved code only, admin-only updates with authorization, least-privilege installation, testing before install, and monitoring of external packages constrain the ability to introduce or activate malicious systemd units via systemctl on operational systems, but do not block all legitimate post-install abuse paths or non-install vectors.
T1574prevents — A.8.19's rules on approved code only, tested updates by admins, least-privilege install rights, and monitoring of external/supplier changes stop many hijack vectors at install time (e.g. poisoned libraries or untrusted executables), but leave open runtime hijacks such as path/registry poisoning after approved software is present.
T1574.001prevents — A.8.19's rules on approved code only, tested updates, least-privilege installation rights, and monitoring of external/supplier changes stop many (but not all) planting/substitution vectors that enable DLL side-loading, search-order hijacking, and phantom substitution on operational systems.
T1574.004prevents — A.8.19's rules on approved code only, tested updates, least-privilege installation rights, and monitoring of external/supplier changes constrain the insertion of an unapproved malicious dylib into an operational search path, but leave open developer-controlled build-time search paths, weak linking, and unpatched vulnerable apps that still allow the technique.
T1574.005prevents — A.8.19 requires strict rules on permitted software types, least-privilege installation rights, approved executable code only, trained/admin-authorized updates, and testing before install; these block many (but not all) installer-permission-weakness vectors on operational systems, especially user-driven or unvetted installer runs.
T1574.006prevents — A.8.19's rules on approved code only, least-privilege installation rights, trained admins, testing before install, and monitoring of external/supplier changes constrain many vectors for introducing malicious libraries that could be used in LD_PRELOAD-style hijacks, but do not reach environment-variable controls, runtime linker behavior, or developer/debug use of the mechanism itself.
T1574.007prevents — A.8.19's rules on approved code only, tested updates by admins, least-privilege installation rights, and monitoring of external/supplier changes stop many PATH-hijacking opportunities (especially write-to-PATH and unvetted binaries), but leave residual cases such as legitimate-but-vulnerable software already present or configuration changes that still permit an earlier malicious entry.
T1574.008prevents — A.8.19's rules on approved code only, tested updates by admins, least-privilege installation rights, and monitoring of external/supplier changes stop many hijack-vulnerable programs from being introduced or left unpatched on operational systems, but do not guarantee full-path calls or eliminate all search-order defects in vendor or legacy binaries.
T1574.009prevents — A.8.19's rules on approved code only, tested updates, least-privilege installation rights, and monitoring of external/supplier changes stop many unquoted-path hijacks at install time by blocking malicious placement or unvetted executables, but leave residual cases (e.g. pre-existing unquoted paths in vendor services, user-installed approved software that still has the flaw, or registry changes outside the install process).
T1574.010prevents — A.8.19's rules on approved code only, admin-only updates with authorization, testing before install, least-privilege installation rights, and monitoring of supplier changes directly stop many (but not all) ways an adversary can replace a service binary via weak file/directory permissions on Windows operational systems.
T1574.011prevents — A.8.19's rules on least-privilege software installation, approved executables only, trained admins, and strict user-install policies constrain who can write to service-related Registry keys and what binaries they may point to, blocking the hijack vector in a slice of cases; the control does not itself set or audit the ACLs on HKLM\SYSTEM\CurrentControlSet\Services keys, so many permission-flaw scenarios remain reachable.
T1574.014detects — A.8.19 requires audit logging of all updates plus monitoring of supplier activities and externally supplied packages, which can surface anomalous or unauthorized software/installation events that realize this technique, but does not mandate process-level or runtime detection of AppDomainManager hijacking itself.
T1574.014prevents — A.8.19's rules on approved code only, admin-only updates after testing, least-privilege installation rights, and monitoring of external/supplier changes constrain the loading of untrusted assemblies or tampered config/env vars that enable AppDomainManager injection, but leave open developer-controlled .NET runtime behaviors, custom domains, and unvetted internal assemblies that the control does not reach.
T1601detects — A.8.19 requires audit logging of all updates to operational software plus monitoring of supplier activities and externally supplied packages, which can surface unauthorized modifications to a system image after the fact; this is genuine but only a slice because the control is scoped to approved/administered changes on conventional operational systems and does not mandate runtime or storage integrity monitoring that would catch live in-memory or boot-time modifications on embedded network devices.
T1601prevents — A.8.19's rules on approved code only, admin-only updates with authorization, testing before install, configuration control, and least-privilege installation directly stop many live or stored modifications of the monolithic OS image on network devices; the remainder is supply-chain or pre-installed images outside operational change processes.
T1601.001prevents — A.8.19's rules on approved code only, admin-only authorized updates, testing before install, least-privilege installation rights, and monitoring of supplier changes directly block the standard operator procedures (TFTP/FTP/SCP/console, debug commands, bootloader manipulation) an adversary must use to patch a network-device system image, but leave open the possibility of supply-chain compromise of an approved image or of an already-compromised admin performing the patch.
T1601.002detects — A.8.19 requires audit logging of all updates plus monitoring of supplier activities and externally supplied packages, which can surface a downgrade when it occurs as an unauthorized change; this is limited to logged/visible cases on operational systems and does not broadly instrument the embedded/network-device technique itself.
T1601.002prevents — A.8.19 requires only approved code, tested updates, vendor-supported versions, least-privilege installation rules, and monitoring of changes on operational systems; this directly stops most adversary-driven downgrades to unsupported/weaker images on network devices, but leaves a remainder for approved supplier actions, tested legacy images still supported by the vendor, and cases where downgrade masquerades as a permitted patch.
T1610prevents — A.8.19's rules on approved code only, admin-only updates after testing, least-privilege installation rights, and monitoring of external/supplier changes stop many unauthorized or malicious container deployments on operational systems, but do not block all vectors such as API-driven or dashboard-based deployment of images already present in the environment.
T1611prevents — A.8.19's rules on approved code only, least-privilege installation rights, trained admins, testing before install, and avoiding unmaintained/vendor-unsupported software constrain several vectors (privileged containers, malicious modules, unpatched escape vulns, unauthorized bind mounts via user-installed tools), but leave many others (kernel bugs, misconfigurations of docker.sock or hypervisor settings, post-install exploits) untouched.
T1612prevents — A.8.19's rules on approved code only, admin-only updates after testing, least-privilege install rights, and monitoring of external packages directly constrain the build of unapproved/malicious container images on operational hosts, but leave open developer/admin misuse, untested approved builds, and local base images that satisfy the rules.
T1620detects — A.8.19 requires audit logging of all updates to operational software plus monitoring of supplier activities and externally supplied packages, which can surface anomalous or unauthorized reflective loading events that involve code installation or updates, but the control is silent on runtime memory behavior, process anomalies, or non-update fileless execution so only a minority slice is covered.
T1620prevents — A.8.19's rules on approved executable code only, least-privilege installation rights, tested/authorized updates by admins, and no development tools on operational systems constrain many vectors for introducing and reflectively loading unauthorized code, but leave open in-memory reflective loading of already-resident benign tools (e.g. PowerShell Assembly.Load) or approved-but-vulnerable libraries.
T1677prevents — A.8.19 requires approved code only on operational systems, testing before install, least-privilege installation rules, and monitoring of external/supplier code changes; this stops several poisoning vectors (e.g. unapproved executables, untested updates, malicious user-installed packages) but leaves the remainder of repository-level config-file and PR-based injections untouched because the clause addresses runtime operational systems rather than the CI/CD build definition itself.
T1685prevents — A.8.19's rules on approved code only, admin-only updates, testing before install, least-privilege installation rights, and monitoring of supplier changes directly stop many forms of tampering with or disabling of security tools on operational systems; the remainder is post-install runtime tampering that the control does not reach.
T1685.002prevents — A.8.19's rules on approved code only, tested updates, least-privilege installation rights, trained admins, and monitoring of supplier changes constrain how an adversary could reach and execute the disable/modify actions on cloud logging components, but do not stop a privileged insider or already-compromised admin from performing them.
T1686prevents — A.8.19's rules on approved code only, admin-only updates after testing, least-privilege installation rights, and monitoring of supplier changes constrain many vectors for installing the tools or scripts that disable/modify firewalls, but do not stop an already-privileged adversary from using built-in platform commands (e.g. esxcli, netsh, ufw) or approved update mechanisms to alter firewall policy.
T1687prevents — A.8.19's rules on approved/tested updates, least-privilege installation, vendor/open-source maintenance, and monitoring of external packages directly stop many exploitable vulnerabilities from being introduced into defensive components, but leave residual risk from zero-days, unpatched supported software, and non-installation defects in already-deployed tools.
T1689prevents — A.8.19 explicitly requires maintaining vendor and open-source software at supported/latest releases, considering risks of unsupported versions, and applying patches to reduce vulnerabilities, which directly stops adversaries from forcing or using vulnerable downgraded/outdated versions on operational systems (the core of T1689); it is only partial because the control is scoped to operational software installation rules and does not address all downgrade vectors such as network protocol negotiation or boot manager manipulation.

Prevented OWASP Web Top 10 (2025) risks (5)

OWASP Web Top 10 (2025) risk categories this ISO control helps prevent or mitigate — our AI-authored analysis (authority llm_unverified, under review).

Direction: ← other covers this; → this covers other (F/M/P = full / mostly / partial). gov = governs / implements (a mandate, not coverage).

A02→P A03→P A05→P A08→P A09←M

Why these map — AI rationale (under review)

A02mitigates — A.8.19's rules on approved/authorized/tested updates, least-privilege installation, and avoiding unmaintained/vendor-unsupported software reduce the chance that weak defaults or exposed settings are introduced or left in place, but do not address the existing misconfigurations themselves nor harden the broad range of cloud/framework/server settings that define the OWASP class.
A03mitigates — A.8.19's rules on approved code, testing before install, supplier monitoring, least-privilege installation rights, and applying patches to reduce vulnerabilities limit the consequence (realized impact) of some supply-chain failures once present, but do not bound or reduce impact for the category's dominant members (compromised build pipelines or signing infrastructure).
A05mitigates — A.8.19's rules on approved/tested/patched software and least-privilege installation can stop malicious or vulnerable code that would enable injection payloads from reaching the interpreter, but this is only a minority slice of the broad injection class whose dominant members (SQLi, XSS, etc.) arise inside already-installed custom application logic.
A08mitigates — A.8.19's rules on approved code only, testing before install, configuration control, rollback, audit logs, supplier monitoring and least-privilege installation limit the blast radius or consequence of an integrity failure (e.g. by rejecting unsigned/malicious updates or enabling safe rollback), but do not address the core weakness of trusting code/data without verification such as insecure deserialization or CI/CD pipeline compromise.

Control IDs, short titles and the structured attribute table (control type, CIA properties, cybersecurity-concept, operational capability, security domain) are facts from ISO/IEC 27001:2022 Annex A / ISO/IEC 27002:2022. The full implementation guidance prose lives in ISO/IEC 27002:2022 — not reproduced here. Cross-walks to NIST 800-53, NIST CSF 2.0, OWASP ASVS, CWE, MITRE ATT&CK and OWASP Web Top 10 are our own AI-authored analysis (authority llm_unverified, under review), not an ISO, NIST, MITRE or OWASP product — how ours compare.