A submission can begin to unravel with one simple reviewer question: what exactly did you test? Vulnerability tables and severity scores may appear complete, yet they can leave the product scope, attack paths, and remediation trail unclear. FDA guidance expects cybersecurity evidence to connect testing with identified risks, controls, and resulting findings. Submission duties under FDA Section 524B began on March 29, 2023.
FDA initially allowed a transition period under its Refuse to Accept policy, which expired on October 1, 2023. The current premarket cybersecurity guidance, issued on February 3, 2026, explains how manufacturers should connect threat models, risk assessments, software components, controls, and testing records.
For manufacturers, the harder task begins after the assessment. Your evidence must make every testing decision easy for reviewers to trace, understand, and evaluate.
Key Takeaways
- Penetration testing should be planned as part of the submission evidence process, not treated as a separate technical exercise completed at the end.
- The assessment scope should follow trust boundaries and attack paths across the entire medical device system, including supporting applications and infrastructure where relevant.
- Every report must identify the exact hardware, firmware and software build tested. Evidence from a different product version can weaken traceability during review.
- Technical severity alone does not define medical device risk. Findings must also be assessed for their effect on clinical workflows, essential performance and patient safety.
Does FDA Section 524B Require Penetration Testing?
No. FDA Section 524B does not explicitly require every cyber device to undergo penetration testing. It requires sponsors of covered premarket submissions to demonstrate that the device meets the applicable statutory cybersecurity obligations.
FDA’s February 2026 guidance recommends penetration testing as part of the cybersecurity testing evidence submitted for review. Passing one assessment alone does not establish FDA Section 524B compliance.
Which Medical Devices Fall Under FDA Section 524B?
A device falls under FDA Section 524B when it:
- Contains sponsor-authorised software or firmware
- Can connect to the internet
- Has technological features that may be vulnerable to cybersecurity threats
The requirements apply to covered 510(k), PMA, De Novo, Product Development Protocol, and Humanitarian Device Exemption submissions.
Internet capability may include Bluetooth, cellular, Ethernet, cloud services, update servers, or temporary service connections. A USB or serial port does not automatically make a product a cyber device. You must assess whether it creates a path to an internet-connected system.
Related applications, APIs, portals, telemetry platforms, and update systems may also form part of the cybersecurity scope.
What Must Section 524B Penetration Testing Cover?
Testing should follow the device architecture, identified threats, and trust boundaries across the complete medical device system. The final scope depends on the attack surface and potential safety impact.
Embedded Device, Firmware and Hardware Interfaces
Where relevant, testing should examine:
- Secure boot, firmware signatures, anti-rollback controls, and update recovery
- Firmware extraction, modification, reinstallation, and unauthorised code execution
- JTAG, UART, USB, Ethernet, serial connections, and removable media
- Hardcoded credentials, stored secrets, authentication, and privilege controls
- Local data protection, cryptographic key storage, and data integrity
- Diagnostic modes, maintenance functions, tamper protections, and security failure behaviour
The scope must remain risk-based. A software-only device will not require the same firmware and hardware testing as an implantable, diagnostic, or connected therapeutic device.
Wireless and Communication Interfaces
For Connected medical devices, testing should cover Wi Fi, Bluetooth, BLE, cellular, NFC, radio frequency telemetry, and proprietary wireless protocols where present.
The assessment should examine:
- Pairing, bonding, device authentication, encryption, message integrity, and session management
- Replay attacks, impersonation, eavesdropping, and unauthorised commands
- Resilience to radio interference and denial of service conditions
Testing should challenge the communication assumptions recorded in the threat model rather than rely only on general wireless scans. FDA recommends assessing whether an attacker could alter, drop, or replay communications across the medical device system.
The report should also explain whether compromise could disrupt therapy delivery, suppress alarms, alter diagnostic results, or affect essential device performance.
Mobile Apps, Web Applications, APIs and Cloud Services
Companion applications and back-end systems belong in the test scope when they can influence device security, safety, or effectiveness. Testing should follow data, commands, and software updates as they move between the device and supporting assets.
Relevant checks may include:
- Authentication, account recovery, roles, permissions, and session expiry
- API access, device registration, ownership transfer, and certificate validation
- Local storage, application tampering, and behaviour on rooted or jailbroken devices
- Tenant isolation, cloud access controls, secrets, and administrative interfaces
- Data confidentiality, integrity, logging, and audit records
Update Infrastructure and Healthcare Deployment Environment
Follow the update from the build and release system through signing, distribution, download, authentication, and field installation. The assessment should confirm that rollback controls work and that an interrupted or failed update leaves the device in a safe, recoverable state.
FDA recommends evaluating the complete update path, including technologies outside the manufacturer’s control. Recreate realistic healthcare conditions during testing, including:
- Segmented and unsegmented networks, firewalls, proxies, and identity providers
- Shared clinical workstations, maintenance laptops, servicing tools, and connected devices
- Network loss, time synchronisation faults, and unavailable logging systems
Destructive checks should take place in an isolated environment that closely represents the intended deployment. Production clinical systems and real patient data should remain outside the test scope unless an exceptional, formally approved arrangement defines strict safeguards.
Why a Vulnerability Scan Is Not Enough for FDA Evidence
Automated scans can uncover known flaws, exposed services, outdated software, and weak configurations. They cannot show whether the device can withstand a realistic attack.
A scan may also miss chained vulnerabilities, abused clinical functions, bypassed update controls, or unsafe behaviour after a security failure. FDA recommends broader evidence, such as:
- Security requirement and interface testing
- Misuse cases and unexpected input checks
- Fuzzing and robustness testing
- Code and software component analysis
- Credential and penetration testing
A penetration test confirms whether selected controls work under attack. It does not replace source review, component analysis, requirement testing, or risk management. The report should also record failed attack attempts and protections that worked correctly.
Our FDA Section 524B Penetration Testing and Documentation Process
Documentation planning begins before the first test case. We confirm the intended submission pathway and the manufacturer’s preliminary cyber device determination.
1. Applicability and Test Readiness Review
We establish the test baseline by recording:
- Device components and hardware revisions
- Software and firmware versions
- Applications, cloud services, interfaces, and deployment environments
We then review the threat model, risk assessment, security requirements, architecture views, SBOM, vulnerability assessment, update design, earlier reports, and known anomalies. The software inventory is also checked against applicable FDA SBOM requirements.
Missing, outdated, or conflicting records are flagged before the scope is approved. Testing should not begin without a usable threat model and clear security requirements, since these documents determine which attack scenarios and controls need examination.
2. Threat-Informed Scope and Rules of Engagement
We set clear limits for the assessment before testing begins. The plan defines what testers may do and which actions remain prohibited. It also covers safety controls, test access, recovery steps, logging, and incident contacts.
Each test is linked to a relevant threat and the control designed to address it. This keeps the work focused on risks that could affect device safety or operation.
3. Manual and Automated Security Testing
We use automated tools for discovery, then manually investigate the attack paths approved in the scope. Testing may examine privilege escalation, authentication bypass, device impersonation, logic abuse, firmware changes, update compromise, and attacks that cross between systems.
The evidence records the tools and versions used, relevant configurations, manual techniques, test environment, dates, duration, and limitations. It also captures successful attacks and meaningful attempts that existing controls stopped. FDA recommends documenting cybersecurity test methods and results clearly enough to support premarket review.
4. Safety Aware Finding Assessment
A technical score never tells the whole story for a medical device. We examine the access an attacker needs, the difficulty of the attack, the privileges involved, and whether user action is required. We also consider detectability and the effect on clinical workflows, essential performance, patient safety, data integrity, confidentiality, and device availability.
CVSS can help rank technical severity, but it cannot determine medical device risk on its own. Each confirmed finding enters the manufacturer’s cybersecurity risk management process, where exploitability, existing controls, residual risk, and possible patient harm are reviewed together.
5. Reporting, Remediation Support and Retesting
We review confirmed findings with the manufacturer’s security, engineering, quality, and regulatory teams. Developers receive clear correction guidance, while a closure log records the response selected for every issue.
Retesting uses the exact corrected build. It shows whether the weakness is fully resolved, partly corrected, or still exploitable. The review also captures reopened findings and new security problems caused by the fix.
6. Submission Documentation Crosswalk
We prepare a crosswalk that identifies:
- The relevant Section 524B clause or FDA guidance section
- The supporting submission document or eSTAR response
- The exact product version and attachment reference
The crosswalk connects applicable test evidence with the manufacturer’s risk records, threat model, architecture files, verification records, unresolved anomalies, and cybersecurity management plan. Evidence related to software component vulnerabilities is also linked to Section 524B(b)(3).
The penetration testing report presents the independent test results. The manufacturer’s assessment records how each finding was evaluated and resolved.
FDA Section 524B Documentation Deliverables
The service combines technical testing with organised documentation that manufacturers can use during internal review and premarket submission preparation. FDA expects cybersecurity information to be clear, consistent, and linked to the device under review.
| Deliverable | What it contains | How it supports the submission |
| Applicability and Scope Memorandum | The submission pathway, device description, preliminary Section 524B determination, system boundaries, related assets, interfaces, intended environment, approved exclusions and tested product versions. | Establishes exactly which product and system configuration the assessment covers. It also records the basis for including or excluding each asset. |
2. Test Readiness Findings
| Deliverable | What it contains | How it supports the submission |
| Test Readiness Findings | Missing threat scenarios, incomplete security requirements, architecture conflicts, SBOM gaps, version mismatches, absent update records, and differences between the test setup and intended production environment. | Gives the manufacturer a clear list of issues to resolve before testing begins, so the assessment uses the correct device build and complete supporting records. |
3. Rules of Engagement and Threat-Informed Test Plan
| Deliverable | What it contains | How it supports the submission |
| Rules of Engagement and Threat-Informed Test Plan | Test boundaries, safety controls, approved methods, attack scenarios, required access, and recovery procedures. | Shows how each test relates to a documented threat and security control. |
4. Original Technical Penetration Test Report
| Deliverable | What it contains | How it supports the submission |
| Original Technical Penetration Test Report | Tester independence, scope, duration, methods, tested versions, findings, evidence, limitations, and controls that resisted attack. | Gives FDA the original assessment results. When a third party conducts the test, FDA recommends submitting its original report. |
5. Manufacturer Finding Disposition Support
| Deliverable | What it contains | How it supports the submission |
| Manufacturer Finding Disposition Support | Device impact, safety implications, risk references, existing controls, planned corrections, accepted risk, deferred action reasons, fielded product impact and correction timelines. | Records how the manufacturer evaluates and responds to every confirmed finding. The manufacturer retains responsibility for final risk decisions and submission statements. |
6. Remediation and Exception Register
| Deliverable | What it contains | How it supports the submission |
| Remediation and Exception Register | Finding owner, correction plan, target date, current status, compensating controls, retest outcome, residual risk, approval authority, submission treatment and postmarket commitment. | Provides one record for tracking open findings, approved exceptions and future corrective work. |
7. Retest Report
| Deliverable | What it contains | How it supports the submission |
| Retest Report | Corrected build details, repeated methods, closure evidence, partial fixes, reopened findings, new weaknesses and remaining limitations. | Confirms the final status of each retested issue and identifies the product version assessed. |
8. FDA Documentation Crosswalk and Submission Index
| Deliverable | What it contains | How it supports the submission |
| FDA Documentation Crosswalk and Submission Index | Evidence locations, original third-party reports, manufacturer dispositions, retest records, unresolved findings, postmarket commitments, and covered hardware and software versions. | Directs reviewers to the relevant evidence and separates independent test results from manufacturer decisions. |
Why Choose Qualysec for FDA Section 524B Penetration Testing and Documentation?
An attack does not always remain inside the medical device. It can move through a wireless connection, companion application, API, cloud platform, or update service. Crest Accredited company Qualysec follows these paths across the agreed system scope, using manual testing and automated techniques to uncover exploitable flaws, logic weaknesses, and connected attack chains.
The engagement continues through remediation. Your team receives reproducible findings, practical correction guidance, consultation support, and retesting of the corrected build. Qualysec also prepares organised technical evidence to support submission work. The manufacturer remains responsible for final risk decisions and regulatory statements.
Share your device architecture, product versions, interfaces, related systems, existing cybersecurity records, and target submission date. Qualysec will review the available information and define the testing prerequisites and scope.
Conclusion
Premarket cybersecurity evidence should tell one consistent story. Identified threats must lead to clear security requirements, tested controls, documented findings, risk decisions, remediation, and verified corrections.
The law defines the cybersecurity duties for covered cyber devices, while FDA guidance explains the evidence manufacturers should prepare for premarket review. Starting early helps your team assess the correct product build, include relevant supporting systems, and resolve documentation gaps before submission.
FAQs
1. Does FDA require an independent third-party penetration test?
No. External testing is not required for every device. FDA expects the report to identify the tester’s expertise and independence from the development team. When an outside provider conducts the assessment, manufacturers should submit the original report.
2. What must be included in an FDA medical device penetration test report?
The report should identify the tester, scope, duration, methods, results, and observations. It should also specify the tested product version and provide enough evidence to understand each finding.
3. Is automated vulnerability scanning enough for a Section 524B submission?
No. Scanning finds known flaws and weak configurations, but it does not confirm realistic exploitability. Manual testing and other verification activities are needed to examine attack paths, misuse cases and control effectiveness.
4. Must mobile apps, APIs and cloud systems be included in the test?
Yes, when their compromise could affect device safety, effectiveness or security. The scope should include supporting systems that exchange sensitive data, commands, credentials or software with the device.
5. Does a USB or serial port make a medical device a cyber device?
No. The connector must be assessed for its ability to create an internet path, including through a service computer or network. FDA considers even brief service connectivity relevant when determining internet capability.
6. When should penetration testing take place before an FDA submission?
Testing should leave enough time for corrections, retesting and document updates. The final assessment should examine a stable build that accurately represents the product submitted to FDA.
7. What happens when vulnerabilities remain unresolved before submission?
The manufacturer should document the remaining risk, compensating controls and reason for deferral. Records should also state the correction timeline, treatment of fielded devices and any continuing postmarket actions.
