SSL Is Not Security. Here Is What Actually Protects a WordPress Business Site.

The padlock in your browser address bar means your website is secure. That is what millions of business owners have been told, and it is a reasonable assumption given how HTTPS has been marketed for the past decade.

It is partially true. Which is the most dangerous kind of wrong.

SSL, more precisely TLS, encrypts the connection between your visitor's browser and your server. When a customer fills in a contact form, their name and email travel encrypted across the network. A third party sitting between the user and your server cannot intercept that data in transit. That is what the padlock certifies.

That is all the padlock certifies.

It says nothing about what is running on your server. Nothing about whether your WordPress plugins carry unpatched vulnerabilities. Nothing about your database configuration. Nothing about your file system permissions. Nothing about whether there is already malware sitting in your wp-content directory, quietly redirecting visitors to fraudulent pages.

During our operations review this week, I looked at three sites that came through our migration queue. All three had valid, up-to-date SSL certificates. All three had active security issues the certificate had no mechanism to detect. The padlock was green. Two had plugins with published exploit code. One had a modified core file.

What the Padlock Actually Certifies

SSL certificates come in several grades. The most common, and the type issued automatically by services like Let's Encrypt, is a Domain Validation (DV) certificate. To obtain one, you need to prove you control the domain. That is the entire verification process. No identity check, no review of the site operator, no confirmation the site is legitimate.

Free, automatically provisioned SSL should be standard practice. Web60 provisions and renews certificates automatically for every site on the platform. That is the right approach. The issue is not automatic SSL. The issue is that the industry spent years training users to treat the padlock as a safety signal, without being precise about what it actually certifies.

What it certifies: the connection between this browser and this server is encrypted.

What it does not certify: the server is hardened, the installation is secure, the backups have been verified, the plugins are patched.

According to the Anti-Phishing Working Group's phishing activity trend reports, more than 90% of phishing sites now carry valid HTTPS certificates ^[1]. The proportion has risen consistently over several years as free DV certificates became widely available. The padlock is present on pages designed to harvest card details and on pages processing legitimate transactions. A certificate authority cannot distinguish between the two, because it is not verifying intent. It is verifying domain control.

Why the Padlock Cannot Stop the Real Attacks

Here is the operational reality of how WordPress sites get compromised. The vast majority of attack vectors bypass SSL entirely.

Injection attacks. Cross-site scripting (XSS) and SQL injection attacks arrive as normal requests over a valid encrypted connection. The exploit payload targets vulnerabilities in plugins or themes at the application layer. The Wordfence 2024 Annual WordPress Security Report documented roughly 9 billion XSS exploit attempts blocked across their network during that calendar year ^[2]. Every one arrived over HTTPS. The defence is server-level request filtering and application hardening, not encryption.

Brute force login attempts. A credential-stuffing script connects to your WordPress login endpoint exactly as a legitimate user does, over an encrypted HTTPS session, then attempts thousands of password combinations per hour. SSL does not flag this as anomalous. Server-level intrusion prevention, specifically fail2ban monitoring authentication logs and blocking IP addresses that exceed login thresholds, is what intercepts it. That layer runs independent of what certificate is in place.

If your host does not have this configured, your access logs accumulate thousands of automated attempts per day. Most will fail. Some, eventually, will not. An attacker with a valid credential conducts an authenticated session that looks like any other.

Unpatched plugin vulnerabilities. The 2025 Verizon Data Breach Investigations Report, which analysed over 12,000 confirmed breaches, found that vulnerability exploitation accounts for roughly one in five of the initial attack vectors identified ^[3]. For WordPress sites, this means publicly disclosed plugin vulnerabilities with exploit code already in circulation. The gap between a CVE being published and active exploitation in the wild is regularly measured in hours. SSL does not patch a plugin. A defined update cycle with pre-deployment staging verification closes that window. Nothing else does.

Compromised credentials. Reused passwords, weak admin usernames, credential-stuffing attacks using leaked email and password combinations from unrelated breaches. An attacker with a valid credential conducts an authenticated session. The SSL connection looks exactly like a legitimate admin login. The difference is only visible to anomalous activity monitoring at the application layer.

Server-side file access. Any attacker who gains server access through a misconfigured permission, a compromised FTP credential, or a plugin that allows file writes is working inside the encrypted perimeter. SSL is not a relevant variable from that point.

What Server-Level Security Actually Requires

I am going to describe what a properly managed WordPress hosting environment deploys at the server level, because most discussions of website security focus on the application layer. The foundational decisions are made below it.

Intrusion prevention. fail2ban monitors authentication logs across SSH, the WordPress login endpoint, and other access points in the hosting environment. IP addresses that exceed defined login attempt thresholds are blocked automatically. This requires no WordPress plugin and no user action. It runs in the server environment and intercepts most brute-force attempts before they accumulate enough volume to become a credential threat.

The street-level consequence of not having this: a review of your raw access logs would show thousands of automated login attempts daily. Most fail. Some do not.

Automated malware scanning. Scheduled scans of WordPress file contents and database entries, looking for known malware signatures, modified core files, and injected code patterns. When a file in wp-content changes outside a legitimate update event, the scanner flags it. This is the layer that catches a compromise before your visitors' browsers display a security warning.

When Google's Safe Browsing service indexes a compromised WordPress site, the browser warning appears within hours. Not when the site owner notices something is wrong. Not after a call to the hosting provider. When the next customer types your domain and sees a red warning page. That is the operational reality of a compromise detected by Google rather than by your own host's scanner.

