KVM-over-IP Security Guide: Hardening Sanctioned IP KVMs and Finding Rogue Ones

A KVM-over-IP device gives whoever controls it the keyboard, screen, power button and virtual media of a computer, below the operating system and outside most endpoint controls, and low-cost models now cost less than a keyboard. Enterprise IP KVM switches have long run data centre consoles, while small single-port devices such as PiKVM, TinyPilot, JetKVM, NanoKVM and the GL.iNet Comet are bought by administrators, home labs and, according to the FBI, by fraudulent remote workers running laptop farms. This guide covers both sides: hardening the IP KVMs you approve, and detecting the ones you did not. It is written for infrastructure, endpoint and security operations teams. Device facts were checked against vendor documentation and published research on 11 November 2026.

Key takeaways

• An IP KVM is a full-control remote access path. It sees the BIOS, boot menu and login screen, can mount ISO images and press power, and is invisible to the host's own remote access controls.
• Cheap devices ship weak. Eclypsium's March 2026 research reported nine vulnerabilities across four low-cost IP KVM vendors, including a CVSS 9.8 missing authentication flaw with no fix, plus missing firmware signature checks and weak brute-force protection.
• Put sanctioned devices on the management network. No internet exposure, no vendor cloud relay unless approved, central authentication with MFA, and session logging.
• Rogue devices leave identity and network traces, not endpoint ones. USB and display identifiers can be changed, so combine host device telemetry, network discovery and sign-in analytics.
• The laptop farm case is an identity problem. The FBI names TinyPilot, PiKVM and GL.iNet devices in North Korean IT worker schemes; a KVM finding on a corporate laptop warrants a joint HR, security and identity response.

What an IP KVM can do

An IP KVM captures the video output of a target machine, presents itself to that machine as a USB keyboard and mouse (and often a USB drive or optical drive), and streams the session to a browser or VNC client. Many models also drive ATX power and reset pins, a serial console, or a smart plug. The control is the same as sitting at the machine.

The capabilities that matter for risk are virtual media (boot the host from an attacker-chosen image), power control, keystroke injection at the login screen, and screen capture of anything displayed, including one-time codes and secrets.

Published vulnerabilities and what they teach

In March 2026 Eclypsium disclosed nine vulnerabilities across the GL.iNet Comet RM-1, the Angeet/Yeeso ES3, Sipeed NanoKVM and JetKVM, as reported by The Hacker News on 18 March 2026.

• Unsigned updates mean supply chain risk: a device that accepts unsigned firmware can be tampered with in distribution or by anyone who reaches its update function. Ask every vendor whether firmware is signed and verified on the device.
• Debug ports are physical backdoors: UART root access matters wherever the device sits in a shared space.
• Some products will never be fixed: if a vendor has not shipped a fix for a critical authentication flaw, remove the product rather than wrap it in compensating controls.

Check device CVEs against the CISA KEV catalogue as part of normal triage; none of the CVEs above was confirmed as listed when this guide was written.

Hardening sanctioned IP KVMs

Treat the IP KVM as privileged access: sessions should start from the same controlled path as your other administrative access. See the Privileged Access Workstations Guide.

Choosing between device classes

• Data centres and many servers: use the server BMC console first, and an enterprise IP KVM switch with central management only where BMCs are absent or unsuitable. Central management gives directory authentication, role-based port access and audit logs.
• Small sites and labs: a single-port device can be acceptable if it supports changed defaults, MFA, signed updates and local-only access, and if it is recorded in the asset inventory.
• Remote support for staff laptops: do not use IP KVMs. Use your approved remote support or RMM tool, which runs with the user's knowledge and leaves endpoint logs. See the RMM Tool Security Guide.
• Procurement rules: ban devices whose vendor has unfixed critical vulnerabilities, no signed firmware, or mandatory cloud relays you cannot disable.

Detecting rogue IP KVMs

Rogue devices appear in two forms: a device plugged into a server or desktop on your premises (MITRE ATT&CK T1200 Hardware Additions), and a device attached to a corporate laptop at a remote location so someone else can operate it (T1219.003 Remote Access Hardware). No single signal is reliable, because PiKVM documents that its USB and EDID identifiers can be changed to mimic a real keyboard and monitor.

Laptop farm indicators

The FBI's public service announcement I-101326-PSA of 13 October 2026 says North Korean IT workers "use external hardware such as TinyPilot, PiKVM, GL.iNet, and other Keyboard Video Mouse (KVM) over IP devices" to control employer laptops held by facilitators, and lists KVM/IP hardware or a second laptop controlling company equipment as an employer indicator. Microsoft's June 2025 Jasper Sleet research also names PiKVM and TinyPilot. Because the KVM sits outside the laptop, the laptop's own telemetry may show only a new keyboard and display, so the stronger signals are elsewhere: sign-ins from addresses that do not match the stated location, public VPN use, remote access tools installed soon after delivery, and the FBI's advice to combine several weak signals before escalating. See the Insider Threat from Fake IT Workers Guide and the Hiring Fraud and Candidate Identity Verification Guide.

