When reviewing a connected medical device, the FDA looks for evidence that its security controls address its identified risks throughout the product life cycle. A manufacturer may have strong security features built into a product and still face questions if the submission does not connect those controls to test results. The U.S. Food and Drug Administration (FDA) describes these expectations in its February 2026 premarket cybersecurity guidance. Many roadblocks begin well before the submission is assembled, making early coordination between regulatory and engineering teams important, with quality and cybersecurity staff involved from the start.
Security Work Starts Too Late
Cybersecurity can create problems when it is treated as a documentation exercise near the end of development. At that stage, teams may discover that earlier design decisions were never supported by a formal threat model or clearly documented security requirements.
Retrofitting that evidence is difficult. Starting security activities earlier allows threat modeling to influence the architecture while changes are still practical.
For a concrete authentication example, the National Institute of Standards and Technology (NIST) documented infusion-pump certificate validation through Cisco Identity Services Engine (ISE) in its 2018 practice guide. Its test configuration used Extensible Authentication Protocol–Transport Layer Security (EAP-TLS), and the expected results included successful authentication in ISE and an online pump in the pump-server portal. That level of detail gives reviewers more to assess than “authentication passed.”
Documents Tell Different Stories
Submission materials are often created by different teams at different points in development. That can produce subtle inconsistencies.
An architecture diagram may show a wireless interface that receives little attention in the threat model. A risk assessment might identify a vulnerability without clearly connecting it to verification evidence. Software documentation can also fall out of sync after a design change.
Cybersecurity evidence is stronger when reviewers can follow a clear path from an identified threat to the control used to address it and the testing that demonstrates the control works. Make that traceability part of your regulatory strategy, rather than leaving teams to reconcile documents just before submission.
Testing Needs More Than a Pass Result
Security testing should provide meaningful evidence about the actual device and its attack surface. A penetration test report needs to explain its scope and test configuration. Without the methods and findings, a passing result may leave important questions unanswered.
Effective medical device security validation should connect testing activities with documented security requirements and identified risks. Findings also need appropriate disposition. If testing discovers a weakness, the submission should make clear how the issue was evaluated and whether corrective work or additional testing followed.
Consider a historical component-level example: OpenSSL’s November 2022 advisory identified certificate-processing vulnerability CVE-2022-3602 in versions 3.0.0–3.0.6, fixed in 3.0.7. For an affected device, a useful closure record would identify the replacement library and link to regression tests of certificate handling. But the historical fixed version alone is not a present-day acceptance criterion; the review must address the device’s actual build and remaining risks.
Software Components Create Ongoing Responsibilities
Connected devices frequently incorporate open-source, commercial, and off-the-shelf software. For applicable premarket submissions involving cyber devices, Section 524B of the Federal Food, Drug, and Cosmetic Act requires a software bill of materials (SBOM) identifying these components. The SBOM is a statutory requirement for those submissions, not simply an optional inventory.
The challenge continues after the inventory is created. Manufacturers need processes for monitoring vulnerabilities that could affect included software and determining whether updates or other responses are necessary.
A component that appears acceptable during development can acquire a newly disclosed vulnerability after the device reaches the market. Premarket documentation therefore needs to connect logically with postmarket cybersecurity processes.
FDA Cybersecurity: Postmarket Planning Cannot Be an Afterthought
The agency’s cybersecurity expectations extend beyond authorization. Manufacturers of applicable cyber devices need plans and procedures for monitoring, identifying, and addressing vulnerabilities after release.
A plan that exists only on paper can create questions if it does not reflect how updates will actually be developed and tested. It also needs to account for distribution and communication with users. The device architecture itself can affect whether security updates are practical once products are deployed.
Before FDA submission, ask your team to trace one security finding from the affected software component through corrective work and retesting. Then check whether the same record explains how an update would reach deployed devices through your postmarket surveillance process. Check out the infographic below for more information.
