There's a comforting story about cyber attacks where somebody brilliant finds something nobody has ever seen. It happens. It is also, in my experience, not what happens to you. What happens to you is that a hole was found by a researcher, written up, given a number, fixed by the vendor, and then left open on your machines for long enough that somebody with a scanner found you.
That's the uncomfortable part of this job. The majority of what we clean up was preventable with information that was public, free and specific. Not "you should have better security". More like "this exact door, on this exact version, was documented as unlocked in March".
So let me explain the machinery behind that, because once you see it, the priorities sort themselves out.
1. What a CVE actually is, in plain English
CVE stands for Common Vulnerabilities and Exposures. When somebody finds a security flaw in a piece of software, it gets entered into a public catalogue and given a reference number, something like CVE-2026-1234. That number is how the whole industry talks about the same hole without confusion: the vendor, the researcher, your security tooling and, yes, the person attacking you.
Most also carry a severity score out of ten, which tells you roughly how bad it would be and how easily it can be reached. That score is useful, but on its own it is not a priority list. A medium-severity flaw in something exposed to the internet and being actively exploited today matters far more than a critical-severity flaw in a system three firewalls deep that nobody has ever attacked.
Here's the bit business owners rarely have explained to them: the catalogue is public on purpose, and it is public to everyone. Publishing is what forces vendors to fix things and lets defenders act. But the moment a flaw is published, the clock starts, and it runs for both sides. Researchers get to write detection. Attackers get a specification. For widely-used software, working exploit code frequently appears within days of disclosure, sometimes hours.
Which means patching is not maintenance. Patching is a race you have already been entered into without being asked, against people reading the same list you could be reading.
The standard behind it: ISO 27001 calls this management of technical vulnerabilities (Annex A 8.8): know what software you run, know what is being disclosed about it, and act in a defined timeframe. The Essential Eight is blunter, patching applications and patching operating systems are two of its eight strategies. Two of eight. That is how much of the problem this single discipline covers.
2. Browser extensions: the supply chain nobody audits
Now the one that gets underestimated, and the reason I wanted to write this.
Your business almost certainly has a procurement conversation before it installs new software on a server. It almost certainly has no conversation at all before somebody adds a browser extension. And yet, for most staff, the browser is the workplace. Email, payroll, banking, the CRM, the finance system, the client files. It all runs in that window.
When you install an extension, look at what it asks for. A very common permission reads, in Chrome's own words, that it can "read and change all your data on the websites you visit". Read that again with your payroll system in mind. People grant it to get a colour theme, a coupon finder or a PDF converter.
The genuine risk isn't usually that the extension was malicious the day it was installed. It's these three, in rough order of how often I see them:
- Ownership changes. A popular, legitimate extension gets sold. The new owner inherits an install base with standing permissions and the ability to push an update to every one of them. The extension you vetted two years ago is not necessarily the code running today.
- The developer gets compromised. Attackers phish extension developers precisely because a single stolen publishing account reaches every user at once, through the official store, signed and trusted.
- It was always quietly harvesting. Plenty of free extensions are funded by the browsing data they collect. That may not be malware, but it is your staff's session with your systems, leaving your business, under a licence agreement nobody read.
The uncomfortable question I'd put to any owner: could you produce a list, right now, of every extension installed across your organisation? Almost nobody can. That's not a failure of diligence, it's that nothing prompts you to look. It's software, with access to your most sensitive systems, that never went through any of the gates your other software went through.
The fix is genuinely not difficult. Extensions can be managed centrally, the same way we manage everything else on a device: allow the handful the business actually needs, block the rest, and remove the ability for the install base to change underneath you. What that turns into is a short, boring, known list, which is exactly what you want.
The standard behind it: the Essential Eight calls this application control and user application hardening, restricting what can execute and locking down the browser specifically. ISO 27001 covers it under installation of software on operational systems (Annex A 8.19) and the supplier relationships controls, because an extension developer is a supplier with access to your data, whether you have ever thought of them that way or not.
3. End-of-life software: the hole that never gets fixed
Everything above assumes there is a patch to install. End-of-life software is the case where there isn't, and will never be one again.
This is the part I think is genuinely misunderstood. When a product reaches end of support, it does not become insecure on that date. It becomes permanently and increasingly insecure from that date. Researchers keep finding flaws. The catalogue keeps growing. Your version simply stops receiving the fixes. Every month that passes, the public list of known, documented, unpatchable ways into that system gets longer, and there is no action available to you that shortens it.
Windows 10 is the live example for most Australian businesses. Support ended on 14 October 2025, and every month since has added to the pile. We wrote up what that actually means in practice, but the summary is that a machine still running it is not "a bit behind", it is accumulating exposure with no remedy.
It rarely stops at the security question, either. Cyber insurers ask about unsupported operating systems, and the answer affects both cover and price. Your larger customers' procurement questionnaires ask. Compliance obligations that require you to keep systems current do not accept "it still works" as evidence. And the software you rely on stops being tested against it, so the eventual failure often arrives as a broken line-of-business application rather than as a breach.
I understand entirely why it happens. Replacing working hardware feels like spending money on nothing. But the honest framing is that you're not choosing between spending and not spending, you're choosing between a planned cost and an unplanned one, and the unplanned one arrives with downtime attached.
The standard behind it: ISO 27001 asks you to manage the lifecycle of what you run, secure configuration and the technical vulnerability controls both assume supported software underneath them (Annex A 8.8, 8.9, 8.19). An unsupported operating system doesn't fail one control, it removes the foundation several others stand on.
4. What I'd actually do about it
None of this needs a transformation programme. It needs four unglamorous things done consistently:
- Know what you own. You cannot patch, or retire, what you don't know is there. An inventory of devices, operating systems, applications and browser extensions is the unsexy foundation everything else rests on, and it's the step most often skipped.
- Patch on a clock, not on a mood. Define a timeframe, apply it, and be able to show it was met. The Essential Eight's guidance for internet-facing systems is measured in a small number of days, not weeks, and there's a reason for the urgency.
- Manage the browser like you manage the desktop. A controlled extension list, centrally enforced. It costs an afternoon to set up and closes a door most businesses don't know is open.
- Put end-of-life dates in the budget, not the backlog. Every operating system and major application has a published end-of-support date, years in advance. That's a planning calendar handed to you for free. Use it and the replacement is a line item, ignore it and it's an emergency.
This is precisely the work we do inside managed devices and security operations, and I'd rather explain the reasoning than have you take it on faith, which is why this piece exists.
The attacker doesn't need to be clever if you've left something documented, numbered and published unattended for six months.
If there's one thing to take away, it's that "known" is the operative word in every section above. These aren't mysteries. The CVE is published, the extension permissions are printed on the install screen, and the end-of-support date was announced years ahead. Every one of them is a decision, and the only real question is whether it's being made deliberately or by default.
If you don't know which, that's worth an hour of somebody's time. It's free, and as always, it'll be a conversation rather than a pitch.
