CVE Remediation for Devices You've Already Shipped

TL;DR

CVE remediation is the work of getting a known vulnerability down to an acceptable risk level and proving it stayed there. For software you operate, that ends when the patch deploys. For a device already in a customer's hands, it ends when you can show the fix is present in the binary that shipped, which is a different and harder problem. This guide covers the five-step workflow, how to rank findings when CVSS alone misleads you, what to do about components you cannot patch, and how to verify a fix survived the build.

What is CVE remediation?

CVE remediation is the work of reducing the risk a known vulnerability poses to an acceptable level, then proving the reduction held.

A CVE is a public identifier for a disclosed flaw, issued through the CVE Program. Remediation is everything you do after the identifier shows up in a scan of your product.

For most of the industry, that work happens on infrastructure you control. You see a finding, you patch the host, you rescan. Done.

We work with manufacturers, and it does not go like that.

When the vulnerable code is inside a device sitting in a hospital, a substation, or a vehicle, three things change:

• You ship an update. You do not apply one. Whether the fix reaches the device depends on your customer's update policy, their maintenance window, and in some cases whether the unit supports field updates at all.
• The fix has to survive the build. A patched source tree still has to make it through cross-compilation, linking, and packaging before it becomes the firmware you sign.
• Somebody is going to ask for proof. Regulators and enterprise customers want the test report, not your word.

So the definition we work to is longer than the industry standard one: remediation is complete when the fix is verified in the artifact the customer is running, and you have the evidence on file.

Everything below is how you get there.

How is remediation different from patching?

Patching is one remediation method among several. Configuration changes, compensating controls, component replacement, and documented risk acceptance all close a finding.

The two words get used interchangeably and it causes real problems. A patch is a code change from a vendor or maintainer. Remediation is the decision about what to do with a finding, and patching is one of the available answers.

The distinction matters most when a patch is unavailable or unsafe to deploy:

• The upstream project is abandoned and no fix exists.
• The fix requires a major version bump that breaks your platform.
• The vulnerable component came from a supplier as a compiled binary.
• The device is in a safety-critical deployment and the patch has not cleared validation.

In every one of those cases patching is off the table and remediation is still required. Treating the two as synonyms leaves teams stuck, reporting a finding as "cannot remediate" when what they mean is "cannot patch."

The reverse trap is worse. Applying a patch and calling the CVE closed, without checking that the patched code reached the shipped image, produces a clean dashboard over an unfixed device. We see it regularly.

What are the standard steps in a CVE remediation workflow?

Five steps: confirm the finding applies, rank it against your product, choose a remediation path, build and ship the fix, verify it landed.

1. Confirm the finding applies. Is the component actually in this product, at this version, in a configuration where the vulnerability is reachable? A large share of scan output fails this test.
2. Rank it. Severity, exploitation status, and product context, covered in the next section.
3. Choose a path. Patch, reconfigure, add a compensating control, replace the component, or accept the risk in writing.
4. Build and ship. Implement, build, regression test, package, sign, release, and tell customers it exists.
5. Verify it landed. Confirm the fix is present in the built artifact and that nothing else broke.

Most vulnerability management programs are strong on step 2 and thin on steps 1 and 5. Tooling pushes you that way: scanners rank things beautifully and tell you nothing about whether the finding was real or whether the fix worked.

Where the loop closes. Steps 1 and 5 are the same skill applied at two ends of the process. Both require analysis of the compiled artifact. That makes them the cheapest place to add rigour, because one capability serves both. Fitting this into a wider process is covered in our post on SSDLC and global cybersecurity regulations.

How should you prioritize CVEs for remediation?

Start with CVSS severity, then adjust for active exploitation, exploit probability, and whether your product reaches the vulnerable code at all.

CVSS gives you a 0 to 10 severity score describing impact under favourable exploit conditions. It is a useful starting point and a poor stopping point, because it says nothing about your product.

Four signals, in the order they change a decision:

