{"id":82827,"date":"2026-05-05T15:50:24","date_gmt":"2026-05-05T19:50:24","guid":{"rendered":"https:\/\/www.inmotionhosting.com\/blog\/?p=82827"},"modified":"2026-05-05T15:50:29","modified_gmt":"2026-05-05T19:50:29","slug":"dedicated-server-vs-shared-hosting-security-configuration","status":"publish","type":"post","link":"https:\/\/www.inmotionhosting.com\/blog\/dedicated-server-vs-shared-hosting-security-configuration\/","title":{"rendered":"Dedicated Server vs. Managed Shared Hosting: Who Controls Your Security Configuration?"},"content":{"rendered":"\n
\"Dedicated<\/figure>\n\n\n\n

On managed shared hosting, the hosting provider controls the server configuration. <\/p>\n\n\n\n

They decide which TLS versions to support, how security headers are applied, when software gets patched, and what you’re allowed to change. On a dedicated server, you do. That distinction doesn’t matter much when everything is running fine. It matters a great deal when a security audit, a vendor risk review, or a SecurityScorecard report flags specific issues your current environment won’t let you address.The honest answer to that question is: it depends on who owns the server.<\/p>\n\n\n\n

This article explains exactly what security configuration decisions live at the server level, why managed hosting environments limit your access to them, and what actually changes when you move to a dedicated server with root access.<\/p>\n\n\n\n

What Does “Managed” Mean for Security?<\/h2>\n\n\n\n

Managed hosting is a tradeoff, not a flaw. The provider handles the infrastructure so you can focus on your site. That includes server setup, software updates, hardware maintenance, and yes, security configuration. The result is a faster path to a running site, with less technical overhead.<\/p>\n\n\n\n

The tradeoff is that “managed” also means “configured by someone else.” The web server, the operating system, the firewall, the TLS stack \u2014 those components are configured according to the provider’s standards, not yours. Their standards are set once, applied broadly across a shared environment serving many customers, and updated on the provider’s timeline.<\/p>\n\n\n\n

That works well for the vast majority of hosting needs. For businesses that need to meet specific security benchmarks, satisfy enterprise procurement requirements, or fix findings on an external security rating, it creates a ceiling that’s difficult to work around without changing hosting environments.<\/p>\n\n\n\n

What Security Decisions Live at the Server Level?<\/h2>\n\n\n\n

Several security configurations exist entirely outside your application code and outside your content management system. They’re set in the web server software \u2014 Apache, cPanel, Nginx, or LiteSpeed \u2014 and in the operating system configuration. The WordPress admin panel, cPanel file manager, and even FTP access don’t touch them.<\/p>\n\n\n\n

TLS protocol versions.<\/strong> Whether your server accepts TLS 1.0, 1.1, 1.2, or 1.3 connections is controlled in the web server’s SSL configuration file. TLS 1.0 and 1.1 were deprecated by the IETF in 2021 due to known cryptographic vulnerabilities. Whether they remain enabled on your site depends entirely on what the server is configured to accept.<\/p>\n\n\n\n

Cipher suites.<\/strong> Which encryption algorithms your server advertises during the TLS handshake is a separate, adjacent configuration. Weak cipher suites \u2014 those using RC4, 3DES, or export-grade key lengths \u2014 appear as distinct findings on security scoring platforms even when you’ve upgraded TLS versions. Removing them requires editing the same server-level configuration.<\/p>\n\n\n\n

HTTP security headers.<\/strong> Headers like HTTP Strict Transport Security (HSTS), Content Security Policy (CSP), X-Content-Type-Options, and X-Frame-Options are sent by the web server with every HTTP response. Adding them reliably requires either a directive in the web server’s virtual host configuration or an .htaccess rule on Apache servers. The web server sends them before the application layer ever processes the request.<\/p>\n\n\n\n

Certificate configuration.<\/strong> The signature algorithm, revocation support (OCSP stapling), and deployment options for a TLS certificate are set when the certificate is installed and configured on the server. An application plugin can’t change these after the fact.<\/p>\n\n\n\n

Software patching cadence.<\/strong> Which version of PHP, OpenSSL, and the Linux kernel is running on the server is determined by whoever manages package updates. How quickly a critical CVE gets patched \u2014 versus how quickly it appears in a scan \u2014 depends on that person’s schedule and authority.<\/p>\n\n\n\n

What Security Settings Does Managed Hosting Control on Your Behalf?<\/h2>\n\n\n\n

Managed WordPress hosts handle security well within their model. WP Engine, for example, provides a managed firewall that blocks common attacks, automated plugin updates, and around-the-clock monitoring with rapid response to threats and malware. These protections are real, and for many sites they’re sufficient.<\/p>\n\n\n\n

The constraint is that the security decisions are the provider’s to make, not the customer’s.<\/p>\n\n\n\n

WP Engine closely manages certain settings in order to protect server performance or for security purposes. Their platform documentation lists a set of configurations that customers cannot change independently. Some require submitting a support request with no guaranteed timeline. Revisions in WordPress, for example, cannot be enabled in the wp-config.php or php.ini files, because those settings will be overwritten at the server level.<\/p>\n\n\n\n

On TLS, WP Engine has deprecated TLS 1.0 and 1.1 across the platform, and customers don’t have the option to defer or opt into a version lower than TLS 1.2. That’s good security practice, and it resolves those specific findings. But the inverse is also true: customers cannot push beyond the platform’s TLS defaults, cannot select specific cipher suite configurations, and cannot make certificate deployment decisions that differ from what the platform provides.<\/p>\n\n\n\n

For HTTP security headers, the situation requires careful reading. Adding security headers from within WordPress \u2014 through a plugin or a custom functions.php entry \u2014 is possible, but it’s application-layer delivery. A security scanner checking what the server sends at the network level may not see these headers the same way as headers set in the web server configuration. HTTP security headers work best when they are set at the web server level, which means your hosting account. On a managed platform, whether those headers get set at the server level, or how the CDN layer between the customer and the origin server handles them, is the provider’s decision. On WP Engine’s Advanced Network, traffic routes through Cloudflare at the DNS level. What headers Cloudflare passes, strips, or modifies in transit depends on how WP Engine has configured that integration, not on what you put in an .htaccess file.<\/p>\n\n\n\n

Why Is Content Security Policy So Difficult to Fix on Managed Hosting?<\/h2>\n\n\n\n

Content Security Policy<\/a> is the most commonly flagged missing header in external security audits. CSP tells the browser exactly which sources of scripts, styles, images, and other assets are permitted to load on your pages. A missing CSP is a reliable finding on SecurityScorecard, SecurityHeaders.io, and most PCI compliance scans.<\/p>\n\n\n\n

Implementing CSP correctly requires two things: a defined policy tailored to your site’s specific resource dependencies, and reliable delivery of that policy header with every response. The second part is the problem in managed environments.<\/p>\n\n\n\n

On an Apache server, you can add a CSP directly to your .htaccess file, which applies the policy site-wide and is more secure than using meta tags. On an Nginx server, you add it to the server block in the virtual host configuration. Both methods require the ability to write to and reload server configuration files. On a managed WordPress platform, those files belong to the provider.<\/p>\n\n\n\n

Plugins can inject CSP headers via PHP’s header()<\/code> function, but this creates several failure modes: caching layers may suppress or override PHP-generated headers, CDN edge nodes may not propagate them consistently, and any CDN configuration change by the provider can silently break delivery. Environments where you’re unable to access raw server files via cPanel, FTP, or SSH require using a plugin approach, which carries more implementation risk.<\/p>\n\n\n\n

The result is a situation where you can do the work to implement a CSP, confirm it’s “working” in your browser, submit a support ticket requesting server-level configuration, and still have the header appear inconsistently in an automated scan.<\/p>\n\n\n\n

How Does a Dedicated Server Change Your Security Configuration Options?<\/h2>\n\n\n\n

Root access means you own the configuration. Every security decision described above becomes a configuration file you can edit, reload, and verify.<\/p>\n\n\n\n

Disabling TLS 1.0 and 1.1 on an Apache server requires one line in the SSL configuration and a service reload. Adding cipher suite restrictions \u2014 removing RC4, 3DES, and export grades \u2014 takes about five additional lines. These changes take effect immediately and can be verified with tools like openssl s_client<\/code> or Qualys SSL Labs<\/a> before and after.<\/p>\n\n\n\n

Adding HSTS to every response is a single directive in the virtual host block:<\/p>\n\n\n\n