Unresolved Anomalies in FDA Cybersecurity Filings

Published June 11, 2026

Why this matters

A device may have no known unresolved security anomalies; document the assessment rather than assuming open findings must exist. A clean submission acknowledges what is open, characterizes the risk, and shows that the residual is acceptable. The Feb 2026 guidance is explicit:

Submissions that omit the section, or include a one-liner saying "no unresolved anomalies," draw the same deficiency pattern: "Provide the manufacturer's assessment process and the results, including any items identified and the rationale for leaving them unresolved." That request stops the review clock on PMA / De Novo and triggers an AI request on 510(k).

Official sources: FDA, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions (February 2026); FDA eSTAR Program; FDA Cybersecurity in Medical Devices FAQs (Section 524B); NIST Cybersecurity Framework.

What counts as an unresolved anomaly

Reviewers treat the following as in-scope for the anomaly assessment:

• Known CVEs in third-party components that are present in the SBOM but not yet patched, including those VEX-marked under_investigation or affected with a deferred fix
• Static analysis findings that have been triaged and suppressed (with rationale) but remain in the codebase
• Dynamic analysis / DAST findings that were accepted as low-risk or deferred to a future release
• Penetration test findings that were not remediated before submission
• Fuzz testing crashes that have been triaged but not yet fixed
• Architectural decisions that introduce known residual risk (e.g. legacy protocol support required for interoperability)
• Configuration items that are not at the cybersecurity ideal (e.g. a logging level that is reduced for performance)

This is not a list of failures. It is a list of decisions. Reviewers credit explicit decisions and penalize silence.

What every anomaly entry must contain

We recommend six elements for each entry; this is an organizing approach, not a prescribed regulatory schema:

1. Identifier, internal tracking ID, plus CVE / CWE where applicable.
2. Description, what the anomaly is, in language a reviewer can understand without internal context.
3. Cybersecurity impact, the threat(s) it relates to (referenced by threat model ID), the patient-harm pathway it could enable, and the CVSS or equivalent severity.
4. Compensating controls, what is in place that reduces the practical risk (network isolation, authentication requirement, off-by-default configuration, monitoring detection).
5. Residual-risk justification, why the remaining risk is acceptable, tied to the risk assessment thresholds.
6. Planned resolution, when and how the anomaly will be addressed (next minor release, next major release, monitored indefinitely with rationale).

For VEX-driven CVE entries, the VEX statement and the entry above must agree. Reviewers cross-check.

How to present a clean assessment

The cleanest format we have seen accepted is a single appendix to the testing attachment with two tables and a narrative:

Table 1, Anomaly process. How does the manufacturer surface anomalies? What feeds are watched (NVD, GitHub Advisory DB, CISA KEV, EPSS, vendor advisories, internal bug tracker, pen test reports, fuzz use output)? Who triages? On what cadence?

Table 2, Open anomalies at submission. One row per anomaly with the six recommended elements above.

Narrative. A one- to two-page summary that explains the patterns reviewers should expect to see, calls out the highest-residual items, and links each one back to the risk assessment residual-risk argument and the postmarket monitoring plan.

Common deficiency patterns

See also: PreSTAR vs eSTAR: What Each FDA Template Is For, eSTAR v7.1 Cybersecurity for IVDs vs nIVD Submissions, and Patch and Update Mechanism Testing.

1. No assessment at all. "Submission does not contain an assessment of unresolved cybersecurity anomalies. Provide."
2. "None" without process. "Manufacturer states no unresolved anomalies. Provide the process by which anomalies are identified and triaged, and the evidence supporting the 'none' conclusion."
3. CVE list without VEX agreement. SBOM shows an applicable CVE; anomaly assessment does not list it; no applicability rationale explains the omission. VEX is optional and is not required by FDA guidance.
4. Pen test findings deferred without rationale. Pen test report shows a Medium finding; anomaly list shows the same finding "deferred"; no compensating control listed and no residual-risk argument. Reviewers ask why.
5. Suppressed SAST findings with stub rationale. "False positive" with no detail. Reviewers want the analysis that supports the suppression.

How Blue Goat Cyber prepares anomaly assessments

We treat the anomaly assessment as a synthesis deliverable that draws from the SBOM, the SAST/DAST reports, the pen test report, and the fuzz use output. Every entry is checked against its source artifact and against the risk assessment residual-risk thresholds. VEX statements are reconciled with the assessment entries. The assessment goes into the testing attachment with cross-references that let a reviewer trace any item back to its source in one hop. Where decisions favor deferral, we write the compensating-control narrative before submission, not in response to a deficiency.

If the FDA raises a cybersecurity question, we answer it at no extra cost until the cybersecurity portion is closed. See our cybersecurity submission services.

If you want one team to own the whole cybersecurity package, see our full-service FDA premarket cybersecurity submission support.

FAQ

Need help preparing your anomaly assessment?

If you are within 4-8 weeks of a 510(k), De Novo, or PMA submission and have not yet built the unresolved anomalies appendix, we will synthesize it from your existing artifacts and write the residual-risk argument. Request a scoping call.

Christian Espinosa, Founder, Blue Goat Cyber., ex-military red team. Blue Goat track record: 275+ FDA submissions supported, zero cybersecurity rejections. More on the author.

Related reading

• FDA Cybersecurity Testing Requirements Taxonomy
• The SPDF Playbook
• eSTAR v7.1 Cybersecurity Attachments mapping
• Cybersecurity Management Plan for FDA Submissions
• Security Control Categories the FDA Expects
• STRIDE Threat Modeling for Medical Devices

More on this topic

• Mastering Cybersecurity in MedTech