IP-KVM for a Homelab: Remote Console, BIOS Access and Security

An IP-KVM is a small network appliance that captures a computer's video output, pretends to be its USB keyboard, mouse and flash drive, and can press its power and reset buttons, all from a web browser. That gives you BIOS and boot access to any homelab machine, which also makes it equal to physical access. Keep it off the internet, reachable only over a VPN on a management network, with changed passwords and a second factor.

This post goes one level deeper than our guides to Redfish and OpenBMC. Those cover the management controller that lives inside a server. This one covers the box you add from the outside when your machines do not have one, which describes most homelabs built from desktops, mini PCs and repurposed workstations.

Key takeaways

• An IP-KVM does four jobs: HDMI capture, USB keyboard and mouse emulation, virtual media and ATX power control. Unlike remote desktop it works with the OS down; unlike a BMC it sits outside the target.
• Open source builds such as PiKVM run on a Raspberry Pi with an HDMI to CSI bridge (or USB dongle) and the USB OTG port in gadget mode.
• Anyone who logs in can type into firmware setup, boot your machine from an uploaded image and power cycle it. Treat the login like the key to the server room.
• PiKVM ships with root/root and admin/admin. Change both, then enable two factor authentication.
• CISA BOD 23-02 (13 June 2023) tells US federal agencies to take management interfaces, including out of band server management, off the internet or put a separate access control point in front. Homelabs should copy that rule.
• The safe pattern: no port forwarding, WireGuard as the only way in, a management VLAN, a certificate from your own CA, TOTP, regular updates and logs kept elsewhere.

What is an IP-KVM?

KVM stands for keyboard, video and mouse. The original KVM switch was a box on a desk that let one keyboard, monitor and mouse control several computers. An IP-KVM, also called KVM over IP, moves that console onto the network. You open a browser tab and see exactly what a monitor plugged into the target machine would show, including the firmware splash screen, the boot menu and a kernel panic. Your keystrokes and mouse movements are sent to the machine as if a USB keyboard and mouse were plugged into it.

Modern IP-KVMs bundle four functions. Each has its own hardware and its own risks, so it helps to separate them.

The PiKVM README summarises the same feature set in its own words: full HD video through an HDMI to CSI bridge or a USB dongle, WebRTC, H.264 over HTTP and MJPEG video, a bootable virtual CD, DVD or flash drive, a USB keyboard and mouse with PS/2 support, ATX power functions, access through a web UI or VNC, and the ability to use IPMI, Redfish and Wake-on-LAN to control the server. It also describes a ready made OS with a read only filesystem and HTTPS out of the box.

How does an IP-KVM differ from a BMC, IPMI, Redfish and remote desktop?

The cleanest way to separate these terms is by where the management code runs.

Server BMC

A baseboard management controller is a separate small processor soldered onto a server motherboard. It has its own network port (or shares one), its own firmware and its own power rail, so it stays up when the server is off. Most offer remote console, virtual media, power control, sensors and event logs. The key difference from an IP-KVM is that the BMC is part of the server. You cannot add one to a desktop or a mini PC that did not ship with it.

IPMI

The Intelligent Platform Management Interface is the older protocol that many BMCs speak for power control, sensor data and Serial over LAN. The PiKVM IPMI page calls it "a legacy protocol for remote server management" and strongly recommends against using it outside trusted networks because of the protocol's insecurity. When PiKVM's IPMI server is enabled, its docs note that passwords are stored as plain text "due to the IPMI legacy" and advise not reusing them anywhere else.

Redfish

Redfish is the DMTF standard intended to replace IPMI. The Redfish Specification (DSP0266, version 1.20.0, dated 30 November 2023) defines an HTTP based interface with JSON payloads and published JSON Schema for resources such as systems, chassis, managers and accounts. PiKVM's own docs describe Redfish as "a more modern server management protocol designed to replace IPMI" that is based on HTTP and fixes many security issues, and PiKVM supports it natively for power management. Scripts that already speak Redfish to real BMCs can drive a PiKVM the same way.

Software remote desktop

VNC, RDP and similar tools run inside the target's operating system. They are excellent once the OS is up and useless before it is: no firmware setup, no boot device choice, no help when a kernel update leaves the machine at a rescue prompt.

The short version

How are open source IP-KVMs built on single board computers?

The best documented open source design is PiKVM. Its handbook describes several hardware platforms that share one software stack: ready made V3 and V4 devices from the project, and do it yourself builds called V1 and V2. Everything in this section comes from the DIY V2 guide and related handbook pages, which explain why each part is there.

The base board

The V2 guide recommends a Raspberry Pi 4 with 2 GB of memory and says there is no point buying more, "since PiKVM software uses very few resources." A Raspberry Pi Zero 2 W also works and is cheaper, but the guide calls it a less reliable choice because it has no wired Ethernet. The README lists support for Pi 2, 3, 4, 5 and Zero 2 W.

