Hardening your OS: Windows, macOS, Linux

A CISO sends me his fleet’s hardening baseline: 220 items, committee-approved, signed off by the IT department, deployed by GPO. Item 1, disable SMBv1. Item 47, disable PowerShell v2. Item 89, set the screen sleep timeout. Everything is correct. Except the managing director uses his local administrator account day in, day out, his password is Manchester2024!, and the machine hasn’t had a security update in five months because the reboots bothered him during video calls. The checklist was perfect. The endpoint, wide open like a barn door.

The usual trap

Hardening an operating system, in most organizations, has become an exercise in documentary compliance. You download a benchmark, you tick boxes, you produce a report, you file it away. The report says the endpoint is hardened. The endpoint, meanwhile, understands nothing about the threat that actually targets it. It’s exactly the same trap as compliance without a threat model: security theatre that burns budget and produces false assurance.

CIS Benchmarks, Microsoft baselines, NCSC configuration guides are useful documents. They catalogue a set of settings known to be better than the defaults. They are not threat models, and they don’t claim to be. A Windows CIS Benchmark runs to several hundred recommendations. Applying them all without thinking amounts to hardening uniformly across points whose importance varies by a factor of a hundred. Disabling SMBv1 on a laptop that never does network sharing changes nothing about your exposure. Working in an administrator account every day changes everything. The two measures carry the same weight in the compliance report. They do not carry the same weight against an attacker.

The second trap is the giant checklist perceived as a token of seriousness. The longer the list, the more rigorous it looks, and the more unmanageable it actually is. A baseline of 220 items that nobody maintains degrades within months: an exception granted here, a setting broken by an update there, an endpoint reinstalled without the profile. After a year, the report still shows 220 items “compliant” while half the endpoints have drifted. A handful of measures actually applied and verified beats an encyclopaedia of theoretical settings. Hardening isn’t a project you finish, it’s a state you maintain.

The real threat model: what we actually harden against

Before lining up settings, you have to know what actually hits endpoints. The dominant threat model isn’t the sophisticated movie attack. It’s industrialized opportunism: a generic malware delivered by attachment or booby-trapped download, which executes in the context of the current user and tries to establish persistence. Nearly all the endpoint compromises we debrief follow this pattern, and three facts characterize it.

The entry vector almost always goes through the user. An attachment opened, a macro enabled, an executable downloaded from a fake site, a phishingSocial engineering attack pushing targets to disclose credentials or execute code.See glossary link that serves a poisoned installer. The malicious code starts with the rights of the open session. If that session is administrator, the malware instantly is too: it installs ransomwareMalware encrypting data and demanding ransom, often paired with prior exfiltration.See glossary, disables the antivirus, plants a rootkitMalware installing deep in the OS to remain invisible and persistent.See glossary, and the endpoint is lost. If the session is standard, the same booby-trapped file is confined to the user’s personal files — annoying, repairable, with no escalation to the system.

The average attacker exploits vulnerabilities that are already patched. According to recurring analyses of real attack vectors, the overwhelming majority of compromises exploit flaws for which a patch had existed for more than a month. The ordinary adversary doesn’t burn a 0-day on a random endpoint: he scans machines that are behind on patches and walks in through the door the vendor already documented and closed for those who update. Update lag is, statistically, the leading factor in compromise.

Persistence hides in predictable places. Malware that wants to survive a reboot registers itself in known mechanisms: Run keys in the Windows registry, scheduled tasks, services, LaunchAgents and LaunchDaemons on macOS, systemd units and cron on Linux. And it installs itself in directories accessible without elevated rights: %TEMP%, %APPDATA%, the user folder. Hardening effectively means making those places and mechanisms inhospitable, not reciting a benchmark.

The right approach: harden by impact, not by exhaustiveness

The pragmatic shift is to rank measures by their real effect on the threat model above, then to apply first the ones that block the most scenarios for the least effort. About a dozen measures, cross-cutting or per-OS, do most of the work. The rest is fine-tuning reserved for the profiles that need it.

The cross-cutting baseline, valid on all three OSes

