Medical Device Security Testing: DAST Guide

I use DAST to check how running medical device software responds - not to prove the whole device is secure. Before sending test requests, I define the approved scope, use a nonclinical setup, and set clear stop conditions.

In this guide, I walk you through 6 steps:

1. Map interfaces, user roles, and access rules.
2. Prepare test accounts, workflows, monitoring, and recovery.
3. Test web, API, mobile, firmware-linked, and network paths within approved limits.
4. Verify findings, protect test records, and rate technical risk separately from patient harm.
5. Assign fixes and supplier duties, then retest.
6. Document remaining risk and check readiness before closure.

My rule: <u>patient safety comes before scan coverage</u>. I pair DAST with code, dependency, protocol, and penetration tests because a clean scan is not regulatory approval - or proof that every attack path was tested.

DAST: Dynamic Application Security Testing for Real-World Protection | Uplatz

sbb-itb-535baee

Prepare a Safe Medical Device Test Environment

Use the interface and role map to build a controlled test environment that matches relevant production flows, trust boundaries, and clinical workflows. Follow applicable medical-device security standards, including AAMI TIR 57 and IEC 81001-5-1, and test only authorized paths ^[3].

Configure Devices, Accounts, and Workflows

Recreate the device version being tested, its configuration baseline, and the services that support the clinician portal, API, mobile link, cloud back end, and network-connected device functions. Create accounts for each role, add representative test data, and document how to reset the setup.

Prepare workflow states for login, enrollment, patient association, configuration, export, and deprovisioning. Record the exact state under test so others can repeat it. Re-test after software or dependency changes, and score findings based on the deployment context using Censinet RiskOps™ ^[3]. Once the setup can be reproduced, define monitoring and stop thresholds before the first request.

Set Monitoring and Stop Conditions

Monitor logs, alerts, traffic, and device state during each run. Set stop conditions before testing:

• Unexpected patient-data exposure.
• Loss of device function or service instability.
• Repeated authentication failures.
• Any change that could affect clinical use.

Record the exact inputs, outputs, and thresholds so each run can be reproduced.

Record Test Inputs and Acceptance Criteria

Keep test cases, inputs, expected outputs, and pass/fail criteria under version control in the quality management system (QMS). For each case, define the expected response, failure threshold, and rollback condition.

Link each test case to the security control and applicable regulatory requirement it verifies. Use IEEE 2621-style checklists so teams can repeat both test execution and evidence collection ^[3].

Test Medical Device Software Interfaces

Test each authorized interface against the workflows in the threat model. Run tests with and without authentication, and compare access across clinician, technician, administrator, supplier, and read-only roles. Use automation to cover more paths and repeat tests, then manually verify sensitive-data exposure, authorization failures, and device-state changes. Web scans alone do not establish device security. Test non-HTTP interfaces separately.

Use this table to match each interface with the test depth and evidence it needs.

Start with web portals and APIs. Then move to mobile, firmware-linked, and network interfaces.

Test Web Portals and APIs

Base coverage on the OWASP Web Security Testing Guide and OWASP API Security Top 10. Check login and account recovery, session expiration, refresh-token rotation, replay, and logout. Test object-, function-, and property-level authorization separately from UI restrictions, including nested patient and device identifiers.

Cover injection, XSS, CSRF, uploads, TLS, CORS, security headers, and information leakage. Use schemas, mobile traffic, and JavaScript bundles to find undocumented and deprecated routes.

Check gateway-service trust, callbacks, webhooks, server-side request forgery, and unsafe handling of external API responses. Test resource limits only within approved bounds. Inspect outputs and logs for PHI leakage, and verify audit events for sensitive actions. Record inaccessible routes and workflows as coverage gaps.

Next, treat mobile clients as separate trust boundaries.

Test Mobile Connections to Clouds and Devices