• Active exploitation. A vulnerability confirmed as exploited in the wild outranks a theoretical one. CISA's Known Exploited Vulnerabilities catalog is the standard reference, and FDA's premarket guidance recommends that KEV-listed vulnerabilities be designed out of a device rather than risk-accepted.
• Reachability. Whether your firmware calls the vulnerable code path. This eliminates more findings than any other signal, because a library linked for three functions carries vulnerabilities across the hundreds you never invoke. Exploitability-based prioritization is how we cut this down.
• Exploit probability. EPSS, maintained by FIRST, estimates the likelihood of exploitation in the near term. Useful for ordering the middle of the queue where CVSS scores bunch up.
• Severity. CVSS, which sets the floor for the other three signals to adjust.

Then apply what no database knows about your product. Is the vulnerable service exposed on the network interface, or reachable only over a debug header inside a sealed enclosure? Does exploitation affect patient safety, grid stability, or a status LED? Can the device be updated in the field, or is a flaw shipped today permanent for the life of the unit?

A CVSS 9.8 in an unreachable code path on an air-gapped device ranks below a CVSS 6.1 in a network-facing service on a fleet that auto-updates. The score does not know that. You do.

What are your remediation options when you cannot patch?

Four paths stay open: change the configuration, add a compensating control, replace the component, or accept the risk with written justification.

Every option carries a different cost and a different reach on a device you have already shipped.

Two notes from doing this work.

Risk acceptance is a legitimate engineering decision, and it is only defensible in writing. Record the identifier, why remediation is not feasible, the controls already in place, the residual risk, who accepted it, and when it gets reviewed again. A deferred finding with that record is a position. The same finding deferred silently is a gap that surfaces during an audit, years later, when nobody remembers the reasoning.

Advisory-only remediation counts, and it has to be tracked. Telling customers to disable a feature reduces risk on the units where they do it. Your records should show how many that is.

Why do published version ranges send you after the wrong CVEs?

A range names the release that carried the fix. Versions below it get flagged, including versions built before the vulnerable code existed.

One CVE shows this cleanly, and it is worth walking through because the pattern repeats constantly.

CVE-2017-13704 is recorded in the National Vulnerability Database as affecting "dnsmasq before 2.78." A malformed DNS packet drives a negative value into a memset size parameter, which then writes up to 0xffffffff zero bytes and crashes the process. CVSS 3.0 base score 7.5, High.

Now the part the range leaves out. The vulnerable memset calls were added in 2.77, as a hardening measure to zero response buffers. The flaw is a regression. It exists in 2.77 and was fixed before 2.78. Versions 2.76 and earlier never contained the code.

An SBOM listing dnsmasq 2.76 gets flagged against "before 2.78," and the finding is wrong. Three distribution security teams reached that conclusion independently: Debian's security tracker marks wheezy, jessie, and stretch not-affected with the note "Regression introduced in 2.77," and SUSE and Amazon Linux both record their packages as unaffected.

Three causes account for most bad findings:

• Range arithmetic. "Before X" assumes every earlier release is vulnerable. Regressions break that assumption.
• Silent backports. A supplier applies a fix without bumping the version string, so the version reads vulnerable and the code is not.
• Unreachable code. The function is present and your product never calls it.

Every one of these is caught by looking at the compiled artifact. None of them is caught by reading a version number.

Which components in your firmware can you not patch yourself?

Supplier blobs, vendor SDKs, and RTOS binaries arrive compiled. Remediation there means pressuring the supplier or mitigating around the component.

A firmware image is an assembly of parts with different owners, and your remediation options change per part.

The bottom three rows are where remediation programs stall, and the stall is contractual. If your supplier agreement carries no security patch SLA, you have no remediation path for their component and nothing to negotiate with.

Two things help. Knowing precisely which supplier component carries the finding, which needs analysis of the compiled image, since these components declare nothing in a build manifest. And getting patch obligations into supplier contracts before you need them, which starts as a procurement conversation.

How do you verify a security fix actually shipped?