Standard account for daily work, administrator reserved for installations. This is the most effective and least applied hardening measure. It cleanly breaks the malware’s automatic escalation: a booby-trapped file opened in a standard session can’t install itself in the system, disable protections, or make itself persistent at the machine level. On Windows, create a standard account to work in and a separate administrator account to install. On macOS, same logic — a standard account works, system actions call for an occasional administrator password. On Linux, it’s already the default of any serious distribution; the trap is to break it by granting a broad, permanent sudo.

Automatic updates, no exceptions and no deferral. Since patch lag is the leading factor in compromise, automation is the best effort-to-effect control there is. Windows Update in automatic mode with an enforced reboot window. macOS with automatic installation of system and app updates ticked. Linux with unattended-upgrades on Debian/Ubuntu or dnf-automatic on Fedora/RHEL, tested with --dry-run before activation. The cultural rule that matters: a pending reboot is non-negotiable, even for an executive on a video call.

Disk encryption with a user secret, not hardware only. BitLockerMicrosoft disk encryption integrated into Windows Pro/Enterprise.See glossary, FileVaultDisk encryption integrated into macOS since OS X Lion.See glossary, or LUKSDisk encryption standard on Linux, via cryptsetup and dm-crypt.See glossary being active isn’t enough: you need a PIN or a passphrase, not TPMCryptographic chip on the motherboard storing keys and attesting boot integrity.See glossary-only unlocking. The detail of the modes, the sleep states, and recovery-key management is the subject of a dedicated article — it’s the natural complement to hardening, and the most frequent deployment mistake on this point is BitLocker in TPM-only mode.

Fast screen lock and verified boot. Automatic lock under two minutes of inactivity, unlock by password or biometrics — not just a sleep. Secure BootUEFI mechanism cryptographically verifying the boot chain.See glossary enabled in the UEFI to prevent loading an unsigned bootloader or kernel. These two settings cost nothing and close common physical-access vectors.

Windows: the additional settings that count

Beyond the cross-cutting baseline, Windows offers four high-impact levers that most baselines drown among hundreds of minor items.

The first is the ASR rules (Attack Surface Reduction) in Windows Defender, widely under-used even though they’re free and deployable by GPO or Intune. Three rules earn their activation immediately: block child processes launched by Office applications (a Word that starts PowerShell is almost always an attack), block the execution of obfuscated scripts, and block the launch of binaries from temporary and download folders. Those three rules alone cover the most common infection chain: attachment, macro, script, payload in %TEMP%.

The second is blocking unsigned Office macros. In the Trust Center of each Office application, select “Disable all macros except digitally signed macros.” Booby-trapped Word and Excel documents received by email remain an active vector, and the macro stays the weapon of choice for mass campaigns because it executes without installing anything. Microsoft now blocks macros from files originating from the internet by default, but that protection can be bypassed and disabled: don’t rely on it alone.

The third is UAC set to “Always notify.” Yes, it’s more intrusive than the default “Notify only when apps try to make changes.” And yes, it’s precisely that extra notification that gives you a chance to notice a privilege elevation you didn’t trigger.

The fourth, reserved for sensitive endpoints on Windows Enterprise or Education, is application allow-listing via AppLocker or Windows Defender Application Control. The principle: only let explicitly authorized executables, scripts, and DLLs run. Deployment happens in two stages — first in audit mode for two to three weeks, which logs without blocking and lets you map false positives and legitimate business tools, then in enforce mode once the list has stabilized. Skipping the audit stage guarantees a wave of tickets and a hasty rollback.

macOS: Gatekeeper, SIP and the Objective-See toolkit

macOS arrives with a solid protection baseline, and most of the hardening consists of not sabotaging it. Keep Gatekeeper in strict mode (App Store and identified developers), the default for several versions: it refuses unsigned and unnotarized apps. The one moment you’re tempted to bypass it is to install a dubious piece of software pulled from a forum — that’s exactly the moment not to.

