Practical Audit Logging for KVM over IP
A KVM over IP device is one of the most privileged systems on a network.
It can access BIOS screens, boot menus, recovery environments, and systems that normal remote tools cannot reach. That is what makes KVM over IP useful. It is also what makes visibility important.
Some TinyPilot customers have asked a simple question:
Can we see when TinyPilot was accessed and how it was used?
That question comes up when multiple technicians, vendors, or internal teams may need access to the same device. TinyPilot does not need to become a full compliance platform, but administrators still need a practical record of important access and control events.
That is the need behind a reference audit logging prototype we built for teams that want to experiment with device-level visibility. It is not built into TinyPilot today.
The solution: selected event logging
The prototype records selected events to a local audit log on the device.
The goal is not to capture everything. The goal is to capture the events that help administrators understand when TinyPilot was accessed, controlled, or changed.
Examples include:
- User login and logout events
- Failed login attempts
- KVM session start and end events
- Paste-to-target activity (metadata only — not pasted text)
- Virtual media mount, unmount, upload, and fetch-from-URL
- Serial console configuration changes
- Firmware update activity
- Device configuration changes
- User, role, and password changes
- User script execution
- Power actions (shutdown/restart) and debug log export
Events are written as structured JSON lines, making them easier to inspect, archive, or collect with other tooling.
What audit logging can and cannot show
KVM over IP auditing is not the same as auditing a normal web application.
Some events are easy to attribute to a TinyPilot user. Other events may come from lower-level access logs where the device can see the source IP address, request path, HTTP method, and response status, but not always a clean authenticated user identity for that specific action.
That means some investigations may require correlation. For example, the log might show that an administrator logged in, then shortly afterward a virtual media request came from the same source IP. In many environments, that is useful. But if users share an IP address, sessions overlap, or traffic passes through shared infrastructure, it may not prove that one specific person performed one specific action.
This prototype is not forensic-grade logging, a SIEM replacement, or a compliance certification. It is a practical device-level record of selected events that TinyPilot can reasonably observe.
What we do not log
The prototype does not record keystrokes, session video, or pasted text.
That is intentional.
A KVM session can expose extremely sensitive information: passwords, recovery keys, API tokens, customer data, patient data, proprietary information, and anything else visible on the remote screen.
Recording full session contents would create a new sensitive data store. Instead, the audit log focuses on selected access and control events. It can show that a KVM session started, that paste was used, or that virtual media was mounted — but not what was typed, pasted, or visible on screen. Request bodies and live keyboard/mouse input over WebSocket are not stored.
The result: practical visibility
Audit logging makes TinyPilot deployments more explainable.
Administrators can review selected access events. Security teams can see failed login attempts and configuration changes. Support teams can understand whether a device was accessed during a troubleshooting window.
Audit logging is one part of a broader security model. It should be paired with restricted network access, HTTPS, user authentication, role-based access control, strong passwords, secure overlays where appropriate, and internal policies for who is allowed to access each device.
Our goal is to make TinyPilot adaptable enough to fit real customer environments without pretending that one device can solve every security or compliance requirement by itself.
Try the audit logging prototype
This is not a built-in TinyPilot feature. It is a reference implementation for teams that want to experiment with device-level audit logging in their own environment.
Events come from TinyPilot application logs and nginx access logs, so some entries include a username, others include a source IP and API path — rarely both on the same line.
By default, logs rotate daily and are kept on the device for 14 days.
View the TinyPilot audit logging prototype →
As with any change to a privileged access device, review the implementation before installing it, test it on a non-production unit first, and make sure it fits your access-control, log retention, and monitoring requirements.
If audit logging is important to your TinyPilot deployment, we would like to hear what events, formats, and integrations would be most useful.
Have a deployment requirement?
TinyPilot audit logging came from customer conversations.
If you're using TinyPilot in an environment with specific access, auditing, security, or workflow requirements, we'd like to hear how you're using it and how we can help.