Observe approved live API calls, then test server-side controls independently of the app. Verify enrollment, device binding, synchronization, account switching, token storage, refresh, and revocation. Include queued actions submitted after access has been revoked.

Assess certificate validation. Inspect local storage, deep links, and exported components for exposed data or actions performed without permission. Bluetooth, Wi-Fi, and NFC tests require separate approval and nonclinical equipment.

Then test device-linked and network-facing paths that the app cannot fully expose.

Test Firmware-Linked and Network Interfaces

Test management, maintenance, diagnostic, boot, recovery, communication, and companion app interfaces. Run network-service tests on an isolated network with representative gateways. Include malformed-message handling and protocol robustness.

A successful update API response does not prove that the device verifies firmware signatures or trusted sources. Assess integrity checks, source verification, rollback and downgrade protection, authorized rollback, and interrupted-update recovery only in an approved safety-controlled environment.

Never interrupt updates or fuzz safety-critical protocols on patient-connected devices. Record device-state and recovery evidence alongside network results.

Collect Evidence and Rank Healthcare Risks

Treat scanner alerts as leads, not confirmed findings. Validate the behavior and rule out false positives first. Then link each confirmed finding to its asset, threat, control, and evidence. Note any potential patient harm, PHI exposure, or workflow disruption. Use a three-way traceability matrix to connect each test case to the control it validates and the requirement it satisfies. ^[3]

Record confirmed findings in a format another tester can reproduce.

Document Findings for Reproduction

Give each confirmed finding its own identifier and record the exact state under test: endpoint, affected asset, software and firmware versions, account role, workflow state, prerequisites, reproduction steps, and timestamps with time zones. Include tool settings only when they affect reproduction.

Attach sanitized requests, responses, screenshots, logs, and traces. Keep observed behavior separate from potential harm. Record technical severity, exploitability, confidence, false-positive checks, proposed fixes, compensating controls, and retest evidence. Link later verification to the original finding rather than overwriting its history.

Protect Evidence and Sensitive Data

Store technical evidence in an access-controlled repository. Keep sensitive data out of general reports, and put reproduction details in restricted attachments, separate from executive summaries.

If testing unexpectedly collects sensitive data, restrict access. Follow approved incident and data-handling procedures before copying, deleting, or distributing it.

Rate Technical Severity and Clinical Impact

Use a healthcare risk matrix that rates cybersecurity risk and clinical impact separately. Record the CVSS v4.0 Base, Threat, and Environmental scores, along with the vector and deployment assumptions. For each deployment context, document network architecture, physical access controls, and user groups. Hospital and home-care deployments may need different assessments. ^[3]

Have security, clinical engineering, and clinical stakeholders assess effects on therapy, measurement accuracy, alarms, patient data exposure, downtime, and care workflows. Weigh safeguards, detectability, and whether mitigation can be applied safely. Give issues affecting therapy, measurement, alarms, PHI, or downtime priority over purely administrative flaws. Document why each rank fits both the technical exposure and the patient-care impact. ^[3]

Rank findings by patient impact so remediation starts with the highest-risk issues. Use those rankings to guide remediation, retesting, and supplier follow-up.

Remediate Findings and Coordinate Suppliers

Use the patient-impact ranking from testing to set the fix order and retest priority. Put each validated finding into change control with a named owner, a deadline based on clinical and technical risk, and a clinical safety review.

Keep remediation evidence linked to the affected product version in the manufacturer QMS. Connect validated findings and changes to the affected requirements, controls, threat models, software, firmware, configurations, and deployments.

Verify Fixes and Approve Residual Risk

Before deployment, check patch compatibility, manufacturer authorization, workflow impact, and update constraints. Retest the original attack path, then related endpoints across the device, app, and cloud backend. Run regression tests and check safety-critical performance. Treat every software, dependency, or interface change as a new verification event.

Blocking an attack path does not close the finding. Record the remaining exposure, tested control effectiveness, approval authority, review dates, and closure criteria.

