Security plugins are scanners and monitors. They detect known signatures, log login attempts, and alert you to problems that have already occurred. They do not close attack surfaces, they do not enforce authentication standards, and they do not configure your server to resist attack.
A genuinely hardened WordPress installation restricts what PHP can execute, removes information disclosure vectors, enforces strict Content Security Policy headers, disables functionality that exists for convenience but provides entry points for attackers, and limits privilege at the database level. These are configuration decisions, not plugin settings.
I have worked with NHS Scotland and financial sector clients where security posture is a compliance requirement, not a preference. The hardening methodology I apply reflects that standard, not a consumer-grade checklist.
One thing to understand about WordPress compromises: the most damaging ones show no obvious symptoms. A site operating as a link farm, serving spam to search engine crawlers while appearing clean to human visitors, can continue that way for months or years. The client in one of my case studies had been breached for eleven months before a routine audit caught it. The breach had not triggered a single alert. The security plugin had not reported anything unusual. The site was doing exactly what it looked like it was doing — serving normal pages — to anyone not specifically looking for the infection.