From negative seven to Negative Zero

An organisation can be fully patched and still be easy to compromise, because updates fix flaws in products and leave everything around them untouched. No update will delete an administrator account nobody needs, close a management interface that was left exposed or remove cloud permissions that were granted too generously. Those conditions take deliberate engineering work to put right, and they are often what decides whether an intrusion stays a contained incident or turns into a business crisis.

Negative Zero’s thesis is that security should continuously remove the weaknesses attackers rely on, rather than waiting to respond once they have been used. Patching still matters, but it belongs alongside secure configuration, restricted access and preventive controls that have actually been tested. Threat intelligence should point that work at the attack paths that are relevant to you, and an agentic security engineer can help your team find those weaknesses, fix them and verify that each fix has held.

What the exploitation data tells us

Google Mandiant’s M-Trends 2026 report estimates that the mean time to exploit in 2025 was minus seven days. Google’s explanation is that, on average, exploitation began before the patch had even been released, so the familiar model of waiting for a fix and then applying it quickly was already too late for the typical vulnerability in its analysis. The figure describes the vulnerabilities Mandiant studied rather than every flaw published that year, but it is a striking measure of how far attackers have moved ahead of the patch cycle.

VulnCheck’s first-half 2026 analysis added 495 vulnerabilities to its known-exploited catalogue, and for 23.43% of them there was evidence of exploitation on or before the day the CVE was published. Google’s Threat Intelligence Group separately recorded 141 vulnerabilities that were both disclosed and exploited between January and August 2026, already more than the 127 it counted across the whole of 2025.

The volume is rising as well. Google’s Threat Intelligence Group counted monthly disclosures doubling from 5,045 in January 2026 to 10,740 in August, and exploited vulnerabilities climbing from an average of 10.5 a month in 2025 to 18 a month this year. Not all of that is AI, and Google puts much of the disclosure surge down to automated CVE numbering and bulk vendor advisories, but AI-assisted research is adding to it. In May, Anthropic reported that it and around 50 partners in Project Glasswing had used Claude Mythos Preview to find more than ten thousand high- or critical-severity vulnerabilities, and in October it said partners had uncovered at least 129,000 verified vulnerabilities between April and July, more than 33,000 of them rated high or critical. Google also found that half of AI-discovered vulnerabilities lead to remote code execution, against 26% of the rest, and Anthropic itself says the limit is now how quickly findings can be verified, disclosed and patched. More flaws found faster means more exposures waiting for a fix, which is the window that good configuration has to cover.

The release of a patch, the public disclosure of a flaw and the first observed exploitation are different dates, and the most recent vulnerabilities have simply had less time to gather evidence of exploitation. Zero Day Clock has stopped publishing time-to-exploitation metrics, partly because that effect can make recent years look artificially faster than they really were.

There is no grace period after disclosure that you can depend on. Organisations need to patch promptly whenever a fix exists, to have preventive controls already working before one does, and to treat the weaknesses that no update will ever address as remediation work in their own right.

Configuration determines what an attacker can do

A software vulnerability is a flaw in the product itself, the kind of problem a vendor resolves by shipping a patch. A misconfiguration is something else entirely: the product may be perfectly sound, but it has been deployed or run in an unsafe way, with an administrative interface left open to the internet, a default setting nobody changed, or an account given far more access than its job requires. Exposure is what decides whether an attacker can actually reach and use either kind of weakness, and an attack path is the chain that links them together, leading from a first foothold through to privileged access, stolen data or a service brought to a halt.

Updating a remote access product may remove a known flaw while leaving its management interface open and its access to internal systems as broad as before, and restricting that access may reduce your exposure without repairing the flaw at all. In practice you often need both changes, along with evidence that each one actually worked.

NSA and CISA list poor privilege separation and insufficient network segmentation among the misconfigurations they see again and again, and CIS Control 4 treats secure configuration as something to be managed continuously rather than set once. A remediation record should therefore name the exploitable condition, the service it affected and the correction that was verified, because “server patched” on its own tells only part of that story.

