Why Hypervisor Log Retention Must Live Off the Host

Hypervisor log retention must live off the host because whoever controls an ESXi or other hypervisor host can delete, rotate away or never write its local logs. Attackers who target virtualization platforms know this and use it. Plan retention so that the evidence of a hypervisor compromise is stored in systems the compromised host cannot touch, for long enough to cover how long intruders actually stay hidden.

Why is the hypervisor a special logging problem?

A hypervisor sits beneath every workload it runs, so one compromised host exposes many servers at once, while the guest operating systems cannot see what happens beneath them. Endpoint agents in guest VMs do not watch the hypervisor, and many hypervisors cannot run third-party security agents at all.

That leaves the hypervisor's own logs as the main record. On ESXi those logs are written locally by default, rotated after a small number of files, and controlled by the same administrator account an intruder wants. If the attacker holds that account, the main record is under their control.

What do attackers do to hypervisor logs?

Attackers clear logs, keep their actions from being logged, and run activity that never touches the logs defenders watch. All three appear in recent reporting.

CrowdStrike's December 2025 profile of the China-nexus group Warp Panda describes log clearing, file timestomping and unregistered VMs that were shut down after use on VMware infrastructure. In October 2026, CISA added the ESXi logging zero-day CVE-2026-41709 to the KEV catalog after CrowdStrike reported the same group used it to cut audit trail visibility. The flaw scored only 2.7 on CVSS, yet it was worth exploiting before a patch existed. Our explainer on insufficient logging vulnerabilities covers why that class scores low and still matters.

How long should you keep hypervisor logs?

Keep them at least as long as you would need to investigate an intrusion that went undetected for months. For most organizations that means a year or more in a central store, not the few files a host keeps locally.

The reason is dwell time. Espionage groups aim for long-term, quiet access, and the Warp Panda activity CrowdStrike describes ran from 2025 into early 2026. If your retention is 30 days, an investigation that starts in month four will find nothing from the initial access. Check any regulatory or contractual minimum you are bound by, then set the longer of the two.

Build retention on three independent records

No single log source survives a full host compromise. Plan for at least three that fail independently:

1. Forwarded host logs. Every ESXi host sends syslog to a remote collector over TCP or TLS. Our guide on how to forward ESXi syslog to a remote server covers the settings.
2. Management plane events. vCenter records tasks and events for actions it issues. Ship those to the same collector, but remember that vCenter itself has been a target, including through the vCenter CVE-2026-59310 attacks.
3. Network and identity records. Flow logs and firewall logs for management interfaces, plus authentication logs from your identity provider. These show who reached the hypervisor and when, even if the host hides what they did next.

When these three agree, you can trust the timeline. When one is silent and the others are not, you have found where to look.

Protect the collector like a crown-jewel system

Retention is only as strong as the place the logs land. Decisions to make up front:

• Separate administration. The team or account that runs vSphere should not be able to delete collector data. Use different credentials and, ideally, a different identity domain.
• Immutable storage. Use write-once or object-lock storage for the retention window, so even an administrator cannot shorten it quietly.
• Silence alerts. Alert when a host or vCenter stops sending logs. A sudden drop in volume deserves the same attention as a burst of failed logins.
• Integrity checks. Hash archived log files or use a platform that does, so you can show they were not altered.

Budget for the storage, not the incident

The usual objection is cost. Hypervisor syslog is mostly text and compresses well, so a year of it is usually a modest storage bill. Compare that with an incident response engagement that has no hypervisor evidence to work from, where responders must rebuild a timeline from guest systems and network traces alone. Set the retention target, size the storage against current log volume, and review it when you add hosts.

What to review this quarter

• Confirm every hypervisor host has a remote log host configured and is actually sending.
• Confirm the collector's retention meets your target and that vSphere administrators cannot change it.
• Patch known logging flaws on hypervisors with the same urgency as remote code execution bugs when they appear in KEV.
• Run one tabletop exercise that assumes the hypervisor logs were tampered with, and check which other records would still tell the story.