ADAM PULSE Knowledge Base
Cybersecurity · Vulnerability Management · Legacy Risk

Why do old cybersecurity vulnerabilities still matter?

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

The short answer: Old cybersecurity vulnerabilities still matter because vulnerable systems can remain in use for years after a fix becomes available. Attackers do not stop exploiting a weakness simply because it is old. If a system is still exposed, still vulnerable, and still reachable, the opportunity may remain.

That is one of the most important lessons from WannaCry.

Microsoft released the critical security update associated with the vulnerability later exploited by WannaCry on March 14, 2017. The WannaCry outbreak began spreading widely in May 2017, roughly two months later. Microsoft’s bulletin stated that the vulnerability could allow remote code execution through specially crafted traffic sent to vulnerable SMBv1 servers.

The software fix existed.

Many affected systems simply had not received it.

That leads to a cybersecurity principle every business should understand:

> A patch existing does not mean the vulnerability has disappeared.

The vulnerability remains relevant anywhere the patch has not been installed or the affected technology has not been retired.

And automated attackers can keep looking.

What Is a Software Vulnerability?

A software vulnerability is a weakness that may allow an attacker to affect the confidentiality, integrity, or availability of a system.

Vulnerabilities can exist in:

Some vulnerabilities cause relatively minor problems.

Others can potentially allow:

The important point is that security vulnerabilities are not limited to traditional computers.

Almost any device running software can potentially contain them.

What Is a Security Patch?

A security patch is an update intended to correct a security weakness.

A vendor may release a patch after:

Installing the patch changes the affected software so the known weakness is no longer exploitable in the same way.

That sounds simple.

Operationally, it often is not.

Why Don’t Businesses Install Every Patch Immediately?

There are legitimate reasons organizations sometimes delay updates.

Businesses may need to consider:

Imagine a hospital system, manufacturing line, financial platform, or restaurant point of sale environment.

The organization cannot always say:

“A patch exists. Install it everywhere right now.”

An update could unintentionally disrupt an important application.

That is why patch management is a process.

The objective is not reckless updating.

It is risk based, timely remediation.

What Is Patch Management?

Patch management is the organized process of identifying, evaluating, testing, deploying, and verifying software updates.

NIST describes patching as a critical part of preventive maintenance and a necessary cost of doing business. NIST recommends that organizational leadership, business owners, and technology teams develop a coordinated strategy that operationalizes patching and reduces cybersecurity risk.

A mature patch process asks:

What systems do we have?

Which systems are affected?

How serious is the vulnerability?

Is it being actively exploited?

Is the system internet facing?

Can we patch it immediately?

Do we need testing first?

What happens if we cannot patch it?

How do we verify remediation?

That is much more sophisticated than:

“Run Windows Update every once in a while.”

What Was WannaCry?

WannaCry was ransomware that spread widely in May 2017.

It encrypted files on affected systems and demanded payment.

Its impact was significant because the malware was also capable of spreading between vulnerable Windows systems.

The outbreak affected organizations around the world.

One of the reasons WannaCry became such an important cybersecurity case study is that Microsoft had already released security updates addressing the underlying SMB vulnerabilities before the outbreak.

Microsoft published security bulletin MS17-010 on March 14, 2017. The bulletin classified the update as critical and explained that specially crafted messages sent to an SMBv1 server could allow remote code execution.

The patch existed before the widespread attack.

That fact makes WannaCry one of the clearest examples of why patch management matters.

Did WannaCry Exploit an Unpatched Vulnerability?

Yes.

WannaCry exploited weaknesses associated with Microsoft's Server Message Block protocol.

Microsoft's MS17-010 security update addressed the relevant SMB vulnerabilities before the May 2017 outbreak.

That means organizations that remained vulnerable after the patch became available faced a preventable exposure.

This does not mean patching would have prevented every operational impact in every organization.

But the broader lesson is powerful:

> Known vulnerabilities create known defensive actions.

Once a vendor provides a fix, the risk conversation changes.

The question becomes:

Have we applied it?

