Ophthalmic Devices cybersecurity.

• OCT, fundus, and slit-lamp imaging systems
• Refractive and cataract surgical lasers
• Visual-field and electrophysiology diagnostics
• AI-assisted DR / AMD / glaucoma screening
• Surgical guidance and IOL planning systems

• Device ↔ DICOM / PACS (image storage)
• Device ↔ EHR (HL7, FHIR)
• Device ↔ vendor remote support (tunnel, MFA)
• Device ↔ AI add-on module (signed artifacts)
• Device ↔ USB / removable media (controlled, logged)

Do ophthalmic devices need DICOM-specific cybersecurity testing?

Yes. OCT, fundus cameras, perimetry systems, and ophthalmic surgical platforms almost universally use DICOM (with a strong dose of Eye Care-specific service classes), so DICOM service fuzzing, authorization tests across C-STORE/C-FIND/C-MOVE, and parser memory-safety evidence are part of the scope. DICOM toolkits have a long CVE history and reviewers expect explicit testing rather than narrative claims of conformance.

How do you scope a surgical-laser cybersecurity engagement?

We focus on the control system (laser parameter authorization, energy-delivery integrity, foot-pedal and treatment-pattern interfaces), the service interfaces (USB, serial, vendor remote support), and any networked planning workflow that feeds the device. Safety-critical control paths are exercised on staging hardware only and coordinated with the device's IEC 60601-1 (and applicable -2-22 for laser surgical) and IEC 14971 risk file. The SPDF captures every interface, its authentication, and its failure mode.

What about OCT and fundus image data on the cloud?

Cloud-stored ophthalmic images are PHI and frequently sensitive (they reveal systemic conditions beyond ophthalmology). We test encryption at rest and in transit, key custody, tenant isolation, and authorization on every read path - including image-sharing flows between practices and reading centers. The SPDF documents storage regions, retention, and any cross-border data flow so reviewers, hospital procurement, and privacy counsel see one coherent story.

Are USB and serial service interfaces in scope?

Yes. Service ports (USB, RS-232, Ethernet service VLAN, vendor proprietary) are a common path to privileged access on ophthalmic platforms, and they're a frequent FDA finding when left enabled by default. We verify that they're authenticated, locked down on shipped product, gated by physical or procedural controls, and properly documented in labeling. The threat model treats them as untrusted local interfaces regardless of how 'internal' the vendor considers them.

How do you support a 510(k) or De Novo for an OCT or imaging device?

Standard premarket cyber package: STRIDE-based threat model, SBOM in SPDX or CycloneDX with VEX, security architecture views, authenticated penetration testing focused on DICOM, network, service, and (when present) cloud surfaces, MDS2, labeling content, and a postmarket cybersecurity management plan under section 524B. Everything is packaged for eSTAR and cross-references the IEC 14971 risk file.

Do you cover the in-clinic workstation that drives the device?

When the workstation is part of the cleared system or recommended configuration, OS hardening, application allowlisting, update mechanisms, and remote-access exposure are all in scope. End-of-life Windows is documented with compensating controls (segmentation, allowlisting, restricted services) plus a migration plan - reviewers accept that combination but reject silence on it.

How do you handle AI-driven ophthalmic SaMD (DR screening, AMD analysis, glaucoma progression)?

AI ophthalmic SaMD is treated like other AI/SaMD: model supply-chain controls (signing, version pinning, load-time verification), training-data lineage in the SPDF, adversarial-input testing where clinically meaningful, and PCCP-aware change control if you have one. The DICOM ingestion path is fuzzed and authorization-tested separately from the model so issues in either layer are isolated and traceable.

What about reading-center and tele-ophthalmology integrations?

Reading centers and tele-ophthalmology partners are modeled as explicit external trust boundaries with documented authentication, authorization, and data-retention controls. We test the case-routing and image-sharing APIs for cross-tenant isolation and stale-session access, and we verify that revocation flows actually terminate the partner's access. These integrations frequently surface authorization findings if not designed deliberately.

How do you cover surgical-suite integration (e.g., femto-cataract, vitrectomy platforms)?

Surgical platforms are scoped as connected systems within the OR sub-network: console, foot pedal, irrigation/aspiration controllers, energy modules, navigation, and any imaging integration. We model the OR network with explicit trust boundaries, exercise vendor remote-service tunnels for MFA/jump-host/session-recording compliance, and pen-test the service paths end-to-end - the same playbook applied to surgical robotics, scaled to ophthalmic specifics.

What standards stack applies to ophthalmic devices?

Typical baseline: FDA 2026 final premarket cybersecurity guidance, AAMI SW96, AAMI TIR57, IEC 62304 (often Class B or C depending on indication), ISO 14971, IEC 60601-1 with applicable particulars (e.g., -2-22 for laser surgical, -2-57 for ophthalmic light sources), and DICOM-specific test cases. EU manufacturers add MDR Annex I §17.2 and MDCG 2019-16; we map across both regimes.

What postmarket cybersecurity expectations apply?

A formal postmarket cybersecurity management plan under section 524B: continuous SBOM monitoring across device firmware, embedded OS, in-clinic workstation, and any cloud components; CVD intake with severity-based SLAs; controlled patching through the QMS; and a secure update mechanism (signed, anti-rollback, atomic, recovery-safe) that respects clinic uptime constraints.