Patch management vs vulnerability management: what is the difference?

By Michael Obraitis, Managing Partner, and Michael Dale, CEO·Published August 12, 2026·Last reviewed August 2026·ADAM Pulse Knowledge Base

The short answer: Attackers continue exploiting old vulnerabilities because vulnerable systems continue to exist.

A vulnerability does not stop being useful to criminals simply because a patch has been available for months or years.

If an attacker can automatically find an exposed system that never received the fix, an old vulnerability can remain commercially useful attack infrastructure for a very long time.

That leads to one of the most important lessons from the honeypot experiment:

> Old vulnerability does not mean old risk.

The honeypot reportedly encountered a file identified by numerous malware scanners as WannaCry, the ransomware associated with the massive 2017 outbreak.

The extraordinary part is not merely that WannaCry is old.

The extraordinary part is what its continued appearance represents:

Attackers keep old tools because organizations keep old weaknesses.

What Is a Software Vulnerability?

A software vulnerability is a weakness in software, firmware, configuration, or system design that can potentially be exploited.

Vulnerabilities can exist in:

• Operating systems
• Applications
• Firewalls
• Routers
• VPN appliances
• Cameras
• Servers
• Cloud software
• Browsers
• Plugins
• Firmware
• Network services

The vulnerability itself is the weakness.

An exploit is a method or technique used to take advantage of that weakness.

What Is a Security Patch?

A security patch is an update intended to correct a vulnerability or other security problem.

NIST defines enterprise patch management as the process of identifying, prioritizing, acquiring, installing, and verifying patches, updates, and upgrades throughout an organization.

NIST also frames patching as preventive maintenance for technology and a necessary cost of doing business.

Why Is Patching So Important?

Because known software flaws can become repeatable attack paths.

Once defenders understand a vulnerability, vendors may release a patch.

But attackers learn about vulnerabilities too.

The security race then changes.

Before disclosure:

Who knows about the weakness?

After disclosure and patch release:

Who has actually fixed it?

NIST notes that patching helps prevent compromises, data breaches, operational disruptions, and other adverse events.

Why Do Hackers Attack Vulnerabilities That Are Years Old?

Because exploitation can be automated.

An attacker can scan large numbers of systems looking for a specific exposed service or software version.

The logic can be extremely simple:

Find system

↓

Check for weakness

↓

Attempt known exploit

↓

If successful, deploy payload

↓

Move to next system

The attacker does not care that the vulnerability is old.

The attacker cares that it still works.

Why Would Anyone Still Be Vulnerable Years Later?

Because real technology environments are complicated.

Organizations may have:

• Forgotten servers
• Unsupported applications
• Legacy operating systems
• Old network appliances
• Vendor managed systems
• Devices that cannot easily be rebooted
• Systems with compatibility concerns
• Poor asset inventories
• Failed patch deployments
• Remote offices
• IoT devices
• Test systems that became production systems

Patch management is therefore not simply:

Click Update.

It is an operational discipline.

What Was WannaCry?

WannaCry was ransomware that caused widespread disruption in May 2017.

It encrypted data and attempted to spread between vulnerable Windows systems.

The outbreak became one of the most recognizable examples of how a known software weakness combined with inadequate patch deployment can create enormous operational consequences.

CISA continues to recommend ransomware defenses that include keeping operating systems, software, and firmware updated and prioritizing remediation of known exploited vulnerabilities.

What Vulnerability Did WannaCry Exploit?

WannaCry became associated with exploitation of vulnerabilities in Microsoft's Server Message Block technology addressed by Microsoft security bulletin MS17-010.

Microsoft released security updates before the May 2017 WannaCry outbreak.

That timing is one reason WannaCry remains such an important patch management case study.

A fix can exist.

A vulnerability can be publicly understood.

And organizations can still remain exposed.

What Is EternalBlue?

EternalBlue is the name commonly associated with an exploit targeting a Windows SMB vulnerability addressed by Microsoft's MS17-010 security update.

It became widely known after the 2017 WannaCry outbreak.

The important business lesson is not the exploit's technical mechanics.