Why Would Attackers Exploit an Old Vulnerability?

Because old vulnerabilities can still work.

Attackers care less about a vulnerability's birthday than defenders sometimes do.

They care about:

Does it still work?

If vulnerable systems remain available, an older exploit may remain useful.

In some cases, an older vulnerability can actually become easier for attackers to use over time because:

The vulnerability gets older.

The attacker's job may get easier.

Do Hackers Still Scan for Old Vulnerabilities?

Yes.

Automated systems can search for technologies and versions associated with known weaknesses.

This means attackers do not need to assume every organization is current.

They can look for the exceptions.

Imagine a vulnerability from five years ago.

Ninety nine percent of companies may have fixed it.

That sounds encouraging.

But if automated scanning can identify the remaining one percent, those systems still represent targets.

Attack automation changes the economics.

The attacker does not need every organization to be vulnerable.

They only need to find the ones that are.

Why Known Vulnerabilities Can Be Attractive to Attackers

A previously documented vulnerability gives attackers information.

They may know:

Defenders have access to much of the same information.

This creates a race between:

Remediation

and

Exploitation.

The vulnerability disclosure itself is not the problem.

Public disclosure helps defenders understand and correct risk.

The danger is leaving known weaknesses unresolved.

What Is a CVE?

CVE stands for Common Vulnerabilities and Exposures.

The CVE system provides standardized identifiers for publicly known cybersecurity vulnerabilities.

An identifier might look like:

CVE 2025 XXXX

The identifier allows:

to refer to the same vulnerability consistently.

Think of a CVE number as a standardized reference number for a security flaw.

Does Every CVE Need to Be Patched Immediately?

Not necessarily.

Thousands of vulnerabilities can be disclosed over time.

Organizations need prioritization.

Factors may include:

This is why vulnerability management should not become:

Patch everything in numerical order.

Some vulnerabilities deserve much faster action than others.

What Is CVSS?

CVSS stands for Common Vulnerability Scoring System.

It provides a standardized way of describing vulnerability severity.

You may see vulnerabilities categorized with scores such as:

Low

Medium

High

Critical

Severity is useful.

But severity alone should not determine patch priority.

A vulnerability with a very high score on an isolated test system may present less immediate risk than a slightly lower scored vulnerability being actively exploited against an internet facing firewall.

Context matters.

What Is CISA’s Known Exploited Vulnerabilities Catalog?

The Cybersecurity and Infrastructure Security Agency maintains the Known Exploited Vulnerabilities Catalog, often called the KEV Catalog.

CISA describes it as an authoritative source for vulnerabilities known to have been exploited in the wild and recommends that organizations use it as an input to vulnerability management prioritization.

This is extremely useful.

A vulnerability may have a theoretical risk.

Another may have evidence showing attackers are actually using it.

Those two situations deserve different urgency.

Known Exploited Should Mean Higher Attention

Imagine two vulnerabilities.

Vulnerability A

High severity.

No known evidence of active exploitation.

System is internal and heavily restricted.

Vulnerability B

Slightly lower severity.

Actively exploited.

System is directly exposed to the internet.

Which should receive attention first?

Likely Vulnerability B.

This demonstrates why patching should be risk based rather than purely score based.

CISA's KEV Catalog provides defenders with one important piece of that context.

What Does “Exploited in the Wild” Mean?

It means there is evidence that attackers have actually used the vulnerability against real systems.

This is different from:

“Researchers proved exploitation is theoretically possible.”

Real world exploitation increases urgency.

It means someone has moved from:

Could this work?

to

This has worked.

That should influence vulnerability prioritization.

What Is a Zero Day Vulnerability?

A zero day generally refers to a vulnerability for which defenders may not yet have an available patch when exploitation or disclosure occurs.

Zero days receive enormous attention because organizations may have limited defensive options.

But businesses should not let the excitement around zero days distract them from a more common problem:

Known vulnerabilities that simply have not been fixed.

A company can spend enormous amounts of money worrying about sophisticated unknown attacks while leaving a three year old critical vulnerability unpatched.

