See the machine before the operating system starts - firmware settings, boot menus, startup errors and installers - and present virtual media to it.

Remote desktop, SSH and management agents all run on top of a working operating system with working networking. When either has failed, they are unavailable, which is exactly when access matters.

An IP KVM captures the video output directly, so it shows whatever is on the screen from the moment power is applied: firmware setup, storage controller configuration, boot device selection, a kernel panic, a blue screen, a stalled update.

It also injects keyboard and mouse input at the same level, so those screens can be operated.

Virtual media extends this to mounting an image file as a local drive, allowing installation and recovery.

The practical effect is that almost nothing requires physical attendance except hardware replacement - which is what makes remote and unstaffed sites viable.

An image file on the operator's machine or a server is presented to the remote system as a local optical or USB drive, which it can boot from and read.

The IP KVM emulates a USB storage device attached to the managed machine. The machine sees an ordinary drive and treats it as one - so it appears in the boot menu, can be selected as a boot device, and works with any operating system or utility without special support.

The file is streamed over the network from wherever it is stored, which is why performance depends on the connection. Installing an operating system this way over a slow link is possible but slow, and mounting the image from a server local to the site is far quicker than from an administrator's laptop.

The uses are operating system installation, firmware updates, booting recovery environments, and running diagnostics.

It is also the most sensitive capability in the product: whoever can mount media can boot the machine from anything they choose, which is complete control of the hardware.

Management network only, never internet-facing, multi-factor authentication, directory integration, per-port authorisation and session logging.

An IP KVM sits below the operating system, so none of the controls on the managed machine apply to it. Access to the KVM is access to the hardware.

It should be on a management network unreachable from the general user network, and reached through a controlled path - a jump host or a VPN with strong authentication - rather than being exposed.

Authentication should use the central directory so accounts follow employment, with multi-factor enforced.

Authorisation should be per port where supported, so an administrator can reach only their own systems.

Session recording provides both audit and, practically, a record of what was done during an incident.

Change default credentials and keep the firmware current. This class of device has a history of vulnerabilities, and one exposed to the internet with default credentials is found within hours.

Usually not for those servers - but for equipment without one, and for consolidating access, it still has a place.

Modern servers include a management controller that provides remote console, virtual media and power control over its own network port. That covers the requirement natively and is the normal arrangement in a modern server estate.

Where an IP KVM still earns its place: industrial computers, appliances, storage systems and older equipment without such a controller; environments where a single consolidated access point with unified authentication and logging is preferred over many individual controllers; and cases where the controller's own network access is deliberately restricted.

It is also useful as a fallback when a management controller itself fails or is unreachable, which does happen.

The important point either way is that the management controllers need a properly separated network of their own - the out-of-band property comes from the network design, not from the device.

Modest for console work, more for virtual media - and latency affects usability more than bandwidth.

A console session compresses the screen and sends changes, so a mostly static text screen uses very little. A graphical desktop with movement uses considerably more, and the quality setting trades bandwidth against image fidelity.

Latency is what makes a session pleasant or frustrating. Mouse movement with noticeable delay is difficult to work with, and over a long-distance link that is the limiting factor rather than bandwidth.

Virtual media is where bandwidth matters. Installing an operating system streams several gigabytes, and over a slow link that takes hours. Mounting the image from a server at the same site as the KVM avoids the problem entirely and is worth arranging in advance.

For routine console work, even a cellular fallback link is usually adequate - which is what makes cellular out-of-band access practical.

Many do, or integrate with switched power distribution units - and the combination is what makes remote recovery complete.

Console access alone cannot help with a machine that has locked up completely and does not respond to any input. A power cycle is the remedy, and without remote power control that means a site visit.

Some IP KVM products include power outlets directly. More commonly they integrate with switched power distribution units, so the same interface that shows the console also offers power control for that machine.

The combination - see the screen, control the keyboard, mount media, cycle the power - covers essentially everything short of physical hardware failure.

When specifying, confirm the integration works with the specific power distribution units in use, and that the mapping between console ports and outlets is maintained. A power control interface that cycles the wrong outlet is worse than none, and mapping errors are common where racks have been reconfigured.

Only if it has an independent path - which is the whole point of specifying one.

An IP KVM on the production network fails with it. On a separate management network it survives most faults, provided that network has its own switches, cabling and power.

For a complete site network failure, an independent wide-area path is required: a cellular modem in the KVM, or a cellular router on the management side, or a dial-in connection where a line exists.

That is the arrangement that lets a site with no working circuits still be diagnosed and recovered - and it is what distinguishes a genuine out-of-band design from remote access that merely uses different software.

Test it. Equipment used rarely by design is equipment whose failures go unnoticed, and a fallback path that has not been exercised in a year should not be assumed to work.

Document how to use it, including credentials held somewhere that does not depend on the site being reachable.