A patch fixes the flaw itself. A mitigation reduces the chance or the impact of the flaw being exploited, but usually leaves the flaw in place.

 

What is a patch?

The US National Institute of Standards and Technology (NIST) defines patching in its enterprise guidance, Special Publication 800-40 Revision 4, as the act of applying a change to installed software, whether firmware, an operating system or an application, that corrects security or functionality problems or adds new capabilities. The same publication describes enterprise patch management as the full cycle of identifying, prioritizing, acquiring, installing and verifying patches, updates and upgrades across an organization.

The authors, Murugiah Souppaya and Karen Scarfone, argue that patching should be treated like the servicing of a company vehicle fleet, routine maintenance that prevents expensive breakdowns, rather than an optional extra. In their framing, it is a standard cost of doing business that organizations should follow and track.

Why is the patch the gold standard?

According to the same NIST document, installing a patch, update or upgrade to a version without the flaw are the only responses that can eliminate a vulnerability without removing functionality. Everything else works around the problem.

Learn more: What is patch management?

 

What is a mitigation?

A mitigation is any measure that lowers risk without correcting the underlying defect. NIST gives examples such as disabling a vulnerable feature, deploying firewalls, and using network segmentation to isolate vulnerable assets so that the attack surface shrinks. When a patch does not yet exist, NIST describes an emergency mitigation as a procedure used to “temporarily mitigate vulnerabilities before a patch is available.”

Typical mitigations include:

  • Turning off a risky feature or service
  • Blocking certain network traffic at a firewall
  • Moving a vulnerable system onto an isolated network segment
  • Restricting who can reach the system
  • Applying a vendor-supplied configuration change or workaround
  • Increasing monitoring so that exploitation is spotted quickly

 

Where the terms get confusing

In NIST’s risk-response vocabulary, “mitigate” is a broad category. NIST lists four responses to software risk: accept, mitigate, transfer and avoid. Under “mitigate,” the agency includes both eliminating the vulnerability, for example by patching or upgrading, and deploying extra controls that reduce exploitation.

That is why government bodies often say “mitigate” when they actually mean “patch.” When the US Cybersecurity and Infrastructure Security Agency (CISA) launched Binding Operational Directive 22-01 in November 2021, its stated aim was to push federal agencies to mitigate actively exploited vulnerabilities, and the directive states that known exploited vulnerabilities should be “the top priority for remediation.”

 

When a patch is not an option

NIST’s guidance lists several practical reasons that immediate patching is sometimes not viable:

  • No patch exists yet. A vulnerability may be announced before a fix is ready, and NIST notes it could be days, weeks or months before one is released.
  • The product is end-of-life. If the vendor no longer supports the software, a patch will never arrive.
  • Operational constraints. The organization may need to wait for a scheduled outage window, run tests, or update other software that interacts with the component.
  • Regulatory or safety limits. Some equipment, particularly in highly regulated sectors, can only be updated on a delayed schedule after extensive testing and certification, and updating it independently may void warranties.
  • Competing priorities. Limited staff means some patches wait while higher-priority ones go first.

NIST also warns that emergency mitigations are sometimes needed because a patch itself is flawed. A patch might fail to fix the vulnerability, might disrupt other systems, or might even be compromised.

 

Case study: Log4Shell

The December 2021 Log4Shell crisis shows both tools in action. According to a joint advisory from CISA, the FBI, the NSA and the cyber agencies of Australia, Canada, New Zealand and the United Kingdom, Log4Shell was disclosed on December 10, 2021, and public reporting indicated exploitation had begun around December 1. The advisory reports that a proof-of-concept exploit was publicly available and that the FBI had observed widespread scanning, with attackers deploying cryptomining and botnet malware.

A follow-on weakness, CVE-2021-45046, was disclosed on December 13 and led Apache to release version 2.16.0. Another, CVE-2021-45105, was disclosed on December 16, prompting version 2.17.0, which the advisory dates to December 17, 2021. In other words, the “fix” itself needed fixing within a week.

For organizations that could not update immediately, the agencies recommended vendor-provided mitigations. The advisory said these workarounds “should not be considered permanent fixes,” and warned that other mitigations should be used at the organization’s own risk because they may be incomplete, temporary, or cause harmful effects such as application instability or a denial-of-service condition.

The advisory also shows how mitigation and patching work together rather than competing:

  1. Isolate known and suspected vulnerable assets, treating them as compromised until they are mitigated and verified.
  2. Patch the affected library to the latest version, noting that updating Java alone is not enough.
  3. Apply workarounds only where an immediate patch is not possible.
  4. Verify the result using more than one method, and keep monitoring.