Cybersecurity needs both perspectives.

What Is an N Day Vulnerability?

Security professionals sometimes use terms such as N day or one day vulnerability to describe a flaw that has already been publicly disclosed.

A patch may already exist.

That changes the attack dynamic.

Attackers know about it.

Defenders know about it.

The question becomes:

Who acts first?

The defender installs the patch.

Or the attacker finds the vulnerable system.

Are Old Vulnerabilities Easier to Exploit?

Sometimes.

Over time, attackers may gain access to:

An exploit that initially required significant expertise may eventually become easier to use.

This creates a counterintuitive reality:

> A vulnerability can become technically older while becoming operationally easier to attack.

Age does not automatically reduce risk.

Why Are Internet Facing Systems More Urgent?

Because attackers can potentially reach them directly.

Examples include:

An internal vulnerability still matters.

But public exposure can make discovery and exploitation easier.

This is why internet facing vulnerabilities frequently deserve faster remediation.

What Should Be Patched First?

There is no universal list for every business.

But priority should often increase when several factors combine:

Known active exploitation

plus

Internet exposure

plus

High privileges

plus

Critical business system

plus

No compensating controls.

That is a very different risk from:

Low impact vulnerability

plus

isolated lab computer

plus

no internet access.

Patch management is ultimately risk management.

Should Firewalls Be Patched Quickly?

Yes.

Firewalls are security devices, but they are also internet facing computers running software.

CISA's Known Exploited Vulnerabilities Catalog includes vulnerabilities affecting firewall products and routinely instructs organizations to apply vendor updates or mitigations for affected technologies. For example, CISA has cataloged exploited vulnerabilities affecting firewall platforms and directed organizations toward vendor remediation.

The lesson is important:

Security equipment needs security maintenance too.

A firewall does not become immune to vulnerabilities because its purpose is security.

What About VPN Appliances?

The same principle applies.

VPN appliances are often publicly reachable because remote users need to connect.

That makes vulnerability management especially important.

Ask:

Is the VPN current?

Is the firmware supported?

Are known vulnerabilities present?

Is MFA enabled?

Is unnecessary access disabled?

Are authentication logs monitored?

VPN security requires both identity protection and software maintenance.

Do Routers Need Security Updates?

Yes.

Routers run software and firmware.

They can contain vulnerabilities.

They may remain deployed for many years.

Businesses should know:

What router models are installed?

Which firmware versions are running?

Are they still supported?

Who is responsible for updates?

A router that continues forwarding traffic is not automatically a safe router.

Again:

Working does not necessarily mean secure.

Do Security Cameras Need Patches?

Yes.

Security cameras are computers.

They may contain:

All of those components can potentially contain vulnerabilities.

A camera may remain installed for ten years.

That creates an important lifecycle question:

Does the manufacturer still provide security updates?

What Is End of Life Software?

End of life software or hardware has reached a stage where the manufacturer no longer provides normal support.

That can eventually include security updates.

The device may still function perfectly.

But a newly discovered vulnerability may never receive a fix.

CISA's KEV guidance sometimes directs organizations to discontinue use of products where remediation is unavailable, particularly for end of life technologies.

This is why lifecycle management belongs in cybersecurity.

What Is End of Support?

End of support generally means the vendor no longer provides the normal updates, technical support, or security maintenance associated with a product.

Exact terminology varies by manufacturer.

The important business question is:

If a serious vulnerability is discovered tomorrow, will anyone fix it?

If the answer is no, the organization needs another plan.

“It Still Works” Is Not a Security Strategy

Imagine a ten year old firewall.

The internet works.

Employees can browse.

VPN connects.

Phones function.

Management says:

“Why replace it?”

Because the relevant question may not be:

Does it work?

It may be:

Is it still supportable and securable?

This distinction is critical.

Technology lifecycle decisions should consider:

Not just whether the power light is on.

What Should You Do If a System Cannot Be Patched?

Sometimes patching is not immediately possible.

Maybe:

