Penetration testing belongs in the evidence
Penetration testing supports FDA evidence, but does not replace lifecycle security work.
A penetration test validates security controls. It is not a standalone compliance checkbox, and it cannot replace the engineering and risk management work that surrounds it.
Beyond the test report
Threat models, scanning, risk documentation, and lifecycle plans complement penetration testing evidence.
A test report is only part of the evidence
Penetration testing is a point-in-time check of attack paths and controls. FDA cybersecurity evidence also needs a threat model, security requirements, vulnerability scanning and SBOM analysis, verification results, risk documentation, and plans for updates and vulnerability handling.
Test the real device
Representative hardware, software, interfaces, and connectivity make findings relevant to the final product.
The test must represent the real device
The unit under test must represent the final product, including its hardware, software, interfaces, and connectivity. Document the environment, proximity to the device, equipment, tools, and conditions that produced each finding. Scope exclusions matter as much as the interfaces tested.
Separate safety from severity
CVSS describes technical severity; qualified safety and clinical teams assess patient safety risk.
Technical severity is not patient safety risk
Testers identify what an attacker can access, manipulate, or disrupt and whether those actions can be detected. CVSS describes technical severity, not patient harm. Qualified safety risk management professionals and clinical teams assess safety and effectiveness through the device's risk management process.
Document each finding's disposition
Link findings to risks, controls, and evidence, then document mitigation or residual risk.
Findings need a documented disposition
A list of vulnerabilities is not the end of the work. Link findings to identified risks, security requirements, controls, and test evidence. Address each finding through mitigation or a documented residual-risk decision, and retain evidence that supports verification.
How Medcrypt supports your team
Medcrypt supports risk management and documentation around testing performed by qualified independent testers.
Our role is the surrounding cybersecurity and regulatory work. Independent qualified testers execute the penetration test; your team retains responsibility for the device's safety risk decisions.
Define the risk context
Medcrypt helps refine threat models and risk assessments that inform independent test scope.
See threat modeling supportBuild the risk context for the test
Our experts help develop or refine your threat model and cybersecurity risk assessment. Use that architecture and risk context to define test objectives, key assets, interfaces, and controls with the independent testing firm. The scope should follow the device, not a generic scan.
Plan lifecycle testing
Medcrypt helps integrate SBOM generation, vulnerability scanning, and testing considerations throughout device development.
Place testing in the development lifecycle
Medcrypt helps integrate SBOM generation, vulnerability scanning, and security testing considerations into development. Code review, static and dynamic analysis, interface testing, and SBOM analysis address different weaknesses. The final premarket penetration test validates controls after earlier testing findings have been addressed.
Connect evidence to risk
Medcrypt supports risk documentation that connects independent test results, controls, remediation, and residual risks.
See cybersecurity consulting servicesConnect test evidence to risk documentation
Medcrypt supports cybersecurity risk management and submission readiness. The testing firm's report should document methods, scope, exclusions, test dates, tester qualifications, and evidence of exploitation. Connect those results to requirements, controls, remediation, and residual-risk decisions in your submission documentation.
Maintain postmarket evidence
Medcrypt helps establish monitoring and patch strategies; major device changes can warrant retesting.
Maintain the evidence after release
Our services help establish vulnerability monitoring and patch strategies. Penetration testing does not replace postmarket surveillance, disclosure, or safe update processes. Major changes to architecture, connectivity, cryptography, or the update system can warrant repeat testing with independent testers.
Medcrypt's company-wide track record
These figures describe Medcrypt's broader medical-device cybersecurity work, not penetration-testing engagements or testing-specific outcomes.
Questions about penetration testing
No. A penetration test contributes objective evidence, but it does not replace threat modeling, security requirements, vulnerability scanning, SBOM analysis, or other security testing. The submission also needs traceable risk documentation, control rationale, remediation and residual-risk decisions, and postmarket vulnerability and update plans. A clean test report is not a certification or an FDA approval guarantee.
Qualified independent testers simulate attacks and document the technical findings. Medcrypt's support described on this page covers threat modeling, cybersecurity risk management, security testing considerations, and submission readiness. It does not describe in-house penetration-test execution. Agree the actual test scope and execution responsibilities with the testing firm, and document its methods and tester qualifications.
The unit under test should accurately represent the final product intended for market deployment. Its hardware, software, interfaces, connectivity, and intended operating environment inform the scope. Record the conditions of testing, proximity to the device, tools, equipment, and any exclusions. Give testers the threat model, risk assessment, requirements, and design documentation so they can validate relevant controls and report reproducible evidence.
Document each finding as a risk or map it to an existing risk, then mitigate it or record its residual-risk disposition. Preserve technical details and exploitation evidence so the weakness and the control response can be verified. CVSS scores technical severity; it does not assess potential harm to patients or operators. Qualified safety risk management professionals and clinical teams assess safety and effectiveness within the device's risk management process.