Mitigation vs Remediation: When a Compensating Control Can Close a Finding

Vulnerability and audit findings are routinely marked "closed" when a compensating control has reduced the risk, even though the weakness is still there and the control may quietly stop working. Mitigation and remediation are both legitimate responses, but they close a finding in different ways, carry different audit evidence and expire on different terms. This guide explains how each one closes a finding, how auditors and authorising officials treat compensating controls, how to set exception expiry, and the triggers that force a mitigation to convert into a real fix. It pays particular attention to exposed non-human identity credentials, where "mitigated" is often mistaken for "fixed". It is written for vulnerability management leads, GRC and audit teams, and engineers who own findings.

Key takeaways

• Remediation removes the weakness; mitigation reduces its exploitability or impact. A mitigated finding is still an open risk with a residual rating, an owner and an end date.
• Frameworks keep mitigated items visible. FedRAMP's Rev. 5 POA&M guidance states that approved operational requirements are still open risks and never move to the Closed tab.
• A compensating control is evidence, not a status. It closes nothing unless it addresses the actual attack path, is tested, is monitored and has an expiry tied to a remediation date.
• Some triggers force conversion. Confirmed exploitation, a fix becoming available, a control failure or a second renewal should end the mitigation and start the remediation clock.
• Exposed credentials are only remediated by revocation and replacement. Restricting where a leaked key works is mitigation; GitHub's documentation says a committed secret should be considered compromised.

The short answer

The NIST glossary defines risk mitigation as prioritising, evaluating and implementing appropriate risk-reducing controls, and NIST SP 800-30 Rev. 1 treats it as a subset of risk response. For remediation, the glossary carries a definition from NIST SP 800-216: "the neutralization or elimination of a vulnerability or the likelihood of its exploitation", alongside a CNSSI 4009 definition of actions taken to correct known deficiencies and weaknesses. The glossary also lists a CNSSI definition of remediation as "the act of mitigating a vulnerability or a threat", which shows why the terms blur in practice.

Use a working rule that survives audit: remediation changes the vulnerable thing (patch, upgrade, code fix, configuration correction, credential revocation, decommissioning), so a rescan or retest no longer finds the weakness. Mitigation changes something around it (a WAF rule, segmentation, disabling a feature, restricting a key's network scope, added monitoring), so the weakness remains and a scanner will still report it. NIST SP 800-53 Rev. 5 control CA-5 captures the intent: a plan of action and milestones documents "planned remediation actions" to correct weaknesses and "reduce or eliminate known vulnerabilities". Both outcomes are allowed. Only one of them ends the record.

Side by side

How each one closes a finding

Most programmes need more than two states. The table below separates them so that reporting does not count a mitigated finding as fixed.

These states mirror FedRAMP's Rev. 5 POA&M guidance, which FedRAMP now marks as legacy content for reference during its transition to the Consolidated Rules for 2026, so check current FedRAMP rules before relying on it for an authorisation. In that guidance, a risk adjustment lowers a scanner-defined rating through mitigating factors or compensating controls; an operational requirement covers a finding that cannot be remediated, and FedRAMP will not approve one for a High vulnerability, although the risk may be mitigated; and a vendor dependency is not a deviation request but remains an open risk with at least monthly vendor check-ins. A high-risk vendor dependency must be mitigated to Moderate within 30 days. Items move to the Closed tab only when corrective actions are applied and evidenced, or a false positive is approved.

For deadlines and exception design, see the Remediation SLAs and Vulnerability Exceptions Guide; this page concentrates on the boundary between the two outcomes.

Mitigation: threat model, architecture and failure modes

Threat model: a known weakness that an attacker can reach, where the fix is unavailable, unsafe to deploy in time, or blocked by a business dependency. Mitigation buys time by cutting reachability (take the interface off the internet), blocking known exploit patterns (a WAF or IPS rule), shrinking impact (remove privileges, segment) or raising detection (alerting on exploitation indicators).

Architecture in words: a control sits between the attacker and the weakness, or between the weakness and what it can reach. Its effectiveness depends on every attack path crossing it. A WAF rule protects only traffic that passes through the WAF; a firewall rule protects only the interfaces it governs. See the Virtual Patching and Compensating Controls Guide for choosing and testing the control itself.

Failure modes:

• Bypass: a rule blocks the published proof of concept but not variants, alternative encodings or a second endpoint.
• Drift: a firewall change, a new load balancer or a cloud migration creates a path that skips the control.
• Silent expiry: the control is removed in a clean-up months later because nobody recorded why it existed.
• Exposure before mitigation: the weakness was reachable before the control went in, so compromise may already have happened. Mitigation does nothing about that.

Controls that make mitigation defensible: a named owner, a test against the attack path and its variants, monitoring that proves the control is still in the path, a residual risk rating, and an expiry date no later than the planned remediation date.

Remediation: threat model, architecture and failure modes

Threat model: the same weakness, removed so that no attack path leads to it. Remediation is the only response that lets the record end without an ongoing control cost.

Architecture in words: the vulnerable component, code, configuration or credential is replaced or corrected and the change is verified by the same method that found the weakness. Remediation is broader than patching. It includes removing an unused package, correcting a configuration baseline, changing a design that exposed an internal API, revoking and reissuing a credential, or decommissioning the asset. CISA's BOD 22-01 FAQ, for example, treats removing an asset from the network as the option when the catalogue action cannot be applied in time, and describes isolation as a form of removal.

Failure modes:

• Unverified closure: the ticket closes on deployment, without a rescan, and the patch failed on part of the estate.
• Partial scope: one instance is fixed; the same library in a container base image or another service remains.
• Regression: a later build reintroduces the vulnerable version because the dependency was not pinned.
• Fix without clean-up: the software is patched, but credentials, sessions or keys exposed while it was vulnerable are left valid.

Audit treatment of compensating controls

Auditors and assessors differ in vocabulary but ask the same questions: does the control meet the intent of the requirement, is it documented and approved, has it been tested, and is it still operating?

Two practical consequences follow. First, a mitigation that has not been re-validated since the last assessment is weak evidence; schedule re-tests and keep the results with the record. Second, an audit finding about the vulnerability process itself, such as mitigated items reported as remediated, is a control deficiency in its own right. See Audit Exception vs Control Deficiency for how auditors grade that.

Exceptions, expiry and when mitigation must convert to remediation

A mitigation is a time-bound exception. Set its expiry from the remediation plan, not from a default, and define the events that end it early.

Tooling should enforce expiry: when the date passes, the finding returns to breached status automatically rather than waiting for someone to notice. The Vulnerability Risk Acceptance and Exception Template and the Hardening Exceptions and Compensating Controls Template provide usable record formats.

Where identity fits: exposed NHI credentials

Credential findings are where the two terms are most often confused. OWASP lists NHI2:2025 Secret Leakage in its Non-Human Identities Top 10, describing API keys, tokens, encryption keys and certificates leaking into source code, configuration files, logs and chat tools, and recommends short-lived credentials, automated rotation and secret scanning. GitHub's secret scanning documentation is blunt: "Once a secret has been committed to a repository, you should consider the secret compromised." It also notes that alerts are not closed automatically when the token is removed from code.

Removing a secret from the current code is not remediation either: the value is still valid wherever it was copied. The Cloudflare Thanksgiving breach shows the cost of an unverified assumption: after the October 2023 Okta incident, one service token and three service account credentials were not rotated because they were wrongly believed to be unused, and an attacker used them weeks later. See the Leaked Credential Response Playbook and Credential Rotation at Scale.

Worked scenario

A payments company's quarterly review finds three items marked closed.

1. A critical flaw in an internet-facing file transfer appliance was closed after a WAF rule went in. The vendor released a fix five weeks ago. Treatment: reopen as mitigated, start the remediation clock from the fix release, retest the WAF rule against the observed exploit, and hunt for compromise during the window before the rule was deployed.
2. An outdated TLS configuration on a legacy batch server carries an operational requirement because a partner cannot upgrade. Treatment: keep it open, confirm network restriction to the partner's addresses, set a review date and record the partner's committed upgrade date. Escalate if renewed a second time.
3. A cloud access key found in a public repository was closed when the commit was deleted. Treatment: reopen, revoke and reissue the key, review provider logs from the commit date, and move the workload to short-lived credentials so the finding class cannot recur.

Only the second item was a legitimate open mitigation. The other two were misreported, which is itself a process finding. The scenario is illustrative.

Decision criteria

• Remediate directly when a tested fix exists and can be deployed inside the SLA, or when the finding is an exposed credential.
• Mitigate, then remediate when exploitation is likely before the fix can be deployed safely, or when no fix exists yet.
• Accept with mitigation only when remediation would break a required function, with an end date tied to a replacement plan.
• Retire when repeated renewals show the asset will never be fixable; isolation or decommissioning is remediation.
• Small organisations: keep one exception register with expiry dates and a monthly review; prefer remediation, because every mitigation adds upkeep a small team cannot sustain. Large organisations: separate statuses in tooling, automatic expiry, approval levels by severity, and quarterly re-validation of long-lived controls. Compare deadline models in Fixed Patch SLAs vs Risk-Based Remediation Windows.

Implementing the distinction

1. Define statuses: add remediated, mitigated, accepted, vendor dependency and false positive to the finding workflow, with required evidence fields for each.
2. Reclassify the backlog: sample closed findings from the last two quarters and rescan; anything still detected moves to mitigated or reopened.
3. Pilot: run the new statuses in report-only mode for one business unit for a quarter, reporting mitigated items separately without escalation.
4. Enforce: make expiry automatic, require conversion triggers to reopen items, and add credential rotation as a closure condition for secret findings.
5. Roll back by returning a unit to report-only if the workload surge causes rushed, unsafe changes; never by extending expiries silently.

Detection and measurement

• Control health: monitor that each compensating control is still in the path (rule hit counts, firewall configuration drift, key usage logs).
• Rescan disagreement: any finding marked remediated that reappears in the next scan.
• Credential use after exposure: authentication events from a supposedly revoked or restricted key.

Metrics:

• Open mitigated findings by severity and age, reported separately from remediated counts.
• Percentage of mitigations converted to remediation by their expiry date.
• Percentage of compensating controls re-validated in the last quarter.
• Reopen rate: findings closed as remediated that are detected again within 90 days.
• Median time from secret exposure to revocation, for NHI credential findings.

Framework mapping

In ISO/IEC 27001:2022 the relevant points are clause 6.1.3 Information security risk treatment and Annex A 8.8 Management of technical vulnerabilities.

Common failure patterns

• Reporting mitigated findings as closed: backlog metrics look healthy while the weaknesses remain.
• No conversion trigger: a mitigation outlives the vendor fix by months because nothing reopened it.
• Untested compensating controls: a rule that blocks one proof of concept is accepted as full mitigation.
• Exempting credentials on assumption: as in the Cloudflare case, "unused" is a guess until last-used data confirms it.
• Deleting the commit instead of revoking the secret: the credential stays valid wherever it was copied.
• Endless renewals: the same exception renewed every quarter without a replace-or-retire decision.

Practitioner checklist

• Separate remediated, mitigated, accepted, vendor dependency and false positive in tooling and reports.
• Require a tested attack-path control, owner, residual rating and expiry for every mitigation.
• Tie each mitigation expiry to a planned remediation date, never to a default.
• Define conversion triggers: fix released, exploitation confirmed, control failure, second renewal, scope change.
• Verify every remediation with a rescan or retest before closure.
• Close secret findings only after revocation, replacement and log review.
• Re-validate long-lived compensating controls at least quarterly.
• Report mitigated findings by age to the risk committee.

Standards and references

• NIST: Glossary, Remediation
• NIST: Glossary, Risk Mitigation
• NIST: SP 800-53 Rev. 5
• NIST: SP 800-40 Rev. 4, Guide to Enterprise Patch Management Planning
• CISA: BOD 22-01 Reducing the Significant Risk of Known Exploited Vulnerabilities
• FedRAMP: Plan of Action and Milestones (legacy playbook)
• OWASP: Non-Human Identities Top 10, NHI2:2025 Secret Leakage
• GitHub: Resolving alerts from secret scanning

Related NHI Mgmt Group resources: Remediation SLAs and Vulnerability Exceptions Guide · Fixed Patch SLAs vs Risk-Based Remediation Windows · Virtual Patching and Compensating Controls Guide · Security Exceptions and Risk Acceptance Guide · OWASP NHI Top 10 NHI2 Secret Leakage Guide