Most exploited weaknesses already have a fix, and the countermeasure that applies the fix is the one most often late, partial or unverified. MITRE D3FEND names it Software Update (D3-SU) and defines it simply as "Replacing old software on a computer system component." It sits under the Harden tactic as a child of Platform Hardening. D3FEND's entry is brief, with one patent reference and no implementation notes, so this card adds what a defender needs: which ATT&CK techniques D3FEND relates to updating, how to make the update channel itself trustworthy, how to prove coverage, and where updating does not help. Process and programme design live in the Patch Management Guide and the ATT&CK mitigation view in M1051 Update Software; this page does not repeat them.
Key takeaways
- Updating is a hardening control, not only a fix. D3FEND places it under Harden because it changes the software the attacker would otherwise target.
- The update channel is an attack path. A trojanised update signed by the real vendor bypasses most checks, so the channel needs its own protections: signature and freshness checks, staged rings and monitoring of the deployment tool.
- Coverage is the metric that matters. An update that is approved but not installed everywhere, including firmware and add-ins, leaves the same exposure as no update.
- Unsupported software cannot be updated. End-of-life products need replacement or compensating controls; NIST SP 800-53 SA-22 makes this an explicit control.
- D3FEND's ATT&CK links are inferred. They come from the shared Software artefact and cover persistence through server components, add-ins, firmware and supply chain compromise.
D3-SU at a glance
| Attribute | Value |
|---|---|
| D3FEND ID | D3-SU (d3f:SoftwareUpdate) |
| Tactic | Harden |
| Parent technique | Platform Hardening |
| Digital artefact | Software (D3FEND relation: updates) |
| D3FEND reference | US patent US10474448B2, Method and system for providing software updates to local machines |
| Scope in practice | Operating systems, applications, libraries and dependencies, browser and office add-ins, drivers, firmware, appliances |
| Effort | Ongoing; low per update when automated, high for appliances, firmware and systems that need downtime |
| Main limitation | Does nothing before a fix exists, and the update path can itself deliver malicious code |
How it works
NIST SP 800-40 Rev. 4 describes enterprise patch management as identifying, prioritising, acquiring, installing and verifying patches, updates and upgrades, and frames it as preventive maintenance for technology. For D3-SU the important parts are the last two steps: replacing the old software on each component and proving it happened. A practical update pipeline has four stages.
- Source: the update comes from the vendor or project, signed, through a channel the client can authenticate.
- Distribution: an internal tool, a vendor cloud service or a package repository delivers it to endpoints, servers and devices.
- Installation: the component replaces the old version, often with a restart, and ideally removes the previous version, which NIST SP 800-53 covers in SI-2(6).
- Verification: an independent check, such as a vulnerability scan or an inventory query, confirms the new version is running.
The UK NCSC's device guidance adds the operating rules most teams need: turn on automatic updates wherever possible and check occasionally that they still work, install updates ideally within a few days, keep testing short because attackers analyse published patches, use a staged approach in large organisations, plan firmware updates, and replace unsupported devices and software as soon as possible.
ATT&CK techniques D3FEND relates to D3-SU
Relationship type: inferred only. D3FEND derives these relations because D3-SU updates Software and the techniques act on software; it labels them inferred and experimental (D3FEND 1.6.0, checked November 2026). Each ID was checked against ATT&CK v20. The right column is our view of what updating actually achieves.
| Group | ATT&CK techniques | What updating achieves |
|---|---|---|
| Supply chain | T1195.001 Compromise Software Dependencies and Development Tools; T1195.002 Compromise Software Supply Chain | Two-sided: fixed versions remove compromised components, but the update itself is the delivery path for these techniques |
| Server and application components | T1505.001 SQL Stored Procedures; T1505.004 IIS Components; T1137.006 Add-ins | Replacing components can remove planted ones, but only if the update overwrites them and integrity is checked afterwards |
| Firmware and boot | T1542.001 System Firmware; T1542.002 Component Firmware; T1542.003 Bootkit; T1542.004 ROMMONkit | Firmware updates close flaws used to implant code; a reflash from a trusted image can remove an implant |
| Execution through trusted software | T1127.001 MSBuild; T1218.014 MMC; T1546.011 Application Shimming; T1547.008 LSASS Driver | Limited: these abuse legitimate features that updates rarely remove; allow-listing and driver controls matter more |
| Weak file permissions | T1574.005 Executable Installer File Permissions Weakness; T1574.010 Services File Permissions Weakness | Updated installers and services may correct permissions; check them after each update |
| Other | T1564.006 Run Virtual Instance; T1497.003 Time Based Checks; T1056.003 Web Portal Capture | Minimal: listed through the shared artefact |
Related defensive pages: MITRE ATT&CK T1195 Supply Chain Compromise, T1505 Server Software Component Defensive Guide, MITRE ATT&CK T1137 Office Application Startup and MITRE ATT&CK T1542 Pre-OS Boot.
Where it is implemented
| Layer | Mechanism class | Points to check |
|---|---|---|
| Operating system | Built-in update services, OS update management in endpoint management platforms, Linux package managers with signed repositories | Automatic updates on, repository signing keys pinned, restart deadlines enforced |
| Applications | Vendor auto-updaters, third-party patching tools, application stores | Auto-updaters not blocked by permissions or proxies; see the Desktop Application Auto-Update Security Guide |
| Code dependencies | Dependency update bots and lock files in the build pipeline | Updates reviewed and tested before merge; see the Dependency Update Automation Guide |
| Firmware and devices | Vendor firmware tools, signed over-the-air updates, appliance consoles | Signed images, anti-rollback, maintenance windows; see the IoT Secure Firmware Update Guide (SUIT, signed OTA) |
| Update framework | Frameworks such as The Update Framework (TUF) for software repositories | Signed, expiring metadata that resists rollback, freeze and key compromise |
Securing the update channel
The TUF project lists the attacks a secure update system must resist, including arbitrary software installation, rollback, indefinite freeze, mix-and-match and key compromise, and builds its design on trust that expires, compartmentalised signing roles, threshold signatures and freshness checks. The same principles apply to any update channel: clients should refuse unsigned or older packages, notice when they have stopped receiving updates, and survive the loss of one signing key. See The Update Framework (TUF) Guide.
Signatures alone are not enough. In the SolarWinds supply chain compromise, the backdoor was inserted during the build and shipped inside legitimately signed updates that up to 18,000 customers may have installed. The customer-side lessons are staged rings, egress control for update-installed software and monitoring of what new versions do after installation.
Where identity fits
Update and deployment tools run with powerful non-human identities: service accounts with local administrator rights on every endpoint, API keys for vendor update clouds and signing keys for internal packages. An attacker who controls those identities can push any code to the estate, which is ATT&CK T1072 Software Deployment Tools. Scope and vault those credentials, require approval for new deployment packages and alert on deployments outside change windows. See Securing the patch management tool itself and MITRE ATT&CK T1072 Software Deployment Tools.
Implementation steps
- Inventory software and versions. Coverage cannot be measured without a list of components, including firmware, add-ins and libraries. NIST CSF 2.0 ID.AM-02 covers this.
- Turn on automatic updates by default. Use central policy to enforce it and record exceptions with an owner and an end date.
- Define rings. A small pilot ring, a broad ring and a final ring for sensitive systems, with short soak times so testing does not become delay.
- Set deadlines by risk. Faster for internet-facing systems and actively exploited flaws, with an emergency route; see the Emergency Out-of-Band Patching Playbook.
- Prepare rollback. Snapshots, previous packages or vendor rollback features for each ring, tested before they are needed.
- Verify independently. Confirm installation through vulnerability scanning or inventory, not only the deployment tool's own status.
- Plan replacement for unsupported software. Track end-of-support dates and fund replacements before they arrive.
How to verify it works
- Independent version evidence: authenticated scans or agent inventory showing the installed version on each asset.
- Update client health: alerts when a device has not checked in for updates within a set period, since NCSC notes automatic updates can silently fail.
- Integrity after update: file integrity or code integrity checks on server components and add-in locations, so a planted component that survived the update is found.
- Deployment tool audit: logs of who created and approved each package and where it went.
| Metric (examples, set your own targets) | What it shows |
|---|---|
| Percentage of assets on the current supported version within the deadline, by severity | Coverage against policy |
| Median and 90th percentile time from release to installation | Speed, including the slow tail |
| Devices whose update client has not reported within the agreed period | Silent update failure |
| Assets running unsupported software | Exposure that updating cannot fix |
| Rollbacks per release and their cause | Quality of testing and rings |
Limits, bypasses and failure patterns
- Zero-day window: no update exists yet, so other hardening and detection must carry the risk.
- Malicious updates: a compromised vendor build or update server delivers malware through the trusted path.
- Tool-reported success: the deployment console shows success while the old version still runs because a restart never happened.
- Forgotten layers: firmware, appliances, add-ins and embedded libraries left out of the update scope.
- Persistence survives: updating a server does not always remove a planted web shell, module or stored procedure.
- Exceptions that never close: systems excluded for compatibility years ago and still excluded.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SI-2 Flaw Remediation; SI-2(2) Automated Flaw Remediation Status; SI-2(5) Automatic Software and Firmware Updates; SI-2(6) Removal of Previous Versions | Install and verify security-relevant updates within a defined period |
| NIST SP 800-53 Rev 5 | SI-7(15) Code Authentication | Cryptographically authenticate software and firmware before installation |
| NIST SP 800-53 Rev 5 | SA-22 Unsupported System Components; CM-8 System Component Inventory | Replace unsupported components; know what to update |
| NIST CSF 2.0 | PR.PS-02; ID.AM-02 | Software maintained, replaced and removed commensurate with risk; software inventory |
| MITRE ATT&CK | M1051 Update Software | The ATT&CK mitigation counterpart |
| MITRE D3FEND | D3-SU | Technique under Platform Hardening |
Related countermeasures
- Firmware Verification (D3-FV): confirms firmware integrity before and after updates. See D3-FV Firmware Verification.
- System Firmware Verification (D3-SFV): the system firmware case. See D3-SFV System Firmware Verification.
- Trusted Library (D3-TL): builds on vetted, maintained libraries, which updates keep current. See D3-TL Trusted Library.
- Code signing: the basis of update authenticity. See the Code Signing Security Guide.
Practitioner checklist
- Keep an inventory of software, firmware and add-ins with versions.
- Enforce automatic updates centrally and track every exception to an end date.
- Run pilot, broad and sensitive rings with short soak times.
- Require signed updates and refuse older versions on the client.
- Vault and scope the credentials of update and deployment tools.
- Verify installation independently of the deployment tool.
- Check integrity of server components and add-ins after updates.
- Track end-of-support dates and fund replacements in advance.
- Test rollback for each ring before you need it.
Standards and references
- MITRE D3FEND: Software Update (D3-SU)
- NIST: SP 800-40 Rev. 4, Guide to Enterprise Patch Management Planning
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls (SI-2, SI-7, SA-22)
- NIST: Cybersecurity Framework 2.0
- NCSC: Keeping devices and software up to date
- The Update Framework: Security
- MITRE ATT&CK: Update Software (M1051)
Related NHI Mgmt Group resources: Patch Management Guide · NIST SP 800-40 Rev 4 Patch Management Guide · Operating System End of Life and Extended Support Guide · Securing the patch management tool itself · MITRE D3FEND Guide