Configuration also changes as an organisation goes about its work. Troubleshooting can introduce an exclusion that never gets removed, a project can leave temporary access behind when it finishes, and a new deployment can quietly restore an unsafe default. A review completed last quarter cannot tell you what your environment looks like today, so continuous assurance has to spot these changes as they happen, tell authorised exceptions apart from accidental drift, and bring the environment back to the configuration you agreed.

Breaking an attack path

Perimeter gateways are where this happens in practice. On 27 September 2026, CISA warned that two critical zero-day vulnerabilities in Citrix NetScaler ADC and Gateway, each enabling remote code execution, were being actively exploited around the world. What attackers do after a gateway falls is well documented, and members of the Negative Zero team have seen it first-hand while working incident response engagements on NetScaler compromises. When an earlier NetScaler flaw allowing unauthenticated remote code execution was exploited in 2023, CISA reported that the actors implanted a web shell, read the appliance’s configuration files and the key stored alongside them, decrypted an Active Directory credential, used it to query the directory for users, groups, computers and trusts, and then tried to reach a domain controller. In that case network segmentation, together with restrictions on which accounts could authenticate to the domain controller, stopped the attack, and none of those controls depended on a patch.

Patching closes the entry point once a fix exists, and until then hunting for indicators of compromise matters more than waiting. Rotating every secret the appliance holds makes a stolen configuration worthless, segmenting the appliance stops it from being used as a foothold for discovery, and restricting which accounts can sign in to domain controllers blocks the step that turns a gateway compromise into a domain compromise. None of these repairs the gateway flaw, and engineers must verify each boundary and confirm that required services still work. Hardening cannot guarantee protection against an unknown exploit; detection, incident response and recovery remain necessary.

Fundamentals provide the foundation

Cyber Essentials sets out five control areas, and security update management is only one of them, so a programme that measures itself almost entirely by patch percentages is narrower than even this baseline asks for. Negative Zero’s approach is to keep all of these fundamentals in place continuously rather than checking them once a year, and the questions in the table below show what that kind of operational assurance looks like in practice, going beyond what a formal assessment checklist would ask.

More demanding environments will need further controls on identity, segmentation, application security and recovery on top of these. Certification provides assurance within its own defined scope and assessment process, but keeping that protection in place afterwards depends on someone owning it day to day.

Recognised baselines are what make this work consistent from one system to the next. Microsoft recommends established, tested security baselines, and its guidance weighs whether each setting mitigates a real threat without causing worse operational problems in the process. Best practice therefore has to reflect what a system is for and what depends on it, and where a setting cannot be applied, the exception should be justified, owned by someone and given a date for review.

A good baseline describes the outcome it is trying to achieve as well as the setting that achieves it. Removing a service makes sense when it serves no business purpose, but when it does, restricting who can reach it may be the right answer instead, and that decision needs an owner who understands what depends on the service. Without that understanding, a change that is technically compliant can disrupt operations, and teams who have been caught out once will be tempted to work around the control the next time.

Threat intelligence should change the configuration

Threat-informed prevention uses what we know about how adversaries actually operate to remove the weaknesses their attacks would rely on. MITRE’s Center for Threat-Informed Defense describes this as a continuous process that connects intelligence, defensive measures, and testing and evaluation, and intelligence should shape engineering decisions as well as detection rules.

In practice, an advisory about a remote-access service should trigger a check of which versions you run and which of their interfaces can be reached. Intelligence about credential theft should prompt a review of how privileged credentials are used and protected, and campaigns that abuse cloud permissions should lead you to look hard at consent grants, the access that has been granted and how long credentials live. Whatever the finding, it needs an accountable owner and an action that fits it.

Priorities should take account of evidence of exploitation, how reachable a system is, what it means to the business and what protection is already in place. Removing excessive privilege from an internet-facing production service may be more urgent than fixing a high-severity flaw on an isolated development system, although that flaw still needs fixing in its turn, because threat context changes how urgent something is without cancelling the obligations a baseline sets. Where telemetry is stale or missing, that gap should stay visibly marked as unknown rather than being quietly treated as safe.

The identity that matters is not always a person: it may be a workload, an application or an automation account, and reviewing only human administrators leaves all of those access relationships unexamined. Prevention should follow each permission through to the resources it can affect, including who is able to change the policy itself, which makes the business consequence of an apparently small configuration error much easier to judge.