Never disable SIP (System Integrity Protection), whatever the tutorials that demand it “temporarily” to make some utility work. SIP protects the system directories against any modification, including by root. It’s one of the mechanisms that prevent a malware that has obtained elevated rights from durably embedding itself in the system. A disabled and forgotten SIP turns a minor incident into a deep compromise.

Then add the free Objective-See suite, maintained by Patrick Wardle, a former NSA staffer, who produces the best macOS-specific defensive tools. LuLu is an application firewall that asks you whether a new outbound connection is legitimate: it cuts the “phone home” of a malware trying to reach its command server. BlockBlock watches the common persistence mechanisms in real time — LaunchAgents, LaunchDaemons, cron — and alerts when something tries to install itself there. KnockKnock draws up an inventory of everything configured to run at startup; run it after every app installation to see what was added without your knowledge.

Finally, for profiles genuinely exposed to targeted attacks — journalists, executives, activists — Lockdown Mode disables or restricts a set of features historically exploited by spyware of the Pegasus type: WebKit JIT compilation, link previews in Messages, wired connections to unknown devices when the Mac is locked, certain APIs. The ergonomic cost is real — slower browsing on some sites, fewer features — and is only justified for those with a genuine target profile. Enabling it “just in case” on a random endpoint is friction with no benefit.

Linux: don’t sabotage what already protects

The security of a Linux endpoint depends heavily on the distribution, the desktop environment, and who administers the machine. Hardening consists first of not disabling the protections active by default.

Don’t disable AppArmor (Debian/Ubuntu) or SELinux (RHEL/Fedora). These mandatory access control systems confine each process to what it needs, and are a major reason for Linux’s better resistance to local exploits compared with many Windows configurations. The reflex “I’ll disable SELinux because it blocks my application” is a mistake: the right answer is to write the appropriate policy, not to open everything up.

Reduce the sudo cache duration. By default, sudo retains the rights for about fifteen minutes after authentication; on a shared or exposed endpoint, bring that value down to a few minutes, or even to zero with Defaults timestamp_timeout=0 in /etc/sudoers. And only grant sudo to accounts with a documented need for it, with no permissive “everything allowed without a password” rule that cancels the benefit of the standard account.

Finally, verify that the swap is encrypted. An unencrypted swap can collect fragments of memory — keys, secrets, decrypted data — and keep them on disk. On an LVM-on-LUKS configuration, where the entire volume group is in a LUKS container, the swap is protected automatically; otherwise, check with lsblk -f that the swap partition does appear as encrypted.

What’s performative and changes nothing

A share of the “hardening” you see applied serves no purpose other than filling a report. Knowing how to recognize these measures means you don’t spend time on them and don’t believe yourself protected by them.

Renaming the administrator account. This is security by obscurity in its purest form. An attacker who has a foothold on the machine enumerates the accounts in two seconds, including the unique identifier. Rebaptizing “Administrator” as “JohnDoe” delays no one and complicates legitimate administration.

Disabling PowerShell entirely “for security.” PowerShell is a legitimate and powerful administration tool. Removing it creates operational problems without stopping attackers, who fall back on cmd.exe, WScript, or a hijacked system binary. The right approach isn’t disabling but Constrained Language Mode, ScriptBlock Logging, and signing internal scripts.

Disabling Bluetooth or Wi-Fi on principle. Switching off a radio you don’t use marginally reduces the surface, and it’s a reasonable habit. It’s not a decisive security measure: a determined attacker with physical or network access won’t be stopped by the absence of Bluetooth. File this action under “hygiene” rather than “strong protection.”

Changing the SSH port or multiplying cosmetic settings. Moving SSH from port 22 to another reduces the noise of automated scanners in the logs, nothing more. Protection comes from key-based authentication, from disabling root login and passwords, not from the port number. Confusing silence in the logs with a security improvement is a classic mistake.

Stacking up security tools without reducing the surface. Piling antivirus, EDR, third-party firewall, and “cleanup” utilities on an endpoint where the user stays administrator is treating the symptom while leaving the cause. A malware launched with elevated rights neutralizes those tools before they alert. Detection complements surface reduction; it never replaces it.

