FDA 524B Cybersecurity Readiness Report

Your self-assessment indicates you don't have a cybersecurity-specific risk assessment in place yet. For a cloud-connected insulin delivery system with BLE and Wi-Fi connectivity, this is the single most important gap to close before submission.

FDA's cybersecurity risk assessment is fundamentally different from your ISO 14971 safety risk analysis. Where ISO 14971 uses probability × severity, FDA requires exploitability-based scoring because cyber attackers are intentional actors, not random events. For your device specifically, this means scoring each threat based on how accessible the attack surface is (your BLE and Wi-Fi interfaces are remotely accessible, which elevates exploitability scores significantly compared to a device with only physical interfaces).

Your risk assessment needs pre-mitigation and post-mitigation scores for every threat identified in your threat model. Given your architecture (embedded firmware communicating via BLE to a mobile app, which syncs patient insulin delivery data to a cloud platform) you'll need to assess threats at each trust boundary: device-to-phone, phone-to-cloud, and cloud-to-clinician dashboard. Each of these boundaries has distinct threat profiles. The device-to-phone BLE link is susceptible to replay attacks and eavesdropping; the phone-to-cloud channel faces man-in-the-middle risks; the cloud platform has API authentication and data integrity concerns.

FDA reviewers typically start with this document. For insulin delivery devices, where a dosing error has direct patient safety implications, reviewers will scrutinize the connection between cyber risks and clinical hazards with particular care. We recommend using CVSS environmental scoring adjusted for your specific deployment context, and explicitly mapping each cyber risk to specific hazardous situations in your 14971 risk management file.

Your self-assessment indicates some testing has been done but with significant gaps in coverage. For a 510(k) submission, the security testing eSTAR attachment often contains 10 or more individual test reports. A single penetration test is not sufficient.

Given your device architecture, here's what FDA will expect to see in your testing package. For the embedded firmware: static analysis (SAST) covering all custom code with CWE-based rules, and fuzz testing of the BLE GATT services. Every characteristic and descriptor should be fuzzed with malformed data to verify the firmware handles it gracefully without crashing, corrupting state, or accepting unauthorized commands. For the mobile companion app: OWASP Mobile Top 10 testing for both iOS and Android builds, including local data storage review (is patient insulin data encrypted at rest on the phone?), certificate pinning verification, and reverse engineering resistance.

For the cloud platform: API penetration testing covering authentication, authorization, injection, and business logic flaws. Automated vulnerability scanning (SCA) of all SBOM components against current CVE databases. And robustness testing of the full system under adversarial conditions: what happens to insulin delivery if the cloud goes down, if the BLE connection drops mid-command, or if the mobile app receives malformed data from a spoofed device?

Each test type needs a complete report: methodology, tools used, findings with severity ratings, and remediation evidence showing that identified issues were fixed and retested. All findings must trace back to risks in your cybersecurity risk assessment.