Routers, printers, phones and controllers run firmware that almost nobody watches after it ships, so an implant in that firmware can sit undetected for years. MITRE D3FEND names one answer Firmware Embedded Monitoring Code (D3-FEMC) and defines it as "Monitoring code is injected into firmware for integrity monitoring of firmware and firmware data." It sits under the Detect tactic as a child of Platform Monitoring (D3-PM), next to Firmware Verification, Firmware Behavior Analysis and the other platform monitors. This card explains how the technique works, which ATT&CK techniques D3FEND relates it to, where it is found in practice, how to test it and where it stops. It is written for detection engineers, embedded and network device security teams and buyers of OT and IoT equipment, and assumes the background in the Firmware and Boot Security Guide.
Key takeaways
- It is a monitor inside the firmware. Unlike Firmware Verification, which hashes an image from outside, D3-FEMC adds code to the firmware image itself so the device watches its own code and data while it runs.
- It is built into the image, not installed later. D3FEND says the monitoring components are inserted during the firmware imaging process, so the firmware must be modified and re-hosted on the device.
- D3FEND relates it to Pre-OS Boot. The D3FEND page lists inferred relations to System Firmware (T1542.001), Component Firmware (T1542.002) and ROMMONkit (T1542.004), all through the Firmware artefact.
- The research base is narrow. D3FEND cites two references, both by the same Columbia University and Red Balloon Security authors; most organisations meet the technique as a feature of a device or a specialist product, not as something they build.
- The monitor can be attacked too. The original research says software-only monitors can be bypassed by removing their hooks, and D3FEND warns that exposing monitoring hooks may add risk, so pair it with signed updates and external verification.
D3-FEMC at a glance
| Attribute | Value |
|---|---|
| D3FEND ID | D3-FEMC (d3f:FirmwareEmbeddedMonitoringCode) |
| Tactic | Detect |
| Parent technique | Platform Monitoring (D3-PM) |
| Digital artefact | Firmware (D3FEND relation: analyzes Firmware) |
| What it watches | Static firmware code and firmware data segments in device memory, while the device runs |
| Where it is inserted | Into the firmware binary during imaging, before the image is loaded on the device |
| Typical targets | Embedded and network devices: routers, VoIP phones, printers, controllers (the device classes named in the references) |
| Effort | High to build; low to medium to operate when it ships as a device or product feature |
| Main limitation | The monitor shares the device with the code it watches; an attacker who finds and removes it gets silence |
How it works
D3FEND's description starts from a plain observation: firmware in deployed network devices is typically not monitored for malicious changes. The technique embeds a security component in the firmware that gives a near real-time monitoring hook. In D3FEND's words the injected components act like an intrusion detection system for the firmware.
- Insertion: the monitor is added to the firmware binary during imaging. The injected code is assumed to know both the embedded code and the current execution state of the host program, runs alongside it, and operates as an independent entity that does not depend on the host software.
- Integrity checks: it continuously compares monitored elements, such as firmware memory addresses and data segments, against their expected state. D3FEND says memory pages are scanned and, if a modification is found, the component may lock the page to block further changes.
- Reporting: the component may use the firmware's exception handling code to report a detection, which lets it disclose the exact address of the modified memory.
- Composition: D3FEND notes that an implementation may use other countermeasures inside its analysis, such as hashing, which is why D3-FEMC and Firmware Verification often appear together.
What the research shows
The "Defending Embedded Systems with Software Symbiotes" paper by Ang Cui and Salvatore J. Stolfo of Columbia University, cited by D3FEND, describes the idea in detail. A Symbiotic Embedded Machine, or symbiote, is defensive code injected into a host program's firmware. It gets CPU time by intercepting control flow at randomly chosen points in frequently executed code, its parts are placed in unused gaps so the image size does not change, and each injected instance can be made distinct from every other. The proof of concept ran on Cisco IOS 12.2 and 12.3 on MIPS routers and computed a single checksum over the router's code region to catch hooks or patches. The authors report a 100% code modification detection rate with 0% false positives in their experiments, with detection latency that ranged from 56 seconds down to 0.3 seconds depending on how often the monitor ran.
The second D3FEND reference, Red Balloon Security patent US10657262B1 ("Method and apparatus for securing embedded device firmware", granted 19 May 2020), extends the idea: security components injected into a firmware binary produce an image that is functionally and size-equivalent to the original, collect live forensic information while the device is online and support dynamic patching. The patent text also describes detecting unauthorised modification of in-memory data used by firmware functions.
ATT&CK techniques D3FEND relates to D3-FEMC
Relationship type: inferred only. D3FEND lists no hand-made ATT&CK mapping for D3-FEMC. Its page shows relations inferred through the shared Firmware artefact and labels them "inferred, experimental" (D3FEND 1.6.0, checked November 2026). Each ID was checked against ATT&CK v20.
| ATT&CK ID | Technique | How D3FEND links it | What an in-firmware monitor can see |
|---|---|---|---|
| T1542.001 | System Firmware | Shown on the D3FEND page; technique modifies System Firmware, a sub-artefact of Firmware | Changes to BIOS or UEFI code, where a monitor runs on that platform |
| T1542.002 | Component Firmware | Shown on the D3FEND page; inferred via Firmware | Changes to the firmware of a component such as a disk or network controller that carries a monitor |
| T1542.004 | ROMMONkit | Shown on the D3FEND page; inferred via Firmware | A modified ROM monitor on a network device, the device class the symbiote research targeted |
| T1495 | Firmware Corruption | In the D3FEND ontology: technique modifies Firmware | Writes that corrupt firmware, if the monitor survives long enough to report them |
| T1014 | Rootkit | In the D3FEND ontology: technique may modify Firmware | Firmware-resident rootkit hooks in monitored code regions |
| T1693.002 (ICS) | Module Firmware | D3FEND relates ICS T0839 via Firmware; ATT&CK v20 has revoked T0839 and names T1693.002 as its successor | Modified firmware on controller modules |
The D3FEND page shows the three Pre-OS Boot rows under both the Persistence and Stealth tactics. The T1495, T1014 and ICS rows come from the artefact relations in the D3FEND ontology file rather than the technique page. Deeper treatment of the attacker side is in MITRE ATT&CK T1542 Pre-OS Boot, MITRE ATT&CK T1495 Firmware Corruption, MITRE ATT&CK T1014 Rootkit and T1693 Modify Firmware.
Where it is implemented
Few teams inject code into firmware themselves. In practice D3-FEMC shows up in one of four places, and the buying or engineering question is which of them you control.
| Implementation class | Who builds the monitor | What you control | Fits when |
|---|---|---|---|
| Device maker runtime integrity features | The device or chip maker, built into the shipped image | Whether the feature is turned on, where its alerts go, update cadence | You buy network, OT or IoT devices and can set this as a procurement requirement |
| Specialist firmware hardening products | A third party that injects monitoring into the vendor image, as in the Red Balloon patent model | Which images are hardened, re-hosting process, alert collection | High-value embedded fleets where the device maker offers no runtime monitoring |
| In-house embedded engineering | Your own firmware team, as part of the build pipeline | Everything: monitored regions, check frequency, response, signing | You ship your own devices; see Embedded and Firmware Secure Coding |
| Research and test builds | Security researchers or red teams | Lab devices only | Evaluating whether a device class can carry a monitor before procurement |
Whatever the source, the alerts must leave the device. For network equipment that means the monitor's output reaches syslog or a management system that is collected centrally, as covered in the Network Device Syslog and Configuration Change Detection Guide.
Implementation steps
- Find the blind spots. List device classes where you cannot run an endpoint agent: routers, switches, firewalls, printers, BMCs, controllers, cameras. Rank them by exposure and by how hard they are to reimage.
- Ask the supplier first. For each class, ask whether the firmware includes runtime integrity monitoring, what it checks, how often, and how it reports. Record the answer in the asset inventory. Hardware and firmware component lists from the Hardware and Firmware SBOM Guide help here.
- Decide who re-hosts the image. D3FEND's first consideration is that the firmware must be modified and re-hosted. If a third party modifies the image, agree how it is signed and how the device maker's own updates are handled, because each vendor update needs the monitor added again.
- Wire alert collection before go-live. Configure the device to send monitor events to a collector and write a detection rule for them. An in-firmware alert that only appears on a local console is not monitoring.
- Pilot on a lab unit. Load the monitored image on a test device, run normal workloads for at least a full change cycle and record any benign alerts, such as those caused by legitimate configuration writes into monitored data regions.
- Roll out in rings. Move from lab to a small production group to the fleet. Keep the last known good unmodified signed image available so a device can be rolled back if the monitored image causes instability.
- Write the response. A firmware integrity alert on a network device should trigger isolation, collection of the running image and configuration, and reflashing from a trusted source. The Firmware and Bootkit Compromise Playbook covers the steps.
How to verify it works
- Controlled modification test: on a lab device, with the supplier's agreement, make a harmless change to a monitored region (a debug build or test hook supplied for the purpose) and confirm an alert fires and reaches the SIEM with the device name and, where supported, the modified address.
- Heartbeat check: where the monitor emits a periodic status message, alert when it stops. Silence is the signature of a removed or disabled monitor.
- Image identity check: compare the running image hash against the approved monitored image with an external check, the job of D3-FV Firmware Verification. This catches a device quietly reflashed with an unmonitored image.
- Update regression: after each vendor firmware update, confirm the monitor is still present and still reporting.
| Metric | Example target (NHI Mgmt Group suggestion, not a standard) | Why it matters |
|---|---|---|
| Share of in-scope devices running a monitored image | Rising quarter on quarter, tracked per device class | Coverage of the blind spots you listed |
| Devices whose monitor heartbeat was missing for over 24 hours | Zero unexplained | A silent monitor is a failed control |
| Controlled modification tests passed | 100% per device class per year | Proves detection works end to end |
| Days from vendor firmware release to monitored image deployed | Tracked and trending down | Shows the re-hosting process is not delaying patches |
Limits, bypasses and failure patterns
- Removing the monitor: the symbiote paper states that software-only symbiotes can be bypassed by removing all intercepts or disabling the manager or payload, and recommends using them with other defences in depth. An attacker who can reflash the whole image can simply install one without the monitor, which is why external image verification matters.
- New attack surface: D3FEND's own consideration is that exposing monitoring hooks to the injected code may introduce additional risk. The monitor runs with the firmware's privileges, so its own code quality matters.
- Integrity only, not behaviour: the published proof of concept checked code integrity. The authors list stack and heap protection and defence against return-oriented attacks as research in progress, so an exploit that runs without changing monitored code may go unseen. D3-FBA Firmware Behavior Analysis covers behaviour.
- Patching friction: every vendor update needs the monitor re-inserted and the image re-signed. If that takes weeks, teams fall behind on security fixes, trading one risk for another.
- Alerts that stay on the box: a device that records an integrity failure only in local memory, or only on its console, gives no detection value for a remote fleet.
- Thin evidence base: the public research comes from one group and covers a few router firmware versions. Ask suppliers for their own test results instead of assuming the published figures apply to your devices.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SI-7 Software, Firmware, and Information Integrity; SI-7(1) Integrity Checks | Integrity verification of firmware, including checks at runtime |
| NIST SP 800-53 Rev 5 | SI-4 System Monitoring | Getting monitor output into central monitoring |
| NIST SP 800-193 | Platform Firmware Resiliency Guidelines: protect, detect, recover | D3-FEMC is a detect mechanism for firmware |
| NIST CSF 2.0 | DE.CM-09 | Monitoring computing hardware, software and runtime environments for adverse events |
| MITRE ATT&CK mitigations | M1046 Boot Integrity, M1051 Update Software | The preventive controls that sit beside an in-firmware monitor; see M1046 Boot Integrity |
| MITRE D3FEND | D3-PM, D3-FEMC | Parent and technique |
Related countermeasures
- Firmware Verification (D3-FV): external, hash-based checking of the image; the natural partner for an in-firmware monitor.
- Firmware Behavior Analysis (D3-FBA): watches what firmware does rather than whether its bytes changed.
- Bootloader Authentication (D3-BA): a hardening technique that stops unsigned boot code from running; see D3-BA Bootloader Authentication.
- Platform Monitoring (D3-PM): the parent technique; its other children include File Integrity Monitoring, Operating Mode Monitoring and Platform Uptime Monitoring. The overview is in the MITRE D3FEND Guide.
Practitioner checklist
- List device classes that cannot run an endpoint agent and rank them by exposure.
- Ask each supplier whether firmware includes runtime integrity monitoring, and record the answer.
- Agree who modifies, signs and re-hosts monitored images, and how vendor updates are handled.
- Send monitor alerts and heartbeats to a central collector before go-live.
- Pilot on a lab unit and keep a signed known good image for rollback.
- Pair the monitor with external image verification so a reflashed device without the monitor is caught.
- Run a controlled modification test per device class at least yearly.
- Re-test the monitor after every firmware update.
Standards and references
- MITRE D3FEND: Firmware Embedded Monitoring Code (D3-FEMC)
- Columbia University: Defending Embedded Systems with Software Symbiotes
- Red Balloon Security: US10657262B1 Method and apparatus for securing embedded device firmware
- NIST: SP 800-193 Platform Firmware Resiliency Guidelines
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls (SI-7)
- MITRE ATT&CK: T1542.004 ROMMONkit
Related NHI Mgmt Group resources: Firmware and Boot Security Guide · D3-FV Firmware Verification · D3-FBA Firmware Behavior Analysis · Network Device Management Plane Hardening Guide · MITRE D3FEND Guide