Responding to a rogue device

1. Do not tip off first: for a suspected laptop farm, involve HR, legal and security before contacting the user, as the FBI recommends joint IT, HR and security information sharing.
2. Preserve evidence: record device telemetry, sign-in history and network logs; for an on-premises device, photograph it in place and record which port and host it was attached to.
3. Contain access: revoke sessions and tokens for the affected identity, disable the account if the case is confirmed, and isolate the host.
4. Check what the device could reach: virtual media and keyboard access allow booting other media and typing commands; review the host for persistence and changes, including firmware and boot settings.
5. Remove and examine: keep the device as evidence; its storage may hold configuration, tunnels and logs.
6. Close the gap: add the identifiers to device control monitoring, tighten port policies, and update hiring verification where relevant.

For the related playbook, see the Unauthorised Remote Monitoring and Management Tool Playbook.

Where identity fits

An IP KVM has its own accounts, often local and shared, and it bypasses the host's authentication policy by typing at the console. Bring sanctioned devices into the same joiner, mover and leaver process as other privileged accounts, store any break-glass local password in the vault, and rotate it after use. For rogue devices the identity view matters more than the device view: a session operated through a KVM uses a real employee's valid credentials (T1078 Valid Accounts), so continuous identity verification and sign-in analytics are where the case is usually found.

Implementation steps

1. Inventory: find every sanctioned IP KVM, BMC console and console server, with owner, location and firmware version.
2. Remove the weakest: retire devices with unfixed critical flaws, unsigned firmware or forced cloud relays.
3. Harden in place: change defaults, enable directory authentication and MFA, disable unused interfaces, move to the management VLAN.
4. Centralise logs: forward authentication and session events; where a device cannot, restrict it to a jump host that records sessions.
5. Turn on detection in audit mode: alert on USB identifiers and display names of known devices, and on composite HID plus storage arrivals, for 30 days; tune out docks and known peripherals.
6. Add correlation: join device findings with sign-in, VPN and remote tool alerts for the same user.
7. Enforce: block known IP KVM identifiers with device control where business allows, and keep an exception list for sanctioned devices.
8. Rollback: if device control blocks legitimate peripherals, return the rule to audit mode and refine the identifier list.

Detection and measurement

• Percentage of sanctioned IP KVMs with defaults changed, MFA on and current firmware (target 100 per cent).
• Number of IP KVMs reachable from the internet or from user VLANs (target zero).
• Percentage of IP KVM sessions recorded or logged centrally.
• Rogue device alerts per month and their median time to triage.
• Percentage of rogue findings that were correlated with identity signals before closure.

Common failure patterns

• Bought on a card, never inventoried: a team buys a low-cost device for a lab server, leaves default credentials and exposes it through a port forward.
• Vendor cloud relay left on: the device phones home to a cloud service that the security team never assessed.
• Trusting USB names: detection rules keyed only to default product strings miss devices with copied identifiers.
• Treating it as an IT ticket: a KVM found on a remote worker's laptop is closed as a hardware issue instead of opening an identity investigation.
• Flat management network: IP KVMs, BMCs and user devices share a VLAN, so one compromised KVM reaches every console.

Framework mapping

Practitioner checklist

• Every sanctioned IP KVM is inventoried with owner, location and firmware version.
• Default OS and web credentials are changed and named accounts with MFA are in use.
• Unused interfaces (VNC, IPMI, SSH, cloud relay) are disabled.
• Devices sit on a management VLAN with no internet egress and no exposure from user networks.
• Products with unfixed critical flaws or unsigned firmware are removed.
• Virtual media and power actions are restricted and logged centrally.
• Endpoint telemetry alerts on known IP KVM USB and display identifiers and composite HID plus storage arrivals.
• Rogue findings on remote laptops trigger a joint HR, security and identity review.

Standards and references

• FBI IC3: Public Service Announcement I-101326-PSA on North Korean IT workers
• MITRE ATT&CK: T1219.003 Remote Access Hardware
• MITRE ATT&CK: T1200 Hardware Additions
• PiKVM: Authentication and two-factor authentication
• PiKVM: Identifying PiKVM on the target host
• Microsoft Threat Intelligence: Jasper Sleet, North Korean remote IT workers
• The Hacker News: Nine IP KVM flaws across four vendors (Eclypsium research)
• NIST: SP 800-53 Rev 5 Security and Privacy Controls

Related NHI Mgmt Group resources: Server BMC Security · Out-of-Band Management Network Design Guide · Insider Threat from Fake IT Workers Guide · Removable Media and USB Control Guide · Bare-Metal Provisioning and PXE Boot Security Guide