Separate application and hosting responsibilities
A patched server can still run an outdated Joomla extension or an overly privileged user account. Joomla’s core, templates, extensions, accounts and configuration need their own maintenance routine alongside the hosting platform.
Start with a short ownership record: who receives security notices, who can approve and apply updates, who manages users and who can restore the site. For a VPS, use the separate server maintenance guide as well.
Keep software supported
Maintain an inventory of Joomla, templates, extensions and the hosting runtime. Follow the Joomla Security Centre and each extension vendor’s security information. The centre describes resolved core issues; an extension’s own release notices may contain additional action you need to take.
Use a tested update process and remove unused components. Merely disabling something does not necessarily remove its files or exposure. Confirm what a proper uninstall removes and retain a backup before changing the live site.
Give users only the access they need
Use named accounts so that access can be reviewed and removed individually. An editor who publishes articles does not normally need hosting credentials or unrestricted control over every user and extension.
Review former staff and supplier accounts, recovery addresses and powerful group memberships. Protect hosting, registrar, DNS and email accounts too: control of one of those services can affect the website even if the Joomla password is strong.
Set up stronger authentication and recovery
For privileged accounts, evaluate Joomla’s supported MFA or passwordless options and test the chosen method on the actual devices people use. Keep backup and recovery arrangements accessible to the authorised owner without storing them publicly on the website.
Joomla provides several authentication methods, but their availability and behaviour depend on configuration. Fixed verification codes intended for demonstration are not suitable for production. Test both successful login and the recovery process before relying on a method for the only Super User.
The password recovery guide distinguishes ordinary site users from administrative recovery. A second factor and a password are separate parts of access recovery.
Treat extensions and uploads as trust decisions
Install extensions from their legitimate source, verify their release support and understand what data or remote services they access. A small convenience feature can introduce a continuing maintenance obligation.
Restrict file access according to your deployment model, keep sensitive backups and SQL exports outside publicly served folders, and remove temporary diagnostic scripts. Broadly making directories writable to suppress an error can create another problem; investigate the intended ownership and permissions instead.
Make a clean recovery possible
Keep independent backups of the application and database and perform an isolated restore drill. Record the Joomla and extension versions associated with the backup. A backup that already contains an intrusion is not a clean recovery point.
Monitor changes and failures that matter to this site: unexpected users, unexplained redirects, repeated login problems, altered files and missing backup runs. Where logs are available, limit access and keep only what is needed for operations and investigation.
Respond to suspected compromise
Contain the affected site, preserve useful evidence and involve the responsible administrator or host. Establish the entry point, review affected credentials and rebuild or restore into a clean, supported environment as appropriate. Reopening a restored copy without fixing the cause can repeat the incident.
A checklist helps organise the work; it does not certify a site as secure or replace investigation of an actual incident.
References: the Joomla Security Centre, MFA documentation, WebAuthn guide and user-management documentation.