Hardened file system configuration. PHP execution disabled in directories with no legitimate execution need. The uploads folder is the critical one: writable by design, and a common target for malicious file uploads that then execute as scripts. Access to wp-config.php restricted at the server level. File permissions set to prevent unauthorised writes. These are server configuration decisions that operate independently of SSL.

Verified nightly backups. The backup runs nightly. The backup is verified. Earlier in my career I trusted a backup process without checking it was completing cleanly. Found out the restore points were incomplete when a client needed one. We corrected the process immediately. But the lesson was clear: a backup that has never been tested against a restore is not a backup. It is an unverified file archive. The stakes of finding out during an incident, rather than during a routine test, are substantially different.

Defined update cycles. WordPress core, plugins, and themes updated on a structured schedule, with staging environment verification before deployment to production. Not auto-updated directly to production, not left unpatched for months. A solicitor's practice in Sligo that came to us from a previous provider had fourteen active plugins. Four of them had publicly disclosed vulnerabilities. The SSL certificate had been valid and automatically renewed throughout. The vulnerabilities had been active and unpatched for longer than that. The certificate and the exposure coexisted with no contradiction.

None of the above involves SSL. All of it constitutes the actual security stack.

A Realistic Note on Ongoing Maintenance

Server-level security is not a one-time configuration. fail2ban rule sets, malware scan signatures, and firewall configurations need updating as threat patterns evolve. A security setup that was properly configured two years ago and has not been reviewed since is a materially different setup from one actively maintained. When assessing a managed hosting provider, the question is not only "do you have these layers in place?" but "how frequently are they reviewed and updated?" The honest answer to that question tells you more than any feature list.

What This Means for Choosing a Hosting Provider

The term "managed WordPress hosting" is applied to a wide range of products. Some providers manage the WordPress environment comprehensively, including the server-level security stack described above. Others manage the provisioning and availability, leaving application security largely to the site owner.

The SSL certificate looks identical in both cases.

Web60's hosting infrastructure includes fail2ban intrusion prevention, automated malware scanning, server-level hardening, and nightly backups with one-click restore as standard on every hosted site. These are not configuration options. They are the default state of every deployment on the platform.

There is a genuine trade-off worth acknowledging. For a large organisation running multiple WordPress deployments with a dedicated security team, building and maintaining a custom hardened server environment gives granular control that no shared managed platform fully replicates. That workload suits enterprise infrastructure managed by a technical team. But for a business running one or two sites without internal technical resource, having the security stack in place, maintained, and monitored as part of the hosting product removes a significant ongoing operational burden.

For a thorough overview of what a comprehensive WordPress security and backup strategy should include, the complete WordPress security and backup guide for Irish websites covers the full scope, from backup verification to hardening decisions.

If you want to understand what automated monitoring runs on a properly managed platform, what managed WordPress monitors and protects automatically covers the layered approach and the specific checks that run while your site is live.

Conclusion

SSL belongs in every website. The padlock should be standard, and in 2026 it is, including on a substantial proportion of the phishing pages designed to steal your customers' data.

But the padlock is one component in a security stack that requires independent layers operating at different levels: intrusion prevention at the network layer, malware scanning at the file system, hardened configuration at the server, verified backups on a defined schedule, and a structured patch cycle for all dependencies.

The certificate tells visitors their connection is encrypted. That is an accurate and useful signal.

Check what your hosting provider includes beyond that certificate. The rest of the stack is where the security work actually gets done.

Frequently Asked Questions

Does having HTTPS mean my website cannot be hacked?

No. HTTPS encrypts the connection between your visitor's browser and your server. It does not prevent attacks against your WordPress installation, including brute force login attempts, injection attacks via plugin vulnerabilities, or malware injected through compromised credentials. These attacks arrive through encrypted connections and SSL has no mechanism to detect or block them.

What is the difference between SSL and server-level security?

SSL encrypts data in transit. Server-level security covers everything else: intrusion prevention (blocking repeated login attempts), malware scanning (detecting compromised files), file system hardening (restricting what can execute and where), and backup integrity. SSL and server-level security are independent layers that address different parts of the attack surface. You need both.

Can phishing sites have HTTPS certificates?

Yes. According to the Anti-Phishing Working Group's phishing activity trend reports, over 90% of phishing sites now carry valid HTTPS certificates ^[1]. Domain-validated certificates require only that the applicant controls the domain. They do not verify the site's legitimacy or the operator's identity. The padlock tells you the connection is encrypted. It says nothing about who operates the site.

How do I know if my managed WordPress host includes security hardening?

Ask specifically about intrusion prevention (fail2ban or equivalent), scheduled malware scanning, server-level PHP execution restrictions in writable directories, and backup verification procedures. A host that lists SSL as a security feature without addressing these layers is describing the industry baseline, not a comprehensive security setup. The specificity of their answer tells you how much operational attention the security layer actually receives.

What should I do if my WordPress site is compromised despite having SSL?

Contact your hosting provider immediately and request a malware scan. Do not attempt to clean a live compromised site without a clean backup to restore from. Identify the entry point before patching: if you clean the malware without closing the vulnerability, the site will be reinfected. Managed WordPress hosting with verified nightly backups and one-click restore means recovery time is measured in hours rather than days spent rebuilding from scratch.

Sources