Analyze the built firmware image. Compare the vulnerable build against the fixed build and confirm the change survived compilation and packaging.

This is the step teams skip, and it is the one we get called about after something goes wrong.

Fixing a CVE means nothing if the vulnerability persists in the compiled firmware.

A patch can be present in your repository and absent from your release for reasons that have nothing to do with the patch:

• The build pulled a cached object file predating the change.
• The vulnerable library was statically linked from a stale artifact in the build tree.
• A compiler optimization removed the check the fix added.
• The build system pulled the component from a vendor mirror rather than your patched copy.
• Someone reverted the change during a merge and CI stayed green.

None of these show up in code review. All of them show up in the binary.

What verification looks like. You take the build you know was vulnerable, take the build you believe is fixed, analyze both at the binary level, and confirm the specific change is present in the second one and absent from the first. Then check that nothing else moved that should not have. Independent binary-level penetration testing goes further and attempts the original exploit against the fixed build.

What does remediation testing involve in practice?

Before-and-after comparison across source and binary, delta-based retesting of the affected areas, and a fix validation report documenting method and evidence.

Our remediation validation engagements typically include four pieces.

Before and after comparisons. We re-run binary analysis, source code scans, and manual testing to compare the vulnerable version against the fixed version, confirming the vulnerability is gone and nothing else broke.

Delta-based testing. Rather than repeating an entire test suite, we retest the affected areas, which holds coverage without the cost of a full re-engagement.

Fix validation reports. We document the remediation evidence and the methodology, which gives your team something to hand to an auditor or a customer.

Source and binary perspective. We validate the fix from both the code and the compiled firmware, so a change lost during the build or nullified by a downstream toolchain gets caught before release.

"Patching is only half the battle. If you don't verify your fixes, you're flying blind, and that's not a place you want to be with regulators or attackers."

Here is the problem this addresses. Embedded systems are difficult to test after a patch. Firmware is opaque. Dependencies are fragile. Teams are under pressure to ship. Without independent validation, things slip through.

That is where Finite State Services closes the loop.

What do the CRA and FDA require for CVE remediation?

The CRA sets reporting clocks of 24 hours, 72 hours, and 14 days for actively exploited vulnerabilities. FDA wants your test reports in the submission.

The CRA's remediation clock starts at exploitation, not disclosure. From 11 September 2026, manufacturers must report actively exploited vulnerabilities in their products to ENISA and the coordinating national CSIRT: an early warning within 24 hours of becoming aware, a fuller notification within 72 hours, and a final report within 14 days of a corrective measure being available. Severe incidents follow the same first two steps with a one-month final report.

Read that last deadline carefully. The 14 days run from when your fix is available, so the CRA does not set a patch deadline. It sets a reporting deadline pegged to your own remediation, and the final report has to describe the remediation applied. Vulnerabilities you find and fix before anyone exploits them stay inside your ordinary vulnerability-handling process. This obligation covers every in-scope product on the EU market, including units placed there before the deadline.

On independent validation, the record needs correcting. Under the CRA, self-assessment is the default route. Most products, the default category, assess their own conformity under internal control. Important products in Annex III Class I keep self-assessment where harmonised standards or an EU certification scheme cover all applicable essential requirements. Annex III Class II needs a notified body in some cases, and Annex IV critical products need one in every case. Our post on CRA conformity assessments breaks the classes down.

FDA works the same way. The current guidance, Cybersecurity in Medical Devices, issued 3 February 2026, asks manufacturers to submit their own security testing documentation and associated reports. It also asks for the tool name, version, and configuration used to produce them.

So third-party validation is mandatory for a narrow set of product classes. What is universal is the evidence. Both regimes want a written, dated, reproducible record that the fix works, whoever produced it. That record is the output of remediation testing, and it is far easier to generate as you go than to reconstruct afterwards.

Whether you're fixing a critical CVE, responding to a customer penetration test, or preparing for a product launch, the remediation testing service exists so you close the vulnerability instead of checking a box.