D3-IDA Input Device Analysis: What It Detects, Which ATT&CK Techniques It Counters and How to Verify It

A keyboard is trusted the moment it is plugged in, which is why a malicious USB device that types commands, or a person at a keyboard who is not the logged-on user, can act with the full rights of the session. MITRE D3FEND names the countermeasure Input Device Analysis (D3-IDA) and defines it as "Operating system level mechanisms to prevent abusive input device exploitation." It is a Detect technique under Operating System Monitoring, and its digital artefact is the Input Device: keyboards, mice, scanners, cameras, microphones. This card explains what D3FEND says the analysis covers, which ATT&CK techniques it relates to, how defenders implement it with OS device controls and behavioural analytics, how to verify it, and where it falls short. It is written for endpoint security and detection teams; the policy side of USB control is covered in the Removable Media and USB Control Guide.

Key takeaways

• It compares input with a baseline. D3FEND lists the amount of input, the duration of a single input, the time between inputs and the input values as things to analyse, with context such as the user, time, source device and its properties, and other attached hardware.
• Machine-speed typing is the classic signal. D3FEND's own example is a device sending many keystrokes with almost identical delays, which does not match human cadence, so the device is disabled.
• The ATT&CK links are inferred and narrow. D3FEND relates D3-IDA to Keylogging (T1056.001), Video Capture (T1125) and Audio Capture (T1123) through sub-artefacts of Input Device (keyboard, video and audio input devices).
• Most of the practical value is in device control. OS policies that allow or block devices by class, ID or interface (Windows device installation restrictions, USBGuard on Linux) plus logging of new devices (Windows event 6416) are where most estates start.
• Mimicry is the stated weakness. D3FEND warns that attackers given examples of legitimate input could imitate them, so timing analytics alone are not enough.

D3-IDA at a glance

How it works

D3FEND's knowledge base article describes two strands that share the Input Device artefact.

• Behavioural analysis of input: timing and volume of keystrokes and other input compared with a baseline for the user or for human input in general. D3FEND's examples: a device typing with near-constant inter-key delay is disabled; typing of the session user's own name becomes abnormally slow and the session is locked to the password prompt; keystrokes arrive from a second device after the first has been idle for a long time; physical input appears in a session while the same user sent input from another country within the past hour.
• Device context and hardening: D3FEND notes that related hardening filters certain commands or disables OS functionality, and that context includes the device's manufacturer, keyboard layout and whether it is in first use. One D3FEND example is a new external device through which network traffic is suddenly routed, which is disabled and investigated.

The two cited references are about keystroke dynamics: identifying or confirming a person from the rhythm of their typing. D3FEND's summary of the Biometric Solutions article names the raw measurements as dwell time (how long a key is held) and flight time (time between keys). Keystroke dynamics as continuous authentication is a behavioural biometric, covered in the Biometrics Guide and, for fraud use in web sessions, the Transaction Monitoring and Behavioural Biometrics Guide.

ATT&CK techniques D3FEND relates to D3-IDA

Relationship type: inferred only. D3FEND lists no direct ATT&CK mapping for D3-IDA. Each row is inferred because the ATT&CK technique accesses a sub-artefact of Input Device (D3FEND 1.6.0, checked November 2026). D3FEND labels these relations "inferred, experimental". Each ID was checked against ATT&CK v20.

D3FEND does not relate D3-IDA to T1200 Hardware Additions, but the keystroke injection devices D3FEND's timing example describes are a form of hardware addition. That link is NHI Mgmt Group's reading, not a D3FEND mapping; see MITRE ATT&CK T1200 Hardware Additions, MITRE ATT&CK T1056 Input Capture and the USB Drop Attacks Guide.

Where it is implemented

Port-level blocking is a separate D3FEND technique, IO Port Restriction (D3-IOPR), which filters the same Input Device artefact. See D3-IOPR IO Port Restriction. Product names and settings vary; examples here are classes, not recommendations.

Implementation steps