The agencies also flagged a trap, because attackers were reported to patch machines they had already compromised in order to keep exclusive control, defenders were urged to keep careful records of which assets had been patched and when. A “patched” status alone does not prove an asset is clean.

 

Why patching still lags

Even when a patch exists, many systems stay exposed for a long time. A peer-reviewed study presented at the IEEE Symposium on Security and Privacy in 2015 by Antonio Nappa and colleagues analyzed patch deployment for 1,593 vulnerabilities across 10 popular client applications. The researchers found that the median time to patch half of the vulnerable hosts was 18 days for security analysts and 24 days for software developers, but 45 days for general users, more than double the analysts’ figure. That gap between a patch being published and a patch being installed is the window in which mitigations are used.

NIST describes the same tension from the enterprise side. Its guidance explains that deploying patches faster narrows the attackers’ window but raises the chance of disruption from insufficient testing, while heavier testing lowers disruption but widens the window. The agency also warns that delaying routine patching makes later emergency patching harder, because earlier patches that new ones depend on must be installed first.

 

Not everything can be patched at once

Since no organization can fix everything immediately, prioritization is important. CISA’s Known Exploited Vulnerabilities catalog is one tool for this. NIST notes that CISA’s directive requires federal agencies to remediate newly cataloged vulnerabilities within two weeks, and that other organizations may voluntarily use the catalog to prioritize their own patching.

CISA’s director at the time, Jen Easterly, told a House Homeland Security Committee hearing, as reported by GovInfoSecurity, that the directive “fundamentally changes how the federal civilian government addresses vulnerabilities” under active exploitation. The UK’s National Cyber Security Centre (NCSC) takes a similar view of choices and responsibility. Its vulnerability management guidance sets a default of updating as soon as possible, but accepts that sometimes an update does not exist or does not fix the problem, in which case organizations need a process to triage and prioritize. It also makes clear that deciding not to update is a senior-level risk decision, and states that “The organization must own the risks of not updating.”

 

The AI-era ‘patch wave’

The NCSC’s chief technology officer, Ollie Whitehouse, warned in an article, reported by Computer Weekly, that AI-assisted vulnerability discovery could force a correction of accumulated technical debt across software. He urged organizations to prepare for a “patch wave,” which he described as “a rush of software updates” across the technology stack.

Computer Weekly’s summary of the NCSC advice reminds readers that patching and mitigation are partners. The guidance tells teams to prioritize internet-facing systems first, to turn on supplier-provided automatic hot-patching where it exists, and to bring forward update schedules for zero-day flaws. It also notes that patching alone will not always be enough, since legacy and end-of-life systems that cannot be patched need to be brought back into support or replaced, and that organizations should keep investing in cybersecurity fundamentals to limit the damage from any breach.

 

Practical steps

From the different official guidances noted above, these can be used as a good approach:

  1. Know what you run. NIST recommends maintaining a constantly updated inventory of software and assets, since you cannot patch or mitigate what you do not know you have.
  2. Decide your responses in advance. NIST suggests defining scenarios such as routine patching, emergency patching, emergency mitigation and unpatchable assets, so decisions are quick when a crisis arrives.
  3. Patch by default. Make updating the standard, ideally automated, as the NCSC advises.
  4. Mitigate when you must. Use isolation, feature shut-offs and vendor workarounds when no patch exists or cannot yet be deployed.
  5. Treat mitigations as temporary. Track them, and schedule their removal once the real fix is installed.
  6. Verify. Confirm that the patch took effect or the mitigation works, preferably using more than one method, as CISA and its partners advised during Log4Shell.
  7. Plan for the unpatchable. NIST says long-term mitigations such as isolation should be reviewed and periodically re-evaluated for old or mission-critical assets that cannot be updated.

 

FAQs

Why do vulnerabilities exist in software in the first place?

Vulnerabilities arise from human error, design oversights, and the sheer complexity of modern code, so no software of any size can be guaranteed flaw-free.

 

What is the difference between a vulnerability and an exploit?

A vulnerability is the weakness itself, while an exploit is the method or code that takes advantage of it.

 

What does a vulnerability severity score mean?

Scoring systems such as CVSS rate how serious a flaw is, helping organizations decide which ones to address first.

 

Do small businesses need a formal patch management process?

Yes, because attackers target organizations of every size.