The answer should not be:

Ignore it.

Organizations may need compensating controls.

Possible strategies include:

Then develop a plan to remove the underlying risk.

What Is a Compensating Control?

A compensating control reduces risk when the preferred security measure cannot immediately be implemented.

Suppose a vulnerable device cannot be patched.

The organization might:

Remove public access.

Place it on an isolated network.

Restrict communication.

Increase monitoring.

Those actions do not fix the vulnerability.

They reduce the opportunity to exploit it.

This distinction should be documented.

A mitigation is not necessarily remediation.

Mitigation vs. Remediation

These terms are often confused.

Mitigation

Reduce the risk or impact.

Remediation

Correct the underlying problem.

Example:

A vulnerable server is exposed to the internet.

Mitigation

Firewall blocks public access.

Remediation

Vendor patch fixes the software vulnerability.

Both can be valuable.

But they solve different parts of the problem.

What Is Vulnerability Management?

Vulnerability management is broader than patching.

It includes:

Discover

What assets exist?

Identify

Which vulnerabilities affect them?

Prioritize

Which weaknesses present the greatest risk?

Remediate

Patch, configure, replace, or mitigate.

Verify

Confirm the problem was corrected.

Repeat

Because new vulnerabilities continue to appear.

This is a continuous process.

Vulnerability Management Begins With Inventory

You cannot patch a server you do not know exists.

You cannot replace an unsupported camera you forgot was installed.

You cannot update a firewall nobody documented.

That makes asset inventory one of the foundations of patch management.

Ask:

What do we have?

Where is it?

Who owns it?

What software is running?

What version?

Is it supported?

Is it internet facing?

Without those answers, patching becomes guesswork.

What Is a Patch Inventory?

A patch inventory identifies systems and relevant software versions so organizations can determine which updates are needed.

Depending on the environment, this may include:

The broader the technology estate, the more valuable automation becomes.

Why Manual Patching Does Not Scale

Imagine a company with:

5 computers.

Manual patching may be manageable.

Now imagine:

2,000 endpoints

100 firewalls

300 switches

500 cameras

75 servers

multiple cloud environments

The question becomes:

How do we know what is missing?

Automation becomes necessary.

The same theme keeps appearing throughout this series:

> Attackers automate discovery. Defenders need to automate awareness and maintenance.

What Is Automated Patch Management?

Automated patch management uses technology to help:

Automation reduces repetitive work.

But it does not eliminate planning.

Businesses still need to determine:

What can be automatically patched?

What requires testing?

What needs a maintenance window?

What systems are too critical for unattended updates?

Automation supports the process.

Governance controls it.

Should Every Patch Be Automatically Installed?

Not necessarily.

Some environments can safely automate large portions of patching.

Others need testing.

The correct approach depends on:

A low risk browser update and a firmware update on a critical production firewall may require different processes.

Patch management should reflect operational reality.

What Is Emergency Patching?

Emergency patching occurs when a vulnerability requires faster action than the normal maintenance cycle.

This may occur when:

The organization may need to accept more operational disruption to reduce greater security risk.

That decision should have an established process.

Normal Patch Window vs. Emergency Patch Window

A useful patch program distinguishes:

Routine maintenance

from

urgent remediation.

For example:

Routine updates may follow:

Monthly maintenance cycle.

But an actively exploited VPN vulnerability might require:

Immediate change process.

Without emergency procedures, organizations may know a vulnerability is dangerous but have no mechanism to respond quickly.

Who Owns Patch Management?

This is more complicated than:

“IT does.”

NIST specifically emphasizes cooperation between organizational leadership, business owners, and technology teams when building an enterprise patch management strategy.

Why?

Because patching can affect:

IT may implement the patch.

Business leadership helps determine acceptable risk and downtime.

Patch management is therefore a business risk process supported by technology.

What Happens If a Patch Breaks Something?

That risk is real.

It is one reason organizations use:

But patch risk must be compared with vulnerability risk.

Doing nothing is also a decision.

And doing nothing carries its own risk.

