On this page
Published: · Updated:
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.
Interoperability labeling tells the user how the device connects, what network services and ports it requires, what security controls the operator must configure, and how updates and end of support work. The FDA expects this content in user documentation and referenced from the cybersecurity section of your eSTAR submission.
Published June 11, 2026
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)
Keeping labeling and the MDS2 / HSCC disclosure consistent
Every item above appears twice in your submission: once in user-facing labeling and once in the MDS2 / HSCC disclosure. Reviewers and hospital security teams read both, and a mismatch between them is a deficiency, not a formatting nit. Map each element explicitly before you file:
| Labeling statement | MDS2 / HSCC field it must match | Common mismatch |
|---|---|---|
| Open ports and exposed services | Network ports and services in use | Labeling lists only the clinical port; MDS2 lists the service and debug ports too |
| Authentication requirements per connection | User authentication and remote service authentication | Labeling says "authenticated"; MDS2 discloses a shared service account |
| Encryption in transit (TLS version, ciphers) | Transmission confidentiality and integrity | Labeling claims TLS 1.3; MDS2 admits a TLS 1.2 fallback for legacy EHR interfaces |
| Logging of connection and auth events | Audit controls | Labeling promises audit logs; MDS2 shows logs are local only and not exportable |
| Patchability impact on connected systems | Software patching and remote update | Labeling implies zero downtime; MDS2 states the interface restarts on update |
| Vulnerability disclosure intake | Cybersecurity contact and CVD policy | Two different intake addresses across the two documents |
See also: eSTAR v7.0 Cybersecurity for IVDs vs nIVD Submissions, Unresolved Anomalies in FDA Cybersecurity Filings, and Patch and Update Mechanism Testing.
Practical rule: write the MDS2 first, then derive the labeling language from it. The MDS2 forces a factual answer per field, so deriving labeling from it prevents optimistic labeling claims that the disclosure contradicts. If a control is roadmap rather than shipped, say so in both places with the same wording.
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., ex-military red team. Has written interoperability labeling for more than 275 connected medical devices, including infusion pumps, implantables, IVD analyzers, and SaMD platforms. More on the author.
Related reading
About the author
Christian Espinosa, MBA · Founder & CEO, Blue Goat Cyber
U.S. Air Force Academy graduate and veteran with 30+ years in cybersecurity. Founded Alpine Security in 2014 (acquired 2020), then Blue Goat Cyber in 2022. Has supported 275+ medical devices, with no cybersecurity-related rejections to date. Author of three books including The Smartest Person in the Room. Ironman triathlete and mountaineer.