Cybersecurity for prescription digital therapeutics and DTx apps.
Prescription digital therapeutics are mobile- and web-first SaMD with patient-identifiable data and clinical claims. We deliver mobile and API penetration testing, SBOMs, and threat models built for DTx submission packages.
Prescription DTx products live mostly on patient phones and in the cloud - which makes mobile, identity, API authorization, and back-end PHI handling the dominant attack surfaces. The device boundary is the app + the cloud, not the phone.
DTx ships at SaaS cadence (weekly or faster). Cyber regression has to be CI/CD-integrated, not a once-a-year pen test, and PCCPs are increasingly the path to keep release velocity inside the FDA framework.
Typical clinical uses
Key data flows & integrations
Root/jailbreak detection, secure storage, and TLS pinning are basic expectations for prescription-class mobile SaMD.
Object-level authorization gaps (BOLA) are the #1 finding in DTx backends.
Analytics and ad SDKs in DTx apps frequently leak PHI - SBOM and SDK review are essential.
DTx is mostly software - the threat model centers on the cloud back-end, the mobile app, and the data-handling that crosses HIPAA / GDPR boundaries.
Layers shown outermost (top) to innermost (bottom). Dashed rows are part of the surrounding system but out of scope for this view.
DTx products live almost entirely on patient phones and in the cloud, so the dominant incident history is the broader mobile/SaaS PHI breach pattern - which is exactly what reviewers reference when they cite OWASP MASVS and ASVS expectations.
Historical incidents
FTC alleged that Flo's period- and fertility-tracking app shared sensitive health data with third-party analytics SDKs (including Facebook and Google) despite privacy promises. Settlement required independent privacy audits and notice obligations.
FTC, In re Flo Health, Inc., Jan 2021
FTC actions against BetterHelp and GoodRx for sharing user health data with advertising platforms reset industry expectations for SDK and pixel use in any health-related app - directly applicable to prescription DTx products.
FTC, In re BetterHelp, Inc., Mar 2023FTC, In re GoodRx Holdings, Feb 2023
OWASP API Security ranks BOLA as the #1 API risk and it remains the most frequent critical finding in our DTx backend assessments - other-user record access through ID guessing or token misuse.
OWASP API Security Top 10 (2023)
Active threat scenarios
Predictable IDs combined with weak authorization checks allow access to other patients' therapy data, prescriber notes, or PHI.
Analytics, attribution, or A/B SDKs in a prescription build can transmit PHI to third parties unless explicitly stripped from the regulated build.
Long-lived tokens, missing scope enforcement, and refresh-token theft are repeat findings in DTx backends.
Unsigned therapy content delivered from the cloud can be modified in transit or at rest, changing the prescribed regimen.
What FDA reviewers cite
Prescription DTx products live mostly on patient phones and in the cloud - which makes mobile, identity, and back-end APIs the dominant attack surfaces.
Threat models must assume the OS is hostile, the app is reverse-engineered, and the user can be socially engineered.
DTx ships weekly or faster - cyber regression testing has to be CI/CD-integrated, not a once-a-year pen test.
DTx sits under FDA, HIPAA, and increasingly state health-privacy laws - documentation must reconcile all three.
Payer/EHR integrations (FHIR, SMART) bring new auth flows and trust boundaries that need explicit modeling.
What FDA scrutinizes
Reviewers expect a model that assumes the OS is hostile, the app is reverse-engineered, and the user can be socially engineered.
Broken object-level authorization is the #1 finding on DTx pen tests; FDA and hospital security teams both expect explicit testing.
PCCP + CI/CD security gates are how you keep weekly releases compliant without re-submitting.
Standards & deliverables
Six deliverables FDA and notified bodies expect across MedTech, with the digital therapeutics-specific wrinkle on each row. Use it as a scoping checklist before you brief vendors or your QA team.
Machine-readable SBOM (CycloneDX/SPDX) plus VEX feed for every CVE that touches a listed component.
Continuous CVE / advisory monitoring against the SBOM, with a documented triage and disclosure path.
Black/grey-box testing across device, wireless interfaces, mobile apps, cloud APIs, and service tooling.
STRIDE-per-interface threat model with documented mitigations and residual-risk acceptance.
Signed firmware/software updates with rollback protection, integrity verification, and staged rollout.
Public CVD policy, intake channel, and SLAs for triage, fix, and customer communication.
No. HIPAA covers privacy, breach response, and the obligations of covered entities and business associates - it does not satisfy FDA premarket cybersecurity content. You need both, and the cyber documentation has to demonstrate that HIPAA controls are coherent with the FDA-expected security risk management under AAMI SW96 and ISO 14971. Reviewers explicitly flag inconsistencies between privacy notices, BAAs, and the SPDF.
OWASP MASVS L2 by default for prescription DTx, with MSTG-driven test cases. Verification level is tuned to the actual risk profile - prescription products with controlled-substance or pediatric indications often warrant MASVS L2+R (resilience), while adjunctive wellness-style indications may justify L1. The chosen level, the rationale, and the resulting test coverage are all documented in the SPDF so reviewers can see why the depth is appropriate.
Each SDK is enumerated in the SBOM with its version, the data classes it can access, and the destinations it sends to. Data flows are mapped, any PHI exposure is flagged, and we typically recommend stripping ad and attribution SDKs from the prescription build entirely. Analytics SDKs are kept only when configured for de-identified or aggregated telemetry and run through a DPIA-style review. SDK supply-chain risk (typosquatting, dependency confusion, post-install scripts) is also assessed.
Yes. The clinician-facing portal, EHR integrations, caregiver views, and any back-office or admin consoles are scoped together with the patient app so authorization, tenancy, and audit logging are tested coherently. Cross-role authorization (patient vs. caregiver vs. prescriber vs. admin) is one of the highest-impact finding areas in DTx and is exercised exhaustively in the test plan.
A typical premarket cyber package - threat model, SBOM with VEX, mobile pen test, API pen test, prescriber portal pen test, security risk file, and consolidated report - runs 4-7 weeks depending on backend complexity, number of integrated services, and whether the prescriber portal is in scope. Threat modeling and SBOM front-load in weeks 1-2, testing runs in weeks 2-6, and the consolidated package and postmarket plan close out in the final week.
We help you write privacy disclosures, security disclosures, and clinical-claim language consistent with both Apple App Store and Google Play policies and your FDA submission so they don't contradict. App store rejections in this space frequently cite mismatch between the IFU's claims and the listing copy, or PHI-relevant SDK behavior that wasn't disclosed - both of which the cyber and regulatory teams should be solving together, not separately.
Off-the-shelf phones aren't medical devices, so the design has to compensate for OS variability, sideloading, OS-level screen-lock bypass, accessibility-service abuse, and the user installing arbitrary apps in the same trust boundary. We document the assumed platform constraints in the IFU, exercise the highest-impact platform-abuse scenarios in pen testing, and verify that compensating controls (e.g., root/jailbreak detection, secure storage, attestation where available) behave as documented.
Yes. Paired wearables, sensors, and BLE peripherals are scoped as part of the connected system: pairing mode, OTA signing on the peripheral firmware, sensor-spoofing resistance, and battery/DoS handling. Findings against the peripheral feed back into the system-level threat model and SBOM so the regulatory and cyber stories stay unified.
When generative AI affects clinical claims or behavior, the model is part of the regulated software and the cyber package addresses prompt-injection resistance, output-handling/escaping, content provenance, supply-chain controls on the model and its hosting, and any PCCP cyber elements. Where the model is a third-party API, the boundary is documented as an explicit untrusted-but-contractually-bound interface and tested for abuse and PHI leakage.
Typical baseline: FDA 2026 final premarket cybersecurity guidance, AAMI SW96, AAMI TIR57, IEC 62304 (typically Class B for adjunctive DTx, Class C where therapeutic outcome depends on software correctness), ISO 14971, OWASP MASVS for mobile, OWASP ASVS for web/API, plus HIPAA Security Rule mappings. EU manufacturers add MDR Annex I §17.2 and MDCG 2019-16; we map the same artifacts across both regimes.
A formal postmarket cybersecurity management plan: continuous SBOM monitoring across mobile, web, backend, and any peripheral firmware; a published Coordinated Vulnerability Disclosure intake with severity-based SLAs; a controlled patching process through the QMS; and explicit handling for app-store-driven updates so a fast mobile release cycle doesn't break the cleared interoperability or claims. We deliver the postmarket plan as part of the premarket package so it's ready for clearance.
Mobile + cloud threat modeling, SBOM, and pen testing for prescription DTx - without enterprise overhead.
"Blue Goat Cyber's depth of expertise was impressive. We had no in-house cybersecurity experience, and their team guided us through every step of the FDA process. The penetration testing and SBOM testing were thorough and gave us complete confidence."
Cybersecurity for prescription digital therapeutics and DTx apps.