The question should be:

Which risk are we choosing?

Why Backups Matter Before Major Updates

A significant patch or system upgrade can occasionally create problems.

Good change management therefore includes recovery planning.

Before important changes, organizations may need:

The objective is not simply:

Install patch.

It is:

Install patch safely and recover if something unexpected happens.

How Do You Know a Patch Actually Installed?

Verification.

This step is frequently overlooked.

A management system may say:

Patch deployment initiated.

That does not necessarily mean:

Every device successfully installed it.

Some systems may be:

Patch management should verify results.

Why Failed Patches Matter

Imagine an organization reports:

98 percent patched.

Excellent.

But what is the remaining two percent?

If they are:

old employee laptops

that may be one issue.

If they are:

the company's internet facing VPN gateways

that is a completely different risk.

Percentages need context.

The systems that failed may matter more than the number that succeeded.

Patch Compliance vs. Patch Risk

A business may proudly report:

99 percent patch compliance.

That sounds excellent.

But if the missing one percent includes:

a critical publicly exposed firewall vulnerability known to be actively exploited,

the business still has a serious problem.

This is why security metrics need meaning.

Do not only ask:

What percentage is patched?

Ask:

What is not patched, and why?

How Quickly Should a Critical Vulnerability Be Patched?

There is no single timeline suitable for every vulnerability and every organization.

Risk factors include:

Organizations should define patch severity and response targets in advance.

The worst time to decide:

“How quickly do we patch something critical?”

is after a critical vulnerability appears.

Why CISA KEV Should Influence Patch Priority

CISA's KEV Catalog provides real world exploitation information.

CISA explicitly recommends using the catalog as an input into vulnerability management prioritization.

This gives organizations a practical question:

Is this vulnerability on the KEV list?

If yes, urgency should increase.

That does not replace other risk analysis.

It improves it.

Newer Is Not Always More Dangerous Than Older

A vulnerability announced yesterday receives attention.

A vulnerability announced four years ago may receive none.

But suppose:

Yesterday's vulnerability

affects an isolated test machine.

And:

The four year old vulnerability

affects an internet facing production firewall.

Which represents greater risk?

Age alone cannot answer that.

Exposure and exploitability matter.

Old Malware Can Still Be Dangerous Too

Malware families do not automatically disappear when news coverage stops.

Attackers can continue reusing:

as long as they remain effective.

Cybercrime is frequently practical.

Attackers reuse what works.

They do not retire a technique because cybersecurity professionals find it old fashioned.

Why WannaCry Still Matters as a Lesson

The important question is not whether WannaCry is still headline news.

The important question is what WannaCry teaches.

Microsoft had published a critical update before the widespread outbreak.

That means the incident illustrates a broader truth:

Security fixes have value only when organizations deploy them.

The same lesson applies today to:

The product changes.

The principle does not.

A Patch Is Not a Piece of Paper

A vendor advisory says:

Update available.

A security team creates a ticket.

A manager receives an email.

A vulnerability scanner creates an alert.

None of those actions actually fix the system.

The risk changes when someone:

remediates

and

verifies.

This is an important operational distinction.

Awareness is not remediation.

Ticket Created Does Not Mean Problem Solved

This deserves its own cybersecurity principle.

A vulnerability alert appears.

Ticket created.

Status:

Open.

The organization has technically documented the issue.

But the vulnerable system remains vulnerable.

Then:

Ticket assigned.

Still vulnerable.

Meeting scheduled.

Still vulnerable.

Change request created.

Still vulnerable.

The cybersecurity outcome occurs when the exposure is actually corrected or appropriately mitigated.

Workflow is necessary.

Outcome is what matters.

Where USA Telecom and ADAM Fit

Patch management begins with visibility.

USA Telecom and ADAM do not replace dedicated vulnerability scanners, endpoint management platforms, patch management products, or vendor security tools.

But the operational questions align closely with the ADAM philosophy:

What devices exist?

Which locations are online?

Which equipment is reachable?

What changed?

Which systems stopped responding after maintenance?

