eSTAR v7.0 Cybersecurity for IVDs vs nIVD Submissions

Published June 11, 2026

Key Takeaways

• The 8 eSTAR v7.0 cybersecurity slots are structurally identical for IVD and nIVD submissions. The differentiation is content, not container.
• IVD submissions are reviewed by OHT7, which has a distinct cybersecurity posture focused on sample-to-result integrity and laboratory connectivity.
• Slot 3 (Threat Model) on an IVD must address LIS/EHR integration, middleware (e.g., Data Innovations Instrument Manager), and multi-instrument lab environments.
• Slot 6 (Security Controls) must cover patient-result integrity, audit logging tied to QC and CLIA requirements, and authentication models that match laboratory workflows.
• Slot 8 (Labeling) on an IVD reaches the laboratory director, not the clinician — interoperability and IT-security guidance must be written for the lab IT and biomed audience.

Table of Contents

• Key Takeaways
• Why this matters
• The 8 slots are the same — but OHT7 reads them differently
• Slot-by-slot IVD-specific guidance
• The deficiency patterns we see on IVD submissions
• How Blue Goat Cyber builds IVD cybersecurity packages
• FAQ

Why this matters

IVDs are cyber devices under Section 524B exactly the way nIVDs are. The February 3, 2026 final premarket cybersecurity guidance does not carve out a softer path for in vitro diagnostics — same statutory floor, same eSTAR v7.0 structure, same expectation of test evidence. What the guidance does not spell out, and what trips IVD sponsors, is that the reviewing office is different. OHT7 evaluates IVD submissions through a lens shaped by CLIA, lab workflow, and integration patterns that simply do not exist in most therapeutic device reviews.

A nIVD cybersecurity package transplanted into an IVD eSTAR is structurally complete and substantively wrong. Reviewers flag the same patterns on most IVD submissions: a threat model that ignores the LIS, a controls catalog that does not address result integrity, labeling written for clinicians instead of lab directors. Each pattern becomes an Additional Information cycle.

The 8 slots are the same — but OHT7 reads them differently

The eSTAR v7.0 cybersecurity attachments are identical in number and order for IVD and nIVD submissions. The slots are:

1. Cybersecurity Management Plan
2. Security Risk Assessment
3. Threat Model
4. Architecture Views (System, Network, Application, Data Flow)
5. Software Bill of Materials (SBOM)
6. Security Controls
7. Testing
8. Cybersecurity Labeling

For the canonical slot mapping see our eSTAR v7.0 Cybersecurity Attachments guide. What changes for IVDs is the expected content inside each slot.

Slot-by-slot IVD-specific guidance

Slot 1 — Cybersecurity Management Plan

• Reference CLSI AUTO11-A and CLSI AUTO16 where applicable, in addition to AAMI SW96 and IEC 81001-5-1.
• Postmarket commitments must address the laboratory upgrade window — labs cannot patch during a CLIA proficiency-testing event without re-validation.

Slot 2 — Security Risk Assessment

• Patient-harm scenarios on IVDs trace through result integrity, not direct device action. A modified glucose result that drives an insulin dose is the canonical example.
• Map to ISO 14971 and the IVD-specific risk framework in IEC 62304 / IEC 81001-5-1 jointly.

Slot 3 — Threat Model

This is where nIVD packages most often fall short. An IVD threat model must address:

• LIS / middleware integration — ASTM E1394, HL7 v2.5 ORU^R01, HL7 FHIR DiagnosticReport, Data Innovations Instrument Manager, Roche cobas IT, Sysmex SNCS connectivity.
• Sample-to-result integrity — STRIDE Tampering on the sample ID barcode, the analytical result, and the QC record.
• Multi-instrument lab environments — one IVD rarely operates alone; the threat model must include the lab segment, not just the device.
• Remote-service connectivity — most analyzers maintain vendor remote-service tunnels (VPN, MQTT, vendor cloud). Reviewers expect explicit modeling.

See our STRIDE Threat Modeling guide for the underlying methodology.

Slot 4 — Architecture Views

• The Network View must show LIS, middleware, vendor remote service, and lab IT segmentation. A single "connects to hospital network" arrow is the most common red flag.
• The Data Flow View must show sample ID → analytical run → QC → result → LIS as discrete trust boundaries.

Slot 5 — SBOM

• Same Section 524B(b)(3) requirements as nIVDs. CycloneDX 1.5+ or SPDX 2.3+. See the SBOM pillar.
• IVDs frequently embed Windows IoT or Windows 10 LTSC for the analyzer controller — the OS SBOM and patch posture are reviewer focus areas, often surfacing as deficiencies on legacy Win10 builds.

Slot 6 — Security Controls

The 8 control categories (Authentication, Authorization, Cryptography, Integrity, Confidentiality, Logging, Resiliency, Updatability) are identical to nIVD expectations. The IVD-specific overlays:

See also: Preparing Your eSTAR 510(k) Cybersecurity Documentation, Unresolved Anomalies in FDA Cybersecurity Submissions, and Patch and Update Mechanism Testing for FDA Section 524B(b)(1).

• Authentication — role-based for lab tech, supervisor, lab director, service engineer. Single-tech shared logins are common in labs and a recurring deficiency.
• Integrity — explicit controls on the analytical result and QC record path. Hash chains or signed result records are increasingly expected.
• Logging — audit trail must satisfy CLIA §493.1289 (test record retention) in addition to the FDA's cybersecurity logging expectations.
• Resiliency — sample loss is a clinical harm event. The resiliency narrative must address what happens to in-flight samples during a security incident.

