When the Patch Was Not Enough: An Accountability Audit
Here is the fact the comfortable version of this story leaves out. In January 2026, attackers compromised Fortinet firewalls that had already been fully patched against the vulnerabilities disclosed only weeks earlier. The patch worked exactly as intended. The attackers came in anyway, through a different door nobody had found yet.
This is not a story about one vendor. It is a story about the question we ask after a vendor flaw, and the question we fail to ask. So let me build the case the way I build every case: what happened, what the response was, what the outcome tells us, and what every UK small business should learn from it.
The Incident
The timeline is a matter of public record, documented by Fortinet, by the US Cybersecurity and Infrastructure Security Agency, and by multiple independent security firms.
In December 2025, Fortinet disclosed two vulnerabilities in its FortiCloud single sign-on feature, CVE-2025-59718 and CVE-2025-59719. A crafted sign-on message could let an unauthenticated attacker bypass the login on a range of Fortinet products, if that cloud feature was enabled. It was enabled on a great many devices, because it switches on during registration unless an administrator deliberately turns it off. Exploitation began within days. Honeypots recorded attempts in mid-December. Real intrusions followed.
Organisations patched. Reasonably, they assumed that was the end of it.
It was not. In the third week of January 2026, Fortinet customers reported that attackers had gained access to firewalls and created new local administrator accounts, despite those devices running the most recent firmware. Fortinet investigated and confirmed a new, separate vulnerability, CVE-2026-24858, with a severity score of 9.4. It was not a failure to patch. It was a fresh path to the same outcome, and it worked on fully updated devices. CISA added it to its Known Exploited Vulnerabilities catalogue on 27 January 2026, with a remediation deadline for federal agencies of 30 January.
The observed attacker activity, as documented by CISA, was quiet and deliberate: unauthorised changes to firewall configuration, the creation of new accounts, and changes to virtual private network settings that granted those new accounts access.
The Response
Now the part that separates the organisations that handled this well from the ones that did not. The technical response was the easy half. Fortinet deployed a fix to its cloud infrastructure and released updated firmware. Applying it was straightforward.
The accountability response was the hard half, and it had nothing to do with the patch. It was a sequence of questions that someone, somewhere, needed to own. Which of our devices are affected? Which firmware versions are we running? Was the feature enabled? Was management access exposed to the internet? Were the logs reviewed? Were administrative accounts checked for unauthorised additions? Were credentials rotated? Was there any sign of access before the fix went on? Who signed off the conclusion that the business was safe?
For organisations with a provider who had mapped advisory to asset to action, that sequence was a process. For everyone else, it was a scavenger hunt conducted under stress, if it happened at all. The real operational gap exposed by this incident was not a missing patch. It was the missing map: the link between a published advisory and a documented list of which of your devices it touches and what was done about each one.
The Outcome
The outcome is uncomfortable, and it should be. A patched device is not a cleared device. The patch stops future exploitation of a known flaw. It says nothing about whether an attacker was already inside, and it offers no protection against the flaw that has not been disclosed yet. CVE-2026-24858 proved both points in the same incident.
For any business that ran the affected devices, “we patched it” was never a complete answer. The complete answer required someone to have checked administrative accounts, new users, configuration changes, VPN settings, logins, and cloud account activity, and to have confirmed that logging was intact enough to check at all. An organisation that could not produce those checks did not have a smaller incident than one that could. It had a larger one that it simply could not see.
And that is the heart of it. Not watching is not the same as safe. It may only mean nobody was looking.
The Lessons
This is where it stops being a Fortinet story and becomes your story, whatever brand sits at the edge of your network.
You cannot outsource responsibility. You can only outsource tasks. Your provider can run the patch. They can monitor the logs. They can manage the device. They cannot own the question of whether your business survives, because that question is yours. “Our MSP handles cyber” is not a board answer. It is the start of a follow-up question: what exactly do they handle, where is it written, what evidence proves it, and what is outside scope?
Demand the advisory-to-asset-to-action chain. A competent provider should be able to show you, for any major vendor advisory, which of your devices are affected, what was done, and what evidence supports it. Ask how they handle Known Exploited Vulnerability listings. Ask what happens when a flaw is added to the KEV catalogue, how they identify your affected assets, how fast they act, and what evidence you receive. If they cannot answer, you have learned something valuable. That does not mean sack them on the spot. It means have an adult conversation. If the adult conversation causes panic, that tells you something too.
Ignorance is a weak defence when the questions were obvious. I am not saying every business that ran these devices was negligent. Plenty did everything reasonable. But regulators, insurers, and customers increasingly ask whether reasonable steps were taken, and reasonable steps now include evidence: an asset list, a patch process, an admin review, logging, tested backups, an incident contact list, and supplier accountability. “We did not know” is a harder position to defend when the advisory was public and the flaw was on a government catalogue of vulnerabilities under active attack.
How to Turn This Into a Competitive Advantage
The businesses that can show their working are about to look very good by comparison.
Evidence wins trust that reassurance cannot. When a client asks how you handle vendor advisories, “here is our advisory-to-asset-to-action process and here is who owns it” is a far stronger answer than a brand name. In a market where most providers offer fog, documented accountability is a differentiator buyers can feel.
You become the supplier nobody has to worry about. In a supply chain full of unowned risk, being the link that can prove it watches the edge makes you the easy choice for a cautious larger partner.
How to Sell This to Your Board
Three points, framed for the people who carry the liability.
The patch is the cheap half; the accountability is the half that protects you legally. The Breaches Survey 2025/2026 found that revenue-affecting breaches have more than doubled, from 2% to 5%. The documented evidence of reasonable steps is what keeps an incident in the defensible column.
Ownership is a board responsibility that cannot be delegated to a contract. Decision rights, who can take systems offline, who can approve emergency action, who talks to the insurer, belong to the business, not the provider. During a real incident, delay is not admin. Delay is damage.
The cost of building the map is trivial against the cost of not having it. An asset list, a KEV-handling process, and a log-review habit cost time, not capital. The alternative is discovering during a breach that nobody owned the question.
What This Means for Your Business
-
Ask your provider to demonstrate the advisory-to-asset-to-action chain for a recent vendor flaw. Not describe it. Demonstrate it, with your actual devices.
-
Confirm who signs off “we are safe” after an incident. If no named person owns that conclusion, the conclusion is worthless.
-
Verify that logs exist and are reviewed for your edge devices, so that “was anyone already inside” is a question you can actually answer. See our walk-through of building a recovery plan before you need it.
-
Get the scope in writing. What your provider handles, what is documented, what evidence proves it, and what is explicitly outside scope. Covered further in why cyber insurance claims get denied.
-
Treat the KEV catalogue as a deadline. When a flaw affecting your kit lands on it, the clock has already started. Compare with how DragonForce weaponised remote management tools.
The patch worked. That was never the question. The question was who was watching the edge, and whether anyone could prove the business was safe. Own the risk before someone else owns the story.
Related Posts: