Vulnerability risk acceptance: When is it reasonable not to remediate?

In some cases, immediate remediation can create more operational risk than temporarily accepting the vulnerability. For example, a patch may break a critical app, a vendor may not have released a fix, or an affected system may be isolated from the internet and protected by multiple security controls. 

Vulnerability risk acceptance is the formal decision to retain the risk of leaving a known vulnerability unresolved. It may defer remediation temporarily or allow residual risk to remain longer term, provided it falls within the organization’s risk tolerance and receives appropriate oversight. 

Acceptance does not make the vulnerability disappear. A defensible decision states how long the exposure may remain, which assumptions support the decision, what evidence confirms they still hold, and what changes would end it. When those conditions change, the exception should trigger action — not automatic renewal. 

What is vulnerability risk acceptance? 

Vulnerability risk acceptance is a formal decision to leave a known vulnerability unremediated because the organization determines that the current risk is understood, justified, and managed within an approved tolerance. 

The vulnerability remains open. The organization is accepting the possibility of exploitation rather than claiming that the vulnerability has been fixed. 

Risk acceptance is not the same as remediation 

These responses represent distinct ways to handle a security finding after assessment, so teams can match the course of action to the circumstances, intended outcome, and applicable policy and governance requirements. 

Risk acceptance is different from a false positive 

A false positive occurs when a scanner reports a vulnerability that does not actually affect the asset. It should be corrected in the vulnerability management system and not be recorded as an accepted risk. 

A risk acceptance decision applies when: 

• Vulnerability is confirmed 

• Affected asset is known 

• Exposure has been assessed 

• Remediation is not currently being performed 

• An authorized person accepts the remaining risk 

Risk acceptance should be time-bound 

Avoid presenting acceptance as a permanent status. A long-term exception may be legitimate in some cases, but it still needs periodic review. Set a defined end or reassessment point, and revisit the decision if the vulnerability, asset, threat, or business context changes. 

When is it reasonable to accept vulnerability risk? 

A vulnerability may be a candidate for risk acceptance when the organization has evaluated the exposure and determined that immediate remediation is not practical or would create greater risk. 

Acceptance should require a specific justification, not a general statement such as “the system is important” or “the patch is difficult to deploy.” 

When remediation creates unacceptable operational risk 

Remediation can create greater immediate risk when the update would disrupt a critical business service, interrupt patient care, corrupt operational data, break a safety-critical system, disrupt emergency communications, or cause a widespread outage.   

This concern is especially relevant when the update causes compatibility problems with:   

• Clinical or laboratory equipment 

• Manufacturing systems 

• Point-of-sale systems 

• Financial applications 

• Authentication infrastructure 

• Custom software 

• Legacy databases 

• Systems that cannot be taken offline during business hours 

Compatibility problems alone do not justify accepting the vulnerability; the team should first determine whether it can: 

• Test the update in a representative environment 

• Deploy it during a maintenance window 

• Patch a redundant system first 

• Isolate the affected service 

• Apply a vendor-supported workaround 

• Replace the vulnerable component 

• Reduce the system’s exposure until remediation is possible 

For endpoint-based issues, administrators can use PDQ to identify affected devices, create a focused test group, and limit initial deployment to representative systems before making a broader remediation decision. 

No vendor fix or supported update is available 

Risk acceptance may be considered when: 

• Vendor has acknowledged the vulnerability but not released a fix 

• Product is nearing end of life 

• System runs a legacy version 

• Vulnerability affects a third-party component 

• Organization depends on a vendor-controlled update schedule 

These circumstances don't automatically justify risk acceptance. Before approving an exception, confirm whether a supported fix, upgrade, workaround, or alternative remediation path is available.  

If the product is unsupported, include a replacement or retirement plan in the risk acceptance record. Unsupported software should not remain indefinitely under “accepted risk” without executive awareness. 

The affected asset has very limited exposure 

Risk acceptance may be more reasonable when the affected device or service: 

• Has no direct internet access 

• Is separated from user networks 

• Accepts connections only from a small number of known systems 

• Is protected by strict firewall rules 

• Has no sensitive data 

• Is not used for administrative access 

• Is powered off except during controlled operations 

Limited exposure reduces risk, but it does not eliminate it. An isolated system can still be compromised through: 

• Removable media 

• Connected workstation 

• Stolen credentials 

• Misconfigured firewall 

• Trusted management tool 

• Temporary network connection 

Isolation must be verified rather than assumed. Confirm the boundary, permitted connections, and process for approving temporary access. 

A compensating control reduces the practical risk 

Compensating controls are safeguards that reduce the likelihood of exploitation or limit the impact if exploitation occurs. Preventive controls, such as network segmentation and access restrictions, can reduce exposure, while detective controls, such as enhanced logging and monitoring, help teams identify and respond to potential attacks. 

A compensating control should be specific. “The device has security tools installed” is weaker than “Inbound connections to TCP port 3389 are blocked except from the administrative subnet.” 

The vulnerability is low risk in the organization’s actual environment 

A vulnerability’s practical risk may be lower when: 

• Vulnerable feature is disabled 

• Vulnerable component is not used 

• Exploitation requires local access that users do not have 

• Asset does not contain sensitive data 

• Attack path is blocked 

• Affected software is not reachable from the relevant network 

• Vulnerable configuration is not present 

Before accepting the risk, confirm that the vulnerability actually applies to the affected asset. If the required vulnerable configuration or component is absent, the finding may be inapplicable rather than an accepted risk. Validate the finding before determining whether acceptance is necessary. 

Once the vulnerability is confirmed, the IT team should assess its severity and exploitability using available risk signals. It should also review the vulnerability’s CVSS severity rating, whether it appears in CISA’s Known Exploited Vulnerabilities (KEV) catalog, its EPSS score, and the proposed Likely Exploited Vulnerabilities (LEV) metric, where available. 

CVSS indicates severity and the KEV catalog identifies vulnerabilities known to be exploited in the wild. EPSS estimates the likelihood that a published CVE will be exploited in the next 30 days. Meanwhile, LEV uses historical EPSS data to estimate whether exploitation may have already occurred. 

No single score should determine whether to accept the risk. 

Record evidence supporting the low-risk conclusion, including: 

• Affected devices and software 

• Network exposure and reachable services 

• Available exploitability information 

• Business impact 

• Evidence that relevant compensating controls are implemented and functioning as intended 

PDQ can help IT teams verify affected software, versions, and devices through centralized device and software inventory. This gives administrators a clearer view of which endpoints fall within the assessed scope and which still require remediation. 

When is vulnerability risk acceptance not reasonable? 

Risk acceptance is usually not appropriate when the organization can remediate within its normal process and has no compelling reason to delay. 

The vulnerability is actively exploited 

A vulnerability should generally receive urgent remediation when: 

• It appears in an authoritative exploited vulnerability catalog 

• Threat intelligence shows active exploitation 

• Attacks have been observed against the organization 

• Exploitation is easy and the vulnerable assets are exposed 

• Affected system provides privileged access 

• Vulnerability enables remote code execution or credential theft 

If immediate patching is not possible, prioritize emergency mitigation and require formal authorization of any remaining risk. Start with internet-facing or privileged systems, then isolate affected devices, temporarily disable the vulnerable service or feature, restrict access, or apply a vendor-supported workaround. Monitor for signs of compromise and set a short deadline for permanent remediation. 

Confirm that risk acceptance is permitted under applicable regulatory, contractual, and organizational requirements. Some vulnerabilities may be subject to mandatory remediation deadlines or additional approval requirements. 

The vulnerable asset is directly exposed to the internet 

Internet-facing systems generally have a larger attack surface and less room for informal exceptions. 

Risk acceptance is difficult to justify when the affected asset: 

• Exposes a vulnerable service publicly 

• Stores customer or employee information 

• Orovides remote access 

• Handles authentication 

• Connects to internal systems 

• Hosts a public-facing application 

• Supports a high-value business process 

If the system must remain online, block the relevant attack path through access restrictions, filtering, virtual patching, service disablement, or temporary removal from the public network. Verify the measure and treat it as a bridge to remediation. 

The vulnerability affects privileged or identity systems 

Acceptance is especially risky for: 

• Domain controllers 

• Identity providers 

• Privileged access systems 

• Certificate authorities 

• Password management platforms 

• Remote administration tools 

• Endpoint management infrastructure 

• Security monitoring systems 

A compromise of these systems may provide an attacker with access to many other assets. The decision should require a higher approval level or be rejected entirely if effective safeguards are unavailable. 

The exception is based only on inconvenience 

The following are not strong reasons to accept risk: 

• “The team is busy.” 

• “The patch is low priority for us.” 

• “The device is difficult to reach.” 

• “Users will complain.” 

• “We have not had a problem yet.” 

• “The vendor patching process is manual.” 

• “The vulnerability affects too many devices.” 

These conditions may explain a delay, but they do not justify retaining risk indefinitely. They indicate a need for better inventory, deployment processes, maintenance planning, or remediation capacity. 

The same vulnerability has already been accepted repeatedly 

Repeated extensions may indicate that the organization is using risk acceptance to avoid remediation. These should be escalated when the issue requires a permanent architectural fix. Ask whether the business need, asset status, replacement timeline, threat level, or exposure has changed.   

How to apply and verify compensating controls 

The right control depends on the vulnerability and attack path. Controls should reduce exposure rather than simply add another security product. 

Restrict access to the vulnerable service 

Limit which systems, networks, or users can reach the vulnerable service. Verify that: 

• Approved systems can still connect 

• Unauthorized systems cannot reach the vulnerable service 

• Firewall and segmentation rules match the documented exception 

• Network changes have not reopened access 

Disable the vulnerable feature or service 

Remove the attack path when the vulnerable feature is not required for normal operations. Verify that: 

• The feature or service is disabled on every affected asset 

• The configuration persists after a restart or update 

• No management tool or application has re-enabled it 

• Users and applications can still perform required functions 

• A follow-up scan or configuration check confirms the change 

Reduce privileges and limit administrative access 

Restrict the permissions an attacker could use if exploitation requires local access, authentication, or a privileged account. Verify that: 

• Only approved users retain the required privileges 

• Privilege changes are recorded and reviewed 

• Authentication and privilege use logs are monitored for unusual activity 

Monitor for exploitation attempts 

Monitoring cannot remove the vulnerability, but it can shorten the time between an attempted compromise and the response. Verify that: 

• Relevant events generate alerts 

• Alerts reach the responsible team 

• The team has documented response steps 

• Monitoring covers every asset in scope 

• Rescans or configuration checks confirm that the compensating control remains active 

PDQ can help teams keep affected devices and software versions visible during the exception period. Sysadmins can use that view to identify devices that still require attention and revisit the decision as the environment changes. 

Apply virtual patching or filtering as a temporary measure 

Use virtual patching or filtering when a permanent fix is unavailable but the vulnerable traffic or behavior can be identified. Depending on the system, this may involve web application firewall rules, intrusion-prevention signatures, gateway filtering, endpoint rules, or reverse-proxy controls. 

Verify that: 

• The rule blocks relevant exploit patterns 

• Legitimate traffic and required services continue to work 

• The rule covers every affected entry point 

• The rule has a clear exit condition tied to permanent remediation 

Virtual patching should remain a temporary measure unless the vendor or security team confirms that it adequately addresses the exposure. 

How long can a vulnerability remain accepted? 

There is no universal time limit. The acceptable period depends on exploitability, exposure, asset criticality, available controls, and the time required to remediate. 

A high-risk, internet-facing vulnerability may require review within hours or days. A low-risk vulnerability on an isolated legacy system may have a longer review period, provided the remediation path remains active. 

Use risk-based review periods 

Organizations should establish review periods based on their security policies, risk tolerance, and compliance requirements. Use the following as sample guidance rather than fixed timelines. 

Require renewal instead of automatic extension 

At the expiration or reassessment point, require the owner to provide: 

• Updated exposure details 

• Current threat information 

• Evidence that controls still work 

• Progress toward remediation 

• New justification 

• New approval 

Automatic renewal can cause outdated risk decisions to disappear from view. PDQ enables sysadmins to review the vulnerable software and impacted devices associated with a finding, then filter vulnerabilities by affected software, CVSS score, known exploit, PDQ risk score, status, and number of impacted devices. 

Vulnerability risk acceptance decision checklist 

Use this checklist as a practical summary. Before accepting the risk, confirm the following. 

• Vulnerability has been validated 

• Affected assets are identified 

• Asset and business owners are known 

• Vulnerability’s severity and exploitability are documented 

• Internet and internal exposure have been assessed 

• Business impact has been assessed 

• Remediation options have been considered 

• Reason for delay or non-remediation is specific 

• Compensating controls are documented 

• Compensating controls have been tested 

• Correct approver has reviewed the decision 

• Expiration or review date is assigned 

• Remediation or replacement plan exists where possible 

• Exception remains visible in vulnerability reports 

• Conditions for earlier review are documented 

Make risk acceptance an informed decision, not a blind spot

Not every vulnerability can be fixed immediately, but every decision to leave one unresolved should be intentional. Responsible risk acceptance means understanding the exposure, documenting the justification, and maintaining visibility into what still needs attention.

The goal isn't to eliminate every risk at any cost. It's to make informed decisions that balance security with operational needs — while ensuring accepted vulnerabilities don't become forgotten vulnerabilities.

Vulnerability risk acceptance FAQs 

Can a vulnerability be accepted permanently? 

“Permanent” should not mean indefinite or exempt from reassessment. A vulnerability may remain accepted for an extended period when the remaining exposure is understood, documented, and regularly reassessed by the appropriate owners. 

What is the difference between vulnerability risk acceptance and vulnerability remediation deferral? 

Vulnerability risk acceptance is the broader decision to formally retain the risk of leaving a known vulnerability unresolved. Remediation deferral is a decision to postpone remediation until a defined future point, so it may involve temporary risk acceptance — but risk acceptance does not necessarily mean remediation has been delayed or that a fix is planned. 

Can a critical vulnerability ever be accepted? 

Only in rare, short-term circumstances — and generally not if it is actively exploited, internet-facing, affects privileged systems, or enables remote code execution. Acceptance may be considered when no safe fix is available and immediate remediation would threaten a critical service, safety, or essential operations. Any such exception should include documented justification, approval from an authorized risk owner, compensating controls, and a defined review date. 

Who should approve vulnerability risk acceptance? 

Approvers can include the system or application owner, IT or security leadership, a risk committee, compliance officer, or business service executive. 

Should every accepted vulnerability have an expiration date? 

Yes, every accepted vulnerability should have an expiration date or mandatory review date, even when the organization expects the exception to remain in place for an extended period. 

Is vulnerability risk acceptance a compliance violation? 

Not automatically. Vulnerability risk acceptance is an appropriate response when the remaining risk falls within the organization’s approved risk tolerance and does not override regulatory or internal requirements that mandate remediation.