The Raspberry Pi 5 is a special case. The V2 guide says the Pi 5 has no hardware video encoders, so it cannot use the HDMI to CSI bridge or encode H.264; only a USB HDMI dongle with MJPEG video works on it. The guide recommends a Pi 4 or Zero 2 as the base board.

You also need a microSD card. The V2 guide asks for at least 16 GB, class 10, while the handbook's flashing page now says a minimum of 32 GB with class 10 recommended. Buy the larger card; images for virtual media live on it too.

Video capture: HDMI to CSI bridge or USB dongle

There are two ways to get the target's HDMI output into the Pi.

The recommended option is an HDMI to CSI bridge based on the TC358743 chip. It plugs into the Pi's camera connector (the MIPI CSI slot) with a flat ribbon cable. According to the V2 guide it supports H.264 encoding, automatic resolution detection and the lowest latency of the two options. The guide warns never to connect or disconnect the ribbon cable while the device is powered, and to use only a cable with the correct pinout.

The alternative is a USB HDMI capture dongle. The V2 guide is blunt about its limits: MJPEG video only, no resolution detection, much higher latency than the CSI bridge, and some users report that a dongle does not work in the BIOS or stops working after a while. The guide calls it "a black box" that cannot be fixed if it misbehaves. If your target outputs VGA rather than HDMI, the guide suggests a VGA to HDMI converter and notes that some converters do not support every resolution and refresh rate.

USB OTG gadget mode: how a Pi becomes a keyboard and a USB stick

This is the clever part. Most USB ports are hosts: you plug devices into them. A USB On-The-Go (OTG) port can also act as a device, so the Pi can be plugged into the target machine and appear to it as a keyboard, a mouse, a storage drive or a network adapter.

On Linux, this role is called a USB gadget. The kernel documentation on configfs gadgets explains the model: a Linux system with a USB Device Controller (UDC) can be connected to a USB host to extend it with additional functions such as a serial port or mass storage. The host sees a gadget as a set of configurations, each containing interfaces, which the gadget side calls functions. You build the gadget by creating directories and writing values under the configfs mount, then you bind it to a UDC so the host can enumerate it. The kernel docs show that final step as writing the UDC name into a file called UDC.

On a Raspberry Pi 4, only one port can do this. The V2 guide explains that only the USB-C port that receives power can act as a USB device; the other ports are host only. So the build needs a special cable arrangement that lets the USB-C port talk to the target as a device while still receiving power from a supply. The guide documents three variants: a ready made splitter module, a Y splitter built with a USB power blocker on the target side, or a soldered DIY splitter.

USB device emulation has a hard resource limit. PiKVM's USB configuration page says each emulated device consumes hardware resources called endpoints, and the controller offers nine in total.

By default, PiKVM V2 and V3 emulate one absolute mouse and one mass storage drive (plus the keyboard) and use four of the nine endpoints; V4 adds a relative mouse and uses five. The same page warns that some target BIOS or UEFI firmware cannot cope with many emulated devices on a single USB port, and that adding or removing devices requires a reboot. The mass storage page goes further and names some business desktops whose UEFI cannot handle mass storage and keyboard on one port, with symptoms like a black screen, a boot loop or lost firmware settings. Its recommended fix is to configure mass storage but not start it at boot, and enable it only when you need to boot an image.

ATX power control

Video and USB give you the console. Power control needs a cable inside the target's case. PiKVM's ATX board page describes a small adapter board that sits between the motherboard's front panel header and the case's front panel wires, with ribbon cables on both sides, so the case buttons keep working while the KVM can also press them and read the power and disk activity LEDs. The adapter connects back to the KVM with a straight eight wire Ethernet cable, and the docs note that Mac computers lack the needed ATX headers.

For DIY builds the V2 guide lists the parts for a home made ATX controller: four optocouplers from a short list of named part numbers, 390 ohm and 4.7 kilohm resistors, jumper wires and a breadboard. It warns not to use random relay modules or optocouplers, because some are not sensitive enough for the Pi's GPIO or switch on the wrong logic level.

If you skip the ATX board, the V2 guide says Wake-on-LAN can partly replace it, but cannot reboot a hung system and is less reliable, because Wake-on-LAN on the host sometimes stops working for its own or network reasons.

One KVM, many machines: multi-port switches

A homelab rarely has one machine. PiKVM's multiport page describes two routes. The project's own switch adds ports with per port ATX control and per port EDID settings, can be chained to reach up to 20 ports, and is managed from the PiKVM web UI. Third party switches with USB or network control also work. Either way, one compromised KVM login now reaches every machine on the switch, which raises the stakes for everything in the security sections below.

Parts list at a glance

How does the software work?

Video: MJPEG, H.264 and WebRTC

The video side is a streamer called uStreamer, also written by the PiKVM author and licensed under the GPL version 3. It reads frames from the capture device through the Linux video4linux2 (V4L2) interface and serves them to the browser. Its README documents bandwidth efficient H.264 streaming through the Janus WebRTC server, and notes that if you put uStreamer behind Nginx you should turn off proxy buffering, because buffering adds latency.

