Security Review of IEEE 11073 SDC Medical Device Standards

SDC is deployed in environments where devices from different manufacturers share the same network and exchange safety-critical data. Security in such an environment cannot rest with any single vendor but must be Secure by Design and thus must be defined by the standards themselves. This post assesses how the current SDC standards family addresses that. Starting from the MDPWS technology stack, the security controls defined across [MDPWS], [GLUE], and [BPKP] are examined against the four security attributes BICEPS requires of any binding: confidentiality, integrity protection, accountability, and authorization. The assessment identifies two areas where the lack of standardization directly affects cross-vendor interoperability: the absence of a harmonized cryptographic profile and the lack of a standardized trust and identity framework. Further open topics, including the security of UDP-based discovery and time synchronization, do not block interoperability but remain unaddressed at the standard level.

Disclaimer: I am leading the working group Certificate infrastructure and security under the OR.NET association. Thanks to my co-chair Dominik Stegemann from SurgiTAIX AG for reviewing this post. This post solely reflects our personal views.

What is Medical Service-oriented Device Connectivity? #

Modern operating rooms and intensive care units are filled with devices from different manufacturers (infusion pumps, patient monitors) all working side by side but unable to communicate and exchange data in a vendor-neutral way. That’s where Service-oriented Device Connectivity (SDC) comes into play.

The standard family SDC, standardized as part of IEEE 11073, defines how medical devices and services can discover each other, exchange data, and safely coordinate functions over IP-based networks without requiring proprietary middleware. The goal is plug-and-play interoperability of safety-critical devices that scales across vendors and use cases to build a Service-Oriented Medical Device System (SOMDS) that is safe, effective, and efficient.

Introduction to SDC #

IEEE 11073 standards family overview #

SDC is defined by a family of standards all subsumed under IEEE 11073. The different parts can be broadly categorized into three standard layers:

1. Core Standards: These define how devices communicate, discover each other, and exchange data securely. Key components include:
   • Part 20702: The transport protocol, also known as Medical Devices Profile for Web Services (MDPWS),
   • Part 10207: The data and message model for point-of-care medical devices, also known as Basic Integrated Clinical Environment Protocol Specification (BICEPS),
   • Part 20701: The integration architecture (sometimes called the glue standard).
2. Participant Key Purposes (PKPs): PKPs define the roles devices play in the network (like sending metrics or reacting to alarms) and the responsibilities that come with those roles.
   • Part 10700: Defines SDC Base Provider and SDC Base Consumer
   • Part 10701: Defines SDC Metric Consumer and SDC Metric Producer
   • Part 10702 (Alert) and Part 10703 (External Control) are still under active development and not yet released.
3. Device Specializations (DevSpecs): These tailor the standards to specific device types, such as endoscopic cameras or surgical tools, ensuring consistent behavior and interoperability. These standards are still under development.

To visualize this layered architecture and to show the relationships between BICEPS, MDPWS, and device specializations, the so-called SDC Cathedral Window exists:

Relation to IHE/HL7 SDPi #

The IHE Service-oriented Device Point-of-care Interoperability (SDPi) profiles act as the bridge between the technical core of the IEEE 11073 SDC standards and their practical application in clinical environments. While the IEEE standards define the “how” of device communication and data modeling (such as BICEPS and MDPWS), SDPi provides the “what” and “where” by profiling the IEEE standards for specific medical use cases. This also includes requirements that further define security relevant requirements.

This includes narrowing down implementation options to ensure true plug-and-play interoperability across different vendors and integrating SDC with the broader health IT ecosystem, such as HL7 FHIR-based systems.

For this analysis, none of the SDPi requirements are considered but only referenced for completeness when applicable.

Technology stack overview #

Before moving to the security analysis, let’s build a common understanding of the technology stack powering SDC. The SDC data model (i.e., BICEPS) is technology-agnostic and several so-called BICEPS bindings can exist. Today, the only standardized technology stack is defined in [MDPWS]. Together with [GLUE], they form a complete technology stack.

The approach described therein adopts a SOA model where devices operate as service providers or service consumers, interacting through well-defined service interfaces. As such, aspects defined in OASIS’s SOA Reference Model are also found in the design of SDC. In addition, Devices Profile for Web Services (DPWS) is an integral part of the stack.

At the core, this approach uses SOAP (Simple Object Access Protocol) over UDP and HTTP to structure and exchange messages between devices. The service interfaces are defined through WSDL (Web Services Description Language). Data is encoded using XML and XML Schema is used to define and validate data. In addition, [MDPWS] defines usage of the following messaging technology:

• WS-Discovery for automatic service discovery on the network. Two modes are available requiring different transport protocols:
  • Ad hoc mode over IP multicast using SOAP-over-UDP.
  • Managed mode over IP unicast using SOAP-over-UDP.
• WS-Eventing: Publish/subscribe event communication using SOAP-over-HTTP.
• Streaming: A mechanism to announce a stream that continuously delivers data over IP network. The actual streaming technology is explicitly not specified but is left open to meet use case specific requirements. Examples include:
  • SOAP-over-UDP using IP multicast
  • RTSP, RFC 2326

Although streaming is defined in MDPWS, there is no practical agreed on approach for a specific use case.

Besides the SOA stack, an SDC participant should support Network Time Protocol (NTP, RFC 5905) and Differentiated Services (DiffServ, RFC 2474) for accurate time synchronization and prioritized network traffic [GLUE].

As mentioned before, the SDC domain model is technology-agnostic and other transport implementations are possible. A promising approach is protoSDC. This project aims to introduce Protocol Buffers (also known as Protobuf) and gRPC as a transport and messaging protocol for SDC. The working group RT-SDC of the OR.NET association also aims to combine SDC and Data Distribution Service (DDS), in particular its real-time publish and subscribe pattern (RTPS). Both proposals are still in active development and not further considered here.

The following analysis solely focuses on the MDPWS stack.

Analysis of standardized security in SDC #

After a brief introduction to the MDPWS technology stack, let’s review the security properties and controls. The base security requirements for BICEPS bindings, i.e., what the MDPWS binding must fulfill, are defined in [BICEPS] and mandate that the data exchange must be

• confidential (R0087),
• integrity protected (R0088),
• accountable (R0089),
• and authorized (R0083).

To satisfy these requirements on a technical level, the security requirements defined in [GLUE] and [MDPWS] are relevant. These in turn import security requirements from several other standards including:

• WS-I Basic Profile V2.0, Section 7 (Security)
• OASIS DPWS V1.1, Section 6
• OASIS WS-Discovery, Section 8 (Security)
• IETF RFC 5246 - TLS 1.2

Of these, the majority of foundational security requirements are found in OASIS DPWS. Furthermore, [BPKP] is essential to satisfy BICEPS’ accountability attribute.

The following sections provide a high-level overview of the security controls derived from the above standards.

Transport layer security #

As outlined before, MDPWS uses several messaging mechanisms collectively based on SOAP-over-HTTP, SOAP-over-UDP, and support protocols. Analysis of these is covered in the following subsections.

SOAP-over-HTTP #

Communication for SDC participants and relevant services makes great use of unicast HTTP over SOAP, which in turn relies on TCP. To secure this traffic, DPWS defines that a TLS Secure Channel shall be used to secure communication between a client and service. To prevent downgrade attacks, R0063 explicitly prohibits the use of SSL or TLS versions below 1.2 and R0064 requires participants to use the highest TLS version available [GLUE]. Furthermore, TR0216 requires the logging of TLS session details, such as the negotiated cipher suite and TLS version, for audit and forensic analysis [BPKP].

With TLS, asymmetric and symmetric cryptographic primitives are required in specific configurations. Those are commonly referred to as cipher suites. To communicate securely, both TLS endpoints must agree on a cipher suite during the TLS handshake. The core standards do not specify any cipher suite configuration; however, the imported standards do. To gain a holistic view, the following sources are considered:

• OASIS DPWS v1.1: Directly imported in [MDPWS].
• TLS 1.2 (RFC 5246): Directly imported in [GLUE].
• TLS 1.3 (RFC 8446): Implicitly imported since GLUE:R0064 requires using the highest TLS standard which is 1.3 as of today (SDPi:R1544 explicitly requires TLS 1.3).

With that, the following cipher suite configurations, along with a security classification of each cipher suite (Insecure, Weak, Recommended), are derived. They are additionally categorized into MUST and SHOULD support, as well as banned ones:

• DPWS v1.1, section 6.6.1:
  • MUST: TLS_RSA_WITH_RC4_128_SHA (Weak, leans towards insecure)
  • SHOULD: TLS_RSA_WITH_AES_128_CBC_SHA (Weak)
  • Bans:
    • TLS_RSA_WITH_NULL_SHA (Insecure)
    • SSL_RSA_WITH_NULL_SHA (Insecure)
    • any cipher using MD5 (all MD5 ciphers are insecure)
    • any cipher using DH_anon (all DH_anon are insecure)
• TLS 1.2, section 9:
  • MUST: TLS_RSA_WITH_AES_128_CBC_SHA (Weak)
  • SHOULD: Not stipulated.
  • Bans: Not stipulated.
• TLS 1.3, section 9:
  • MUST support TLS_AES_128_GCM_SHA256 (Recommended)
  • SHOULD support
    • TLS_AES_256_GCM_SHA384 (Recommended)
    • TLS_CHACHA20_POLY1305_SHA256 (Recommended)
  • Bans: Not stipulated.

Other requirements or recommendations for hardening TLS endpoints are not found. It is left to the manufacturer to document supported cryptographic protocols (BPKP:DR1579) though it remains unclear if this includes cipher suites, RSA key lengths, or ECC curves.

SOAP-over-UDP #

Some aspects of SDC rely on SOAP over UDP using multicast communication. TLS is not suitable for securing UDP traffic but Datagram Transport Layer Security (DTLS, see DTLS 1.2) is. Though, the SDC standards and none of the imported standards specify usage of DTLS.

Instead, OASIS DPWS requires that the UDP discovery traffic is secured using the Compact-Signature format (DPWS:5011). The cryptographic primitives standardized herein use xml-exc-c14n encoding to generate constant digests using SHA1, which are then used with the RSA-SHA1 signature scheme. SHA1 and RSASSA-PKCS1-v1.5 are both algorithms no longer recommended for new applications. Furthermore, there are hints that this signature format is not implemented by SDC stacks.

The other documented use case for SOAP-over-UDP is streaming. Though, none of the SDC standards define security controls for this use case.

Network Time Protocol (NTP) #

The requirement GLUE:R0007 mandates support of NTP. Correct time settings for SDC participants are important for

1. any certificate validation (e.g., for TLS-based communication)
2. as well as for SDC data exchange defined in the PKPs (e.g., metrics and alarming).

Core NTP is a protocol that does not use TLS and is based on plaintext transport. Over the years, security extensions have been defined, and the more recent ones are based on:

• symmetric key authentication with a CMAC-based MAC or
• asymmetric authentication called NTP Autokey.

Both approaches have their challenges and eventually lead to the development of Network Time Security (NTS) standardized in RFC 8915.

Though, no document in the SDC space explicitly states any security mechanisms for NTP or usage of NTS as a secure alternative. However, abrupt time changes (TR1340) SHALL be logged together with the initial time source and any ongoing time source changes (TR0916) [BPKP].

Authentication and authorization with X.509 Certificates #

According to MDPWS:R0017, the sender must authenticate itself to the receiver and GLUE:R0074 requires an SDC participant to avoid unacceptable risk based on the certificate and its certificate chain. Additionally, TR1164 states that a base provider must protect all of its BICEPS services against unauthenticated access using secure channels [BPKP]. DPWS allows HTTP Basic Auth as well as TLS client certificates (mTLS) for authentication (DPWS:4071) but MDPWS:R0016 explicitly disallows HTTP authentication for all communication between SDC participants. With that, the core of the authentication mechanisms for communication partners relies on mTLS for SOAP-over-HTTP.

With mTLS being used, it comes as no surprise that SDC in turn relies on X.509v3 certificates (see also DPWS:R4045) and every participant must have its own, unique certificate (DPWS:R4043). Using information from the certificate and the certificate chain to restrict access to functions and data is explicitly stated by GLUE:R0075.

An X.509v3 certificate requires an asymmetric key pair and ownership of the private key allows proving ownership of an identity. With this, there is the risk of identity theft when the private key is compromised. The standards do not explicitly mandate any security controls to protect the private key but only BPKP:RR1139 states that the manufacturer shall consider the risk of private key compromise. This leaves it to the manufacturer to implement security controls for private key protection.

Details on the SDC participant certificates are defined in [GLUE] and summarized in the following.

Subject Common Name #

As per GLUE:R0045, the certificate’s Common Name (CN) should be derived using a namespaced UUIDv5 from the device’s primary UDI. The primary UDI is defined as the first element in the pm:MdsDescriptor/pm:MetaData/pm:Udi element which [BICEPS] defines:

UDI fragments as defined by the FDA.

A UDI is a special identifier for medical devices and the concepts are based on the work of the International Medical Device Regulators Forum. With that, it is not only known by the FDA but is also defined within the EU MDR, Annex VI Part C. The actual MDR and FDA accredited UDI system is the GS1 UDI Systematic.

A UDI is typically only assigned to medical devices (either hardware device or software as a medical device). If an SDC participant is not classified as a medical device, it remains unclear what to use instead. In addition, the requirement is a should requirement, so not any participant necessarily has to use it at all.

Nevertheless, if the participant has a UDI, the UDI is not used as is for the CN but is instead encoded using UUIDv5:

CN=uuidv5(udiNamespace, udiHumanReadableForm)

Where

• udiNamespace is different depending on the organization issuing the UDI:
  • fda-udi: 6F8C705D-3A57-5736-A501-972E826947E8
  • eu-udi: 99A295DD-8C45-52B2-8AF8-1C584FC4CDEE
• and udiHumanReadableForm is the UDI representation as printed beneath the barcode on the physical label, e.g. (01)<AI01Content>(21)<AI21Content> (in GS1 terms, this is called the element string syntax)

Example taken from [GLUE]: A device with the FDA-UDI (01)00884838038752(21)DE35115712 has the common name 845754B1-8934-51D7-9EA1-203FB7A8B1B9 which is derived as follows:

uuidv5("6F8C705D-3A57-5736-A501-972E826947E8","(01)00884838038752(21)DE35115712")

During standards writing, there seemed to be uncertainty if a UDI will be globally unique across different regulatory regions. To avoid any collisions, the name-spaced approach guarantees that the CN is globally unique with the downside of being obfuscated to some extent.

Extended Key Usage #

As stated in the beginning, the SDC standards family has the notion of PKPs to define a participant’s roles. Per R0052, those PKPs shall be encoded in the Extended Key Usage (EKU) field of the certificate. R0051 states that the EKU may be used to restrict sensitive operations like remote control [GLUE]. The following EKU OIDs are standardized:

• IEEE 11073-20701-2020 [GLUE]
  • SDC SERVICE PROVIDER: 1.2.840.10004.20701.1.1
  • SDC SERVICE CONSUMER: 1.2.840.10004.20701.1.2
• IEEE 11073-10700-2022 [BPKP]
  • SDC BASE PROVIDER PKP: 1.3.111.2.11073.10700.1.1.1
  • SDC BASE CONSUMER PKP: 1.3.111.2.11073.10700.1.2.1
• IEEE 11073-10701-2022:
  • SDC METRIC PROVIDER PKP: 1.3.111.2.11073.10701.1.1.1
  • SDC METRIC CONSUMER PKP: 1.3.111.2.11073.10701.1.2.1

Besides the standardized EKUs, non-standard EKUs can be used as per requirement GLUE:R0053. Those include manufacturer defined EKU.

While the PKP mechanism enables basic role-based access control, it does not allow an SDC administrator to explicitly authorize two participants to communicate with a specific set of roles. As of today, there is no concept of a centralized authorization server allowing an SDC Administrator to centrally manage allowed communication partners. BPKP:RR1135 transfers the risks of unauthorized SDC participants in an SDC network to the manufacturer, leading to manufacturer-specific solutions (e.g., whitelist approach configured via participant specific functions).

Security Assessment #

After describing the technological foundation of SDC and specifically MDPWS as well as existing approaches and security requirements, let’s structurally work through the security aspects. First, we analyze MDPWS’ compliance with the BICEPS required security attributes. Second, we examine aspects in depth where security standardization affects interoperability.

BICEPS security compliance #

We started with BICEPS requiring fundamental security attributes for a BICEPS binding in terms of confidentiality, integrity protection, accountability, and authorization [BICEPS]. To structure this analysis, we extend the BICEPS security attributes as follows:

• Confidentiality and integrity protection is complemented by availability (i.e., CIA).
• Accountability and authorization are typically considered together with their supporting pillars identification, authentication, and auditing.

Although these extended attributes are not explicitly stated in BICEPS, requirements for them are found in the SDC standards. We summarize these attributes in the following based on the security controls that are mostly found in [MDPWS], [GLUE], and [BPKP].

CIA Pillars #

First, we consider the CIA pillars:

• Confidentiality is achieved through the mandatory use of TLS for all SOAP-over-HTTP communications. However, confidentiality does not exist for WS-Discovery as it is defined in the SDC core standards. That said, [SDPi] introduces the managed discovery option in the SDPi-P Profile for secure and non-multicast discovery across the network. Time-sync via NTP is not secured and a secure SDPi alternative is not available.
• Integrity of communication is ensured where TLS is in use. For WS-Discovery in ad hoc mode, a Compact-Signature format should be used to protect the discovery traffic but its adoption status as part of MDPWS is unclear. Likewise, no integrity protection mechanisms for NTP communications are defined. While confidentiality might not be required for discovery and time-sync traffic, missing integrity protection can lead to security issues (e.g., influencing participant’s time to maliciously bring back an expired certificate into trust).
• For Availability, only BPKP:TR1134 points out that non-network-related clinical functions must be protected and not be affected by any network communication and explicitly mentions network flooding situations (e.g., ARP, ICMP floods). As no recommendations can be found in the standard, the manufacturer has to consider the risks and derive their own countermeasures such as firewalls or rate-limiting.

Extended AAA Pillars #

Before the BICEPS security attributes accountability and authorization are considered, the newly introduced supporting attributes are summarized:

• Identification is based on device-unique X.509v3 certificates tied to a device’s UDI. The UUIDv5 encoding produces a globally unique string, but one that no longer matches the UDI printed on the physical label, which complicates manual verification.

  UDIs are assigned to medical devices only. For participants without a UDI (such as data loggers or gateways representing multiple devices [SDPi]), no primary identifier is specified, leaving the certificate’s CN as the only available reference. BICEPS is also internally inconsistent on this: certain requirements (e.g., GLUE:R0078) reference the certificate’s CN as an identifier without defining an expected format. For strong device and participant identity, a consistent identification scheme is a prerequisite for reliable auditing and accountability.

  Private key protection is left entirely to the manufacturer’s risk assessment (BPKP:RR1139) and no baseline is defined across the ecosystem. There is no control in the standard requiring hardware-based secure elements (e.g., Trusted Platform Module (TPM)) for specific identity types. In a multi-vendor network, the protection level of each participant’s private key depends on individual manufacturer decisions.

• Authentication for TLS-based communication is performed via mutual TLS. HTTP Basic Authentication is explicitly disallowed. For WS-Discovery in ad hoc mode and for NTP, no authentication schemes are defined. When using the proxy as defined in SDPi-P, authentication is given again.

• Auditing is required for SDC message exchanges (TR0216), unauthorized services access (TR0217), time source (TR0916) and large time adjustments (TR1340). A participant must offer an audit log export in syslog format (TR0225, DR1601) [BPKP].

Based on these three attributes, let’s consider the remaining two BICEPS basic security attributes:

• Authorization is based on the authenticated participant using mTLS and the participant’s certificate. SDC does not support a fine-grained centralized authorization server but uses the static participant role information encoded in the certificate’s EKU field. To further constrain a participant’s allowed peers, the certificate chain or other manufacturer-specific approaches (e.g., local whitelists) can be used. There is no standard support for a more dynamic fine-grained authorization approach. This lack of sophisticated authorization approaches leads to isolated and non-interoperable authorization approaches in an SDC network.

  The Zero Trust principle, which requires explicit, continuous verification of every participant before granting access, is not achievable within the current SDC authorization model.

• Accountability is enabled through audit log events and a tamper-protected log export (BPKP:TR0229). The standard requires this protection but does not specify how it should be implemented. Digital signatures and standardized signing formats are not addressed. Log entries for actions triggered by another participant must include that participant’s certificate CN.

  What can be expected in the CN is not defined, which limits how reliably a log entry can be traced back to a specific device or software instance.

Overall, only when all three standards [MDPWS], [GLUE], and [BPKP] together with the standards they import by reference are collectively considered, the required BICEPS security attributes are satisfied. Every standard adds requirements for a new BICEPS required security attribute or additionally extends an attribute that has been introduced in a previous standard. [SDPi] adds another source of security requirements and concepts on top. A comprehensive and consistent write-up of security controls giving a clear picture is needed to avoid inconsistencies and misunderstandings.

All SOAP-over-HTTP communication is secured with TLS but other support protocols (like NTP) are not. Discovery traffic is not protected as specified in the SDC standards but requires the SDPi-P Profile to be supported in an SDC Network. The core BICEPS message exchange happens over secured TLS channels. Mitigations against disclosure and alteration of that data in transit stand on sound grounds. Through AAA services, non-repudiation for BICEPS messages is achieved to a certain extent, although a standardized identity is not granted and if a device has a UDI, it should be obfuscated via a UUIDv5 encoding.

Crypto Agility and Interoperability #

Cryptography and cryptographic primitives are required in SDC for

• establishing TLS sessions and
• to verify a certificate and its chain as part of the TLS handshake.

With TLS, asymmetric and symmetric cryptographic primitives are required in specific configurations (i.e. a cipher suite). Both ends of a TLS session need to mutually agree on a cipher suite. If they cannot agree, the session cannot be established. The list of possible cipher suites - especially with TLS 1.2 - is enormous and also many insecure combinations exist. Considering that SDC was developed with constrained medical devices in mind, implementing all secure ones is impossible and might have impacts on the performance of the device. For example, if a device has no hardware acceleration for AES, using ChaCha20Poly1305-based ciphers might be preferred. In addition, having cipher suites standardized with distinct cryptographic primitives is a prerequisite for cryptographic agility: The ability to swap in different algorithms once a primitive has become weaker or broken, without requiring uncoordinated changes across every device in the network (for more information consider RFC7696 and NIST’s considerations on crypto agility).

However, in the SDC space, there are no lists requiring, allowing, or banning specific cipher suites. A possible list can only be derived from SDC referenced standards like done before. However, this analysis showed that, excluding TLS 1.3, not a single recommended cipher suite is required but only weak ones using insecure SHA-1 and non-ephemeral key exchanges lacking forward secrecy. This bears the risk of downgrade attacks to TLS 1.2 leading to weakly secured TLS sessions. Fortunately, TLS 1.3 is strict on allowed cipher suites and only allows those that are considered secure as of today. It is up to the participant manufacturer to follow guidelines – like the ones from NIST, BSI or the IETF (RFC7525) – to harden the TLS configuration.

Likewise, verifying certificates and their chain requires verifying digital signatures. Signature schemes at least differ between the two major crypto systems RSA and ECC (not to speak of any PQC algorithms) which in turn differ in RSA modulus sizes (also known as key length) and elliptic curve parameters. For every certificate in a potentially long certificate chain, a different signature scheme might be required for verification. To limit the implementation effort for an SDC participant, an agreed-on list of signature schemes would be beneficial. Though, it is the same as for the cipher suites: There are no agreed-on lists of required, allowed, or banned signature schemes.

This matters beyond today’s algorithms: with Post-Quantum Cryptography (PQC) migration now becoming a concrete planning requirement across industries, the absence of a defined baseline means SDC has no specified path to transition away from RSA and ECC when quantum-resistant algorithms become mandatory.

While this lack of standardization can potentially lead to security issues, the greater risk is impaired interoperability between different SDC participants. To address these problems, a TLS profile is required to standardize and harmonize allowed cryptographic primitives and their configuration for the SDC space. A similar approach is documented in the draft for the TLS/DTLS 1.3 IoT Profile.

Standardized Trust and Identity Framework #

While SDC mandates the use of X.509v3 certificates for participant authentication and capability declaration, there is no standardized PKI infrastructure or a PKI concept in the SDC space. In addition, the operational process by which these certificates and their associated trust anchors are distributed and maintained is entirely unspecified. This includes:

• How trust is established across SDC participants and SDC network operators,
• When and how SDC participant certificates are provisioned,
• When and how trust anchors (e.g. root CA certificates) are installed and updated,
• Whether participants validate certificate revocation status and how (e.g. CRLs, OCSP).

The absence of standardized trust models, trust anchor distribution, and certificate lifecycle management (CLM) leads to inconsistent and fragile deployments susceptible to outages due to expired certificates. Manual provisioning of trusted certificates does not scale and increases the risk of misconfiguration or stale trust stores.

In scenarios involving multiple manufacturers, third-party service providers, or dynamic onboarding of devices, the lack of a managed trust establishment framework poses operational and security challenges. Without clear procedures and protocols for managing trust relationships across the network, the foundational assumptions of mutual authentication and role-based authorization become hard to manage.

