Patch management deploys software and firmware updates to your systems. Vulnerability remediation removes a specific weakness by whatever method fits. Some of the most serious pentest findings have no patch at all: a weak service account password, an exposed admin panel, a misconfigured certificate template. A team can meet every patching SLA and still leave those issues open. This guide shows where each process stops and how the two fit together.
What is vulnerability and patch management?
Vulnerability management finds, prioritizes, fixes, and tracks security weaknesses. Patch management tests, deploys, and verifies software updates.
What is vulnerability remediation?
Removing a known weakness by patching, reconfiguring, rotating credentials, or fixing code, then verifying it can no longer be exploited.
What is the main purpose of patch management?
To keep software current in a controlled way, so security fixes reach every system without disrupting operations.
What is the difference between mitigation and remediation?
Remediation removes the vulnerability. Mitigation reduces the chance or impact of exploitation while the vulnerability is still there.
What is the key difference between vulnerability and patch management?
Scope. Patch management handles software and firmware updates. Vulnerability management covers all weaknesses, including misconfigurations and weak credentials.
Key Takeaways
- Patch management delivers one kind of fix. Remediation uses whatever fix fits.
- Misconfigurations and default credentials usually need configuration or credential changes. Access control flaws may require code fixes or patches.
- Patching doesn't undo an earlier compromise. Stolen sessions and persistence can survive it.
- Mitigation buys time when no patch exists or can't be deployed yet, so track it.
- A closed ticket isn't proof of a fix.
- Both depend on an accurate asset inventory. Unknown systems don't get fixed.
What Is Patch Management?
NIST SP 800-40 Rev. 4 defines enterprise patch management as the process of identifying, prioritizing, acquiring, installing, and verifying the installation of patches, updates, and upgrades across an organization. A typical process covers:
- Inventory: knowing which operating systems, applications, firmware, and libraries run where.
- Monitoring: tracking vendor advisories and release cycles, such as Microsoft's monthly updates.
- Testing: checking that an update doesn't break critical applications.
- Deployment: rolling updates out in rings or maintenance windows, with a rollback plan.
- Verification: confirming the system runs the fixed version, sometimes after a reboot.
IT operations usually owns patching, and it covers all updates, not just security ones.
What Is Vulnerability Remediation?
Remediation starts from a finding rather than a release: a scan, pentest, bug bounty report, or threat intelligence alert. The fix depends on the weakness:
- Missing patch: install the update or upgrade to a supported version.
- Misconfiguration: change the setting, such as disabling SMBv1 or locking down a public storage bucket.
- Credential issue: rotate the password or key, or remove the default account.
- Code flaw: fix the logic, such as adding a missing authorization check.
- Unneeded exposure: remove the service, close the port, or decommission the system.
Security usually sets priority, while the system owner applies the fix. That split is why remediation needs tracking, deadlines, and verification.
Related: Vulnerability Prioritization: Beat Patching Paralysis
Patch Management vs Vulnerability Remediation: Key Differences
They share tools and people but start and end at different points.
Aspect | Patch Management | Vulnerability Remediation |
|---|---|---|
Starting point | A software or firmware update becomes available | A weakness is found and assessed |
Scope | Software, firmware, and OS updates | Any weakness: missing patches, misconfigurations, credentials, code flaws, exposed services |
Main question | Are our systems up to date? | Is this weakness still exploitable? |
Typical owner | IT operations or infrastructure | Security sets priority; system owners apply the fix |
Fix methods | Install, upgrade, roll back | Patch, reconfigure, rotate, rewrite, remove, or mitigate until a fix is ready |
Cadence | Scheduled cycles plus emergency releases | Driven by risk and deadlines per finding |
Done when | The update is installed and verified | The fix is verified to remove the weakness; mitigated or accepted risks are tracked separately |
Typical metrics | Patch compliance rate, deployment time | Time to remediate, open findings by risk, overdue items, retest pass rate |
Also Read: Vulnerability Remediation vs Mitigation
Why Patch Management and Vulnerability Remediation Matter
Many intrusions don't need a zero-day. In external and internal assessments, known issues often provide the initial foothold: an outdated VPN appliance, a default password, a forgotten domain setting. From there, internal systems are usually the next target.
CISA's Known Exploited Vulnerabilities (KEV) catalog lists flaws with evidence of exploitation in the wild. On June 10, 2026, CISA replaced BOD 22-01 with BOD 26-04, which introduced risk-based remediation deadlines for federal civilian agencies based on KEV status, internet exposure, exploit automation, and technical impact. Those same factors make a sensible model for any organization.
Good patching keeps known issues manageable. Good remediation closes the ones that matter most, including those a patch cycle never touches.
When Patching Alone Is Not Enough
Patching closes the hole. It doesn't always close the problem.
No patch exists yet
In January 2024, two Ivanti Connect Secure vulnerabilities (CVE-2023-46805 and CVE-2024-21887) were exploited before permanent fixes existed. CISA's Emergency Directive 24-01 told agencies to import Ivanti's temporary mitigation, run its External Integrity Checker Tool, and apply updates as soon as they shipped.
The attacker got in first
Citrix Bleed (CVE-2023-4966) let attackers steal valid session tokens from NetScaler appliances, and CISA's joint advisory AA23-325A describes LockBit 3.0 affiliates exploiting it. Hijacked sessions could stay valid after upgrading, so Citrix recommended removing any active or persistent sessions after the upgrade.
The weakness isn't a software bug
In one red team engagement, we went from an evil twin Wi-Fi foothold to full Domain Admin access through an AD CS certificate template misconfiguration, the kind of path Active Directory penetration testing is built to catch. No missing patches or zero-days were involved, so the fixes were configuration changes.
The patch can't be deployed
Legacy systems, OT equipment, and medical devices often can't take updates without vendor approval or unacceptable downtime. When permanent remediation isn't possible, compensating controls such as network isolation, strict access rules, and monitoring can reduce exposure. The remaining risk and a replacement plan should be documented.
The asset isn't in the inventory
Patch tools only update what they manage. Forgotten test servers and shadow cloud accounts sit outside the process, and the cloud vulnerabilities that go unremediated are often the ones internet-wide scanning finds first.
How Patch Management and Vulnerability Remediation Work Together
In a mature program, patching is one route inside a wider remediation workflow.
1. Discover and Identify Vulnerabilities
Start with an accurate asset inventory. Authenticated scans catch missing patches and many misconfigurations. Pentests find chained attack paths and access control gaps that scanners often miss.
Helpful for you: Penetration Testing vs Vulnerability Scanning
2. Assess Risk and Prioritize Findings
CVSS rates general severity, not your risk. Weigh known exploitation (KEV), exploit likelihood (EPSS), internet exposure, and business value. A medium flaw on an exposed VPN can outrank a critical one on an isolated lab box.
3. Determine Whether a Patch Is Available
Check the vendor advisory. If a patch exists, schedule it by risk, not just the next monthly cycle. If not, assign the finding to whoever can apply another kind of fix.
4. Apply Patches or Alternative Remediation
Deploy the patch or apply the configuration, credential, or code fix. If that isn't possible yet, apply a mitigation with a review date. If exploitation was possible beforehand, look for persistence mechanisms that survive a fix.
5. Test and Verify Remediation
Rescan, check the running version, or retest the exploit path. A scanner may report a fix because the package changed while the service still runs the old binary. For pentest findings, a retest gives strong evidence.
6. Monitor and Track Remaining Vulnerabilities
Track what is open, who owns it, and when it is due. Mitigations and risk acceptances need review dates.
Patch Management vs Vulnerability Remediation Examples
Common findings and how each gets closed:
Finding | Patch Available? | Remediation Approach | How to Verify |
|---|---|---|---|
Missing Windows cumulative update on a file server | Yes | Normal patch process, faster if the CVE is in KEV | Check the installed build and rescan |
Internet-facing VPN appliance with a known exploited flaw | Yes, or not yet | Patch urgently, or apply the vendor mitigation and restrict exposure; check for compromise | Version check, vendor integrity tool, log review |
AD CS template that lets any user request certificates for other users | No | Fix template permissions and settings, remove unneeded templates | Re-run the abuse path in a retest |
Default admin password on a network device | No | Change the credential and restrict management access | Attempt login with the default credential |
API endpoint returns other users' records when the ID is changed (IDOR) | No | Add server-side authorization checks to the code | Retest with another user's ID |
Vulnerable open-source library in a web application | Yes, upstream | Upgrade the dependency, rebuild, and redeploy | Software composition scan of the deployed build |
End-of-life OS on a legacy production system | No longer | Isolate, limit access, monitor, and plan replacement | Network access tests and exception review |
Patch Management and Vulnerability Remediation Checklist
- Keep an asset inventory that includes cloud and third-party hosted systems.
- Assign an owner to every system and application.
- Run scheduled authenticated and external scans.
- Track vendor advisories and the CISA KEV catalog.
- Set remediation deadlines by risk, faster for known exploited and internet-facing issues.
- Test patches before broad deployment and keep a rollback plan.
- Define an emergency patching process for exploited flaws.
- Route non-patch findings to the team that can fix them.
- Document every mitigation with a review date.
- Check for compromise when a flaw may have been exploited first.
- Verify every fix before closing it.
- Record risk acceptances with a named approver and an expiry date.
- Report on overdue findings and time to remediate, not just patch compliance.
Common Patch Management and Remediation Mistakes
- Treating patch compliance as security. A high compliance rate says nothing about a misconfigured service account. Report on open risk, not just missing updates.
- Closing tickets without verification. Retests sometimes show that "fixed" findings are still exploitable: a patch on one cluster node only, a service that never restarted, or a fix applied to staging but not production.
- Patching on the calendar, not the risk. A monthly window suits most updates, but not an exploited, internet-facing flaw.
- Letting mitigations become permanent. Without a review date, a temporary firewall rule can quietly become the permanent fix.
- Ignoring what happened before the patch. If a flaw was exposed for weeks, the patch only stops new attacks. Check for new accounts, web shells, and stolen sessions.
- Missing assets. Shadow IT and acquired networks often sit outside both the patch tool and the scanner, yet internet-wide scanning makes them easy to find.
Must Read: JFrog Artifactory Vulnerability
Patch Management and Vulnerability Remediation Best Practices
- Run one workflow for all findings. Scans, pentests, and advisories should share one tracker and priority logic.
- Set deadlines by risk. Known exploitation and exposure shorten the timeline.
- Separate routine and emergency patching. Keep a tested fast path for exploited flaws.
- Plan for unpatchable systems. NIST SP 800-40 Rev. 4 advises planning multiple long-term risk mitigation methods besides patching.
- Verify before closing. Evidence of the fix is part of done.
- Test attack paths, not just patch levels. A pentest shows which findings an attacker can chain together.
- Measure the right things. Track time to remediate, overdue findings, and retest results.
How OraSec Can Help
OraSec's penetration testers find the weaknesses patching doesn't cover and show which ones an attacker can actually use. Each report ranks findings by real-world exploitability and explains how to fix them, whether that means a patch, a configuration change, or a code fix. Once your team applies fixes, we retest to confirm the issues can no longer be exploited. Our vulnerability assessment and penetration testing service combines automated coverage with manual testing of networks, Active Directory, applications, APIs, and cloud environments.
Recent News: CVE-2026-109618 vs CVE-2026-109619
Conclusion
Patch management keeps your software current. Vulnerability remediation makes sure the weaknesses that matter are actually gone. You need both. Patch on a disciplined schedule, move faster on exploited and exposed issues, and give every non-patch finding an owner and a deadline. Verify every fix before you close it. If you want an independent view of what's still exploitable, talk to our team.
Frequently Asked Questions
Is patching a form of vulnerability remediation?
Yes, it's a common form, but not the only one. Configuration changes, credential rotation, code fixes, and removing unused software are remediation too.
How quickly should critical vulnerabilities be patched?
Set timelines by risk in your policy. BOD 26-04 gives federal civilian agencies risk-based deadlines, with the most urgent due within days.
What is a compensating control?
An alternative safeguard used when the normal fix can't be applied, such as network isolation. It reduces risk but leaves the vulnerability in place.
Does a clean rescan prove a vulnerability is fixed?
It's good evidence, not proof. Scanners can miss some issues, so high-risk findings deserve a manual retest of the exploit path.
Can automated patch management replace vulnerability remediation?
No. Automation deploys vendor updates to managed systems well, but it can't fix misconfigurations, weak credentials, or code flaws, or reach unknown assets.
Who should own vulnerability remediation?
Security usually owns the process, priority, and tracking, while each system owner applies the fix. Every finding needs one named owner and a due date.
