14 Days Is Too Long: Why High and Critical Vulnerabilities Need Rapid Remediation

Why the 14-day Cyber Essentials patching requirement should be treated as a security baseline, not a target.

When was the last time your organisation had a high or critical vulnerability identified?

If the answer is "we fixed it within 14 days", that might sound reassuring.

It might even be enough to satisfy a Cyber Essentials requirement.

But there is a problem with thinking about vulnerability remediation this way.

Fourteen days should not be viewed as fourteen days of acceptable exposure.

It is a maximum timeframe within the Cyber Essentials security update requirements for certain vulnerabilities. The National Cyber Security Centre's broader vulnerability-management guidance goes further, recommending that updates are applied as soon as possible and setting shorter best-practice timescales for internet-facing systems and ordinary operating systems and applications.

The real question isn't:

"Can we patch this within 14 days?"

It is:

"What is stopping us from removing this vulnerability today?"

Fourteen days is not the finish line

One of the easiest mistakes to make with Cyber Essentials is to turn a security requirement into a box-ticking exercise.

"We've got 14 days to patch it."

Technically, that may be the way the requirement is expressed.

But it is the wrong mindset for vulnerability management.

The current Cyber Essentials requirements state that in-scope software must be updated within 14 days where the update fixes vulnerabilities described by the vendor as critical or high risk, where the CVSS v3 base score is 7 or above, or where the vendor hasn't provided a severity level. The requirements also explicitly state that updates should be applied as soon as possible and that 14 days is considered a reasonable period to implement the requirement.

There is an important distinction here.

Compliance asks:

"Did we meet the required timeframe?"

Security asks:

"How quickly can we remove an attacker's opportunity to exploit this vulnerability?"

The second question is the one that really matters.

In fact, the NCSC's current vulnerability-management guidance recommends a five-day best-practice timeframe for internet-facing services and software, seven days for operating systems and applications, and 14 days for internal or air-gapped services and software.

So if your vulnerability-management process routinely takes the full 14 days, you should not automatically consider that a sign of good security.

It may simply mean that you are meeting the minimum acceptable compliance window.

Attackers don't wait for your patch cycle

The moment a vulnerability becomes public, the clock starts ticking.

Attackers, security researchers and automated scanning systems can all begin analysing the vulnerability.

They may:

• Analyse the vulnerability and the vendor's security update
• Reverse-engineer the underlying flaw
• Develop proof-of-concept code
• Search for vulnerable systems
• Scan the internet for exposed services
• Automate exploitation
• Deploy malware or web shells
• Steal credentials
• Establish persistence
• Move laterally through the network

The NCSC explicitly recognises this race between defenders and attackers. Its vulnerability-management guidance states that when a vulnerability is fixed, attackers will often study it and attempt to develop exploits, creating a race between organisations applying the update and attackers looking for systems that have not yet been patched.

That means every day an organisation remains vulnerable is another day in which the attacker has an opportunity.

And sometimes, that window is considerably shorter than 14 days.

Vulnerability disclosure can trigger a race

Imagine a new vulnerability is disclosed on a Monday.

An organisation identifies that it is affected and adds it to the patch-management queue.

The change request is raised.

Testing is scheduled.

The update is planned for the next maintenance window.

The organisation is technically on track to patch within 14 days.

But meanwhile, the attacker is not waiting for the maintenance window.

An illustrative scenario might look like this:

This isn't a prediction of what happens with every vulnerability.

It is an illustration of the fundamental problem.

The attacker doesn't care that your change-control meeting is next Tuesday.

And historical analysis of CISA's Known Exploited Vulnerabilities data has demonstrated just how quickly exploitation can occur. Analysis cited by CISA found that 42% of the exploited vulnerabilities studied were exploited on the day of disclosure, 50% within two days and 75% within 28 days.

A 14-day window can therefore represent a significant period of exposure.

A vulnerability doesn't become dangerous because it has a CVSS score of 9.8

CVSS is useful.

It provides a common way of describing the technical characteristics and severity of vulnerabilities.

But CVSS is not a complete risk assessment.

A vulnerability with a CVSS score of 9.8 is not automatically the highest-risk vulnerability in your environment.

Conversely, a vulnerability with a score of 7.5 should not automatically be placed into a two-week queue simply because it is "only High".

Effective vulnerability management should consider a much broader set of factors, including:

• CVSS
• EPSS
• CISA Known Exploited Vulnerabilities (KEV) status
• Availability of exploit code
• Evidence of active exploitation
• Internet exposure
• Asset importance
• Attack complexity
• Authentication requirements
• Potential impact
• Existing security controls
• Whether the vulnerability can be chained with another weakness