1. Turn on new-device logging. Enable Audit PNP Activity on Windows and forward event 6416; on Linux, run USBGuard with its audit output or collect kernel device logs. Microsoft's monitoring guidance is to report 6416 events where the Subject Security ID is not SYSTEM (S-1-5-18).
2. Build a device baseline. For two to four weeks (an example period), record which device classes and IDs appear on which device groups. Most estates find a short list of keyboards, mice, headsets and docks per model.
3. Write detections on the baseline. Alert on a second keyboard-class device appearing on a host that already has one, on HID devices that also present storage or network interfaces, and on keyboard devices on servers that should have none.
4. Restrict where use is predictable. On fixed-purpose machines, allow only the listed device IDs. Test with "Also apply to matching devices that are already installed" off first; Microsoft warns retroactive blocking of critical classes such as disk drives or network adapters can make a machine unusable.
5. Add behavioural analytics where justified. For administrator workstations or other high-value seats, evaluate input timing detection and decide on the response (alert only, or lock the session).
6. Define the response. A suspected injection device means physical access: lock the session, disable the device, collect the device ID from the event, and check physical access logs for the location.
7. Roll back safely. Keep a break-glass path (a known-allowed keyboard ID, or an administrator procedure to remove the policy) before enforcing any allow list, so a locked-out machine can be recovered.

How to verify it works

• Device insertion test: plug an approved test keyboard and an approved composite test device into a sample of hosts each quarter; confirm event 6416 or the USBGuard event arrives and the composite-device rule fires or blocks.
• Policy state check: confirm the device installation restriction policy is applied on target groups (Resultant Set of Policy or MDM reports), and that USBGuard is running with the intended rule set.
• Timing test: where behavioural analytics are deployed, run an authorised keystroke injection test device in a lab and confirm the alert or lock.
• False positive review: monthly, review alerts for new keyboards, docks and KVM switches and update the baseline rather than muting the rule.

Limits, bypasses and failure patterns

• Mimicked input: D3FEND notes that attackers with examples of legitimate input could mimic it. Injection tools that add random delays defeat simple timing rules.
• Spoofed identifiers: USB vendor and product IDs are reported by the device itself, so an allow list by ID alone can be satisfied by a device that claims to be an approved keyboard. Port and interface rules reduce but do not remove this.
• Logging without baselines: 6416 events are collected but nobody knows what normal looks like, so nothing is ever flagged.
• Blocking the only keyboard: an allow list deployed retroactively without a break-glass path leaves machines unusable and the policy is withdrawn entirely.
• Ignoring remote input: D3FEND's context includes whether input comes from a local or remote system. Remote sessions bypass physical device controls and need session analytics instead; see D3-RTSD Remote Terminal Session Detection.
• Treating it as complete hardware security: device analysis sees what the OS sees. Inline hardware keyloggers that do not enumerate as a separate device are a physical security problem.

Framework mapping

Practitioner checklist

• Enable Audit PNP Activity and forward event 6416, or the Linux equivalent, from all managed endpoints.
• Baseline device classes and IDs per device group before writing rules.
• Alert on second keyboards, HID devices with storage or network interfaces, and keyboards on servers.
• Apply device allow lists on fixed-purpose machines, with a tested break-glass path.
• Do not rely on vendor and product IDs alone; add port and interface rules where possible.
• Decide the response to suspected injection devices: lock, disable, investigate physical access.
• Test with approved devices every quarter and record the result.
• Use behavioural timing analytics only where the seat justifies the tuning effort.

Standards and references

• MITRE D3FEND: Input Device Analysis (D3-IDA)
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls (SC-41 Port and I/O Device Access)
• Microsoft Learn: Event 6416, a new external device was recognized by the System
• Microsoft Learn: Manage device installation with Group Policy
• USBGuard: Rule language
• MITRE ATT&CK: T1056.001 Keylogging
• MITRE ATT&CK: T1200 Hardware Additions

Related NHI Mgmt Group resources: Removable Media and USB Control Guide · USB Drop Attacks Guide · D3-AL Account Locking · MITRE D3FEND Guide