Securing Proxmox VE After a VMware Migration: A Practical Hardening Checklist for SMBs
The default Proxmox install ships fine for a home lab. Production is different. Here is the hardening checklist your migration plan probably skipped.
By William Bradshaw | April 13, 2026 | 9 min read
Proxmox VE is a production-grade hypervisor, and the migration from VMware is more straightforward than most SMB teams expect. That is precisely the problem. Teams complete the technical migration (convert the VMDKs, import the VMs, confirm workloads are running) and declare victory before touching the security configuration. The new platform inherits the same default settings it shipped with, which were designed for a trusted home-lab environment, not a production network handling customer data.
This checklist covers the five hardening areas every SMB should address after a VMware migration before calling the Proxmox environment production-ready. For the migration itself, see our VMware migration checklist and complete ESXi to Proxmox migration guide. This article picks up where those leave off.
Why Post-Migration Hardening Matters
Proxmox VE ships with reasonable defaults for a trusted environment. Most SMB networks do not qualify. After a VMware migration, teams are focused on getting workloads running, and security configuration gets deprioritized. The result is a new hypervisor running production workloads with home-lab-grade defaults.
This is not theoretical. Proxmox's web management interface runs on port 8006 and is often left reachable from the full internal network. The root account is enabled by default. Corosync cluster traffic (if you are running HA) is frequently misconfigured to share a network segment with guest VMs. None of this is acceptable in a production environment handling customer data, financial systems, or regulated workloads.
The good news: locking this down takes a few hours, not days. Here is the sequence.
Migration is exactly when ransomware and opportunistic attackers look for exposure. Newly migrated environments often have more open ports and weaker access controls than production environments that have been hardened over time.
Authentication and Access Hardening
Authentication is the first and highest-value hardening target. These changes should be made before anything else.
Disable Root SSH Login
Edit /etc/ssh/sshd_config and set PermitRootLogin no. Create a named admin user and add it to the sudo group. Restart SSH with systemctl restart sshd. Direct root SSH access is a significant attack surface. Removing it forces all administrative sessions through a named, auditable account.
Enable Two-Factor Authentication on the Web UI
In the Proxmox web interface, navigate to Datacenter → Permissions → Two Factor. Add a TOTP authenticator for each admin account. This applies to the web UI login at port 8006, one of the highest-value hardening steps you can take on a Proxmox installation, and one that is skipped by default.
Restrict Web UI Access
The Proxmox management interface should only be reachable from your management VLAN or VPN. Configure your firewall (or Proxmox's built-in datacenter firewall) to block port 8006 from guest VM networks and untrusted segments. If you are not using a dedicated management VLAN, at minimum restrict access to specific management workstation IPs.
Audit Realm Configuration
- • Under Datacenter → Realms, remove any unused authentication realms
- • If you added LDAP or Active Directory integration during migration testing and no longer need it, remove it
- • Review all user accounts in Datacenter → Permissions → Users, and remove any test accounts created during migration
After making SSH changes, always test the new login in a separate terminal before closing your existing session. Locking yourself out of the Proxmox host during hardening requires console access to recover.
Network Exposure Reduction
Network misconfiguration is the most common source of post-migration exposure. The Proxmox firewall is capable and layered, but it requires explicit configuration to be effective.
Configure the Proxmox Firewall in Layers
Proxmox's built-in firewall operates at three levels: datacenter (applies globally), node (per-host), and VM or container (per-workload). Enable it at all three levels. Start with datacenter-level rules that block inbound access to management ports (8006, 22, 3128) from guest VM networks. Work down to node-level rules, then VM-level rules for any workloads that require individual network policies.
Separate Management Traffic
Create a dedicated Linux bridge for management traffic (the Proxmox web UI and SSH) separate from the bridge used by guest VMs. This is a network architecture change, but it is the correct long-term posture for any production Proxmox deployment. If you cannot implement this immediately, use VLAN tagging to isolate management traffic as an interim control.
Isolate Corosync (Cluster Network)
If you are running Proxmox in a cluster for high-availability, the Corosync cluster traffic must travel on a dedicated, isolated network. Corosync uses multicast or unicast UDP and should never share a network segment with guest VM traffic. Misconfigured cluster networking is one of the most common exposures in hastily migrated environments. A guest VM on the same segment as Corosync can potentially interfere with cluster quorum.
Disable Unused Services
-
•
Check running services:
systemctl list-units --type=service --state=running - • Disable SPICE if you are not using remote desktop via the SPICE protocol
- • Review any services enabled during migration testing that are not needed in production
- • Confirm the Proxmox host is not running any services that were installed for temporary migration tooling (e.g., temporary NFS exports, rsync daemons)
Network segmentation is a compensating control that buys time when other defenses fail. Even with strong authentication, limiting lateral movement from a compromised guest VM to the hypervisor management plane is essential in any production environment.
Storage and Backup Security
Backups are the last line of defense against ransomware. Unencrypted backups on the same network segment as production VMs are not a meaningful safety net. Ransomware operators know to look for and destroy backup targets before encrypting primary storage.
Encrypt Backups at Rest
Proxmox Backup Server supports AES-256 encryption natively. Configure encryption on your backup jobs before enabling automated scheduling. The encryption key should be stored separately from the backup media, not on the Proxmox host itself. Backups of production VMs without encryption at rest are a data exposure risk if backup media is ever lost, stolen, or accessed by an unauthorized party.
Restrict Storage Permissions
- • In the Proxmox web UI, review Datacenter → Storage → Permissions
- • Storage targets should be accessible only to the roles that require them
- • A backup storage target should not be writable by guest VM owners or non-admin roles
- • If using NFS for backup storage, restrict NFS exports to the Proxmox Backup Server IP only, not the full subnet
Maintain an Off-Site or Air-Gapped Backup Copy
The migration window is the highest-risk period for a ransomware event. Your environment is in flux, monitoring is looser, and new configurations may have opened unexpected exposure. Before decommissioning the VMware environment, confirm you have a backup copy that is isolated from the primary environment: tape rotation, cloud backup to a separate provider, or a physically separate Proxmox Backup Server instance on a different network segment.
Test Restoration Before Going Live
A backup you have not tested is not a backup. Restore at least one non-critical VM from the Proxmox Backup Server before declaring the migration complete. Confirm the VM boots, services start, and data is intact. Document the restoration time so you have a realistic RTO estimate.
Encryption and off-site copies are both required. Encryption without off-site means a single physical event (fire, flood, theft) destroys all copies. Off-site without encryption means the remote copy is a liability if that facility is compromised.
Patch and Monitor
A hardened configuration drifts without ongoing patching and monitoring. The steps below establish the operational baseline for keeping the Proxmox environment in a known-good state after the initial hardening is complete.
Subscribe to Security Advisories
The Proxmox security mailing list (security-announce@lists.proxmox.com) delivers advisories without requiring an enterprise subscription. Subscribe before you go live. Critical vulnerabilities in the KVM hypervisor layer or the Proxmox web UI are rare but serious. You want notification the day a patch is released, not weeks later.
Automate Security Updates
Install unattended-upgrades and configure it to automatically apply security updates from the Proxmox security repository. Review the /etc/apt/apt.conf.d/50unattended-upgrades config to confirm Proxmox repos are included alongside the standard Debian security repository. Set maintenance windows that align with your change management process.
Run a Post-Migration Vulnerability Scan
After hardening, a network vulnerability scan against the Proxmox host and its guest VMs validates your work and catches misconfigurations you may have missed. This is exactly the kind of validation that a tool like netvuln-tool is built for: scan the new environment, compare against your pre-migration baseline, and confirm you have not introduced new exposure through the migration and hardening process.
The netvuln-tool Approach
Run netvuln-tool against your Proxmox environment post-migration to validate the hardening steps above. The scan will surface any open management ports, default credentials, weak SSH ciphers, and certificate issues that your checklist may have missed. See how netvuln-tool works →
Establish a Monitoring Baseline
- • Set up resource monitoring alerts in Proxmox for CPU, memory, and storage I/O. Unusual VM resource consumption can be an early ransomware indicator
- • Configure alert notifications (email or webhook) so anomalies surface in real time, not during a weekly review
- • Schedule periodic vulnerability scans: at minimum quarterly, or after any significant configuration change
Post-Hardening Validation Checklist
Work through this list before declaring the Proxmox environment production-hardened. Every item should have a confirmed status.
- ✓ Root SSH login is disabled and tested from an external terminal
- ✓ Named admin user created with sudo access and SSH key authentication
- ✓ 2FA enabled on Proxmox web UI for all admin accounts
- ✓ Web UI (port 8006) not reachable from guest VM networks or untrusted segments
- ✓ Proxmox datacenter firewall enabled with management port restrictions in place
- ✓ Corosync cluster traffic on isolated network unreachable from guest VMs (if HA configured)
- ✓ Backup encryption enabled on all Proxmox Backup Server jobs
- ✓ Restoration test completed successfully on at least one VM
- ✓ Off-site backup copy confirmed before VMware environment is decommissioned
- ✓ Proxmox security advisory mailing list subscription confirmed
- ✓ unattended-upgrades configured and confirmed pulling from Proxmox security repos
- ✓ Post-migration vulnerability scan completed with no critical or high findings outstanding
Need Help Securing Your Proxmox Environment?
Bullium provides security assessments, Proxmox deployment reviews, and managed vulnerability scanning for SMB and mid-market IT teams.