Published: June 11, 2026
Published June 11, 2026
Interoperability labeling tells the user organization how a connected medical device interacts with other systems — networks, EHRs, adjacent devices — and the trust assumptions embedded in those connections. The FDA's February 3, 2026 final premarket cybersecurity guidance treats interoperability as a first-class deliverable and expects the user-facing labeling to cover protocols supported, data exchanged, authentication requirements, error and disconnection behavior, and the boundaries of manufacturer responsibility. It lives in the Labeling section of eSTAR v7.0, with cybersecurity-relevant content cross-referenced from Slot 3 (Threat Model) and Slot 6 (Controls).
Key Takeaways
- Interoperability labeling is a Feb 2026 expectation, not optional.
- Reviewers expect protocols, data, authentication, error behavior, and responsibility boundaries — all in user-facing language.
- Cybersecurity-relevant content (auth, encryption, exposed ports/services) belongs in the labeling and in the MDS2 / HSCC disclosure.
- Labeling lives in eSTAR v7.0's Labeling section, not under Cybersecurity.
- The most common deficiency is silent assumptions — labeling that does not state what the connected ecosystem must do for the device to operate safely.
Table of Contents
- Key Takeaways
- Why this matters
- What goes in interoperability labeling
- Cybersecurity content specifically
- Where it sits in eSTAR v7.0
- Common deficiency and post-deployment patterns
- How Blue Goat Cyber writes interoperability labeling
- FAQ
Why this matters
Connected medical devices fail safely or unsafely depending on what the surrounding ecosystem does. A device that assumes the LIS will validate HL7 message integrity, or that the EHR will enforce role-based access, is implicitly delegating cybersecurity to systems it does not control. Interoperability labeling is where those delegations are made explicit.
"Labeling should clearly describe the device's interoperability with other devices, networks, and systems, including the protocols supported, the data exchanged, the authentication and authorization expectations, the failure modes when interoperability is disrupted, and the boundary of manufacturer responsibility."
The same labeling is read by three audiences: clinicians who operate the device, IT/biomed teams who deploy it, and the FDA reviewer who is asking whether the trust assumptions are reasonable.
What goes in interoperability labeling
A complete interoperability labeling section covers six topics.
1. Protocols supported
List every protocol the device speaks, with the standard reference and version: HL7 v2.x (and which segments), FHIR R4 / R5 (and which resources), DICOM (and which SOP classes), IEEE 11073 (PHD or PoCD), proprietary protocols if any, plus transport layers (TLS 1.2/1.3, MLLP-over-TLS, HTTPS, WebSocket).
2. Data exchanged
For each protocol, name the data classes exchanged: patient identifiers, demographic data, observations/results, orders, device telemetry, audit events. Indicate sensitivity classification. State the direction (inbound, outbound, bidirectional).
3. Authentication and authorization expectations
State what the device expects from the connected system: mutual TLS with which trust store, OAuth 2.0 scopes, SMART-on-FHIR scopes, IHE ATNA, device certificates issued by which CA. If the device performs no authentication at the protocol layer and relies on network segmentation, say so explicitly — silent assumptions are deficiency triggers.
4. Failure and disconnection behavior
What happens when the network drops mid-procedure? When the LIS returns an error? When the EHR is unreachable? When TLS validation fails? Reviewers want to know that the device's clinical function degrades safely, and that the operator is informed.
5. Responsibility boundary
State explicitly what the manufacturer is responsible for and what the user organization is responsible for. Typical pattern:
- Manufacturer: device-side software, signed updates, interoperability protocol implementation, labeling
- User organization: network segmentation, firewall configuration, certificate provisioning, EHR/LIS configuration, monitoring, incident response
This boundary statement is what reviewers look for first. A submission without an explicit RACI for the interoperable ecosystem is incomplete.
6. Configuration guidance
Provide the configuration the device requires of the surrounding systems: ports and protocols to allow on the network, certificate format and CA expectations, EHR/LIS configuration parameters, recommended monitoring rules. This is where IT/biomed teams live.
Cybersecurity content specifically
Inside the interoperability labeling, the FDA's Feb 2026 guidance expects specific cybersecurity-relevant content:
- Open ports and exposed services on the device, with their purpose
- Authentication requirements for each connection
- Encryption posture in transit (TLS versions, cipher suites)
- Logging behavior for connections and authentication events
- Patchability impact on connected systems — does an update affect interfaces that the EHR depends on?
- Vulnerability disclosure intake — where a hospital should report a security issue they discover (the CVD policy)
See also: eSTAR v7.0 Cybersecurity for IVDs vs nIVD Submissions, MDS2 / HSCC Disclosure for Medical Devices Explained, and Unresolved Anomalies in FDA Cybersecurity Submissions.
This content also belongs in the MDS2 / HSCC disclosure. The two documents must agree. See MDS2 / HSCC Disclosure for Medical Devices.
Where it sits in eSTAR v7.0
Interoperability labeling lives in the Labeling section of eSTAR v7.0 — the same section that holds the MDS2 disclosure. The Cybersecurity section's Slot 3 (Threat Model) and Slot 6 (Controls) reference it. Specifically:
- Slot 3 — interoperability risk assessment names the connected systems and the trust boundaries; labeling describes the same boundaries in operator language.
- Slot 6 — controls description names the authentication and encryption controls at the interoperable interfaces; labeling describes what the operator needs to configure to support those controls.
For the full slot layout see our eSTAR v7.0 mapping guide.
Common deficiency and post-deployment patterns
FDA side:
- Labeling describes interoperability functionally but omits the cybersecurity expectations of the surrounding systems → AI request for the responsibility boundary
- Labeling and MDS2 disagree on ports, protocols, or authentication → reviewer flags inconsistency
Hospital side:
- Labeling does not state required firewall rules → biomed team has to reverse-engineer them, deployment delayed
- Labeling assumes mutual TLS with no instruction on certificate provisioning → device deployed without mutual TLS, security posture degraded silently
- Labeling does not describe disconnection behavior → first network outage triggers a safety event the manufacturer is asked to explain
How Blue Goat Cyber writes interoperability labeling
We write interoperability labeling as the user-facing view of the Slot 3 interoperability section. Every protocol the device speaks is documented with version, transport, data classes, authentication expectation, and disconnection behavior. The responsibility boundary is stated explicitly, in plain language IT and biomed teams can act on. The labeling is reconciled with MDS2 v3.0 so reviewers and procurement teams see the same answers. Cybersecurity-relevant content cross-references the Slot 6 Controls and the postmarket commitments in the Cybersecurity Management Plan.
If the FDA raises cybersecurity deficiencies after our submission, we resolve them at no additional cost. See our cybersecurity submission services.
FAQ
Is interoperability labeling separate from the device's instructions for use (IFU)?
It can be a separate document or a section within the IFU. The Feb 2026 guidance does not specify the structure, only the content. Most submissions we have seen accepted use a dedicated "Network connectivity and interoperability" section inside the IFU plus a more technical appendix for IT/biomed.
Does interoperability labeling apply to non-networked devices?
Only if the device exposes any interoperability surface — USB import/export, removable storage, paired mobile app, sensor mesh. A truly standalone device with no external interface does not need interoperability labeling, but reviewers expect that to be stated explicitly.
How does this relate to IEEE 11073, HL7, FHIR, DICOM compliance claims?
Compliance claims belong here. State which standards and which versions the device implements, and name the specific profile (e.g., IHE PCD-01 for vital signs, IHE LAB for laboratory results). Reviewers expect specific profiles, not just standards.
Where does AI/ML model integration fit?
If the device sends data to or receives output from an AI/ML model hosted elsewhere (cloud or on-premise inference service), that is an interoperability boundary. Label the protocol, the data sent, the response received, the failure mode if the model is unreachable, and the manufacturer/operator responsibility split. This intersects with PCCP labeling for AI/ML devices.
What's the relationship between interoperability labeling and the MDS2?
The MDS2 is a structured manufacturer disclosure aimed at hospital procurement and cyber teams. Interoperability labeling is the operator-facing narrative. The two cover overlapping territory — connectivity, ports, authentication, encryption — and must agree. Reviewers cross-check.
Does the labeling need to be updated when the connected ecosystem changes?
Yes. New protocol version, new authentication option, new failure mode, changed firewall requirement, deprecated cipher suite — any of those triggers a labeling update. Most manufacturers fold this into the change-control SOP.
Need help with interoperability labeling?
If you are preparing a 510(k), De Novo, or PMA submission for a connected device and need interoperability labeling that reconciles with your threat model, MDS2, and Slot 6 Controls, we will write it. Request a scoping call.
Christian Espinosa — Founder, Blue Goat Cyber. CISSP, ex-military red team. Has written interoperability labeling for more than 250 connected medical devices, including infusion pumps, implantables, IVD analyzers, and SaMD platforms. More on the author.