TL;DR: When a vendor won't approve a security patch, get the reason in writing, assess exploitation risk and business impact, and reduce exposure. Document any delay as an approved, time-limited exception that names a risk owner, lists compensating controls, and sets review and expiration dates. Test and deploy a fix once it’s authorized, or replace software that cannot be secured.
You’re ready to install a security patch on the server running your payroll software, but the application vendor won’t approve the update.
The good news is you don’t have to wait for a corrected patch to take steps to reduce exposure. A patch management exception documents an approved, temporary delay in patching while compensating controls reduce exposure. This article covers the details.
What does the vendor's refusal actually mean?
When a vendor won’t approve a security patch, determine whether the issue is incomplete testing, a documented incompatibility, or a support restriction. Ask for the affected versions, reason for refusal, and a written timeline for validation or remediation.
Untested patch
An untested patch means the vendor hasn't validated the patch so far. That is not proof of failure but uncertainty. Ask the vendor which versions it will test, when testing will finish, and when it will provide a written compatibility decision.
Documented incompatibility
The vendor has tested the patch but found a specific issue. For example, installing this patch may cause a server to stop working. A confirmed incompatibility may justify a temporary delay, but weigh the operational impact against the risk of leaving the vulnerability exposed.
Ask the vendor for the affected versions, failure details, a supported workaround, and a timeline for validation or remediation. Until that time, the security administrator should apply temporary security controls, such as restricting access to the affected system.
Document any delay as a time-limited exception covering the affected assets and vulnerabilities, business reason, compensating controls, residual risk, risk owner, approver, review date, and expiration date. Once a fix is authorized, test and deploy it through the appropriate change process, then verify remediation and application functionality.
Support restriction
If you install an unapproved patch, the vendor may refuse technical support or warranty coverage. In fact, installing this patch may breach the contractual terms of the vendor's support.
Ask the vendor to identify the support terms affected by the patch and confirm whether your product version still receives security updates. NIST SP 800-40 Rev. 4 identifies end-of-life software as one reason assets may no longer receive patches.
In addition, CIS Controls v8.1 Safeguard 2.2 states that if an organization needs unsupported software, it should document an exception describing mitigating controls and residual risk acceptance.
Getting everything from your vendor in writing enables you to preserve evidence for future audits.
How should you assess risk and reduce exposure?
Confirm affected assets and versions, then check CISA’s Known Exploited Vulnerabilities (KEV) catalog for evidence of exploitation in the wild. Assess exposure and business impact alongside that evidence; absence from KEV does not establish that delaying a patch is safe.
If a vulnerability affecting your systems appears in KEV, prioritize remediation and escalate any approval delays. Use Exploit Prediction Scoring System (EPSS) to help prioritize vulnerabilities, especially when there is no confirmed evidence of exploitation.
While you work with the vendor on approval or a fix, reduce exposure with compensating controls that address the vulnerability’s attack path, such as:
Implement firewall rules to restrict inbound traffic.
Deploy network segmentation.
Implement the principle of least privilege (PLP) to limit access to systems and applications.
Document the security controls that you have implemented to limit exposure. Note that compensating controls provide temporary safeguards rather than completely replacing patches.
When should you escalate, patch, or replace the software?
Escalate when exploitation is reported, risk increases, the vendor misses a deadline, the exception expires, or compensating controls fail.
Follow your organization’s approval policy: IT assesses compatibility and recovery, security evaluates exposure, and the designated risk owner approves any temporary risk acceptance. When vendor approval remains unavailable, the authorized change approver decides whether to deploy the tested patch, continue mitigation, or take the application offline after reviewing support terms and applicable requirements. PDQ's guide to handling patch management exceptions provides more detail.
NIST describes four ways to respond to a potential risk, including Accept, Mitigate, Transfer, and Avoid.
Another situation occurs when a vendor cannot resolve the issue. They may face product EOL, staff shortages, or a fix that requires a major rewrite. In those cases, you should execute your exit plan by upgrading to a newer version, switching products, or retiring the application or product.
How does PDQ help?
You cannot protect what you cannot see. That is why NIST emphasizes that knowing software and versions is essential for patch management.
PDQ’s cloud-based endpoint management software inventories Windows and macOS devices and deploys supported application updates without a VPN. The Premium plan adds vulnerability management and prioritization, with remediation options where supported packages are available.
Manage Windows & macOS devices from anywhere
With PDQ Connect, get real-time visibility into remote and local devices, deploy software, remediate vulnerabilities, automate routine maintenance, and remotely troubleshoot endpoints from one easy-to-use platform.
