MQTT Vulnerabilities in Connected Medical Devices: FDA Risks, Controls, and Deficiency Patterns

MQTT shows up in roughly every connected device program we touch — patient monitors phoning home to a hospital gateway, wearable cardiac sensors streaming to a cloud broker, infusion-pump fleets reporting telemetry, and just about every cloud-companion architecture for a Class II SaMD. It is cheap on the wire, easy to implement, and as a result it is also the protocol we see misconfigured most often in cybersecurity deficiency letters.

This post is the working brief we give clients before we threat-model an MQTT-based device for an FDA submission. It is not "what is MQTT." It is what goes wrong, what the FDA will ask about, and what evidence closes the loop.

Key Takeaways

• MQTT vulnerabilities in submissions are almost always design and configuration issues, not protocol bugs.
• The big six: anonymous brokers, weak or absent TLS, broad topic ACLs, retained-message PHI leakage, QoS-2 denial of service, and broker exposure.
• The FDA expects each MQTT-specific threat in your threat model with a mapped safety consequence and a verified control.
• Mutual TLS with per-device certificates is the baseline. Username/password over TLS is no longer defensible for Class II/III.
• Topic ACLs must be derived from the data flow diagram, not from convenience.
• Retained messages and Last Will and Testament payloads are common PHI leakage paths reviewers now look for.

Why MQTT matters for medical-device submissions

MQTT is referenced explicitly in the FDA's February 3, 2026 final premarket cybersecurity guidance as an example of a communication protocol whose security properties must be documented in the security architecture views and security risk assessment. Reviewers do not want a paragraph saying "the device uses MQTT over TLS." They want a threat model entry per asset, the broker's configuration in evidence, and a penetration test that actually exercised the protocol — not a generic TLS scan.

The bar moved with the 2026 guidance for one reason: MQTT brokers keep showing up in postmarket incidents. Shodan-indexed unauthenticated brokers exposing hospital telemetry have become a routine press story. The FDA reads the same news you do.

The six MQTT vulnerabilities that actually generate deficiencies

1. Anonymous or shared-credential broker access

allow_anonymous true is still the Mosquitto default in many container images, and we still find it in submission-ready firmware. The second-worst pattern is a single device-fleet username and password baked into firmware. If one device is extracted and reverse-engineered, the whole fleet is impersonable.

What reviewers cite: lack of per-device authentication, inability to revoke a single compromised device, no binding between device identity and published topics.

Control: mutual TLS with per-device X.509 certificates provisioned at manufacture, with a documented revocation path through your postmarket cybersecurity plan.

2. TLS that is present but not validated

We see this constantly: TLS is on, but the client does not verify the broker's certificate, accepts self-signed certs in production, or pins to a CA that signs anything. The packet capture looks encrypted, the threat model says "TLS 1.2+," and the device is wide open to a man-in-the-middle on hospital Wi-Fi.

What reviewers cite: insufficient evidence of certificate validation in the security testing report; no rationale for cipher suite selection; missing pinning strategy.

Control: TLS 1.3 where the stack supports it, explicit server-certificate validation, certificate or public-key pinning where the operational model allows it, and a documented cipher allowlist tied to the cryptographic protections section of your security risk assessment.

3. Overly broad topic ACLs

The convenient pattern — device/# for read, device/# for write — is the vulnerable pattern. A compromised or impersonated device can read every other device's telemetry and publish commands into other devices' topics.

What reviewers cite: the security architecture view does not constrain which topics a given device identity may publish or subscribe to, and the broker configuration in evidence shows wildcards.

Control: per-device topic ACLs derived from the data flow diagram. A device with identity dev-{serial} may only PUBLISH to telemetry/{serial}/# and SUBSCRIBE to commands/{serial}/#. Enforced at the broker, tested in pen test, and documented in the architecture view.

4. Retained messages and Last Will and Testament leaking PHI

Retained messages persist on the broker until overwritten. Last Will and Testament payloads are delivered to subscribers when a device disconnects ungracefully. Both routinely contain device state, patient identifiers, or session tokens that the design team never intended to persist.

What reviewers cite: insufficient analysis of data at rest on the broker; no PHI handling rule for retained payloads; LWT contents not enumerated in the data flow.

Control: a written rule about what may and may not appear in retained or LWT payloads, enforced in code review and verified in test. PHI does not belong in either.

5. QoS-2 and unbounded queues as a denial-of-service path

QoS-2 (exactly-once) is expensive. An attacker who can authenticate (or a misbehaving device) can publish high-volume QoS-2 traffic and force the broker to maintain large in-flight state per session. Combined with unbounded max_queued_messages, this is a clean DoS against the broker and every device depending on it.

What reviewers cite: no availability analysis for the broker; no rate-limiting; QoS levels not justified in the design rationale.

Control: per-client connection caps, message-rate limits, bounded queues, and a QoS-level rationale in the design — most medical telemetry is fine at QoS-1.

6. Broker exposed beyond its intended trust boundary

The cloud broker is in a VPC. The on-premise gateway broker is on the clinical VLAN. Then someone opens 1883 (or worse, 8883 without client-cert auth) to the internet for a partner integration, and the asset inventory never reflects it.

What reviewers cite: the security architecture view does not show the broker's network position or its exposure; the SBOM lists the broker but no attestation of its hardening.

Control: broker network position documented in the architecture views, broker hardening checklist (disabled listeners, bind to specific interfaces, no anonymous, audit logging on) in evidence, and a postmarket monitoring entry for unexpected broker exposure.

Mapping MQTT threats into the threat model

For an FDA submission, every one of the issues above needs a row in your threat model with the following columns reviewers expect to see:

• Asset / data flow — which MQTT topic, which direction, which device class.
• Threat (STRIDE) — spoofing for shared-credential access, tampering for missing TLS validation, information disclosure for retained-message leakage, denial of service for QoS-2 abuse, elevation of privilege for broad ACLs.
• Safety consequence — mapped through your ISO 14971 risk file. A spoofed infusion-pump command is not the same harm as a leaked battery-level telemetry.
• Control — the specific cryptographic, ACL, or architectural mitigation.
• Verification — the pen test case, unit test, or configuration audit that proves it.

If you do not already have this structure, our STRIDE threat modeling guide for medical devices walks through it, and the threat model template gives you the column layout reviewers accept.

What the penetration test should actually do

A TLS scanner against port 8883 is not a penetration test of MQTT. The test plan reviewers respect includes:

• Connecting with no credentials, expired credentials, and another device's credentials, and confirming each is rejected.
• Attempting to publish to and subscribe from topics outside the device's ACL scope.
• Sending malformed CONNECT, PUBLISH, and SUBSCRIBE packets — there is a long history of broker memory-corruption CVEs (Mosquitto, EMQX, HiveMQ) and your version needs to be tested, not just listed in the SBOM.
• Replaying captured packets to confirm packet-level anti-replay where the design claims it.
• Stress testing QoS-2 and large retained payloads to validate the availability controls.
• Capturing traffic on a hostile network to confirm certificate validation actually fails the handshake.

The report should land in the pen test section of your premarket package with method, evidence, and a remediation status for every finding.

Deficiency patterns we see in real letters

Anonymized from cybersecurity deficiency letters we have responded to in the last 18 months:

• "The submission does not describe how the device authenticates to the cloud broker or how broker identity is validated by the device. Provide the authentication scheme, certificate management approach, and evidence of validation."
• "The security architecture views do not enumerate the topics published or subscribed to by the device, nor the access control rules enforced by the broker."
• "The risk analysis does not address denial-of-service against the broker as a hazard contributing to loss of essential clinical performance."
• "Provide evidence that retained messages and Last Will and Testament payloads do not contain protected health information."

Every one of these is closeable inside the 180-day response clock if the underlying design is sound. They are not closeable if the broker really is allow_anonymous true and someone has to ship a firmware change first. That is the whole argument for getting MQTT right before submission, not after.

What to put in your submission

A short, opinionated checklist:

1. Architecture view showing the broker, its network position, the trust boundary it sits on, and every device that connects to it.
2. Data flow with one row per MQTT topic, direction, payload class, and PHI flag.
3. Threat model rows covering the six issues above, each mapped to a safety consequence and a verified control.
4. Broker configuration in evidence — actual configuration file or hardening attestation, not a screenshot.
5. Per-device certificate provisioning and revocation procedure in the postmarket plan.
6. Pen test report that exercised the protocol, not just TLS.
7. SBOM entry for the broker and client library, with VEX statements for any known CVEs.

If those seven artifacts are present and consistent with each other, MQTT-specific deficiencies become rare. When they are not, MQTT is one of the easiest things for a reviewer to pick a thread on.

Related reading

• STRIDE threat modeling for medical devices
• FDA-grade threat model template
• Penetration testing scope for FDA submissions
• Security risk assessment under IEC 81001-5-1
• FDA cybersecurity deficiency letter response playbook