Verify the protection that is actually enforced

Microsoft attack surface reduction rules are a good illustration of the gap between a capability you have and the protection you actually get. They can block behaviours such as Office applications creating child processes or malware reaching for credential material, but what they achieve depends on whether each rule applies, whether its prerequisites are met, which mode it runs in and what has been excluded. A rule in audit mode records what it would have blocked without blocking anything at all.

Microsoft’s deployment guidance walks through planning, testing, enabling and monitoring these rules, and the same discipline applies to any control. A configured policy has to reach the devices it was meant for and take effect without causing unacceptable disruption, and validation should inspect the settings that are actually in force and, where it is safe to do so, exercise the behaviour the control is supposed to prevent. Holding a licence or assigning a policy cannot demonstrate any of that on its own.

Remediation also has to reach the place the configuration comes from. If you repair a cloud resource but leave the error in the template that deploys it, the next deployment will simply recreate the weakness, so a durable correction has to include the provisioning process as well as the resource in front of you.

An agentic security engineer closes the loop

Negative Zero’s vision is an agentic security engineer that continuously finds and fixes misconfigurations across cloud and endpoint environments. AI can help interpret guidance, gather the context a decision needs, propose changes and produce the evidence that they worked, but the operating model has to carry all of that through to protection that has been verified, rather than stopping at a recommendation.

The work begins with an inventory of assets, identities, owners and dependencies that is honest about how old each observation is and where coverage has gaps. From there you agree the baselines and the exceptions, compare them with the settings that are actually in effect, and prioritise using the threats and exposure that are relevant to you. Corrections should be tested, reversible and applied within the authority you have agreed, while any change that could disrupt production, access or recovery goes to a person for review first.

Every change the agent makes is written to a full log, recording what it changed, where, when and why, so your team always knows exactly what it did and can roll any change back if it needs to. Once a change is made, the agent confirms it has actually taken effect by checking the resulting state and running a functional or security test, since a “Settings saved” banner in an admin portal only means the form went through, not that the new setting is being enforced on every user and device it should cover. From then on it watches for drift and for exceptions that have expired, leaves the exceptions your team has approved alone rather than reversing them, and updates the templates and procedures behind each fix so the improvement lasts.

Automation needs safeguards of its own. Discovery should be kept separate from privileged execution, credentials kept to the minimum, decision logs retained and rollback tested before it is ever needed. External content should be treated as evidence and never as an instruction to act on, and any dependency the agent is unsure about should go to a person for review, because AI cannot supply business context it does not have or prove that an unknown attack path does not exist.

Measure exposure and control effectiveness

Patch compliance is a useful measure, but it should sit alongside the time it takes to go from confirmed exposure to verified correction, including the oldest cases that are still unresolved. Effective control coverage should be reported across a defined set of assets, with unknown and stale results shown separately rather than averaged away, and every tested attack path that was interrupted should be recorded with its scenario, method and date.

Recurring configuration drift, ageing exceptions and failed changes belong in the same report, because these proposed measures assess operational reliability as well as security improvement. Targets should reflect what the business needs and how exposed it is, and a falling alert count on its own cannot prove that prevention is getting better; the evidence should show what changed and what that change now prevents.

Testing establishes a specific result within a defined scope, and it cannot prove how many future breaches were prevented. Keeping that distinction clear makes customer reporting more credible, and it helps engineers see what has not yet been tested.

Getting to zero

Attackers are now arriving at minus seven days, using flaws before a patch even exists, and racing them to the fix is a contest defenders rarely win. The better answer is to make sure that when they do arrive, the exposed management interface, the forgotten administrator account and the over-generous permission are already gone. That is what Negative Zero is building: an agentic security engineer that brings your environment up to best practice, proves every change worked and keeps it there, with Cyber Essentials as the foundation and real threat intelligence setting the priorities. Every organisation sits some distance from the configuration it knows it should have, and our job is to close that distance and hold it at zero. If you want to see how far your environment is from zero, book a demo.

Sources and further reading