Drug-device combination products do not get a cybersecurity discount. If the device constituent has software and any electronic interface, FD&C Act Section 524B applies - lead center notwithstanding.
Last reviewed: June 2026 against the FDA "Cybersecurity in Medical Devices" final guidance (Feb 3, 2026), FD&C Act Section 524B, 21 CFR Part 3 (combination products), and the Office of Combination Products (OCP) jurisdictional framework.
TL;DR
A combination product is a single therapeutic entity made of two or more regulated constituents - typically a drug and a device, sometimes a biologic and a device. Auto-injectors, on-body drug delivery systems, prefilled connected inhalers, drug-eluting pump platforms, and combo diagnostic-therapeutic patches are the common shapes. FDA assigns a lead center based on the product's primary mode of action (PMOA): CDER or CBER for drug/biologic-led, CDRH for device-led. That assignment governs review pathway, fee schedules, and labeling rules. It does not govern whether Section 524B cybersecurity requirements apply. 524B follows the device constituent. If the device contains software and has any electronic interface capable of connecting to or transferring data from another device or network, it is a "cyber device" under the statute - and the sponsor owes the full premarket cybersecurity package.
What counts as a combination product (and what doesn't)
21 CFR 3.2(e) defines four classes:
| Type | Example |
|---|---|
| 3.2(e)(1) Single-entity | Prefilled syringe; transdermal patch; drug-eluting stent |
| 3.2(e)(2) Co-packaged | Kit with vial + injector in one box |
| 3.2(e)(3) Cross-labeled drug + device | Drug whose labeling specifies a particular device (e.g. specific inhaler) |
| 3.2(e)(4) Cross-labeled investigational | Same as (3) but in trials |
The cybersecurity question turns on one thing: does the device constituent contain software and have an electronic interface?
- Yes - connected auto-injector with BLE pairing to a phone app; on-body infusor with cellular telemetry; smart inhaler logging actuations to the cloud; digital pill with ingestible sensor; drug-pump platform with Wi-Fi: 524B applies. Full cyber package required.
- No - purely mechanical autoinjector with no electronics; standard prefilled syringe; passive transdermal patch: 524B does not apply. Traditional 21 CFR 820/QSR-equivalent device controls only.
The fastest way to get this wrong is to assume "the drug is the point, the injector is just a delivery mechanism." If the injector phones home, it is a cyber device.
How lead-center designation actually works
The Office of Combination Products (OCP) assigns the lead center via a Request for Designation (RFD) or pre-RFD. PMOA controls. A drug-led product reviews under CDER's BLA/NDA pathway; a device-led product reviews under CDRH's 510(k)/De Novo/PMA pathway. Either way, the non-lead center is consulted.
Where sponsors get burned:
- CDER-led, software-rich device - CDER reviewers do not own cybersecurity expertise the way CDRH does. They consult CDRH, which means cyber comments often arrive late in review, compress timelines, and surface deficiencies that should have been caught at the threat-modeling phase a year earlier.
- Late-binding device decisions - the drug program defines the device constituent late in development. Cybersecurity scope (SBOM, secure boot, key management) cannot be designed in retroactively. Doing so adds 6-12 months.
- Platform reuse - sponsors reuse a device platform across multiple drug indications and assume the original cyber package carries forward. It does, but only if the threat model, SBOM, and CVD program are kept current. A 2-year-old SBOM with unpatched criticals is a deficiency every time.
What the cyber package looks like for a combination product
Identical in content to a CDRH-only submission. The deliverables map straight to the FDA premarket cybersecurity deliverables and eSTAR v7.0 map:
[KEY REQUIREMENT] Combination product sponsors must produce, for the device constituent:
- Security Risk Management Report aligned to AAMI TIR57 / ANSI/AAMI SW96 and converged with the safety RMF per ISO 14971 vs AAMI TIR57.
- SBOM in SPDX or CycloneDX (machine-readable), with VEX statements for known vulnerabilities.
- Threat model (STRIDE or equivalent) tied to patient harm.
- Architecture views - global system, multi-patient harm, updateability, security use case.
- Cybersecurity testing - vulnerability scanning, penetration testing, software composition analysis, fuzz testing of communication interfaces.
- Postmarket plan - monitoring, CVD intake, patch cadence, end-of-life.
- Cybersecurity Management Plan under 524B(b)(1). [/KEY REQUIREMENT]
In a BLA/NDA, this lives in Module 3.2.R (regional information) or a dedicated cybersecurity section the sponsor builds and cross-references from the device description module. In a 510(k)/De Novo/PMA, it lives in the standard eSTAR cybersecurity attachments.
The CDER-led trap: budget cyber early
If a drug program lead is reading this, the single most consequential decision is when to engage cybersecurity expertise. The right answer is at the same point you lock the device constituent's bill of materials - typically during late-stage formulation work. Engaging at the BLA prep stage is too late: threat model, SBOM, and any required cryptographic key management need to influence device firmware before design freeze.
Sponsors who learn this the hard way share three regrets:
- Treating the connected device as a marketing feature (real-time adherence dashboards!) without scoping cyber budget for it.
- Outsourcing the device constituent to a contract manufacturer (CDMO/CMO) without contractually obligating SBOM delivery, secure SDLC evidence, and ongoing vulnerability monitoring.
- Pairing with a third-party companion app and assuming the app vendor owns app-side cybersecurity. The submission holder owns it. Period.
How Blue Goat approaches combination product cybersecurity
We start where most sponsors don't: at the device-constituent design freeze, not at submission prep. Our team's prior work on connected drug-delivery systems, on-body infusors, and smart inhalers means we walk in knowing the typical attack surface (BLE pairing flaws, OTA update key management, app-to-device authentication, telemetry endpoint exposure) and the deficiency patterns that follow.
We deliver the full premarket package - SBOM, threat model, security risk management report, architecture views, testing - in a form that drops into either a CDER Module 3 or a CDRH eSTAR. If the FDA raises cybersecurity deficiencies after our submission, we resolve them at no additional cost. Start with our FDA premarket cybersecurity services page or our secure MedTech product design consulting if you are pre-design-freeze.
FAQ
Does Section 524B apply to combination products reviewed by CDER? Yes, if the device constituent contains software and has an electronic interface. 524B is a statute that follows the device, not the review center. CDER will consult CDRH on cybersecurity, and the consulting reviewers apply the same Feb 2026 premarket guidance they apply to standalone devices.
Where does the cybersecurity documentation go in a BLA or NDA? Most commonly in Module 3.2.R (regional information) with cross-references from the device description in 3.2.P.7. Some sponsors create a dedicated cybersecurity sub-section. The format matters less than completeness - reviewers need to find the SBOM, threat model, architecture views, testing report, and Cybersecurity Management Plan without hunting.
Does my purely mechanical auto-injector need cybersecurity documentation? No. If there is no software and no electronic interface, the device is not a cyber device under 524B. Standard device controls apply.
What if the device constituent comes from a CDMO? You, the submission holder, own the cybersecurity obligation. Contractually require the CDMO to deliver an SBOM, secure SDLC evidence, vulnerability monitoring, and patch support for the full postmarket lifecycle. Audit it. The FDA will not accept "the contract manufacturer handles that" as a response to a deficiency letter.
Can I reuse the cybersecurity package from a prior approval on a platform device? Partially. The architecture views and threat model topology may carry forward, but the SBOM must be current (within ~90 days of submission), the vulnerability assessment must reflect today's CVE landscape, and the postmarket plan must reference current FDA expectations. A stale package is a deficiency.
Is the companion smartphone app in scope? Yes, if it is part of the labeled use of the combination product. App authentication, data integrity in transit, secure pairing with the device, and the mobile platform's update mechanism are all in scope for the submission's threat model and testing.
Get a combination product cyber scope
If you are pre-submission on a connected drug-delivery product, get a scoped cybersecurity plan before the device design freezes. We will tell you what 524B requires, what your reviewers will ask for, and what your CDMO needs to deliver - in writing, in one call.
Book a combination product cyber scope
Reviewed by the Blue Goat Cyber medical device team. Christian Espinosa (CISSP, OSCP) leads our combination-product engagements; the team's prior work spans connected auto-injectors, on-body delivery, and smart inhalers.