In-Vitro Diagnostics (IVD) cybersecurity.

• Clinical chemistry, hematology, and immunoassay analyzers
• Molecular diagnostics and PCR platforms
• Point-of-care IVD devices (POC)
• Companion diagnostics tied to therapeutics
• LIS / LIMS middleware and lab-automation orchestration

• Analyzer ↔ middleware (HL7, ASTM, vendor protocols)
• Middleware ↔ LIS / LIMS
• LIS ↔ EHR (HL7, FHIR)
• Analyzer ↔ vendor remote-service tunnel
• Analyzer / cloud ↔ reagent / cartridge identity service

Do CLIA labs change FDA cyber expectations for IVDs?

No - they run in parallel. CLIA governs lab operations and personnel; FDA cybersecurity expectations apply to the IVD device or system as a regulated product. Both apply, and the documentation must be coherent across them: an analyzer's secure-update story, for example, has to make sense to both an FDA reviewer and a CLIA-regulated lab director.

How do you handle analyzers running end-of-life Windows?

End-of-life Windows is the IVD industry's biggest open cyber finding. We document compensating controls in the SPDF and labeling - segmentation, application allowlisting, restricted services, hardened user accounts, time-bounded service access - and we test the resulting attack surface from both authenticated and unauthenticated positions on the lab network. The submission also includes a documented OS migration plan so reviewers see the trajectory, not just the snapshot.

What about LIS / ASTM / HL7 / FHIR interface testing?

Every middleware and LIS interface in scope is enumerated with its protocol, authentication mechanism, and parser. We fuzz the parsers (ASTM E1394 in particular has a thin error-handling history), test authentication and authorization on every message type, and verify behavior under malformed and oversized payloads. Findings are tied back to specific message types so QA and dev know exactly what to remediate.

Do you cover service-engineer remote access?

Yes - vendor remote support paths are one of the most consistently scrutinized cyber surfaces on IVDs because they are high-privilege, often persistent, and outside lab change control. We require and validate MFA, jump-host isolation between the public internet and the analyzer, full session recording with tamper-evident storage, least-privilege scoping, and time-bounded access tokens, and we pen-test the path end-to-end including credential handling on the vendor side.

Is middleware in scope for cyber testing?

If you ship or recommend middleware as part of the cleared system, it's in scope. We test it the same way as the analyzer - application security, authentication, integration security, audit logging - and we make sure the SBOM, threat model, and labeling treat it as part of the regulated product. If middleware is genuinely third-party and out of scope, the boundary is documented explicitly so reviewers don't infer otherwise.

What's the postmarket cybersecurity expectation for IVDs under section 524B?

A formal postmarket cybersecurity management plan: SBOM monitoring across analyzer OS, instrument firmware, middleware, and any cloud components; a Coordinated Vulnerability Disclosure (CVD) program with published intake and severity-based SLAs; a controlled patch and update plan that respects clinical-lab uptime constraints; and integration of CVE triage into your QMS so each finding maps cleanly to a controlled change.

How do you handle multiplex molecular and POC IVDs differently from core-lab analyzers?

Point-of-care and near-patient IVDs (cartridge-based molecular, POC chemistry, rapid antigen with connectivity) often connect over Wi-Fi/cellular and integrate directly with EHRs, so the cloud and EHR boundaries get more weight in the threat model. Core-lab analyzers are usually in a hospital LAN sub-network, where service tunnels and middleware are the dominant threats. The same standards apply, but the test plan is tuned to the actual deployment topology.

Do you cover companion diagnostics (CDx) and software-driven assay reporting?

Yes. CDx and assay-reporting software are in scope as connected components, often with SaMD characteristics. We test the data path from instrument to result to clinician/EHR, verify integrity of the reported result, and audit the change-control story for the assay's software and decision rules. Where AI/ML is in the result chain, supply-chain controls and any PCCP cyber elements are documented in the SPDF.

How do you address third-party reagent / consumable identification?

Reagent and cartridge identification (RFID, barcode, vendor-proprietary) is exercised for spoofing, replay, and counterfeit-consumable acceptance, since accepting a non-genuine consumable is both a clinical and a business-model issue. The SPDF documents the integrity controls and the threat model traces them back to specific patient-impact scenarios.

What standards stack applies to IVDs?

Typical baseline: FDA 2026 final premarket cybersecurity guidance, AAMI SW96, AAMI TIR57, IEC 62304, ISO 14971, ISO 13485, IEC 81001-5-1 for the secure software lifecycle, plus IEC 61010 for the instrument and CLSI standards where applicable. EU manufacturers operating under IVDR add Annex I requirements and MDCG guidance; we map artifacts across both regimes.

How long does an IVD premarket cyber engagement typically take?

For a connected core-lab analyzer with middleware and LIS integration, end-to-end premarket cyber work generally runs 8-14 weeks. POC molecular or rapid devices with cloud and EHR integration typically run 6-10 weeks. Threat modeling and SBOM front-load, pen testing across analyzer/middleware/integrations runs in the middle weeks, and the consolidated submission package and postmarket plan close out at the end - all under a written clearance guarantee.