FDA cybersecurity testing takes more than a clean scan. I use four testing categories to check device security, validate fixes, and link results to patient safety decisions:
- Security requirement testing: Check that security functions meet defined pass/fail criteria.
- Threat-control testing: Check that controls block or limit modeled attacks.
- Vulnerability testing: Find weaknesses and assess whether they affect the device.
- Penetration testing: Test attack paths and their potential impact.
For devices covered by Section 524B, I separate legal duties from FDA recommendations: manufacturers must provide an SBOM, a postmarket cybersecurity plan, and processes for device security and updates. I also keep testing within quality-system controls; the QMSR took effect on February 2, 2026.
My release check is simple: match records to the tested build, validate fixes, check for regression, and assign an owner to every unresolved finding. A released patch is not the same as a deployed patch. That’s why I track customer deployment separately and coordinate with healthcare delivery organizations. This coordination is part of a broader effort to advance third-party risk management across the ecosystem.
<u>The goal: trace each finding from discovery through risk review, testing, release, and postmarket follow-up.</u>
FDA Cybersecurity Testing: From Findings to Postmarket Follow-Up
Case Study: Why FDA Cybersecurity Expectations Are Really QMS Expectations
sbb-itb-535baee
Plan the 4 Cybersecurity Testing Categories
FDA guidance identifies four cybersecurity testing categories.[2][5] Give each its own objective and test evidence. Penetration testing does not replace security-requirement verification. Match coverage to the device’s architecture, intended use, and exposure, with attention to attack paths and patient-safety impact.[7][10]
Use these categories to prevent gaps, duplicate work, and weak evidence.
| Category | Objective | Key inputs | Lifecycle stages | Test records | Related requirements or risks |
|---|---|---|---|---|---|
| Security requirement testing | Verify that specified security functions work as intended | Requirements, design specifications, acceptance criteria | Verification, validation, releases, regression | Procedures, expected and observed results, defects, retests | Authentication, authorization, encryption, logging, secure updates |
| Threat-control testing | Show that controls reduce modeled threats and misuse cases | Threat model, misuse cases, risk controls, safety analysis | Design, validation, major changes | Scenario results, control traceability, residual-risk assessment | Tampering, spoofing, denial of service, patient harm |
| Vulnerability testing | Find known and implementation-level weaknesses | SBOM, vulnerability databases, source code or binaries | Development, release gates, postmarket monitoring | Tool versions, coverage, findings, manual validation | Vulnerable dependencies, weak credentials, malformed inputs |
| Penetration testing | Establish realistic exploit paths and their impact | Attack surface, threat model, rules of engagement | Validation, major releases, risk-based postmarket triggers | Tester expertise and independence, methods, findings, limitations, retests | Privilege escalation, chained attacks, remote compromise |
Verify Security Requirements and Threat Controls
Make each acceptance criterion observable. Test authentication with invalid credentials and specified throttling. Check that lower-privilege accounts cannot perform prohibited actions. Test data protection against specified encryption and key-management requirements, and check that logs include the required event details.
Verify that secure updates reject packages that lack authorization or have been altered, and that update failures leave the device in a defined safe state. Link every test to its requirement, threat or misuse case, risk control, and pass/fail criterion. Threat-control testing must show that a control blocks or limits the modeled attack - not just that the feature exists.[7][9]
Run Vulnerability Scans and Penetration Tests
Combine automated scanning, software composition analysis, and static or dynamic analysis with manual review. Add fuzzing and malformed-input tests for interfaces that parse inputs. Check whether attackers can chain weaknesses, and use black-box testing when an external attacker’s perspective fits the assessment.
Scanner output alone cannot establish exploitability, control effectiveness, or acceptable residual risk. Review findings against the threat model and critical medical device security risks.[8][10]
For penetration testing, define the scope and rules of engagement: targets, exclusions, duration, credentials, prohibited actions, stopping conditions, and evidence handling. Record tester qualifications and independence, scope, methods, attempted and successful attacks, affected components, findings, and limitations. Explain how exclusions limit coverage; untested areas are not proof of security.[5][8] Move every finding directly into risk triage, fix planning, and retesting.
Define System Boundaries and Test Conditions
Map firmware, software, interfaces, update paths, cloud services, dependencies, and trust boundaries. Identify representative hardware and builds, privilege levels, configurations, and network conditions. Explain any differences from the marketed system.
Use isolated settings, synthetic data, and recovery procedures for disruptive tests. Define retest triggers for releases, interface or dependency changes, new vulnerabilities, and incidents. Identify which supported postmarket versions need testing, and set retest frequency based on risk.[6][7][11]
Use these conditions to interpret findings and guide remediation testing. Next, use the SBOM to identify affected components and validate the fix.
Manage Vulnerabilities From Discovery to Fix Validation
Identify Affected Components With the SBOM
Use the versioned SBOM to map vulnerable components to released builds, supported configurations, and deployment locations. Record each component’s name, supplier, version, dependency relationships, hashes where appropriate, execution status, support status, and end-of-support date.
| Workflow stage | Action | Evidence |
|---|---|---|
| Inventory | Map components to builds and configurations | Component-to-build records |
| Vulnerability matching | Match advisories, CVEs, CISA Known Exploited Vulnerabilities, and internal findings | Affected-version analysis and false-positive rationale |
| Reachability and applicability analysis | Check execution, exposure, privileges, and clinical attack paths | Attack-path and applicability assessment |
| Remediation | Upgrade, remove, reconfigure, or apply a compensating control | Change record, due date, and updated SBOM |
| Retesting | Repeat discovery tests; check adjacent functions and supported configurations | Retest report, regression results, and residual-risk decision |
An SBOM shows composition - not exploitability or whether a fix works. Check inventory matches against test evidence and device-specific analysis. Track every finding by affected device version, build, configuration, owner, deadline, and escalation threshold.
Product security coordinates intake. Engineering owns remediation. Designated reviewers approve validation and release. Once you’ve mapped the affected builds, triage them by exploitability and patient impact.
Prioritize Findings by Patient and Security Risk
Run scans on representative builds in isolated environments, using authentication when the test requires it. Resolve discrepancies by checking SBOMs, binaries, configurations, and supplier information.
CVSS is one input, not the whole decision. Assess applicability, reachability, active exploitation, access requirements, and existing controls. Also weigh impacts on essential performance, PHI protection, data integrity, and care availability.
| Disposition | Reason | Action | Evidence |
|---|---|---|---|
| Remediate | An exploitable weakness creates unacceptable safety, security, or availability risk; technical severity alone does not determine disposition | Develop and validate a fix; address critical uncontrolled risks outside routine updates | Approved timeline, test results, and release authorization; finding stays open until validated |
| Mitigate | An exposed weakness has effective temporary controls, but risk remains high enough to require a fix | Restrict access, isolate, or disable affected functionality when safe | Control tests, expiration date, owner, and reassessment schedule |
| Monitor | Applicability or exploitability is uncertain; near-term impact is low or uncertain | Investigate and track new intelligence | Sources reviewed, rationale, and next review date |
| Accept with justification | Residual risk meets approved criteria and an acceptable benefit-risk balance | Obtain time-limited approval and escalation conditions | Signed analysis, alternatives considered, and expiration review |
| Retire or replace | No adequate fix or control that can be maintained; risk remains unacceptable | Plan removal, replacement, or end-of-support action | Affected versions, customer notices, and disposition and completion records |
Internal acceptance does not waive statutory, reporting, monitoring, or patching duties.[12][2][13]
Use the disposition to set the fix scope, retest depth, and release approval requirements.
Validate Fixes and Test for Regression
After triage, rerun the original test and check adjacent functions before release. Identify every affected build and configuration before approving the change. Use comparable test conditions to verify that the vulnerable condition has been removed or controlled.
Check for regression in security controls, clinical functions, interoperability, performance, update and rollback behavior, and temporary controls. A clean scan alone does not prove that a fix works across supported customer configurations.[12][14]
Keep failed fixes open. Record their results, technical reasons, revised plans, and deadlines. Document deferred work and residual risk, then update the SBOM, threat model, and risk file. Obtain the appropriate security, engineering, clinical, quality, and regulatory release approvals.
Tell customers which versions are affected, what actions they need to take, and any prerequisites, recovery steps, and validation limits. Track deployment separately from fix validation so a released patch does not hide unresolved exposure in installed devices.
Carry validated results into the risk file, submission evidence, and postmarket tracking.
Prepare Risk Files and FDA Submission Evidence
Once fixes are validated, package the evidence so the risk file and FDA submission tell the same traceable story. Show how each test result supports a residual-risk decision in both sets of records.
Connect Test Results to Risk Decisions
Include or reference the threat model, cybersecurity risk assessment, SBOM, component-support information, vulnerability assessments, and unresolved anomaly assessments as traceability inputs.[15] Build a chain from risk → requirement → control → test → result → remediation → residual-risk decision → postmarket action. Record document numbers and revision levels so each conclusion links to controlled source records and verified test evidence.[16]
Use those links to organize the required artifacts.
| Artifact | FDA use |
|---|---|
| Threat model and security risk assessment | Link tested threat scenarios and results to risk conclusions. |
| Security requirements and control specifications | Connect measurable requirements and controls to verification evidence. |
| SBOM | Reconcile the submitted build with the tested build. |
| Vulnerability-scan report | Support finding dispositions with validated results and documented limitations. |
| Penetration-test report | Link exploit findings to remediation evidence and residual-risk decisions. |
| Remediation record | Document the validated fix and approved release decision. |
| Regression-test results | Support the conclusion that changes introduced no unacceptable safety or security effects. |
| Residual-risk approval | Record acceptance rationale, qualified approval, and required labeling or postmarket actions. |
Each test record should identify the device build, hardware, network conditions, tools, methods, acceptance criteria, results, deviations, retest outcome, and approval status. Keep failed tests, rejected fixes, and retest attempts - not just passing results.
Next, check that the submission matches the tested configuration.
Check FDA Submission Readiness
Quality records support development; submission evidence supports the FDA filing. Procedures, training records, design reviews, executed tests, and change-control files support lifecycle governance. The submission includes evidence required or recommended for the device and pathway - not every internal record.
For applicable cyber devices, Section 524B requires a postmarket cybersecurity plan, processes and procedures providing reasonable assurance that the device and related systems are cybersecure, postmarket updates and patches, and an SBOM in the submission.[3] FDA also recommends cybersecurity management plans, risk-management outputs, architecture information, cybersecurity testing documentation, and vulnerability and anomaly assessments.[4][7]
Use this final readiness check:
- Scope, architecture, methods, and coverage: Define device-system boundaries, components, interfaces, trust boundaries, data flows, and intended-use configurations. Document test methods, acceptance criteria, environments, tester qualifications, tools and versions, and dates. Show coverage of requirements, threats, attack surfaces, authentication states, update paths, and failure modes.
- Build consistency: Reconcile the SBOM and test evidence with the exact submitted configuration or a clearly justified representative configuration.
- Findings and remediation: Include severity, exploitability, affected assets, clinical or operational impact, disposition, and rationale. Support resolved findings with fix-validation and regression evidence. For unresolved issues, document compensating controls, residual-risk approval, appropriate labeling or restrictions, and postmarket actions.
- Traceability and limitations: Confirm the artifact links above. Explain exclusions, unavailable source code, untested integrations, environmental assumptions, false positives, and coverage limitations.
Maintain Postmarket Records and Coordinate HDO Review
After submission, maintain the same traceability in postmarket monitoring. Keep controlled records of monitoring, triage, impact assessment, remediation, validation, deployment, and closure. Assign owners and justified response timelines. Link each vulnerability to affected versions, risk decisions, validated fixes, deployment status, and residual-risk approval.
Reassess the threat model and risk file when new vulnerabilities, exploit techniques, components, clinical uses, integrations, or deployment conditions materially change the risk.
Coordinate manufacturer and HDO review of findings, affected versions, mitigation instructions, emergency changes, and patch-validation evidence. Track deployment status. Manufacturers should provide accurate device and SBOM information, security assumptions, vulnerability notifications, patch documentation, testing limitations, and deployment guidance.
Conclusion: Keep Testing and Risk Decisions Accountable
Treat accountability as a release gate, not a documentation task. Once validation and submission evidence are set, base release approval on traceable evidence: device-specific test results, a build-matched SBOM, and validated fixes.
Make ownership clear. Label each activity as a Section 524B duty, an FDA recommendation, or an HDO governance task. Assign named owners for test evidence, SBOM maintenance, clinical risk review, remediation, risk acceptance, submission evidence, and postmarket response. In the responsibility matrix, list each approver, the required evidence, the escalation route, and the response time.
Track the time from discovery to closure across triage, mitigation, validation, communication, and patching. Use these metrics to flag stalled decisions - not to judge clinical risk. Every unresolved finding needs a named owner, not just an open ticket.
FAQs
How do I know if Section 524B applies to my device?
Under Section 524B of the FD&C Act, your product is a cyber device if it meets all three conditions: it includes software validated, installed, or authorized by the sponsor; it has direct or indirect internet connectivity; and it contains technology that could be vulnerable to cybersecurity threats [1][2].
Connectivity includes wired and wireless networks, cloud links, companion apps, and hospital networks [2]. If your device qualifies, its premarket submission must include complete cybersecurity documentation to avoid a Refuse-to-Accept (RTA) decision [1][2].
When does a device change require new cybersecurity testing?
New cybersecurity testing is required when a supplement or software update could affect device cybersecurity - for example, by adding software or a new connectivity feature. FDA expects the cybersecurity impact to be addressed and validated through test evidence linked to the updated threat model and controls [1].
After fixes or remediation, repeat testing to confirm that the vulnerability is resolved and no new vulnerabilities have been introduced. Document the retest evidence [2].
What evidence justifies releasing a device with unresolved vulnerabilities?
Manufacturers must document why they accept residual risk and how they plan to monitor it over time. Supporting evidence must identify compensating controls, such as network segmentation, input filtering, or additional monitoring. These controls must reduce risk to an acceptable level without compromising clinical performance or patient safety.
Each decision must link back to the risk assessment and threat model, showing that the remaining risk is acceptable for the device’s intended use.
