Cybersecurity is often discussed in terms of software: firewalls, encryption, intrusion detection systems, and patch management. These controls matter. However, they all operate on top of an infrastructure layer. That layer determines your fundamental security posture before you configure a single rule.
The infrastructure choice: shared, virtualised, or physically isolated, determines which categories of attack are structurally possible against your environment. Some attack vectors exist only in shared environments. Software controls cannot mitigate them because they exploit the shared hardware itself. Physical isolation eliminates these attack categories entirely. It does so not by defending against them, but by removing the shared hardware that makes them possible.
This guide explains the specific attack vectors that shared infrastructure introduces, why software controls cannot fully address them, and how physical isolation on dedicated servers changes your security baseline.
📖 How do dedicated servers improve data security overall?
Read How Dedicated Servers Improve Data Security for Online Businesses, a complete guide to the security advantages of physical isolation, full configuration control, encryption, and compliance support on dedicated infrastructure.
The Security Problem With Shared Hardware
To understand why isolation matters, it helps to understand precisely what is shared in a virtualised or shared hosting environment, and what that sharing enables.
When multiple tenants share a physical server, the following hardware components are shared:
CPU and CPU cache – All processes on the same physical machine share the processor’s L1, L2, and L3 caches. These caches store recently accessed data to improve performance. Critically, they store this data regardless of which process accessed it or which tenant it belongs to.
Memory bus – The pathway between the CPU and RAM is shared across all processes on the physical machine. High-memory-bandwidth operations by one tenant affect memory access latency for all others.
Network interface – The physical network interface card handles all traffic for all VMs on the host. While virtual switches provide logical isolation, the physical NIC and its buffers are shared.
Storage controllers – Disk I/O from all tenants passes through the same physical storage controller, creating I/O contention and, in some configurations, timing side channels.
Each of these shared components is a potential attack surface. Software controls can limit what data flows between them, but they cannot eliminate the fact that the components themselves are shared.
Side-Channel Attacks – The Threat That Software Cannot Block
Side-channel attacks are the most technically significant security risk of shared hardware, and the one that most clearly demonstrates why software isolation has limits.
Spectre and Meltdown
In January 2018, security researchers disclosed two hardware vulnerabilities affecting virtually every modern processor manufactured since the 1990s: Spectre and Meltdown. Both exploit the CPU’s speculative execution feature, an optimisation that predicts which instructions will be needed next and executes them in advance to reduce latency.
Meltdown allows a malicious process to read kernel memory that should be inaccessible. In a virtualised environment, this means a process in one VM can, under certain conditions, read memory belonging to the hypervisor or other VMs on the same physical host.
Spectre is broader and more difficult to patch. It exploits the branch prediction component of speculative execution to cause processes to reveal their memory contents through the shared CPU cache. Unlike Meltdown, Spectre works across process boundaries even with software isolation in place, because it exploits the timing of cache access rather than direct memory access.
Both vulnerabilities were patched through software updates, but the patches introduced performance overhead, in some cases 10–30% on I/O-intensive workloads. Furthermore, variants of these attacks continue to be discovered, because the underlying mechanism, shared CPU cache with speculative execution, is fundamental to how modern CPUs achieve performance.
On a dedicated server, these attacks are irrelevant. There are no co-located processes to attack from, and no co-located attackers to attack you. The shared CPU cache contains only your processes.
Cache Timing Attacks
Beyond Spectre and Meltdown, a broader class of cache timing attacks exploit the shared CPU cache to extract information about other processes. The fundamental mechanism is straightforward: by measuring how long it takes to access specific memory locations, an attacker can determine whether those locations are in the cache, which reveals information about what other processes have recently accessed.
Applied to cryptography, cache timing attacks have been demonstrated to extract private keys from co-located processes by measuring the cache access patterns of encryption operations. While these attacks require significant technical sophistication, they represent a real threat for environments handling high-value cryptographic material, private keys, payment credentials, authentication tokens.
Physical isolation eliminates this attack class because the attacker and target do not share a CPU cache.
📖 Bare metal vs virtualised servers, the security comparison
Read Bare Metal Servers vs Virtualised Servers: What’s the Real Difference?, a complete comparison of physical and logical isolation models, including the security implications of each architecture.
Hypervisor Vulnerabilities – When the Isolation Layer Fails
VPS and cloud environments rely on a hypervisor to provide logical isolation between tenants. The hypervisor is the software layer that divides the physical machine into multiple virtual machines and enforces the boundaries between them.
The security of a VPS environment is only as strong as the hypervisor. When the hypervisor has a vulnerability, that isolation fails, potentially allowing one VM to access another’s memory, network traffic, or storage.
Hypervisor vulnerabilities are rare but real. A selection of significant examples:
VENOM (2015) – A buffer overflow in the virtual floppy disk controller in QEMU (used by KVM and Xen) allowed an attacker with access to a guest VM to escape the VM and execute code on the host. All VMs on the same host were potentially exposed.
Cloudburst (2009) – A VMware Workstation vulnerability allowed code execution on the host from within a guest VM, demonstrating VM escape on a widely deployed hypervisor.
KVM nested virtualisation vulnerabilities – Multiple vulnerabilities in KVM’s nested virtualisation implementation have allowed privilege escalation from guest to host.
Each of these vulnerabilities, at the moment of disclosure, represented a period of exposure for all tenants co-located on affected infrastructure. Patching requires hypervisor updates that typically require brief downtime for the host, affecting all VMs simultaneously.
On a dedicated server, there is no hypervisor. There is no software isolation layer that can fail. The only isolation is physical, hardware that belongs entirely to you.
📖 The complete security hardening checklist for dedicated servers
Read Dedicated Server Security Checklist: How to Harden Your Server After Setup, a phase-by-phase guide covering every security control that physical isolation makes possible, from SSH hardening to WAF installation.
Lateral Movement – Containment as a Security Property
In security, lateral movement refers to an attacker’s ability to move from one compromised system to other systems in the same environment. Containing lateral movement, limiting how far a successful breach can spread, is a fundamental principle of security architecture.
In shared virtualised environments, lateral movement has additional pathways that do not exist in physically isolated infrastructure.
VM-to-VM Lateral Movement
After a hypervisor vulnerability allows an attacker to escape a compromised VM, they have access to the hypervisor, from which all other VMs on the same host are reachable. This effectively turns a breach of one tenant’s environment into access to all tenants on the same physical host.
Furthermore, even without a hypervisor escape, VMs on the same host share network infrastructure at the physical layer. While virtual switches enforce logical separation, misconfigurations, VLAN hopping attacks, and ARP spoofing in the virtual network layer create lateral movement opportunities that physical network separation eliminates.
Supply Chain and Shared Component Vulnerabilities
In shared environments, multiple tenants share the same base images, the same hypervisor version, the same network infrastructure, and the same management plane. A vulnerability in any shared component affects all tenants simultaneously.
On dedicated infrastructure, your server has no shared components with any other customer. A vulnerability affecting another customer’s environment does not affect yours because there are no shared components through which it can propagate.
IP Reputation and Shared Network Identity
On shared hosting environments, multiple customers share the same IP address or the same IP subnet. This creates a security dependency that is entirely outside your control.
If another customer on the same shared hosting environment sends spam, their activity, and consequently your shared IP’s reputation, is affected. Email deliverability suffers for all customers sharing the IP. Some security tools and email servers block entire IP ranges associated with known spam or malicious activity.
Furthermore, if another customer’s site is compromised and used to host malware, phishing pages, or command-and-control infrastructure, the IP address of the entire shared hosting environment may be listed in threat intelligence feeds, affecting all customers sharing that IP.
A dedicated server has a dedicated IP address. Your IP’s reputation is determined entirely by your own activity. No other customer’s security posture affects your network identity.
📖 How does DDoS protection work on dedicated infrastructure?
Read What Is DDoS and How Does It Affect Your Website?, a complete guide to DDoS attack types and how network-level and application-level mitigation work on dedicated infrastructure.
Resource Exhaustion as a Denial-of-Service Vector
In shared environments, resource exhaustion by one tenant can affect the availability of all tenants on the same host. This is typically discussed in the context of the noisy neighbour problem for performance, but it has direct security implications for availability.
A malicious tenant on the same shared host can intentionally consume CPU, RAM, network bandwidth, or disk I/O to degrade or deny service to other tenants. This is a denial-of-service attack that does not require any network-facing exploitation, it operates entirely through shared hardware resource consumption.
Furthermore, a compromised tenant whose server has been enrolled in a botnet may generate outbound traffic or perform compute-intensive operations (such as cryptocurrency mining) that consume resources affecting all co-located tenants.
On a dedicated server, no other tenant shares your hardware. Resource exhaustion by any external party does not affect your availability unless it comes through the network, at which point it is a conventional DDoS attack that your provider’s network-level mitigation addresses.
Compliance – Physical Isolation as a Documented Requirement
Several compliance frameworks treat physical isolation as either a requirement or a significant simplification factor. Understanding why helps explain why regulators and auditors favour dedicated infrastructure.
PCI-DSS – The Payment Card Industry Data Security Standard requires that the Cardholder Data Environment is isolated from other systems. Physical isolation on dedicated hardware provides the clearest implementation of this requirement. Shared virtualised environments require additional documentation to demonstrate that the logical isolation between the CDE and other tenants is sufficient.
GDPR – Article 32 of GDPR requires that appropriate technical and organisational measures protect personal data. Physical isolation is one of the strongest technical measures available, it eliminates the cross-tenant attack surfaces that exist in shared environments entirely rather than mitigating them.
HIPAA – The Health Insurance Portability and Accountability Act’s Security Rule requires safeguards protecting electronic Protected Health Information. Physical infrastructure isolation directly supports the access control, audit control, and integrity requirements of the Security Rule.
ISO 27001 – The international standard for information security management requires risk assessment and the implementation of controls appropriate to identified risks. Physical isolation eliminates entire categories of identified risk, side-channel attacks, hypervisor vulnerabilities, lateral movement via shared components, rather than adding controls to manage them.
📖 How does dedicated infrastructure support PCI-DSS compliance?
Read How Dedicated Servers Support PCI-DSS Compliance, a complete guide to how physical isolation, network segmentation, and full configuration control support the most infrastructure-intensive PCI-DSS requirements.
What Physical Isolation Does Not Address
Physical isolation is not a complete security solution. It is one layer of a defence-in-depth strategy. Understanding what it does and does not protect against prevents overconfidence.
Physical isolation does not prevent network-based attacks. Your dedicated server is still reachable from the internet. SQL injection, credential brute-forcing, and application-layer attacks all arrive through the network and are unaffected by infrastructure isolation. These require application-level controls: input validation, rate limiting, WAF rules, and strong authentication.
Physical isolation does not prevent insider threats. An administrator with legitimate access to the server can exfiltrate data regardless of physical isolation. Access controls, multi-factor authentication, audit logging, and separation of duties address this risk.
Physical isolation does not prevent supply chain attacks. If your application depends on third-party libraries, those dependencies are a potential attack vector regardless of your infrastructure model.
Physical isolation does not replace patching. The OS, web server, database, and application code still require regular security updates. Unpatched software vulnerabilities are the most common cause of successful attacks on dedicated servers.
Physical isolation is a foundational security property that eliminates specific attack categories. The remaining attack surface is addressed by the security controls you implement on top of the isolated infrastructure.
📖 What security controls should you implement on a dedicated server?
Read Dedicated Server Security Checklist: How to Harden Your Server After Setup, a comprehensive phase-by-phase guide to the security controls that complement physical isolation and protect against the attack vectors it does not address.
Build on Infrastructure That Eliminates Risk at the Foundation
Swify’s dedicated servers give your business physical isolation, full hardware control, European datacenters, and network-level DDoS protection, the security foundation that shared environments cannot provide.
→ Explore Swify Dedicated Server PlansFrequently Asked Questions
FAQ 1 :: What is a side-channel attack and does physical isolation prevent it?
A side-channel attack extracts information from a system by observing indirect signals: timing, power consumption, electromagnetic emissions, or cache access patterns, rather than directly accessing protected data. Cache timing attacks and Spectre are the most significant side-channel attacks for server infrastructure. They exploit shared CPU cache to infer what other processes have recently accessed. Physical isolation prevents these attacks because the attacker and target no longer share a CPU cache, the shared hardware through which the attack operates does not exist when hardware is dedicated to a single tenant. Read Bare Metal Servers vs Virtualised Servers: What’s the Real Difference? for a full comparison of the security models.
FAQ 2 :: What is a hypervisor escape attack?
A hypervisor escape is an attack where malicious code running inside a virtual machine exploits a vulnerability in the hypervisor to gain access to the host system or other VMs on the same physical host. Notable examples include VENOM (2015), which affected KVM and Xen hypervisors, and Cloudburst (2009) in VMware. While these attacks are rare, they demonstrate that software-enforced isolation has fundamental limits. On a dedicated server, there is no hypervisor, so hypervisor escape attacks have no attack surface to exploit. The isolation is physical, not software-enforced.
FAQ 3 :: Does physical isolation protect against DDoS attacks?
Physical isolation prevents a specific DDoS-adjacent risk: resource exhaustion by other tenants. On shared hosting, a compromised co-located site generating malicious traffic can consume bandwidth and compute resources affecting all tenants. On a dedicated server, this cannot happen because there are no co-located tenants. For conventional DDoS attacks originating from the internet, dedicated server providers at enterprise datacenters provide network-level mitigation that scrubs volumetric attack traffic before it reaches your server. Read What Is DDoS and How Does It Affect Your Website? for a complete guide to DDoS protection.
FAQ 4 :: Why does shared hosting affect my IP reputation?
On shared hosting, multiple customers share the same IP address. If another customer sends spam, engages in malicious activity, or has their site compromised, that IP address may be added to email blocklists or threat intelligence feeds. All customers sharing the IP are affected, regardless of their own behaviour. This can result in email deliverability failures, being blocked by security tools, and reputational damage caused entirely by another customer’s actions. A dedicated server has a dedicated IP address, and your IP’s reputation depends only on your own activity. Read Why Dedicated Servers Deliver Superior Performance Compared to Shared Hosting for a full comparison of shared vs dedicated infrastructure.
FAQ 5 :: Is physical isolation required for GDPR compliance?
GDPR does not explicitly mandate physical isolation, but it requires appropriate technical and organisational measures to protect personal data. Physical isolation is one of the strongest available technical measures, it eliminates cross-tenant attack surfaces entirely rather than mitigating them with controls. For businesses handling significant volumes of personal data or operating in regulated sectors, physical isolation on a European datacenter dedicated server provides unambiguous data residency and a stronger compliance posture than shared environments. Read Dedicated Servers and GDPR: What You Need to Know for a full breakdown of GDPR infrastructure requirements.
FAQ 6 :: Does a dedicated server prevent all cyberattacks?
No, physical isolation eliminates specific attack categories but does not protect against all threats. Network-based attacks (SQL injection, credential brute-forcing, application vulnerabilities) arrive through the internet and are unaffected by infrastructure isolation. Insider threats from legitimate administrators require access controls and audit logging. Supply chain attacks through third-party dependencies require code review and dependency scanning. Physical isolation is a foundational security property that removes the attack surface specific to shared hardware. The remaining attack surface requires application-level security controls implemented on top of the isolated infrastructure. Read Dedicated Server Security Checklist: How to Harden Your Server After Setup for the complete guide to controls that complement physical isolation.