PiKVM's video page describes three modes on CSI bridge based devices:

• WebRTC H.264. The browser receives H.264 over WebRTC, the W3C standard for real time media in browsers (published as a W3C Recommendation on 13 March 2025). This is usually the lowest latency option and supports audio.
• Direct H.264. H.264 delivered over HTTP. The docs suggest it when WebRTC will not connect; it does not support audio yet.
• Legacy MJPEG. A series of JPEG images. It needs no H.264 support in the browser and uses much more bandwidth.

The same page gives two tuning knobs: bitrate, and the H.264 group of pictures (gop), which controls how often a full reference frame is sent. The docs recommend gop 0 on a good network, gop 60 for WebRTC on a bad network, and gop 0 for Direct mode on a bad network. The README cites 35 to 50 milliseconds of H.264 latency; your numbers will depend on your network and the VPN in the path.

The video stream carries everything on the target's screen, including recovery keys shown during disk encryption setup, which is one more reason to get TLS right.

Keyboard and mouse

Keystrokes and mouse events travel from the browser to the KVM inside the authenticated web session and are written to the emulated USB HID devices. PiKVM supports an absolute mouse, where the pointer lands exactly where you click, and a relative mouse, which sends movements the way a physical mouse does; the handbook has a page on choosing between them, and V4 enables both by default. The docs also describe a mouse jiggler, Bluetooth HID and PS/2 support for older machines.

The important property for security is that the target cannot distinguish these keystrokes from a person at the keyboard. There is no separate trust boundary; firmware setup passwords, disk unlock prompts and login screens all accept them.

Virtual media: the USB mass storage gadget

The Linux kernel's mass storage gadget documentation describes the function PiKVM builds on. Each logical unit is backed by a file, and module parameters such as cdrom (present the unit as a CD-ROM) and ro (report the unit read only so the host cannot modify the backing file) control how the host sees it.

PiKVM's mass storage page builds a full workflow on top. Images live on a dedicated partition mounted at /var/lib/kvmd/msd, which is read only most of the time and remounted for writing only while you upload an image or use a writable drive mode. The web UI's Drive menu lets you upload an image, pick one to connect, switch between CD/DVD and flash drive, set write access, and download an image. The docs say the virtual drive is available "even in BIOS/UEFI", which is exactly why it is useful for reinstalling an OS and exactly why it is a security concern: anyone with the KVM login can boot your machine from an image of their choosing. Since KVMD 4.49 PiKVM also supports DVD emulation, and it can store images on NFS or Samba shares.

Wake-on-LAN

For machines without an ATX board, PiKVM can send Wake-on-LAN magic packets. The handbook's Wake-on-LAN page shows the configuration in /etc/kvmd/override.yaml: set the target's MAC address, and by default the packet is broadcast to 255.255.255.255 on port 9. You can address it to a specific IP instead. On a segmented network, a broadcast from the management VLAN will not reach another VLAN, so point the packet at a specific address and allow it in the firewall.

A read only operating system

PiKVM OS is a build of Arch Linux ARM with the project's own repository for KVM packages, according to its FAQ. The root filesystem is mounted read only during normal operation, which protects the SD card from corruption on power loss. Every configuration change in the docs follows the same pattern: run rw to remount the filesystem writable, make the change, then run ro. Updates use pikvm-update, which the docs recommend running when you have physical access to the device, because a failed update means reflashing the card.

A read only root is good for reliability, but it is not a security boundary: anyone with root can run rw.

Authentication and the web terminal

PiKVM has two separate default accounts, and its authentication page lists them plainly:

• Linux OS admin, used for SSH and the console: username root, password root.
• KVM user, used for the web interface, the HTTP API and VNC: username admin, password admin.

The docs say they are separate accounts with independent passwords and tell you to change both. The web UI includes a browser terminal that runs as an unprivileged user called kvmd-webterm, from which you can su - to root with the root password. The docs show how to disable the web terminal if the device owner and its users are different people.

KVM users are stored in an htpasswd style file at /etc/kvmd/htpasswd and managed with kvmd-htpasswd. The docs note there is no per user access control: every KVM user has the same rights. For larger setups, PiKVM supports external authentication through HTTP, PAM, LDAP and RADIUS plugins.

Two factor authentication has been available since KVM version 3.196. It uses TOTP, the time based one time password algorithm, set up with kvmd-totp init. Two details from the docs are worth knowing before you rely on it:

• The TOTP secret is shared by all web UI users. There is one secret per device, not one per person.
• 2FA does not cover root SSH access, so root still needs a strong password or, better, key based login.

Since KVMD 4.53 you can choose a session lifetime on the login page (1 hour, 12 hours or until reboot), and administrators can set a global maximum in override.yaml. The docs add that VNC sessions are always endless and that long lived video connections are not cut when a session expires until the tab closes.

Why is an IP-KVM equal to physical access?

A person at the console can do things software controls cannot stop, and an IP-KVM recreates those abilities over the network:

• Firmware setup. Change boot order, disable Secure Boot, reset firmware passwords where the board allows, enable or disable devices.
• Boot from attacker controlled media. Upload a live image through virtual media and boot it, bypassing the installed OS and its login.
• Watch the screen. See disk encryption unlock prompts, recovery keys, installer output and anything else displayed.
• Type anything. Enter commands at a root shell left logged in on the console, or at a bootloader prompt.
• Cut power. Force off a machine mid write, or power cycle it repeatedly.

Risk 1: internet exposure

The most direct risk is putting the web UI on the public internet. PiKVM's own port forwarding page explains how to do it and then warns you to set strong passwords and enable two factor authentication first, get a valid HTTPS certificate, and consider a VPN as "a more secure, but less convenient option." The page lists the ports involved: 80 and 443 for the web UI (80 redirects to 443 by default) and 5900 for VNC if enabled.

An exposed login page invites password guessing, and any future bug in the web stack becomes reachable by everyone. A non standard port only reduces scanner noise.

Risk 2: default and shared credentials

Two accounts with well known defaults, root/root and admin/admin, are the first thing anyone tries. Forgetting one of them (typically root, because the web UI only asks for the admin login) leaves SSH wide open. The shared TOTP secret is a smaller issue in a one person homelab, but if several people use the device, nobody can revoke one person's second factor without resetting it for everyone.

Risk 3: stale OS images

An IP-KVM is a Linux computer running a web server, a video streamer, a Python daemon, OpenSSH and a stack of libraries. Like any Linux box it needs updates. Homelab KVMs go stale because they work and are then forgotten. A device flashed two years ago and never updated carries two years of fixed vulnerabilities in its open source components.

Risk 4: virtual media as a boot path

Virtual media is a deliberate, supported way to boot your server from an image you upload over the network. That makes it a powerful attack path. An attacker with the KVM login can boot a live system and mount unencrypted disks without touching your OS login. Even with full disk encryption, someone who can watch the screen and type can tamper with an unencrypted boot partition or wait for you to unlock.

Risk 5: legacy protocols

If you enable IPMI emulation, you add a protocol the PiKVM docs themselves advise against using outside trusted networks, with passwords stored in plain text. VNC, if enabled, opens another port with its own session rules.

Risk 6: the KVM as a pivot

A KVM on your main LAN can reach everything on that LAN. If it is compromised, it is a foothold. If it is on a separate management network, a compromise is contained to what that network can reach.

What does CISA BOD 23-02 say about internet-exposed management interfaces?

CISA issued Binding Operational Directive 23-02, "Mitigating the Risk from Internet-Exposed Management Interfaces", on 13 June 2023. It binds US federal civilian agencies, but its logic applies to anyone.

The directive defines a networked management interface as a dedicated device interface, reachable over network protocols, that is meant only for authorised users to perform administrative tasks on a device, a group of devices or the network. It applies to devices in named classes: routers, switches, firewalls, VPN concentrators, proxies, load balancers, and out of band server management interfaces, with two well known server vendors' BMC products given as examples. The interface must be reachable over the public internet using protocols that include HTTP, HTTPS, SSH, Telnet, SNMP, FTP, TFTP, RDP, SMB, VNC and X11.

The required actions are short. Within 14 days of CISA notifying an agency, or the agency finding such an interface, it must do at least one of two things:

1. Remove the interface from the internet so it is only reachable from an internal enterprise network. CISA recommends an isolated management network.
2. Put access control in front of the interface, as part of a Zero Trust Architecture, using a policy enforcement point that is separate from the interface itself. CISA marks this as the preferred action.

Agencies must also put controls in place so that every in scope management interface, on existing and new devices, has one of those protections. The directive allows an interface to stay reachable from the internet only where all access is mediated in line with federal zero trust guidance, including NIST SP 800-207.

Translating BOD 23-02 to a homelab

An IP-KVM is an out of band server management interface in every practical sense, so it falls squarely within the spirit of the directive.

The idea to borrow is that the control must be separate from the interface. The KVM's own login page, even with 2FA, is part of the thing being protected; a VPN in front means a bug in its web stack is only reachable by people who already hold a VPN key.

Which remote access patterns are safe?

VPN only, no port forwarding

WireGuard describes itself as a simple, fast, modern VPN that uses state of the art cryptography and runs in the Linux kernel and on Windows, macOS, BSD, iOS and Android. Its model suits management access well. Each peer has a public key, and the AllowedIPs setting for a peer acts as both a routing table and an access list: traffic from that peer is only accepted if it comes from the addresses listed for it. The WireGuard site gives the example plainly: a packet from a peer is decrypted and authenticated, and then allowed onto the interface only if its source address is in that peer's allowed IPs; otherwise it is dropped. Our WireGuard setup guide covers a full install.

The PiKVM docs also describe running a hosted mesh VPN client on the KVM itself. That works, but terminating the VPN on your router and routing to the management VLAN keeps the KVM simpler.