It is the timeline:

Vulnerability exists

↓

Security update becomes available

↓

Some systems remain unpatched

↓

Attackers exploit remaining exposure

This pattern continues across many vulnerabilities and products.

What Is SMB?

SMB stands for Server Message Block.

It is a network protocol used for capabilities such as file and printer sharing and other communications between systems.

SMB is legitimate technology.

The security problem arises when vulnerable implementations, unsafe versions, unnecessary exposure, or poor network controls create an attack opportunity.

Was WannaCry Preventable?

There is no single control that prevents every ransomware incident.

But the specific Windows vulnerabilities associated with WannaCry had security updates available before the global outbreak.

That makes WannaCry a powerful example of why timely patch deployment matters.

> A patch that exists but is not installed does not protect the system.

Why Do Businesses Delay Patches?

Common reasons include:

• Fear of downtime
• Compatibility testing
• Limited IT staff
• Vendor restrictions
• Maintenance windows
• Application dependencies
• Reboot requirements
• Remote systems
• Poor inventory
• Unclear ownership
• Change management
• Concern that the patch may break something

These concerns can be legitimate.

The solution is not to ignore them.

The solution is to build a patch management process capable of balancing operational and cybersecurity risk.

Can Security Patches Break Things?

Yes.

Updates can occasionally introduce compatibility problems, performance changes, application issues, or unexpected behavior.

That is why mature organizations use processes such as:

• Testing
• Pilot groups
• Change control
• Backups
• Maintenance windows
• Rollback planning
• Verification

The existence of patching risk does not eliminate vulnerability risk.

Organizations need to manage both.

What Is Patch Management?

Patch management is the structured process used to identify, evaluate, prioritize, test, deploy, and verify software and firmware updates.

NIST SP 800 40 Revision 4 describes enterprise patch management as preventive maintenance.

A mature process asks:

What needs patching?

How important is the vulnerability?

Is the vulnerability being actively exploited?

How exposed is the system?

What could the patch affect?

When will we deploy it?

How will we verify installation?

Patch Management vs. Vulnerability Management

These terms overlap but are not identical.

Patch Management

Focuses on managing software, firmware, updates, and patches.

Vulnerability Management

Is broader.

It includes identifying, assessing, prioritizing, remediating, and tracking weaknesses.

Not every vulnerability is solved by a patch.

Some may require:

• Configuration changes
• Network restrictions
• Disabling a service
• Replacing equipment
• Removing software
• Compensating controls

Patching is one major part of vulnerability management.

What Is Vulnerability Scanning?

Vulnerability scanning uses tools to identify systems and potential weaknesses.

Scanners may examine:

• Software versions
• Missing patches
• Open services
• Configuration
• Known vulnerabilities

Scanning helps answer:

Where might we be exposed?

But scanning alone does not remediate the problem.

Does a Vulnerability Scanner Fix Vulnerabilities?

Usually not by itself.

Discovery and remediation are different functions.

A scanner can report:

Critical vulnerability detected.

Someone or some process still needs to:

Assign ownership

Assess impact

Patch or mitigate

Verify remediation

This is where many programs fail.

They become excellent at producing vulnerability reports and poor at closing vulnerabilities.

What Is a CVE?

CVE stands for Common Vulnerabilities and Exposures.

CVE identifiers provide standardized names for publicly disclosed cybersecurity vulnerabilities.

A CVE might look like:

CVE 2026 XXXX

The identifier helps vendors, researchers, security tools, and organizations refer to the same vulnerability consistently.

Does a High CVE Score Mean Patch Immediately?

Not automatically.

Severity is important, but organizations should also consider context.

Questions include:

• Is the vulnerability actively exploited?
• Is the system internet facing?
• What privileges are required?
• Is exploitation remote?
• What data or business process is affected?
• Are compensating controls present?
• Is the system critical?
• Is a patch available?

Risk based prioritization is more useful than sorting only by a numerical score.

What Is CVSS?

CVSS stands for Common Vulnerability Scoring System.

It provides a standardized method for describing vulnerability severity.

CVSS is useful.