Other industry standards that deal with the challenge to establish trust between different entities from heterogeneous manufacturers exist. These include:

• The Matter PKI most commonly known for smart home appliances in the consumer space.
• The Smart Metering PKI for securing the communication between different entities in the German energy sector.
• The Vehicle-To-Grid (V2G) PKI Use Cases to enable trust between electric vehicles and electric charging stations (see Hubject PKI Infrastructure)

All three frameworks share structural elements that SDC currently lacks. Each defines a formal PKI hierarchy with named roles (root CA, sub-CA, device certificate) together with a certificate policy specifying what each certificate asserts about its holder. SDC has neither. Automated enrollment protocols such as EST and CMPv2 handle certificate provisioning and renewal without manual intervention. And each framework provides a cross-manufacturer trust federation mechanism: Matter uses a Distributed Compliance Ledger, V2G uses a centrally operated root CA structure, and Smart Metering defines a Sub-CA hierarchy per operator.

SDC currently leaves cross-manufacturer trust to bilateral agreements or manufacturer-specific whitelists. A certificate policy, standardized enrollment protocols, and a federated trust root structure would close these gaps without requiring changes to the BICEPS application layer.

Conclusion #

The IEEE 11073 SDC standards provide a coherent security foundation for service-oriented medical device communication. Examining the controls across [MDPWS], [GLUE], and [BPKP] against the BICEPS security attributes shows that the core requirements are covered. Mutual TLS authentication for the primary service communication, mandatory X.509v3 certificates, EKU-based encoding of Participant Key Purposes (PKPs), and auditability requirements form a good cybersecurity baseline. While TLS is mandatory for SOAP-over-HTTP communication, UDP-based discovery traffic does not benefit from equivalent channel protection, and time synchronization mechanisms such as NTP are not normatively secured within the SDC framework. Addressing these support protocol gaps is a Secure by Design requirement that the standards have not yet fulfilled.

The main interoperability challenge is not the lack of security mechanisms, but the lack of harmonized operational profiles and governance structures. TLS is required, but no concrete cryptographic profile is defined — leaving cryptographic agility and a migration path to PQC unaddressed. Certificates are mandatory, yet CLM, cross-manufacturer trust federation, and clear mandatory identity schema are not standardized. As SDC moves beyond bilateral integrations toward broader, multivendor ecosystems, a coordinated TLS profile, a clearly defined PKI trust framework, and a consistent approach to identity and authorization aligned with Zero Trust principles will be necessary to avoid fragmentation. Strengthening these areas helps SDC be practical and secure at scale. Addressing these gaps supports realizing a secure, vendor-neutral “Plug-and-Trust” environment and unlocking the full potential of service-oriented medical device systems in tomorrow’s caregiving environments.

This analysis serves as an introduction to SDC security, forming the basis for a series of articles. Future analysis could explore various specialized areas, such as threat modeling for SDC participants or the evaluation of newly emerging standards and protocols. Likewise, MDPWS is based on XML giving rise to a complete consideration of XML security requirements and secure parser settings. Though, the breadth of these topics warrants a dedicated write-up to ensure a comprehensive treatment.

Sources #

[BICEPS] Health informatics–Point-of-care medical device communication Part 10207: Domain Information and Service Model for Service-Oriented Point-of-Care Medical Device Communication, IEEE 11073-10207-2019, 2019.

[BPKP] Point‐of‐Care Medical Device Communication—Standard for Base Requirements for Participants in a Service‐Oriented Device Connectivity (SDC) System, IEEE 11073-10700-2022, 2023.

[DPWS] Devices Profile for Web Services Version 1.1, OASIS Standard, 2009, available at https://docs.oasis-open.org/ws-dd/dpws/wsdd-dpws-1.1-spec.html.

[GLUE] International Standard for Health informatics–Device interoperability–Part 20701: Point-of-care medical device communication–Service oriented medical device exchange architecture and protocol binding, IEEE/ISO/IEC 11073-20701-2020, 2020.

[MDPWS] Standard for Health informatics–Point-of-care medical device communication Part 20702: Medical Devices Communication Profile for Web Services, IEEE 11073-20702-2016, 2017.

[SDPi] IHE Service-oriented Device Point-of-care Interoperability, Revision 2.2.1, available at https://profiles.ihe.net/DEV/SDPi.