Hardening: meaning

In short

Almost every product leaves the factory configured to work straight away, not to be secure: services enabled "for convenience", default passwords, old protocols switched on for compatibility. Hardening reverses this approach: only what is needed is enabled, with the minimum privileges required. Every service removed is one less piece of attack surface.

How it works

Typical steps:

• changing default credentials and disabling unused accounts;
• uninstalling software and disabling services and ports that are not needed;
• disabling obsolete protocols, such as SMBv1 or TLS versions earlier than 1.2;
• applying the principle of least privilege to users and services, and separating administrative accounts from everyday ones;
• enabling event logging, disk encryption, screen lock and multi-factor authentication;
• in cloud services: restricting external sharing, consents for third-party apps and automatic mail forwarding.

There is no need to invent the rules from scratch: the CIS Benchmarks, vendors' guides and those of national agencies offer reference configurations system by system. In the CIS Controls, secure configuration of devices and software is control number 4.

Why it matters

Many incidents exploit not sophisticated vulnerabilities but weak configurations: an exposed administration panel, an account without MFA, a folder shared with everyone. Hardening, however, is not a one-off job: configurations "drift" over time, with every urgent intervention or new installation. It therefore needs to be checked continuously, comparing the actual state with the expected one, alongside patch management and vulnerability assessment.

Example

A company has used Microsoft 365 for five years without ever reviewing its settings. A check finds: three global administrators without MFA, legacy authentication protocols still allowed, dozens of third-party apps with mail access authorised by users, and a rule that automatically forwards a director's emails to an external address. None of these is a "bug": they are configuration choices. Correcting them reduces risk more than any new product you could buy.

The same applies to a newly installed server: before putting it on the network you apply a reference configuration, document it and check it periodically, so that every deviation shows up as an anomaly to be explained.

Related terms

• Attack Surface Management
• Patch management
• File Integrity Monitoring
• HIDS