But it is not a complete business risk score.

A vulnerability on an isolated test machine and the same vulnerability on an internet facing production server may create very different business risk.

What Is CISA's Known Exploited Vulnerabilities Catalog?

CISA maintains the Known Exploited Vulnerabilities Catalog, often called the KEV Catalog.

It identifies vulnerabilities for which there is evidence of exploitation in the wild.

This can help organizations prioritize vulnerabilities that are not merely theoretical.

CISA encourages organizations to use the KEV Catalog as an input to vulnerability management prioritization.

Why Is Active Exploitation Such an Important Signal?

Imagine two vulnerabilities.

Vulnerability A

Critical theoretical severity, but no known exploitation.

Vulnerability B

Slightly lower severity, but attackers are actively exploiting it against organizations today.

Both may matter.

But active exploitation changes urgency.

This is why patch prioritization should incorporate threat intelligence rather than relying only on severity scores.

What Is a Zero Day Vulnerability?

A zero day generally refers to a vulnerability for which defenders or the vendor have had little or no time to prepare, particularly when exploitation is occurring before an effective patch is broadly available.

Zero days receive enormous attention.

But many real compromises involve vulnerabilities that are not zero days at all.

They are known weaknesses with available fixes.

> The most famous vulnerabilities may be new. The most practical vulnerabilities may simply be unpatched.

Zero Day vs. N Day Vulnerability

Security professionals sometimes refer to a known vulnerability with an available fix as an N day vulnerability.

A zero day creates the difficult problem:

No patch yet.

An old known vulnerability creates a different problem:

Patch exists, but the organization has not deployed it everywhere.

Both matter.

But the second is often an operational management problem.

Why Do Attackers Prefer Known Vulnerabilities?

Known vulnerabilities can offer attackers:

• Public technical details
• Existing exploit code
• Known target software
• Repeatable scanning
• Predictable outcomes
• Large numbers of potential victims

Attackers value reliability.

They do not receive extra credit for using a new vulnerability when an old one still opens the door.

What Is Exploit Code?

Exploit code is software or a technique designed to take advantage of a vulnerability.

Exploit research can be used legitimately by:

• Security researchers
• Penetration testers
• Vendors
• Defenders

It can also be abused by attackers.

Once exploitation knowledge becomes widely available, organizations should assume that capable attackers may incorporate it into automated tooling.

How Quickly Should Businesses Patch?

There is no universal patch deadline appropriate for every vulnerability and system.

Organizations should establish risk based service levels.

Urgency may increase when:

• Active exploitation is confirmed
• The system is internet facing
• Exploitation requires little interaction
• The vulnerability enables remote code execution
• Critical systems are affected
• Sensitive data is exposed
• CISA adds the vulnerability to KEV

Lower risk systems may follow normal maintenance schedules.

The key is to define the rules before the emergency.

What Is Emergency Patching?

Emergency patching is an accelerated process used when the risk of waiting exceeds the normal operational risk of change.

An emergency process might involve:

Rapid assessment

↓

Target identification

↓

Accelerated testing

↓

Deployment

↓

Verification

↓

Enhanced monitoring

Organizations should design this process before a critical vulnerability appears.

Why Verification Matters After Patching

A deployment tool reporting:

Patch sent

does not necessarily mean:

Patch successfully installed.

Systems may be:

• Offline
• Out of disk space
• Misconfigured
• Unable to reboot
• Disconnected from management
• Experiencing update failures

NIST's definition of enterprise patch management explicitly includes verifying the installation of patches and updates.

> Patch deployment is an action. Patch verification is evidence.

Why Asset Inventory Is Essential to Patching

You cannot patch a system you do not know exists.

Imagine receiving a critical vulnerability alert.

The first question becomes:

Do we run this product?

Then:

Where?

Then:

Which versions?

Without reliable inventory, organizations may spend the first hours of an emergency simply trying to identify affected systems.

What Should an Asset Inventory Include?

Depending on the environment:

• Device name
• Owner
• Location
• Operating system
• Software
• Firmware
• Version
• IP address
• Business function
• Support status
• Internet exposure
• Criticality
• Patch responsibility