For the canonical breakdown see FDA Security Control Categories for Medical Devices.

Slot 7 — Testing

• Pen test scope must include the LIS/middleware integration path, not just the device's local interfaces.
• Result-integrity testing — does a tampered HL7 message reach the LIS without detection? — is an expected test case for IVDs and rarely present in nIVD-derived test plans.

Slot 8 — Cybersecurity Labeling

• Audience is the laboratory director and lab IT, not the clinician.
• Must include the LIS integration guidance, expected lab network segmentation, supported HL7/ASTM versions, and the MDS2 / HSCC disclosure tuned to lab procurement.
• See Interoperability Labeling for Connected Medical Devices and MDS2 / HSCC Disclosure.

The deficiency patterns we see on IVD submissions

Four patterns dominate IVD cybersecurity Additional Information requests:

1. LIS/middleware absent from the threat model. The threat model treats the LIS as out of scope. OHT7 disagrees — if the device's output crosses the trust boundary into the LIS, the integration path is in scope.
2. Shared-login authentication left undocumented. Labs run shared technologist accounts in practice. Submissions either pretend they don't or fail to describe compensating controls.
3. Result-integrity controls missing from Slot 6. Authentication and encryption are present; explicit integrity controls on the analytical result are not.
4. Labeling written for the wrong audience. A clinician-facing labeling section in an IVD submission gets cited on relevance — the user is the laboratory, not the bedside.

How Blue Goat Cyber builds IVD cybersecurity packages

We staff IVD engagements with reviewers who have shipped through OHT7 specifically. The threat model is built to reach the LIS and middleware (we maintain reference data flows for Data Innovations, Roche cobas IT, and Sysmex SNCS); the controls catalog is tuned to CLIA logging and shared-login realities; the labeling is written for the laboratory director audience the submission will actually serve. We deliver the eSTAR v7.0 attachments as a complete IVD-tailored package, with the cross-references between Slots 3, 6, 7, and 8 the reviewer expects to follow.

If the FDA raises cybersecurity deficiencies after our submission, we resolve them at no additional cost. See our penetration testing service and the FDA Cybersecurity Testing Requirements Taxonomy.

FAQ

Is the eSTAR v7.0 cybersecurity section different for IVD submissions?

The structure is identical — same 8 attachment slots in the same order. What differs is the content reviewers expect, because IVD submissions are evaluated by OHT7 against laboratory connectivity, sample-to-result integrity, and CLIA-aligned logging that do not appear in most nIVD reviews.

Can we reuse a nIVD cybersecurity package on an IVD submission?

Only as a starting point. The threat model, architecture views, controls, testing, and labeling all need IVD-specific rework — LIS/middleware in the threat model, lab segmentation in the architecture, result-integrity controls in Slot 6, lab-director audience in Slot 8. Submitting a copy-paste nIVD package on an IVD eSTAR is one of the most common ways to receive an Additional Information request.

Does Section 524B apply to IVDs?

Yes. Any IVD that meets the Section 524B definition of "cyber device" — software validated by the sponsor, able to connect to the internet, technologically capable of being compromised — falls under the statute. Most modern analyzers and middleware-connected IVDs qualify. Use our Cyber Device Applicability tool.

What about CLIA-waived or POC IVDs?

CLIA-waived and point-of-care IVDs still fall under Section 524B if they meet the cyber-device definition. The threat model shifts to address connected POC ecosystems (CGM-style cloud sync, EHR integration via FHIR), but the eight slots and the OHT7 reviewing posture are the same.

How does this interact with EU IVDR cybersecurity expectations?

EU IVDR Annex I §17.2 and MDCG 2019-16 require cybersecurity evidence parallel to the FDA's expectations. A well-built IVD cybersecurity package — threat model addressing LIS, integrity controls, postmarket vulnerability management — covers both regimes if you produce a single CycloneDX SBOM and a unified threat model. See our EU MDR vs FDA cybersecurity crosswalk.

Which standards should be cited in an IVD cybersecurity package?

AAMI SW96 (security risk management), IEC 81001-5-1 (secure development), ISO 14971 (risk), IEC 62304 (software lifecycle), and CLSI AUTO11-A / AUTO16 (lab automation interoperability). The labeling should also reference HL7 v2.5, HL7 FHIR DiagnosticReport, ASTM E1394, and LOINC where the device emits coded results.

Ready to scope your IVD eSTAR cybersecurity package?

If you are preparing a 510(k), De Novo, or PMA submission for an IVD and are unsure whether your cybersecurity package meets OHT7's expectations, we will review your draft against the patterns above and scope the gap closure before your submission window. Request a scoping call.

---

Christian Espinosa — Founder, Blue Goat Cyber. CISSP, ex-military red team. Has shipped IVD cybersecurity packages through OHT7 for analyzer platforms, molecular diagnostic systems, and connected POC devices. More on the author.

Related reading

• eSTAR v7.0 Cybersecurity Attachments mapping
• FDA Security Control Categories for Medical Devices
• Cybersecurity Management Plan for FDA Medical Devices
• STRIDE Threat Modeling for Medical Devices
• MDS2 / HSCC Disclosure for Medical Devices
• Interoperability Labeling for Connected Medical Devices