VPS Guide
Who Is Responsible for VPS Security
VPS security responsibility is split between provider and user along a boundary that most providers describe in terms-of-service language and most users discover during an incident.
Overview
A VPS is compromised. The user opens a support ticket. The provider confirms the physical host and network are functioning normally. They cannot assist with the incident — investigating a compromised guest OS, containing the damage, identifying the attack vector, and recovering the server are outside the provider's support scope on an unmanaged VPS. The provider's infrastructure is secure. The user's server is not. These are different security perimeters, and the provider is responsible for one of them.
How to think about it
The provider is responsible for the physical infrastructure: the hardware, the hypervisor, the network infrastructure, and the physical datacenter. If the physical host is compromised, that is the provider's failure to address. If the network infrastructure is attacked, that is the provider's problem to mitigate. If the hypervisor has a vulnerability that allows VM escape — a rare but documented class of vulnerability — that is the provider's security failure.
Everything above the hypervisor — the guest OS, the services running on it, the application, the application's dependencies — is the user's perimeter on an unmanaged VPS. An attacker who gains access to the guest OS through an application vulnerability, an unpatched OS package, or a weak SSH credential has breached the user's perimeter. The provider's infrastructure is unaffected. The provider's support team cannot help with the remediation.
How it works
On unmanaged VPS, the boundary is immediately above the provisioned OS image. The provider delivers a running virtual machine with a clean OS installation. Everything that happens after that point — packages installed, services configured, users created, firewall rules set, applications deployed — is in the user's security perimeter. The provider monitors that the VM is running and the network is connected. The security of what runs inside is the user's domain.
On managed VPS, the boundary moves upward. The provider takes responsibility for OS-level security: applying kernel patches, hardening the default configuration, monitoring for server-level intrusions, and in some cases responding to OS-layer security incidents. The application layer — the web application, its plugins and dependencies, its user management, its data handling — remains in the user's perimeter. The managed provider extended the boundary; they didn't eliminate the user's security responsibility.
Most security incidents that affect VPS users originate in the user's perimeter. Unpatched application vulnerabilities, weak or reused credentials, misconfigured services, outdated software with known CVEs — these are the access vectors for the overwhelming majority of VPS compromises. The provider's infrastructure security is not the limiting factor. The user's perimeter security is.
Where it breaks
The security boundary becomes contentious during incidents. A user on a managed VPS assumes the provider handles security, opens a ticket when the server is compromised, and discovers that the compromise originated in the application layer — outside the managed scope. The provider's response is technically correct and practically useless in the moment. Reading the managed scope carefully before an incident is significantly less stressful than reading it during one.
In context
Fully managed platforms — Kinsta, WP Engine, managed WordPress hosts — extend security responsibility further into the application layer. They monitor for malware in the application, apply CMS and plugin updates, run WAF rules specific to the application type, and often provide incident response that includes application-layer investigation. What the user gives up is configuration access and flexibility. What the user gains is a security perimeter that extends into the layer where most real-world attacks originate.
Unmanaged VPS places the full application security perimeter with the user. This is appropriate when the team has the expertise to maintain it. It requires tracking CVEs for every software component in the stack, applying patches on a schedule, monitoring for indicators of compromise, and having an incident response plan that doesn't depend on provider support. For teams that do this well, unmanaged VPS provides full control and full visibility. For teams that don't, the user's perimeter is the weakest point in the system.
From understanding to decision
The security responsibility question is worth answering before the provider comparison: what security tasks does the workload require, who will perform them, and what happens when something goes wrong? If the answers are clear, the infrastructure choice that matches them is also clearer. If they're not, that gap is worth closing before it becomes an incident.
Related
Where to go next
© 2026 Softplorer