Qubes OS: compartmentalization, and for whom

When the threat profile is very high, classic hardening reaches its limit: everything lives in the same system, and a browser compromise can, by chaining exploits, reach the sensitive documents. Qubes OS answers this problem with architecture. Built on the Xen hypervisor, it runs each use domain in an isolated virtual machine: a VM for the browser, one for email, one for sensitive documents, a disposable one to open a dubious attachment. The compromise of one VM doesn’t grant access to the others.

It is, on paper, the most solid design for a workstation. It’s also the most demanding: a real learning curve, limited hardware compatibility (not all laptops are suitable), some applications hard to integrate, performance behind. Qubes is justified for investigative journalists, security researchers, or profiles facing a state-level threat who have the time to invest in adoption — and who already rigorously apply the baseline of the other OSes. Installing it “because it’s more secure” without understanding the compartmentalization model produces a false sense of security and a real loss of productivity.

What it means in practice

Mistakes we see all the time

• Working in an administrator account day to day. The simplest mistake to fix and the most widespread: you find it on the majority of audited endpoints. A single booby-trapped file opened in an admin session, and the malware inherits all your rights without asking.
• Applying a CIS Benchmark with no threat model. Disabling SMBv1 on an endpoint that shares nothing reassures the report and changes nothing about the exposure. Understanding why each item exists beats ticking everything.
• Deferring updates “when I have time.” In practice, never within 30 days. Patch lag is the leading factor in compromise, far ahead of the absence of some exotic setting.
• Confusing the length of the checklist with the level of security. A baseline of 220 items, never maintained, drifts within months. Ten measures applied and verified beat a theoretical encyclopaedia.
• Disabling protections “because they’re in the way.” SIP cut on macOS, UAC lowered on Windows, SELinux disabled on Linux, Gatekeeper/SmartScreen alerts dismissed by reflex: each disabling reopens exactly the vector the control was blocking.
• Believing the EDR replaces hardening. A malware launched as administrator neutralizes the EDR before it alerts. Detection doesn’t replace surface reduction; it complements it.
• Doing security by obscurity. Renaming the “Administrator” account, changing the SSH port: an attacker with a foothold on the machine reads the configuration in two seconds. It stops no one.

Actionable checklist

• N1 Work in a standard user account, separate administrator account reserved for installations
• N1 Enable automatic OS and app updates, with non-negotiable reboots
• N1 Encrypt the disk with a PIN/passphrase (FileVault, BitLocker+PIN, LUKS), recovery key off the device
• N1 Automatic screen lock under 2 minutes and Secure Boot enabled in the UEFI
• N2 Enable the OS firewall and, on macOS, install LuLu to control outbound connections
• N2 Block unsigned Office macros and enable the Windows Defender ASR rules
• N2 Adopt CIS Benchmark Level 1 as the baseline, Level 2 for the endpoints of sensitive functions
• N2 Automatically measure fleet compliance against the target level and track drift monthly
• N2 Reduce accounts with local administrator rights and audit sudo/AppArmor/SELinux on Linux
• N3 Deploy AppLocker or WDAC in allow-list (audit then enforce) on sensitive Windows endpoints
• N3 Enable Lockdown Mode and install BlockBlock + KnockKnock for targeted-risk profiles (macOS)
• N3 Evaluate Qubes OS for highly exposed profiles with the technical skills

Going further

The frontmatter references frame hardening without reducing it to compliance: the CIS Benchmarks and the Microsoft security baselines give the Level 1/Level 2 references, the NCSC device security guidance complements on the endpoint-configuration side, and the Objective-See suite concretely tools up macOS. The Qubes OS documentation sheds light on choosing a compartmentalization architecture for highly exposed profiles.

OS hardening only makes sense when articulated with the rest of the endpoint chain. The immediate complement is Disk encryption, really?, which details the protection states and recovery-key management. For the phishing-resistant authentication that protects the accounts behind the OS, see YubiKey and FIDO2. And to transpose these measures to an endpoint that leaves the controlled perimeter, read The travel laptop.