A separate management VLAN

A VLAN splits one physical switch into several isolated networks. Put the KVM, any BMCs, your switch's admin interface and similar devices on a management VLAN, and write firewall rules so that only the VPN subnet and perhaps one admin workstation can reach it. Our home firewall build guide covers VLAN setup end to end. Two rules matter most for a KVM: nothing on the IoT, guest or main LAN can open a connection into the management VLAN, and the management VLAN cannot reach the internet except for the update mirrors and time servers it needs.

TLS with your own CA

PiKVM ships with a self signed certificate, and clicking through its warning is exactly the habit that lets a man in the middle succeed. Since the KVM is not on the internet, the clean answer is a small private CA: one root key kept offline, a certificate per management device with the right Subject Alternative Names, and the root installed only on the devices you administer from.

TOTP second factor

TOTP is defined in RFC 6238, published in May 2011. It derives a short code from a shared secret and the current time, using a default time step of 30 seconds that the RFC describes as a balance between security and usability. It works offline and needs only an authenticator app.

NIST SP 800-63B-4 gives the right expectations. It notes that OTP authentication is not phishing resistant, requires verifiers to rate limit failed attempts (no more than 100 consecutive failures on one account), and requires passwords used as a single factor to be at least 15 characters, while passwords used only as part of multi factor authentication must be at least 8. For a KVM behind a VPN, TOTP is a sensible second layer. For a KVM exposed to the internet, TOTP alone does not stop someone who tricks you into typing the code into a fake page.

Step by step: set up and secure a homelab IP-KVM

This assumes a PiKVM DIY V2 build on a Raspberry Pi 4 with a CSI bridge and ATX board, a router that supports VLANs and WireGuard, and a Linux or macOS workstation.

Step 1: plan the network

An example address plan:

Configure the switch port for the KVM as an untagged access port on VLAN 99.

Step 2: flash the OS image

Download the PiKVM OS image for your exact combination of board and capture device from the handbook's flashing page. Images differ: for example, the Raspberry Pi 4 has separate images for the HDMI to CSI bridge and the USB dongle. The page lists a SHA-1 checksum beside each image and documents two methods, Raspberry Pi Imager and a Linux command line with dd. The command line route is where people lose data.

Warning: the next command overwrites the target device completely. Writing to the wrong device destroys its data. First identify the SD card by size and model, with the card removed and then inserted, so you can see which device appears:

# Linux: list block devices before and after inserting the card
lsblk -o NAME,SIZE,MODEL,TRAN,MOUNTPOINTS

# macOS
diskutil list

Only when you are certain of the device path (for example /dev/sdX on Linux or /dev/diskN on macOS), unmount any mounted partitions on it and write the image:

# Verify the download first: compare with the sha1 value shown next to the image link
sha1sum v2-hdmi-rpi4-latest.img.xz

# Confirm the device path one last time (the handbook suggests this exact listing)
lsblk -dpno NAME,SIZE,MODEL

# Linux example from the handbook: replace /dev/mmcblkX with the device you confirmed
xz --decompress v2-hdmi-rpi4-latest.img.xz
sudo dd if=v2-hdmi-rpi4-latest.img of=/dev/mmcblkX bs=4M status=progress conv=fsync oflag=direct
sync

SHA-1 is enough to catch a corrupted download, but it is a weak defence against a deliberately altered file, so download only over HTTPS from the project's own site.

Connect HDMI, the USB-C splitter, the ATX board and management VLAN Ethernet, and power last.

Step 3: change both default passwords before anything else

Open the web UI from a machine on the management VLAN, log in once as admin/admin, open the web terminal and become root (the default root password is root). Then follow the handbook:

su -
rw
passwd root            # new strong root password
kvmd-htpasswd set admin   # new web UI password
ro

Use a password manager and at least 15 characters, NIST's floor for single factor passwords, since until 2FA is on the password is the only factor.

Step 4: update the OS

Run the updater while you are physically next to the device, as the handbook recommends:

su -
pikvm-update

If the command is missing, the docs say you are on an old release and should install the updater first:

rw
pacman -Syy
pacman -S pikvm-os-updater
pikvm-update

Reboot, then check the KVMD version with pacman -Q kvmd.

Step 5: switch SSH to keys

2FA does not cover SSH, so the PiKVM docs recommend key access for root. Copy a key, confirm it works, then turn off SSH passwords.

# On your workstation
ssh-keygen -t ed25519 -f ~/.ssh/pikvm_ed25519
ssh-copy-id -i ~/.ssh/pikvm_ed25519.pub root@192.168.99.10
ssh -i ~/.ssh/pikvm_ed25519 root@192.168.99.10   # confirm this works first

# On the KVM, as root
rw
sed -i 's/^#\?PasswordAuthentication .*/PasswordAuthentication no/' /etc/ssh/sshd_config
sshd -t && systemctl restart sshd
ro

Keep your existing session open while you test a new one, so a typo cannot lock you out.

