Cybersecurity Penetration Testing for FDA “Cyber Devices”: What Section 524B and the 2026 Final Guidance Demand

FDA cybersecurity reviews used to be light touch. That ended when Section 524B was added to the FD&C Act through the 2023 Consolidated Appropriations Act. The June 2025 final cybersecurity guidance significantly raised the bar and was superseded in February 2026 by an updated final guidance aligned with the new Quality Management System Regulation (QMSR).

FDA’s cybersecurity expectations extend beyond penetration testing and are intended to be implemented throughout the Secure Product Development Framework (SPDF), from design inputs through post-market maintenance.

By 2026, if your device meets the definition of a “cyber device” and you do not include penetration testing in your 510(k), you can expect an Additional Information request within weeks.

In addition to defining cyber devices, Section 524B requires manufacturers to establish processes for vulnerability monitoring, cybersecurity risk management, software transparency through SBOMs, and post market cybersecurity maintenance.

Here is what manufacturers need to submit in 2026.

Is your device a “cyber device”?

Under Section 524B, a cyber device is any medical device that: (1) includes software validated, installed, or authorized by the sponsor as a device or in a device; (2) has the ability to connect to the internet; and (3) contains any such technological characteristics validated, installed, or authorized by the sponsor that could be vulnerable to cybersecurity threats. Cloud-connected Software as a Medical Device (SaMD), mobile medical applications, and hybrid cloud architectures are commonly considered cyber devices under the FDA’s framework. Almost every connected device, wearable, infusion pump, imaging system and SaMD now qualifies. If you are unsure, contact the FDA or treat your device as in scope and document your rationale.

Manufacturers should document a formal Cyber Device assessment demonstrating whether the product meets the criteria defined in Section 524B. Devices with no software, networking capability or exploitable technological characteristics may fall outside the scope of Section 524B requirements.

Cybersecurity Expectations for FDA 510(k) Submissions

• Software Bill of Materials (SBOM) in a machine readable format, such as SPDX or CycloneDX, listing every commercial, open source and off the shelf component.
• The SBOM should include commercial software, open source software, off-the-shelf components and Software of Unknown Provenance (SOUP) used within the device.
• Manufacturers should continuously monitor SBOM components for newly disclosed vulnerabilities throughout the product lifecycle.
• Third-party software suppliers should be evaluated and controlled through documented supplier management processes.
• Threat model that maps assets, data flows, trust boundaries and adversary scenarios, using a structured method such as STRIDE.
• While STRIDE is commonly used, manufacturers may apply alternative threat modelling methodologies provided the approach is systematic and appropriately documented.
• Penetration test report from an independent tester, covering network, application and physical interfaces, with reproducible methods.
• Vulnerability assessment with CVSS scoring and a clear closure status for every issue at submission time.
• Risk prioritization should consider exploitability, attack complexity, patient impact and operational context in addition to CVSS scores.
• Testing should evaluate both authenticated and unauthenticated attack scenarios to simulate realistic adversary behaviour.
• All identified vulnerabilities should be tracked through remediation, verification and formal closure activities.
• Co-ordinated vulnerability disclosure process so external researchers can report findings post market.
• Where vulnerabilities cannot be fully mitigated, residual cybersecurity risks should be documented and justified.
• Manufacturers should establish a documented process for receiving, assessing, investigating and responding to externally reported vulnerabilities.
• A Product Security Incident Response Team (PSIRT) can provide governance for coordinated vulnerability management activities.
• Post market cybersecurity surveillance plan, including monitoring, patch cadence and customer communication.
• Manufacturers should monitor vulnerability databases, threat intelligence feeds, vendor advisories and relevant cybersecurity alerts.
• The post market cybersecurity program should include documented incident detection, investigation, escalation and response procedures.
• Significant cybersecurity findings should be evaluated through the organization’s CAPA process where appropriate.

What “good” penetration testing looks like

FDA ready pen test is more than running a scanner. The lab should follow a documented methodology, such as NIST SP 800-115 and produce a report that links every test case to a threat in your model. Testing should evaluate both authenticated and unauthenticated attack scenarios to simulate realistic adversary behaviour. Cloud-hosted services and supporting infrastructure should be evaluated for configuration weaknesses, access control issues and exposed attack surfaces.

Where mobile applications are used, Android and iOS components should be included within the assessment scope. API assessments should evaluate authentication, authorization, input validation, session management and data exposure risks.

Wireless communication channels such as Bluetooth, BLE, Wi-Fi, NFC and Zigbee should be assessed where applicable.

Findings should be triaged using CVSS, then mapped to either a fix, a compensating control or an accepted risk with a rationale. Software update mechanisms should be tested to verify integrity, authenticity and protection against unauthorized modification. Re-test evidence is critical: if a finding was high severity and was fixed, show the proof not just a sentence.

Common findings for the FDA flags

• Hardcoded credentials in firmware or backup utilities.
• Unencrypted Bluetooth Low Energy or Wi-Fi pairing flows.
• Outdated TLS, weak cipher suites or expired certificates.
• Missing input validation on cloud APIs.
• Default debug ports left open in production firmware.
• No tamper detection on USB or serial ports used for service.
• Insecure software update mechanisms.
• Missing code-signing validation.
• Weak authorization controls.
• Excessive privilege assignments.
• Misconfigured cloud services.
• Lack of security relevant audit logging.

How testing connects to your QMS?

Effective February 2, 2026, the FDA’s Quality Management System Regulation (QMSR) replaced the former Quality System Regulation (QSR), incorporating ISO 13485:2016 by reference into 21 CFR Part 820. The February 3, 2026 cybersecurity guidance update aligns all quality system references accordingly. Cybersecurity activities must now map explicitly to ISO 13485 clauses, they are not optional add-ons.

The threat model should be referenced from your risk management file, the SBOM should be a controlled document and the pen test report should be part of design verification evidence.

Cybersecurity threats should be evaluated as part of the overall risk management process, with controls verified and residual risks documented in accordance with ISO 14971. Cybersecurity requirements, threat mitigations, verification activities, and vulnerability management processes should be integrated into the software lifecycle activities defined by IEC 62304. A cybersecurity traceability matrix can demonstrate linkage between threats, requirements, controls, testing activities and residual risk.

When the FDA inspects you, they will ask to see this traceability.

Build cybersecurity testing in the early

The cheapest pen test is the one you run on an early prototype. Late stage findings often mean schedule slips, re-designs and re-submission costs. Independent pre-submission testing surfaces issues before the FDA ever sees the device and gives your team time to fix them properly, an approach fully consistent with the SPDF (Secure Product Development Framework) that the FDA’s guidance recommends.

Adopting a shift-left security strategy reduces remediation costs, minimizes redesign efforts, and accelerates regulatory submissions.” Static Application Security Testing (SAST), Software Composition Analysis (SCA) and architecture reviews can identify vulnerabilities earlier in development.

Need a cybersecurity test partner that understands FDA?

NexorTest provides medical device penetration testing, SBOM support and threat modelling aligned with Section 524B and the February 2026 guidance.

In addition to penetration testing, manufacturers often require cybersecurity risk management planning, threat modelling, attack surface analysis, SBOM preparation, FDA cybersecurity documentation support, and post-market cybersecurity monitoring. Collectively, these activities provide evidence supporting compliance with Section 524B requirements while helping demonstrate reasonable assurance of cybersecurity to FDA reviewers.

Visit NexorTest Technologies or our Cybersecurity and Pen Test service page to book a consultation.