If a patch is delayed, document why continued operation is justified. Verify that temporary isolation or access restrictions work without disrupting care, and confirm that monitoring can detect the attack pattern. Keep temporary risk acceptance separate from a verified permanent fix.

Define Supplier Duties and Escalation Paths

When a fix crosses a vendor or cloud boundary, assign the external owner before approving the internal change. Before testing begins, agree on the approved test scope, contacts, documentation, threat-model summaries, prior evidence, known limitations, patch timelines, and retest duties. Outsourcing the work still requires a named risk owner.

Use Findings in Healthcare Risk Management

Use unresolved findings to guide third-party assessments, enterprise risk ownership, and deployment decisions. Keep those issues linked to medical device security risks and PHI exposure. Retain residual-risk decisions, and carry unresolved items into continued monitoring and postmarket review.

Conclusion: Medical Device DAST Readiness Checklist

A completed scan is not approval. Medical device DAST works alongside threat modeling, static analysis, software composition analysis, and clinical safety review.^[6]

Use this checklist before testing and again before closure, after testing, remediation, and risk review. Mark each item ready/not ready and link the supporting evidence.

• [ ] Scope: Written authorization specifies device models, software versions, interfaces, accounts, environments, permitted source IPs, test windows, and exclusions.
• [ ] Environment: A representative nonproduction environment closely matches production, with representative versions, synthetic data, monitoring, backups, and recovery.
• [ ] Coverage: All materially different clinical, administrative, maintenance, remote-support, integration, and recovery paths have defined inputs and acceptance criteria.
• [ ] Stop conditions and exclusions: Unsafe behavior, alarm failures, PHI exposure, clinical disruption, or out-of-scope access stop testing. Untested areas have documented reasons and assessments.
• [ ] Findings: Reproducible evidence identifies the affected version, interface, role, and workflow. Technical severity and healthcare impact are rated separately.
• [ ] Owners: Each issue has an internal owner, supplier duties where needed, a target date, and an escalation path.
• [ ] Residual risk: Remaining exposure has time-limited approval, validated interim controls, and a reassessment trigger.
• [ ] Retest evidence: Closure records show that the original attack fails, clinical functions still work, and reviewer approval is documented.^[4][5]

FAQs

How do I choose DAST tools for medical devices?

Use a risk-based inventory to prioritize web apps, mobile apps, and APIs that handle ePHI. Choose tools that test authenticated workflows, role-based access, and multi-step clinical journeys. They should also support OpenAPI/Swagger API discovery and SSO/SMART on FHIR authentication.

For devices with fragile TCP/IP implementations, make sure the tools allow light discovery scans that won’t disrupt them.

Verify CI/CD integration so testing is repeatable and version-controlled in environments that match production.

What if I can’t replicate the clinical environment?

Build a staging or lab environment that closely matches production, including WAF rules, IAM roles, SSO settings, VLANs, and firewall policies ^[1][2]. Use infrastructure-as-code to keep it in sync with production releases ^[1].

Use synthetic or de-identified data that reflects realistic patient and lab relationships. This lets you simulate clinical conditions without putting live systems at risk ^[1][2]. If the setup doesn’t reflect normal use closely enough, testing may miss vulnerabilities that surface during day-to-day work ^[1].

How often should I retest medical device software?

Retest throughout the software lifecycle - after software changes, firmware updates, interface modifications, or changes to trust boundaries. After remediation, retest to confirm the fixes work and haven’t introduced new vulnerabilities.

For production systems, scan at least every six months. Quarterly or monthly scans provide a stronger safety net. Update your scan scope and retest quarterly, or after major deployments, upgrades, or network restructuring.

Related Blog Posts

• Cybersecurity Testing for 510(k) Submissions: Guide
• How Penetration Testing Supports FDA Compliance
• Testing Medical Device Interoperability
• Best Practices for Using DAST Tools in Healthcare