The inventory does not need to begin perfectly.

It needs to become trustworthy.

What Is Shadow IT?

Shadow IT refers to technology used without appropriate visibility or governance from the organization's technology or security teams.

Examples might include:

• Unapproved cloud applications
• Test servers
• Department purchased software
• Old remote access tools
• Unmanaged devices

Shadow IT creates patching risk because ownership may be unclear.

Why Are Forgotten Servers Dangerous?

A forgotten server may still be:

Powered on

Internet connected

Running software

Accepting connections

The business may have forgotten it.

Automated scanners have not.

> Attackers do not need your asset inventory. They can build their own from what you expose.

Why Are Legacy Systems Difficult to Patch?

Legacy systems may depend on:

• Old applications
• Unsupported operating systems
• Specialized hardware
• Vendor certifications
• Industrial equipment
• Medical equipment
• Custom software

The organization may fear that an update will break the business process.

That can create long term vulnerability exposure.

What Is End of Life Software?

End of life software is technology that the vendor no longer supports according to its lifecycle policy.

Security updates may stop.

That means newly discovered vulnerabilities may remain unresolved.

An end of life system can continue functioning operationally while becoming increasingly difficult to secure.

Does “It Still Works” Mean It Is Safe?

No.

Operational functionality and security support are different things.

A ten year old server may:

Boot successfully

Run the application

Serve customers

and still:

Lack current security support.

This distinction is critical for budgeting.

Replacing unsupported technology is not merely an upgrade project.

It can be risk reduction.

What Are Compensating Controls?

When a patch cannot be deployed immediately, organizations may use temporary controls to reduce exposure.

Depending on the vulnerability, these might include:

• Disabling the vulnerable service
• Restricting network access
• Blocking external exposure
• Segmentation
• Application controls
• Increased monitoring
• Vendor recommended mitigations

Compensating controls should not become permanent excuses for avoiding remediation unless the risk is formally understood and accepted.

Why Network Segmentation Matters for Unpatched Systems

If a vulnerable system cannot immediately be patched, segmentation can limit who and what can reach it.

Segmentation can also limit the system's ability to reach unrelated resources if it becomes compromised.

It does not remove the vulnerability.

It reduces exposure and potential blast radius.

What Is Attack Surface Reduction?

Attack surface reduction means reducing the number of opportunities attackers can use.

Examples include:

• Closing unnecessary ports
• Removing unused software
• Disabling unused services
• Restricting remote administration
• Eliminating default accounts
• Removing obsolete systems
• Limiting internet exposure

Sometimes the safest vulnerable service is the one the business does not actually need to run.

Why Internet Facing Systems Need Special Attention

Internet facing systems can be discovered by automated scanners.

Examples include:

• VPN gateways
• Firewalls
• Web servers
• Remote desktop services
• SSH
• Email systems
• File transfer services

A critical vulnerability on an exposed edge device may deserve substantially greater urgency than the same vulnerability on an isolated internal test system.

Why VPN and Firewall Patching Matters

Organizations sometimes focus patching on Windows laptops and servers while overlooking infrastructure appliances.

But firewalls, VPN gateways, routers, and other edge systems also run software.

They can contain vulnerabilities.

And because they often sit at the boundary of the network, they can be highly attractive targets.

Firmware belongs in vulnerability management too.

What Is Firmware?

Firmware is software embedded in hardware devices.

Routers, cameras, firewalls, printers, storage systems, and IoT devices may all depend on firmware.

Firmware updates can include security fixes.

A patch management program that covers only employee computers is incomplete.

Why Are Remote Offices Hard to Patch?

Distributed environments may include:

• Different internet connections
• Local firewalls
• Limited bandwidth
• Devices that are rarely online
• No local IT staff
• Different maintenance windows

Central visibility becomes especially important.

Organizations need to know not only:

Did we approve the update?

but:

Did the remote device actually receive it?

Why Do Reboots Matter?

Some patches require a restart before the update becomes fully effective.

A system can therefore report an update while still waiting for a reboot.