Step 6: enable TOTP and a session limit

TOTP depends on the clock, so check NTP first, as the handbook asks.

timedatectl            # "System clock synchronized: yes"
rw
kvmd-totp init         # scan the QR code with an authenticator app
ro

From now on the login page asks for the six digit code. For API or VNC logins, the docs say to append the code to the password with no space.

Then cap session length in /etc/kvmd/override.yaml (the docs' example is six hours):

kvmd:
  auth:
    expire: 21600

rw
systemctl restart kvmd
ro

Step 7: switch off what you do not use

• Web terminal. If you always use SSH, disable it: rw, systemctl disable --now kvmd-webterm, ro.
• VNC. It is off by default. Leave it off unless you need it, and note VNC sessions never expire.
• IPMI. Off by default. Leave it off; the docs advise against IPMI outside trusted networks.
• Mass storage at boot. If you only need virtual media occasionally, the docs show how to keep it configured but not started at boot, and enable it on demand.

Step 8: put a certificate from your own CA on the KVM

Create a small private CA on an offline or well protected machine, then issue a certificate for the KVM's name. These commands use OpenSSL:

# One time: create the CA (keep ca.key offline and backed up)
openssl req -x509 -newkey ec -pkeyopt ec_paramgen_curve:P-256 -nodes \
  -keyout ca.key -out ca.crt -days 3650 -subj "/CN=Homelab Management CA"

# Per device: key and signing request for the KVM
openssl req -newkey ec -pkeyopt ec_paramgen_curve:P-256 -nodes \
  -keyout kvm.key -out kvm.csr -subj "/CN=kvm.mgmt.home.arpa"

# Sign it with SAN entries for the name and the management IP
printf "subjectAltName=DNS:kvm.mgmt.home.arpa,IP:192.168.99.10\nextendedKeyUsage=serverAuth\n" > kvm.ext
openssl x509 -req -in kvm.csr -CA ca.crt -CAkey ca.key -CAcreateserial \
  -out kvm.crt -days 397 -extfile kvm.ext

# Check the result
openssl x509 -in kvm.crt -noout -subject -issuer -dates -ext subjectAltName

Copy kvm.crt and kvm.key to the KVM. The handbook's VPN page shows where the bundled web server reads its certificate (/etc/kvmd/nginx/ssl/server.crt and server.key), the group ownership it expects and the service to restart. The same steps, with your own files:

# On the KVM, as root, after copying kvm.crt and kvm.key to /root
rw
cp /root/kvm.key /etc/kvmd/nginx/ssl/server.key
cp /root/kvm.crt /etc/kvmd/nginx/ssl/server.crt
chown :kvmd-nginx /etc/kvmd/nginx/ssl/*
ro
systemctl restart kvmd-nginx

If you enabled VNC, the same page uses /etc/kvmd/vnc/ssl/ with the kvmd-vnc group and service. Then install ca.crt as a trusted root on your admin devices only. Never copy ca.key to the KVM. If you later expose a public name, the handbook's Let's Encrypt page documents a kvmd-certbot helper instead.

The home.arpa domain is designated by RFC 8375 (May 2018) as a special use domain for home networks, so it will not clash with a real public name.

Step 9: set up WireGuard on the router or firewall

Generate keys for the WireGuard server (your router or an edge Linux box) and each admin device, as in the WireGuard quick start:

umask 077
wg genkey | tee server.key | wg pubkey > server.pub
wg genkey | tee laptop.key | wg pubkey > laptop.pub

Server side /etc/wireguard/wg0.conf:

[Interface]
Address = 10.99.0.1/24
ListenPort = 51820
PrivateKey = (contents of server.key)

[Peer]
# admin laptop
PublicKey = (contents of laptop.pub)
AllowedIPs = 10.99.0.2/32

Laptop side:

[Interface]
Address = 10.99.0.2/32
PrivateKey = (contents of laptop.key)

[Peer]
PublicKey = (contents of server.pub)
Endpoint = your-home-address.example:51820
# Route only the VPN and management subnets through the tunnel
AllowedIPs = 10.99.0.0/24, 192.168.99.0/24
PersistentKeepalive = 25

Bring it up with wg-quick up wg0 on both sides and check the handshake with wg show. Forward only UDP 51820 on the router, to the WireGuard host. Nothing else.

Step 10: write the firewall rules for the management VLAN

The firewall decides what a VPN peer, or anything else, can reach. An nftables sketch for a Linux router where wg0 is the VPN, vlan99 is management, and vlan10 and vlan20 are the main LAN and servers. Adapt names to your system and test from each network afterwards.

table inet filter {
  chain forward {
    type filter hook forward priority 0; policy drop;

    ct state established,related accept

    # VPN admins may reach the management VLAN on HTTPS and SSH only
    iifname "wg0" oifname "vlan99" ip saddr 10.99.0.0/24 tcp dport { 22, 443 } accept

    # Management VLAN may reach update mirrors and NTP on the internet
    iifname "vlan99" oifname "wan0" tcp dport { 80, 443 } accept
    iifname "vlan99" oifname "wan0" udp dport 123 accept

    # Optional: let the KVM send Wake-on-LAN to the servers VLAN
    iifname "vlan99" oifname "vlan20" udp dport 9 accept

    # Everything else into or out of vlan99 is dropped by policy
    iifname { "vlan10", "vlan20" } oifname { "vlan10", "vlan20", "wan0" } accept
  }
}

Note what is not there: no rule lets vlan10 or vlan20 reach vlan99, and no rule lets the internet reach anything except the WireGuard port handled by the input chain.

Step 11: log access and keep the logs elsewhere

On the KVM, check what is recorded:

journalctl -u kvmd --since "24 hours ago"
journalctl -u sshd --since "24 hours ago"

Then forward the journal to a log host on the management VLAN with whatever collector you already run, so an attacker with root on the KVM cannot quietly erase the record. The handbook also documents Prometheus monitoring, which shows unexpected reboots. Watch for logins at odd times, repeated failures, virtual media uploads you did not do and unexpected power actions. If your router logs WireGuard handshakes, keep those too: a handshake from a peer you thought was offline is worth a look.

Step 12: keep it updated and verify from outside

Schedule pikvm-update for times when you can reach the device physically, and afterwards confirm 2FA and your certificate are intact. Then test exposure from outside, such as a phone hotspot:

# Replace with your public address. Expect every TCP port to be filtered or closed.
nmap -Pn -p 22,80,443,5900,623 your-home-address.example
nmap -Pn -sU -p 623 your-home-address.example   # IPMI should not answer

From a device on your main LAN, try to open the KVM's address. It should time out. From your laptop on the VPN, it should load.

Step 13: handle virtual media with care

Treat installer images like any other software you install:

• Download images only from the project or distribution's own site, and check the published checksum and signature before uploading.
• Connect the image read only unless you specifically need the target to write to it.
• Disconnect the image when the job is done, and delete images you no longer need from /var/lib/kvmd/msd.

How do IP-KVMs, BMCs, CPU out of band engines and remote desktop compare?

This table covers the four categories a homelab owner usually weighs. Costs are given as rough categories rather than prices, which change too often to be useful.

An IP-KVM's advantage is that it is outside the target and under your control: you can read its source, update it on your schedule and wipe it if in doubt. A BMC costs nothing extra, but its firmware lifecycle belongs to the vendor, and second hand servers often run BMC firmware that will never be updated again. CPU or chipset engines need provisioning; configure them from your platform vendor's documentation. Many homelabs end up with two layers: remote desktop or SSH for daily use, and an IP-KVM or BMC on the management VLAN for the days when something will not boot.

Common mistakes

Changing only the web password. The web UI prompts for admin, so people change that one and forget that root/root still opens SSH. Change both, then switch SSH to keys.

Port forwarding "just for this weekend". Temporary forwards become permanent because nothing reminds you to remove them. If you need remote access, set up the VPN once.

Putting the KVM on the main LAN. Every smart TV, guest phone and IoT gadget on that network can then reach the KVM's login page. Use a management VLAN.

Clicking through the certificate warning. A self signed certificate that you always accept trains you to accept any certificate, including an attacker's. Issue one from your own CA.

Treating 2FA as a replacement for network isolation. TOTP is a second layer behind the VPN, not a substitute for it. NIST notes OTP is not phishing resistant.

Never updating. A KVM that works is easy to forget. Its OS still needs pikvm-update on a schedule.

Leaving images attached. An installer ISO left connected, especially in writable flash mode, is a boot path waiting to be used. Disconnect it when done.

Enabling IPMI for convenience. The project itself recommends Redfish or its own API over IPMI, and IPMI passwords are stored in plain text.

Forgetting the KVM switch multiplies impact. One login to a KVM with a four port switch is four machines' worth of physical access. Protect it accordingly.

FAQ

What is the difference between a KVM switch and an IP-KVM?

A KVM switch shares one physical keyboard, monitor and mouse between several computers on a desk. An IP-KVM puts that console on the network, so you see the screen and type from a browser anywhere you can reach it. Many IP-KVMs can drive a KVM switch to reach several machines.

Can an IP-KVM access the BIOS or UEFI setup?

Yes. It captures the HDMI output from power on and acts as a USB keyboard, so firmware setup, boot menus and bootloader prompts all work. Some firmware has trouble with many emulated USB devices on one port; the PiKVM docs explain how to start mass storage only on demand to avoid that.

Is it safe to expose PiKVM to the internet?

It is safer not to. The PiKVM port forwarding page itself says a VPN is more secure, and CISA's BOD 23-02 tells federal agencies to remove management interfaces from the internet or put a separate access control point in front of them. Use WireGuard and a management VLAN instead.

What are the PiKVM default passwords?

According to the PiKVM handbook, the Linux root account defaults to root/root and the web UI account defaults to admin/admin, with no 2FA. They are separate accounts and both must be changed.

Can I build an IP-KVM with a Raspberry Pi 5?

The PiKVM V2 guide recommends a Pi 4 or Zero 2 W instead. The Pi 5 has no hardware video encoders, so it cannot use the HDMI to CSI bridge or encode H.264, and only works with a USB capture dongle and MJPEG video.

Do I need an ATX board for power control?

Only if you want to press power and reset remotely and read the power LED. Wake-on-LAN can turn a machine on, but the V2 guide notes it cannot reboot a hung system and is less reliable.

Does an IP-KVM replace a server's BMC?

It can stand in for one on machines that do not have a BMC, such as desktops and mini PCs. On servers that already have a BMC, the BMC usually adds sensor data and event logs that an IP-KVM cannot see. Either way, both belong on the management VLAN.

Is TOTP enough to protect a homelab KVM?

No, not on its own. TOTP blocks password reuse attacks but is not phishing resistant according to NIST SP 800-63B-4, and on PiKVM the secret is shared by all web users and does not cover SSH. Use it behind a VPN, together with strong passwords and SSH keys.

Why is virtual media a security risk?

Anyone with the KVM login can boot your machine from an image they choose, bypassing OS logins entirely. Connect images only when needed, read only where possible, and disconnect them afterwards.

How often should I update the IP-KVM?

Check at least monthly and after any security announcement from the project. PiKVM recommends updating when you can physically reach the device, in case the card needs reflashing.

The software inside the box: an honest bridge

An IP-KVM is hardware, and Safeguard does not analyse hardware, scan firmware, manage devices or protect endpoints. Nothing in the walkthrough above depends on Safeguard. The connection is narrower. A PiKVM is a Linux system built from open source software: an Arch Linux ARM base, the Python KVM daemon, the uStreamer video streamer in C, nginx, OpenSSH and the libraries underneath them. Many homelab owners also write their own code around it, such as scripts that call the KVM's HTTP API, Redfish automation, dashboards and container images for a log host. Those repositories and images pull open source dependencies with their own vulnerability histories, and that is where Safeguard can help: scanning repositories, container images and SBOM files for known vulnerable components, and opening upgrade pull requests for review when a fixed version exists.

Fix it without waiting for upstream

Your KVM's own OS is updated by its project, and you should apply those updates on schedule. The automation, dashboards and container images you build around your homelab are different: every rebuild pulls dependencies again, and keeping those open source components on fixed versions is your job, which is what the section below is about.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

None of these demos touch KVM hardware or firmware; they show the software side described in the bridge above.

The first demo is a real Safeguard CLI session: it installs the CLI, opens the interactive terminal and asks it to fix a lodash CVE in a repository. It reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, prints a summary and pushes nothing. The same flow applies to a homelab dashboard or an automation repository that drives your KVM's API: scan it, then let the assistant propose the dependency upgrade under your approval.

Click through it at your own pace, or open it full screen.

The second demo sets up the Safeguard runner on your own machine, approves it with its device code and then scans from the terminal. That suits a homelab, where the code and container images live on your own hardware and you want the scan to run there too.

Click through it at your own pace, or open it full screen.

The third demo is a real Android session: it sends work to a computer running the CLI and approves the command on the phone with Allow once, Allow for turn or Deny. If you are away from home and connected over your VPN, that keeps a human approval on every command the assistant runs on your homelab machine.

Click through it at your own pace, or open it full screen.

To try it on your own repositories, download Safeguard and follow the CLI documentation.

Quick check

Sources

• PiKVM Handbook
• PiKVM Handbook, Authentication and 2FA
• PiKVM Handbook, Advanced authentication
• PiKVM Handbook, DIY PiKVM V2 quickstart
• PiKVM Handbook, Mass storage drive
• PiKVM Handbook, USB configuration
• PiKVM Handbook, ATX board
• PiKVM Handbook, Video modes
• PiKVM Handbook, Wake-on-LAN
• PiKVM Handbook, Port forwarding
• PiKVM Handbook, IPMI and Redfish integration
• PiKVM Handbook, Multiport KVM over IP
• PiKVM Handbook, VPN access
• PiKVM Handbook, Let's Encrypt certificates
• PiKVM Handbook, FAQ
• PiKVM repository README
• uStreamer repository README
• Linux kernel documentation, USB gadget configured through configfs
• Linux kernel documentation, Mass Storage Gadget
• DMTF Redfish Specification DSP0266 version 1.20.0
• DMTF Redfish Developer Hub
• CISA Binding Operational Directive 23-02
• NIST SP 800-207, Zero Trust Architecture
• WireGuard
• WireGuard quick start
• RFC 6238, TOTP: Time-Based One-Time Password Algorithm
• RFC 8375, Special-Use Domain 'home.arpa.'
• PiKVM Handbook, Flashing OS
• NIST SP 800-63B-4, Authentication and Authenticator Management
• W3C WebRTC: Real-Time Communication in Browsers

Last reviewed: 24 October 2026.