Compliance & Regulation

How ELTON supports CAPA for cybersecurity vulnerabilities

A cybersecurity vulnerability is a quality event. The FDA said as much in its 2016 postmarket cybersecurity guidance, which points manufacturers to their CAPA systems when a vulnerability presents uncontrolled risk. And CAPA is not a soft expectation. 21 CFR 820.100 is one of the most frequently cited sections in FDA inspections, and it applies to security findings the same way it applies to a failed weld.

Findings reach you from two directions. Internal: your own testing, code review, SBOM analysis. External: coordinated disclosures, customer complaints, field service reports. The external path also pulls in 21 CFR 820.198, because a security report from the field is a complaint and has to be handled as one. Both routes end in the same place: a record that has to stand on its own months or years later, in front of someone who wasn't there when the call was made.

One CAPA trail for every cybersecurity findingInternal findingtesting, review, SBOMExternal reportCVD, complaint, fieldCapture and tracecomponent, version,score, rationaleCorrectpatch linked, retestedJustify no-fixevidence on recordAudit-readyrecord820.100 / 8.5.2Preventive action (ISO 13485 clause 8.5.3)recurring components and weaknesses across products feed design rules and supplier controls
Corrective action closes the finding. Preventive action changes the next product.

The QMSR shift doesn't retire CAPA. It sharpens it.

In February 2026 the QMSR takes effect and 21 CFR Part 820 incorporates ISO 13485:2016 by reference. Corrective action becomes clause 8.5.2, preventive action becomes 8.5.3. The vocabulary changes. The obligation doesn't: identify the cause, act on it, verify the action worked, and keep records that prove all of it.

So the question for security teams is not whether vulnerabilities belong in CAPA. It's whether your vulnerability records can survive contact with a quality auditor, whichever rulebook that auditor is holding.

What a defensible cybersecurity CAPA record contains

When ELTON registers a finding, it links the vulnerability to the affected components, the device version, and the software architecture it lives in. It records how the issue was discovered, when it was triaged, why it was scored the way it was, and what happened next. That's the traceability 820.100 asks for: every action traceable to a root cause and an outcome.

The scoring piece matters more than most teams expect. A severity number with no documented method behind it invites the follow-up question. ELTON rates findings through the MITRE CVSS rubric the FDA qualified as an MDDT, so the rationale behind every severity call is part of the record rather than one engineer's recollection.

Corrective action in security depends on system context, not just vulnerability presence. ELTON evaluates exploitability and downstream impact against the device's interfaces and trust boundaries. If you remediate, the patch is linked to the original finding and retested, so the record shows the system-level risk actually dropped. If you don't remediate, the 2016 guidance lets you justify a controlled risk, and that justification gets captured as evidence rather than a sentence in a spreadsheet.

An inspector never asks whether you had vulnerabilities. They ask what you did about them, and whether you can show it.

Most findings end in a documented no-fix. That's the correct outcome for the majority of vulnerabilities in any real device. But a no-fix without evidence is exactly the vague risk acceptance that turns into a Form 483 observation.

Preventive action is where the data starts paying

Correction closes one finding. Prevention needs patterns. Because ELTON holds findings across products and releases, it surfaces the recurring third-party component, the insecure configuration that keeps reappearing, the design weakness shared by three product lines. Those trends feed preventive updates to design rules, supplier controls, and internal process, each one logged and linked back to the originating issue.

That's also what the 2016 guidance means when it asks manufacturers to keep reassessing exploitability and severity over time. Prevention isn't a brainstorm. It's what your own data tells you to change before the next disclosure arrives.

I've watched security teams treat CAPA as a paperwork tax, something quality makes them do after the interesting work is over. I think that's backwards. CAPA is where security work becomes legible to the quality system, and the quality system is what the FDA actually inspects. If a vulnerability disposition can't survive that translation, it isn't finished.

← All intelligence
Get started

See your device through ELTON.

Start with one device. We build the twin from documentation your quality system already produces, run AI discovery remotely, and show you the graph: the handful to fix, and the evidence for everything else.

Automate medical device vulnerability discovery and verification. FDA §524B methodologyExploitability proven on-device95% faster than legacy testing Book a Demo
Platform
Platform OverviewDigital TwinAutonomous TestingExploitability VerificationVulnerability GraphRemediation OptimizationELTON TestLink™Lifecycle & MetricsCVSSv4 Migration
Solutions
FDA §524BEU MDR/CRAEU REDNIS2IMDRF N60 / N73Postmarket SurveillanceIncident Response
Why ELTON
Why ELTONPricing
Resources
Intelligence & BlogRegulatory GuidesWebinarsWhitepapers
Company
AboutLeadershipCareersContact Book a Demo