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.
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.
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.
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.
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.
One issue a month on AI, exploitability, and FDA cybersecurity review. No spam, unsubscribe anytime.
Yes. The FDA's 2016 postmarket cybersecurity guidance points manufacturers to their CAPA systems when a vulnerability presents uncontrolled risk. 21 CFR 820.100 is one of the most frequently cited sections in FDA inspections, and it applies to a security finding the same way it applies to a failed weld.
Yes. External findings arriving through coordinated disclosure, customer complaints or field service reports pull in 21 CFR 820.198, so a security report from the field has to be handled as a complaint. Internal findings from testing, code review and SBOM analysis end in the same kind of record.
No. In February 2026 the QMSR takes effect and 21 CFR Part 820 incorporates ISO 13485:2016 by reference, so corrective action becomes clause 8.5.2 and preventive action becomes 8.5.3. The vocabulary changes, the obligation does not: identify the cause, act on it, verify the action worked, keep records.
Yes, and it is the correct outcome for most vulnerabilities in any real device. The 2016 guidance allows a justified controlled risk. A no-fix without evidence is the vague risk acceptance that turns into a Form 483 observation, so the reasoning has to be captured as evidence rather than a line in a spreadsheet.
Correction closes one finding. Prevention needs patterns: 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.