CyberMed Checklist
Medical Device Penetration Testing Prep Checklist
Use this before scoping a penetration test for a connected medical device. The goal is simple: give testers the context they need, protect the test environment, and make the final report useful for engineering, risk management, and FDA-facing documentation.
1. Define the scope
Start with the product context. A good scope keeps the test focused and prevents late confusion about what was actually examined.
- □List each product component in scope: device software, firmware, mobile app, web app, cloud service, API, admin portal, update path, and local interface.
- □Mark what is out of scope and why. Examples: production hospital environments, destructive testing, third-party systems, or features not yet released.
- □Map each in-scope component to the intended user, clinical workflow, data handled, and safety-relevant function.
- □Identify any supporting systems that could affect device security, such as fleet management, logging, remote support, or deployment tooling.
- □Confirm whether the test should cover unauthenticated, patient, clinician, technician, hospital IT, admin, and integration roles.
2. Gather architecture and risk context
Testers should understand how the system works before they start probing. Security findings are more useful when they tie back to architecture and risk.
- □Current architecture diagram with trust boundaries, network zones, protocols, data stores, and external integrations.
- □Data-flow notes for PHI, device telemetry, commands, software updates, credentials, logs, and audit records.
- □Authentication and authorization model, including role definitions, token/session behavior, password rules, and privilege changes.
- □Known security controls: encryption, secure boot, firmware signing, SBOM process, logging, rate limits, alerting, and access review.
- □Threat model, cybersecurity risk assessment, or risk-control traceability if it already exists. Draft material is still useful.
3. Prepare the test environment
A clean environment reduces false starts, protects production users, and gives the team a safer place to reproduce findings.
- □Test environment URL, device build, firmware version, app version, API base URLs, and cloud tenant details.
- □Test accounts for each role, plus clear permission boundaries for what testers may and may not change.
- □Seed data that reflects realistic workflows without exposing real patient data.
- □Rules for destructive testing, denial-of-service attempts, fuzzing, account lockout, update rollback, and alert generation.
- □Named technical contacts for environment resets, account unlocks, device reflashing, and urgent safety questions.
4. Decide what evidence needs to come back
Penetration testing should produce more than a list of bugs. Decide up front how findings should support remediation, review, and submission work.
- □Define how findings should map to severity, exploit path, affected component, evidence, reproduction steps, and recommended fix.
- □Agree how the report should connect findings to cybersecurity risks, controls, verification activities, and remediation records.
- □Decide whether leadership, engineering, QA/RA, and submission teams each need a different summary view.
- □Set expectations for retest timing, retest evidence, residual risk notes, and what happens when a finding is accepted rather than fixed.
- □Save final artifacts in the design history file or cybersecurity evidence package with version, date, and scope notes.
5. Ask these before kickoff
Use these questions with engineering, QA/RA, product, and security before the test starts.
- □What product version, configuration, and environment should represent the system under test?
- □Which workflows could affect safety, therapy delivery, alarms, clinical decisions, data integrity, or device availability?
- □What findings would block a submission, customer deployment, hospital review, or investor diligence step?
- □Who owns remediation decisions after the report lands?
- □What evidence will QA/RA need from the test, beyond a vulnerability list?