A note from the operational side, rather than the governance side. This blog leans board-facing for a reason — it is most of who reads me. But there is a smaller, more technical strand that I think is worth keeping alive, because the operational disciplines that prevent most real-world compromises are unglamorous, easy to ignore, and unlikely to feature in any vendor pitch deck. Two in particular have earned their keep in every environment I have run, and I am increasingly of the view that they are the closest thing to a free lunch the discipline offers. They are: default-deny on USB, and hardware-backed multi-factor authentication.
Default-deny on USB
The simple fact about USB is that, in any computer made in the last decade, plugging in a USB device is the most privileged thing a human being can do to it without typing a password. The device can present itself as a keyboard and type commands. It can present itself as a network adapter and route traffic through an attacker-controlled gateway. It can present itself as a storage device and exploit the auto-mount workflow. It can do all three at once, in a sequence designed to evade detection. The threat model has not improved, and the operating systems have, charitably, made only marginal progress on it.
The control that actually works is default-deny. The host does not enumerate any USB device that has not been explicitly authorised, by class, by ID, or by serial number. The user can plug in whatever they like — keyboards, drives, hardware tokens, the BadUSB the conference handed out — and nothing happens. The cost of this is low: most users have a small, stable list of legitimate devices, and authorising them takes a few seconds.
On Linux, USBGuard is the right tool. The policy file lives in /etc/usbguard/rules.conf, and the discipline is: write the list of devices you actually use, set the daemon to block everything else by default, and read the audit log when something unexpected gets plugged in. There is no cost to running it. The friction is one-off, at the moment a new device is introduced. On Windows, the equivalent is Device Installation Restrictions via Group Policy. On macOS, it is more constrained but the principle of explicit authorisation, default deny is the same.
I have used USBGuard on every machine I personally administer for the last six years. The number of times the policy has actually denied a malicious device is small — it is not the headline value. The headline value is that the discipline of thinking about what I am authorising has caught two devices I would otherwise have plugged in without thinking. One was a USB drive from a conference that, on inspection, presented as a HID keyboard. The other was a hub bought from a high-street retailer that registered an audio device alongside the four USB-A ports. Neither was necessarily malicious. Both were noteworthy.
The control catches the obvious BadUSB attack. It also catches the less obvious I have just unboxed this hub and it is doing something I did not expect moment, which is the moment most people would have ignored.
Hardware-backed multi-factor authentication
The second discipline is hardware-backed multi-factor authentication. This is the discipline of insisting that every meaningful authentication — administrative access, source code repositories, email, cloud provider consoles, password manager — requires presentation of a hardware token that cannot be exfiltrated by a remote attacker. In practice this means FIDO2 hardware authenticators (YubiKey, Nitrokey, SoloKeys, Token2) for everything that supports them, and TOTP on a hardware token rather than a phone app for the long tail that still does not.
The reason this matters is that the dominant remote-access compromise pattern in 2024 and 2025 — credential phishing, infostealer-on-host, session-token theft — is defeated cleanly by hardware-bound authenticators in a way it is not defeated by SMS, voice, push, or app-based codes. The LAPSUS$ spree of 2022 was the moment this became impossible to ignore: a group of teenagers compromised Microsoft, Okta, Nvidia, and Samsung primarily by defeating push-based MFA through fatigue prompts. Hardware MFA would have stopped them. The lesson has had four years to land. It still has not landed everywhere. The session token is bound to the hardware. The hardware does not leave the user. The token does not transmit to a phishing site. The attacker who has the password and the recovery email and access to the user's session cookies still cannot authenticate, because they do not have the hardware in their pocket.
This is the closest thing the field has to a single high-leverage control. It is also the most boring. Hardware tokens cost money. They get lost. They get left at home on the wrong day. They do not work on every site. The friction is real, particularly at the moment of introduction. Once introduced, the friction is minimal: a tap on the device, every few authentications, takes less time than a TOTP code.
I run two YubiKey 5C NFCs on every account that supports them, with a third backup in a fire safe. I use Token2 PINcards for the long tail of services that do not yet support FIDO2 but do support TOTP. I do not use phone-based authentication for anything that touches money, identity, or production systems. I have not had an authentication compromise in the seven years I have run this discipline. The discipline is not the only reason. It is, I think, the largest single contributor.
Why this matters at policy level
The reason to write this down at the level of blog post rather than staff handbook is that these two disciplines, between them, prevent more real-world compromise than any tool a CISO will buy this year. They are, however, the unglamorous bottom of the spending priority list. The vendor who sells one of these will not buy you dinner. The vendor who sells the AI-driven SOC platform will. The reading of board papers will therefore tend to push spending in the opposite direction to the marginal-impact return.
The marginal-impact return is, in my experience: default-deny on USB prevents a class of attacks that does not arrive often but, when it does, defeats almost everything else; hardware MFA prevents the dominant attack class in the current threat environment, almost completely, for a few hundred pounds per user one-off.
If you are a CISO running a budget meeting this year, the question worth taking into it is: what fraction of our security spending in 2026 will go to these two disciplines, and is that fraction proportionate to their actual contribution to the firm's resilience? If the answer is single-digit percent, the spending plan is not optimised for outcomes. It is optimised for the conversation.
That is the work. The unfashionable work. It does not change much, year on year, and that is most of what is good about it.