Organizations need processes for:

• Scheduling restarts
• Communicating downtime
• Verifying services afterward
• Confirming patch state

The unfinished reboot can become the forgotten last step.

Can Automatic Updates Solve Patch Management?

Automatic updates can significantly improve security for many systems.

But enterprise environments may still require:

• Testing
• Scheduling
• Compatibility management
• Verification
• Exception handling
• Reporting

Automation is valuable.

Governance is still necessary.

What Is Patch Compliance?

Patch compliance measures whether systems meet an organization's defined update requirements.

For example:

Critical patches installed within required timeframe

Supported operating system version

No outstanding high priority updates

Compliance metrics should help identify exceptions rather than simply create attractive dashboards.

Why “95 Percent Patched” Can Still Be Dangerous

Suppose an organization has 1,000 systems.

A 95 percent patch rate sounds excellent.

But that leaves:

50 systems unpatched.

Now suppose the 50 include:

Internet facing servers

VPN appliances

domain controllers

critical production systems.

The percentage alone hides the risk.

> Patch management is not only about how many systems are current. It is about which systems are not.

What Is Vulnerability Remediation?

Remediation is the action taken to remove or sufficiently reduce a vulnerability.

That may involve:

• Installing a patch
• Changing configuration
• Disabling a service
• Upgrading software
• Replacing equipment
• Restricting access

The desired outcome is reduced risk, not merely closing a ticket.

What Is a Vulnerability Exception?

Sometimes a vulnerability cannot be remediated within the normal timeframe.

A formal exception process should document:

• The vulnerability
• Affected system
• Business owner
• Reason for delay
• Compensating controls
• Residual risk
• Expiration or review date
• Remediation plan

An exception should represent a conscious risk decision.

Not forgotten work.

Why Patch Management Is a Business Process

Patching touches:

Security

Operations

Finance

Application owners

Vendors

Leadership

End users

A critical server cannot always be rebooted whenever IT wants.

A medical device may require vendor approval.

A restaurant location may need updates outside operating hours.

A manufacturing system may support continuous production.

Patch management therefore requires coordination.

NIST specifically frames patching as preventive maintenance that organizations need in order to achieve their missions.

Patch Management Is Preventive Maintenance

Businesses already understand preventive maintenance elsewhere.

You change oil before an engine fails.

You replace worn components before equipment stops.

You inspect safety systems before an emergency.

Cybersecurity patching follows a similar principle.

> Do not wait for exploitation to prove that maintenance was necessary.

Where USA Telecom and ADAM Fit

USA Telecom and ADAM are not replacements for vulnerability scanners, endpoint management platforms, patch deployment systems, EDR, SIEM, or professional vulnerability management services.

Their value can support the operational visibility surrounding technology maintenance.

After a patch or firmware change, teams may need to know:

Did the device come back online?

Did the VPN tunnel recover?

Did voice services register?

Did the circuit fail over?

Did latency change?

Is the remote site reachable?

Did the firewall remain stable?

That matters because security teams need to patch.

Operations teams need confidence that the business still works afterward.

Patch Management and Network Monitoring Should Work Together

Consider a remote firewall.

Vulnerability management: Critical update required.

Change management: Maintenance approved.

Patch system: Firmware installed.

Network monitoring: Device stops responding.

Monitoring: Backup circuit activates.

Monitoring: Primary service returns.

Validation: VPN tunnel restores.

Ticketing: Maintenance documented and closed.

That is a complete operational story.

The patch is only one step.

Why Monitoring Can Make Businesses More Comfortable With Patching

One reason organizations delay changes is fear:

What if something breaks?

Better monitoring can reduce that uncertainty.

Teams can establish:

Before change baseline

↓

Deploy update

↓

Watch availability and performance

↓

Validate critical services

↓

Escalate abnormalities

This does not eliminate patch risk.

It improves operational confidence.

25 Patch Management Questions Every Business Should Ask

