Skip to main content

Case Study: Baxter Connex Spot Monitor Shared Key (2024)

Why This Case Matters​

This case is a clean example of a shared failure domain. A shared or default cryptographic key is not device identity; it means compromise or discovery of one key can affect many devices, configurations, or update paths.

What Happened​

In May 2024, CISA published an advisory for the Baxter Welch Allyn Connex Spot Monitor. The advisory describes a use of default cryptographic key vulnerability, tracked as CVE-2024-1275, affecting versions 1.52 and prior.

CISA reported that the impacted product used a default cryptographic key for potentially critical functionality. An attacker could potentially modify device configurations and firmware data, with possible impact or delay in patient care. Baxter made an updated version available and recommended upgrading, applying network and physical security controls, and ensuring a unique encryption key is configured.

What Failed​

  • A default key created a shared trust anchor across affected devices.
  • Device configuration and firmware-related trust depended on key material that was not unique enough for the product risk.
  • Key provisioning and configuration evidence was not sufficient to prevent or detect a shared-key condition before release.
  • Customers needed mitigation guidance to configure unique keys and reduce exposure.

Secure-by-Design Lessons​

LessonWhat product teams should do
Device identity must be uniqueProvision each device with unique identity material tied to the device, product, or deployment context.
Shared keys create shared failuresAvoid default or common cryptographic keys for critical functionality.
Provisioning must be auditableRecord how keys and certificates are generated, injected, protected, rotated, and verified.
Update authorization must be separate from device secretsFirmware signing should rely on well-controlled manufacturer signing keys and robust device verification.
Customer configuration mattersIf users must configure unique keys, document that clearly and retain evidence that the product can enforce or verify it.

Evidence That Should Exist​

EvidenceWhy it matters
Device identity designShows how devices are uniquely identified and authenticated.
Key-management designShows which keys exist, what they protect, where they are stored, and how they are rotated.
Manufacturing provisioning recordsShows unique identity material is generated and applied correctly.
Hardware key-protection evidenceShows private or secret material is not extractable or hard-coded in firmware.
Update authorization designShows firmware and configuration changes are authenticated and integrity-checked.
Release verification evidenceShows production firmware and configuration do not contain shared default keys for critical functions.
Customer mitigation recordsShows affected users were told how to update or configure unique keys.

What Product Teams Should Check​

  • Do any devices share the same cryptographic key, credential, certificate, or token?
  • Are any default keys used for critical functions after manufacturing or first boot?
  • Can the product detect, reject, or warn about default key material?
  • Can manufacturing, service, or customer tooling prove that production devices are no longer using default key material?
  • Are firmware updates signed with manufacturer-controlled signing keys and verified on the device?
  • Are provisioning records tied to device serial numbers, hardware revisions, firmware versions, and release batches?
  • Could we identify which devices are affected if key material or provisioning evidence is questioned?

Sources​