The NCSC's current guidance specifically recommends triaging and prioritising vulnerabilities rather than relying on a simplistic approach to severity. It also highlights the CISA KEV catalogue as a useful source of threat intelligence.

This is an important distinction:

Severity tells you something about the vulnerability. Risk tells you something about the vulnerability in your environment.

Don't make the mistake of treating High as "less important"

There is another dangerous mindset that sometimes appears in patch-management processes:

Critical = fix immediately

High = we'll get to it

Attackers don't necessarily operate according to your severity categories.

A High vulnerability affecting an internet-facing VPN appliance could be considerably more urgent than a Critical vulnerability affecting an isolated internal system with no realistic attack path.

And vulnerabilities don't always exist in isolation.

Attackers can chain vulnerabilities together to create an attack path that is considerably more dangerous than any individual vulnerability might suggest.

For example, a recent CISA and FBI advisory described threat actors chaining multiple vulnerabilities affecting Ivanti Cloud Service Applications. The vulnerabilities were used together to gain initial access, execute commands, obtain credentials and deploy web shells.

This is why simply sorting a vulnerability-management dashboard by CVSS score isn't enough.

A High vulnerability may deserve emergency treatment when it:

• Is exposed directly to the internet
• Has public exploit code
• Affects a VPN or firewall
• Provides authentication bypass
• Enables remote code execution
• Requires no user interaction
• Can be chained with another vulnerability
• Is being actively exploited

What happens when a vulnerability is already being exploited?

This is where the CISA Known Exploited Vulnerabilities, or KEV, catalogue becomes particularly useful.

A vulnerability being listed in KEV means there is evidence that it has been exploited in the wild.

At that point, the question changes.

You are no longer asking:

"Could someone exploit this?"

You are asking:

"Someone already is. Are we exposed?"

The NCSC's current guidance is explicit that normal business-as-usual patching timelines may be inappropriate when attackers are scanning or attacking systems at scale. It recommends speeding up the response and taking immediate actions where active exploitation is occurring.

This is why a sensible vulnerability-management programme should treat KEV status as a major prioritisation factor.

A vulnerability can have a lower CVSS score and still demand immediate action if there is evidence that attackers are actively exploiting it.

Internet-facing systems deserve particular urgency

Not every vulnerable machine presents the same level of risk.

Consider these four systems:

An internal workstation

A public-facing web server

An internet-facing VPN appliance

A firewall sitting on the network perimeter

The vulnerability could be identical.

The risk isn't.

An internet-facing system provides an attacker with a potential route directly into your environment. The NCSC therefore recommends shorter best-practice update timescales for internet-facing services and software than for internal or air-gapped systems.

This is one reason why organisations need to know exactly what they have exposed to the internet.

You cannot prioritise an internet-facing vulnerability if you don't know that the vulnerable system is internet-facing.

And you cannot protect an asset that isn't properly recorded in your asset inventory.

What if you genuinely can't patch within 14 days?

Real-world environments aren't always simple.

There may be:

• Legacy applications
• Unsupported systems
• Vendor dependencies
• Operational constraints
• Critical business services
• Compatibility problems
• Required testing
• Systems that cannot easily be taken offline

The answer isn't simply:

"We can't patch it, so we'll ignore it."

A better approach is:

Identify → Assess → Mitigate → Remediate

First, identify exactly what is affected.

Then assess the actual risk.

If immediate remediation isn't possible, implement appropriate temporary controls.

These could include:

• Removing internet exposure
• Disabling vulnerable functionality
• Network segmentation
• Restricting access
• Applying vendor mitigations
• Increasing monitoring
• Blocking known attack paths
• Isolating the affected system

But compensating controls shouldn't become a permanent excuse for not fixing the underlying problem.

There should be an owner.

There should be a documented reason.

There should be a review date.

And there should be a plan to achieve proper remediation.

The NCSC makes a similar point in its vulnerability-management guidance: there can be legitimate reasons not to update, but the organisation must own the risk of that decision.

Finding the vulnerability isn't enough

Imagine your vulnerability scanner identifies a critical vulnerability.

The IT team applies the patch.

The ticket is closed.

Job done?

Not necessarily.

You need to know that the remediation actually worked.

A patch can fail.

A device can be offline.

A machine can be missed.

An update can install incorrectly.

A vulnerable version can remain somewhere else in the estate.

This is why effective vulnerability management needs a verification stage.