Did an update affect connectivity?

Is a firewall still online?

Did a VPN tunnel recover?

Which locations require investigation?

Patching and monitoring frequently intersect.

Why Monitoring Matters After a Patch

Imagine updating a firewall at 2:00 AM.

The update completes.

Now ask:

Did the firewall come back online?

Did internet connectivity return?

Did VPN tunnels reestablish?

Did voice services recover?

Did branch connectivity return?

Patch management tells you:

The update was installed.

Operational monitoring tells you:

The business service recovered.

Both matter.

A Successful Patch Can Still Create an Operational Incident

The security update may install correctly.

But perhaps:

The patch succeeded technically.

The change failed operationally.

This is why post change validation matters.

Patching Should Have a Before and After

A strong maintenance process can include:

Before

Confirm device

Confirm backup

Confirm configuration

Confirm maintenance window

Confirm recovery plan

During

Apply update

Monitor status

After

Verify device

Verify connectivity

Verify applications

Verify VPNs

Verify critical services

Document result

That creates closed loop maintenance.

Patch Management Is Really Lifecycle Management

Eventually, every technology reaches a point where patching is no longer enough.

The product becomes unsupported.

The manufacturer stops releasing updates.

The hardware cannot run newer software.

Now the solution is:

Replacement.

This makes cybersecurity partly a budgeting problem.

Organizations need to plan for technology lifecycle costs before equipment reaches a security dead end.

What Should Businesses Do About Old Technology?

Ask:

Is it still supported?

When does support end?

Is replacement budgeted?

Is it internet facing?

Can it be isolated?

Does the manufacturer provide updates?

What business process depends on it?

Unsupported equipment should not surprise the organization.

Lifecycle planning should identify it before support disappears.

Vulnerability Management Is a Continuous Cycle

The process does not end.

Inventory

↓

Scan

↓

Identify

↓

Prioritize

↓

Patch or mitigate

↓

Verify

↓

Monitor

↓

Repeat

Tomorrow:

A new vulnerability appears.

A new device is installed.

A vendor releases firmware.

An application changes.

A server is moved.

The cycle continues.

Cybersecurity is ongoing maintenance.

20 Patch Management Questions Every Business Should Ask

1. Do we know every operating system and network device we manage?

2. Who is responsible for patching each one?

3. Which systems are internet facing?

4. Which vulnerabilities are currently critical?

5. Are any vulnerabilities known to be actively exploited?

6. Do we use CISA's KEV Catalog in prioritization?

7. How quickly do we respond to emergency vulnerabilities?

8. What is our normal patch cycle?

9. Which systems require testing before updates?

10. What happens when a patch fails?

11. How do we verify successful installation?

12. Are firewalls being patched?

13. Are VPN appliances current?

14. Are routers and switches current?

15. Are cameras and IoT devices receiving updates?

16. Which technologies are nearing end of support?

17. What systems cannot currently be patched?

18. What compensating controls protect those systems?

19. Do we validate business services after maintenance?

20. Is replacement budgeted before unsupported equipment becomes a crisis?

Those questions transform patching from:

“Did Windows Update run?”

into:

“Are we managing technology risk throughout its lifecycle?”

The Better Question Is Not “How Old Is the Vulnerability?”

The more useful questions are:

Is our system affected?

Is it exposed?

Is exploitation occurring?

Is there a patch?

Have we installed it?

If not, why?

What protects the system in the meantime?

How will we verify remediation?

Age may provide context.

Risk determines priority.

Key Takeaway

WannaCry remains one of cybersecurity's clearest lessons because the critical Microsoft update associated with the vulnerability existed before the widespread May 2017 outbreak.

The larger lesson is not simply:

“Install Windows updates.”

It is:

Know your assets.

Know your versions.

Know what is exposed.

Know which vulnerabilities are being exploited.

Prioritize intelligently.

Patch promptly.

Mitigate when patching is impossible.

Replace unsupported technology.

Verify remediation.

Monitor after change.

And remember:

> A vulnerability does not expire because the news cycle moves on.

Attackers can continue using old techniques as long as vulnerable systems remain.

The question is not:

“Is this vulnerability old?”

The question is:

“Does it still work against us?”

Frequently asked questions

Why do old cybersecurity vulnerabilities still matter?

Because systems may remain vulnerable years after a fix becomes available. Attackers can continue scanning for and exploiting systems that have not been patched or replaced.

What is a software vulnerability?

A vulnerability is a weakness in software, hardware, configuration, or technology that may allow an attacker to compromise security.

What is a security patch?

A security patch is an update designed to fix a known security weakness.

What is patch management?

Patch management is the process of identifying, evaluating, testing, deploying, and verifying software and firmware updates.

What was WannaCry?

WannaCry was ransomware that spread globally in May 2017 and exploited vulnerabilities in Windows SMB implementations.

Was there a patch before WannaCry?

Yes. Microsoft published MS17-010 on March 14, 2017, roughly two months before the widespread WannaCry outbreak.

What was MS17-010?

MS17-010 was Microsoft's critical security bulletin addressing multiple vulnerabilities in Windows SMB, including flaws capable of remote code execution.

Why did WannaCry spread if Microsoft had already released a patch?

Many affected systems had not installed the relevant updates or were otherwise still vulnerable.

Do hackers still use old vulnerabilities?

Yes. A vulnerability can remain useful to attackers as long as vulnerable systems continue to exist.

Do hackers automatically scan for unpatched systems?

Automated tools can identify exposed technologies and systems that appear susceptible to known vulnerabilities.

What is a CVE?

CVE stands for Common Vulnerabilities and Exposures. It provides standardized identifiers for publicly known cybersecurity vulnerabilities.

What is CVSS?

CVSS is the Common Vulnerability Scoring System, which helps describe vulnerability severity.

What is CISA KEV?

CISA's Known Exploited Vulnerabilities Catalog identifies vulnerabilities for which there is evidence of exploitation in the wild.

Should vulnerabilities in CISA KEV receive higher priority?

CISA recommends using the KEV Catalog as an input into vulnerability management prioritization. Active exploitation should significantly influence remediation urgency.

What is a zero day?

A zero day is generally a vulnerability for which defenders may not yet have an available patch or sufficient prior warning when exploitation or disclosure occurs.

Are old vulnerabilities less dangerous?

Not necessarily. Age does not determine risk. Exposure, exploitability, active exploitation, system criticality, and available defenses matter.

Do firewalls need patches?

Yes. Firewalls run software and can contain vulnerabilities.

Do routers need updates?

Yes. Routers require firmware and software maintenance and should remain within supported product lifecycles.

Do security cameras need firmware updates?

Yes. Network cameras run software and should be patched according to manufacturer guidance.

What is end of life software?

End of life technology is software or hardware that has reached the end of its vendor supported lifecycle and may no longer receive security updates.

What should I do if a device cannot be patched?

Reduce exposure, isolate or segment it, apply vendor recommended mitigations, increase monitoring, and develop a plan to remediate or replace the affected technology.

How quickly should critical patches be installed?

The appropriate timeline depends on risk, active exploitation, exposure, business criticality, and operational impact. Organizations should establish defined response targets in advance.

Does installing a patch automatically mean the problem is solved?

No. Organizations should verify that the update installed successfully and confirm that the affected system is no longer vulnerable.

What is vulnerability management?

Vulnerability management is the continuous process of discovering assets, identifying vulnerabilities, prioritizing risk, remediating or mitigating weaknesses, verifying results, and repeating the process.

Sources

Editorial note

Cybersecurity risk and the controls appropriate to it vary by organization. Evaluate these recommendations against your own technology environment, business requirements, regulatory obligations, threat profile and risk tolerance.

Talk to us about your network security

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.

Related articles

Microsoft fixed it. Why did companies still get hacked? · How do hackers find vulnerable computers? · Why would hackers target my small business? · Why change default passwords? · Patch management vs vulnerability management

← 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