1. Do we know every system that requires patching?
2. Do we inventory operating systems?
3. Do we inventory applications?
4. Do we inventory firmware?
5. Do we know which systems are internet facing?
6. Do we know which systems are end of life?
7. Who owns patching for each system?
8. Who owns vendor managed equipment?
9. How quickly do we address actively exploited vulnerabilities?
10. Do we use CISA KEV in prioritization?
11. Do we have an emergency patch process?
12. Do we test critical updates?
13. Do we have rollback plans?
14. Do we know which patches require reboots?
15. Do we verify successful installation?
16. Can we identify failed deployments?
17. Can we identify systems that were offline during deployment?
18. Do remote offices receive updates reliably?
19. Are firewalls and VPN appliances included?
20. Are cameras and IoT devices included?
21. Are vulnerability exceptions documented?
22. Do exceptions have expiration dates?
23. Do we monitor systems after significant updates?
24. Can we validate critical business services after patching?
25. Would we know today which systems remain vulnerable to a newly exploited weakness?

The Better Question Is Not “Did We Deploy the Patch?”

Ask:

Did every affected system receive it?

Did installation succeed?

Did the system reboot if required?

Is the vulnerability actually gone?

Did the application continue working?

Did the remote location return online?

Are there systems we forgot?

Are unsupported systems still exposed?

Did we document exceptions?

Are attackers already exploiting this vulnerability?

That is patch management.

Key Takeaway

WannaCry remains an extraordinary cybersecurity lesson because it demonstrates the difference between:

A vulnerability being fixed by the vendor

and

a vulnerability being fixed inside your business.

Those are not the same event.

A security update can exist for months.

If the vulnerable system never receives it, the attack surface remains.

NIST frames enterprise patch management as preventive maintenance and defines the process as identifying, prioritizing, acquiring, installing, and verifying patches, updates, and upgrades.

CISA continues to emphasize timely updates as a fundamental ransomware defense. citeturn0search0turn0search6

The business lesson is simple:

> A patch that exists but is not installed does not protect the system.

And perhaps the more important lesson is:

> Old vulnerability does not mean old risk.

Attackers automate scanning.

Attackers preserve techniques that still work.

Attackers do not care whether the vulnerability appeared yesterday or years ago.

They care whether your system is still vulnerable today.

So patch management should not be treated as an occasional IT cleanup project.

It is preventive maintenance.

Know what you have.

Know what versions are running.

Know what is exposed.

Prioritize real risk.

Patch or mitigate.

Verify.

Monitor.

And replace technology that can no longer be secured.

Because the age of the exploit is far less important than one question:

> Does it still work against you?

Frequently asked questions

Sources

• CISA — Known Exploited Vulnerabilities (KEV) Catalog. “CISA maintains the authoritative source of vulnerabilities that have been exploited in the wild”, and organizations “should use the KEV catalog as an input to their vulnerability management prioritization framework.”
• Microsoft — Microsoft Security Bulletin MS17-010 — Critical: Security Update for Microsoft Windows SMB Server (4013389), published 14 March 2017. Six SMBv1 CVEs, five remote code execution and one information disclosure.
• CISA / US-CERT — Alert TA17-132A: Indicators Associated With WannaCry Ransomware (12 May 2017). WannaCry propagated via the MS17-010/EternalBlue SMBv1 exploit.
• CISA — Cyber Hygiene Services. Free vulnerability and web application scanning for enrolled organizations.
• CISA, NSA, FBI and MS-ISAC — #StopRansomware Guide (v3.1, October 2023).
• NIST — The NIST Cybersecurity Framework (CSF) 2.0 (NIST CSWP 29, 26 February 2024).
• NIST — NIST Cybersecurity Framework 2.0: Small Business Quick-Start Guide (NIST SP 1300, February 2024).
• FTC — Cybersecurity for Small Business.

USA Telecom Consulting LLC is a Service-Disabled Veteran-Owned Small Business running a 24/7 NOC. We monitor networks, circuits and firewalls for regulated and defense-supply-chain organizations.

← More from the ADAM Pulse Knowledge Base

Prepared by ADAM Pulse (USA Telecom Consulting LLC) — managed AI governance, network, and NOC services. Support: (888) 989-4872 · support@adampulse.us