After remediation, ask:

Did the patch actually work?

And:

Did we fix every affected system?

That might involve:

• Rescanning the environment
• Agent-based verification
• Checking patch status
• Reviewing asset inventories
• Identifying failed updates
• Confirming vulnerable versions have disappeared
• Checking newly discovered systems
• Verifying remediation across the entire estate

The NCSC explicitly recommends verifying and regularly reviewing the vulnerability-management process, rather than treating it as a one-off exercise.

Vulnerability management is a continuous process

A mature organisation doesn't operate this way:

Scan → Fix → Pass Cyber Essentials → Forget

Instead, it operates:

Discover → Assess → Prioritise → Remediate → Verify → Monitor → Repeat

New vulnerabilities appear every day.

Software changes.

New devices are deployed.

Cloud services are introduced.

Systems become unsupported.

New exploits are developed.

Attackers change their techniques.

Your vulnerability-management process therefore has to keep moving.

The NCSC describes vulnerability management as an ongoing process that helps organisations understand which vulnerabilities exist across their technical estate, identify failed updates and respond quickly when significant vulnerabilities emerge.

Cyber Essentials can provide an important baseline.

It shouldn't be the end of the process.

A practical vulnerability-remediation SLA for SMEs

Every organisation should consider defining its own remediation targets.

For example:

These are suggested operational targets, not a universal rule that every vulnerability must be handled identically.

In fact, the NCSC's current best-practice timescales would suggest even shorter targets for internet-facing systems: five days for internet-facing services and software, seven days for operating systems and applications, and 14 days for internal or air-gapped services and software.

Most importantly, severity alone should not determine priority.

An internet-facing High vulnerability with public exploit code and evidence of active exploitation may deserve emergency treatment.

An isolated Critical vulnerability with no realistic attack path may present a very different risk.

The goal is not simply to reduce the number of red entries on a vulnerability dashboard.

The goal is to reduce the opportunities available to an attacker.

The question businesses should actually ask

Instead of asking:

"Can we patch this within 14 days?"

Ask:

"What is preventing us from patching this today?"

That question can expose weaknesses in the wider vulnerability-management process.

Perhaps you don't have an accurate asset inventory.

Perhaps nobody owns the system.

Perhaps patching is entirely manual.

Perhaps there is no emergency change process.

Perhaps updates are not being monitored.

Perhaps failed patches aren't being identified.

Perhaps the business has become dependent on unsupported software.

Perhaps there is simply no agreed process for deciding what happens when a critical vulnerability is disclosed.

If an organisation routinely needs the entire 14-day window to remediate high and critical vulnerabilities, that could indicate a vulnerability-management problem rather than simply a patching problem.

You can't fix vulnerabilities you don't know about

All of this depends on one fundamental capability:

Knowing what is vulnerable.

Regular vulnerability scanning can help organisations identify:

• Missing security updates
• Unsupported software
• Failed patches
• Vulnerable applications
• Unexpected systems
• Newly exposed services
• Persistent vulnerabilities
• Changes across the estate

The NCSC recommends automated vulnerability scanning as part of an effective vulnerability-management programme and emphasises the importance of understanding the vulnerabilities present across the technical estate.

Scanning is not vulnerability management by itself.

But without reliable visibility, effective vulnerability management becomes extremely difficult.

You can't prioritise what you don't know exists.

And you can't remediate what you haven't discovered.

Fourteen days should be the ceiling, not the goal

Cyber Essentials has done something valuable by putting a clear timeframe around the remediation of high and critical vulnerabilities.

But organisations should be careful not to interpret that timeframe as a recommended period of exposure.

The current Cyber Essentials requirements give organisations up to 14 days for certain high and critical security updates, while explicitly stating that updates should be applied as soon as possible.

The NCSC's broader vulnerability-management guidance goes further, recommending shorter best-practice timescales for internet-facing systems and ordinary operating systems and applications, and calling for an accelerated response when vulnerabilities are being actively exploited.

That distinction matters.

Because attackers don't wait 14 days.

They don't wait for your next maintenance window.

They don't wait for your change advisory board.

And they certainly don't care whether you can demonstrate compliance.

They are looking for an opportunity.

Every unpatched vulnerability represents one.

So the mature question isn't:

"Can we fix this within the Cyber Essentials deadline?"

It is:

"How quickly can we remove this opportunity from the attacker?"

For high and critical vulnerabilities, the answer should be:

As quickly and safely as possible.

Because 14 days isn't 14 days of safety.

It's 14 days of opportunity.