Blog · Healthtech · 16-min read
Secure architecture patterns for medical device connected apps
Skip to content
Last substantive review: August 2026.
A connected medical-device product is a system, not a device plus an app. Code and commands can cross firmware, Bluetooth or USB, a mobile or desktop client, cloud APIs, support consoles, update infrastructure, and manufacturing systems before they affect the user. A secure architecture has to follow that complete path. Securing only the companion app leaves the most important trust decisions implicit.
This article provides engineering guidance. It is not regulatory certification, legal advice, a claim of FDA approval, or a substitute for a manufacturer's quality system, safety process, regulatory strategy, or independent assessment. Device classification, submission obligations, and compliance conclusions should be made by the manufacturer with qualified regulatory and legal advisers.
The current FDA reference is the February 2026 medical-device cybersecurity guidance, which superseded the June 2025 edition. It discusses device design, labeling, premarket documentation, security risk management, architecture views, testing, and section 524B cyber-device considerations. The guidance itself contains nonbinding recommendations, while section 524B includes statutory requirements for covered cyber-device submissions. An engineering team should keep those categories separate.
Begin with a global system view that an engineer, safety lead, and reviewer can all follow. It should identify every asset that stores, transforms, signs, or relays code, data, identity, or a command:
Mark trust boundaries where ownership, privilege, protocol, physical control, or threat assumptions change. Do not draw “the cloud” as one trusted box. A public API, an internal command service, the release-signing system, and a support console have different identities and consequences. Do not draw the phone as trusted merely because the manufacturer shipped the app. Phones can be shared, rooted, restored from backup, offline for long periods, or controlled by malware.
| Boundary | Design question | Evidence to keep |
|---|---|---|
| Device ↔ local app | How are both endpoints authenticated, paired, revoked, and protected from replay? | Pairing flow, key lifecycle, protocol tests, recovery behavior |
| App ↔ cloud | Which user, tenant, device, and action does each request represent? | Authorization policy, token scope, audit events, negative tests |
| Cloud ↔ device | Can a cloud command exceed the device's local safety authority? | Command allowlist, device-side validation, rate and replay controls |
| Release system ↔ fleet | How is an update authorized, verified, staged, interrupted, and recovered? | Signing controls, update architecture, rollout and rollback tests |
| Support ↔ customer system | What can a technician inspect or change, and who approves it? | Role matrix, step-up authentication, session and change logs |
FDA's guidance recommends documenting security context, domains, boundaries, critical user roles, and external interfaces, then relating those views to the identified attack surface. That documentation is useful before any submission question arises: it exposes hidden dependencies and gives engineering a stable basis for requirements and tests.
A threat model should name assets, trust assumptions, adversary capabilities, abuse paths, mitigations, and residual risk across the whole product lifecycle. FDA specifically recommends including supply chain, manufacturing, deployment, interoperability, maintenance and update, and decommissioning risks. One important assumption in the guidance is that a hospital network may be hostile: an adversary could alter, drop, or replay packets. That is a more useful starting point than assuming a protected clinical LAN.
Work from concrete misuse and harm paths. Could a copied device credential impersonate another unit? Could a replayed phone command change a setting twice? Could a cloud tenant mix-up expose or control another customer's device? Could an update failure leave the device unable to perform an essential function? Could log or analytics traffic exhaust a constrained control loop? Could a support role change configuration without a second approval?
Security risk and safety risk are distinct but connected. A vulnerability assessment asks whether a weakness is exploitable and what an attacker can do. A safety analysis asks what hazardous situation and patient harm could follow. Link the two with traceable identifiers, but do not collapse them into one score. A network denial of service may have little confidentiality impact and still have a serious availability consequence. Conversely, a mobile analytics leak may create privacy risk without changing therapy.
Update the threat model when an interface, device capability, cloud service, component, deployment environment, or support path changes. Treat it as a design artifact with owners and review gates, not a diagram created at the end of a project.
Identity is the spine of a connected architecture. A device should have a unique, revocable logical identity that the platform can map to its model, hardware revision, firmware build, owner or facility, support state, and key status. The authentication material should be provisioned and protected in a way appropriate to the hardware, such as a secure element or hardware-backed keystore where available.
A serial number is an identifier, not a secret. A shared factory password or fleet-wide private key creates a fleet-wide failure: compromising one unit can expose every unit that uses it. FDA's guidance advises against designs in which compromise of one device reveals keys for others and specifically cautions against master keys stored on the device or keys derived only from discoverable identifiers.
Plan the entire lifecycle:
Human roles remain separate from device identity. Patient, clinician, caregiver, biomedical technician, support engineer, manufacturing operator, and release signer should not share a generic “user” permission. Service-to-service and build-system identities need their own scopes and rotation. A device certificate proves which unit connected; it does not prove that the person holding the phone may issue every command.
The mobile or desktop application can improve usability, perform local validation, and protect local secrets, but it should not be the final authorization authority. The device and cloud must independently validate the identity, freshness, scope, and safety constraints of a consequential command. A modified client should not be able to unlock an undocumented API by skipping a screen.
The OWASP Mobile Application Security Verification Standard provides a useful baseline across storage, cryptography, authentication, network communication, platform interaction, code quality, and resilience. OWASP also notes that mobile apps often interact with backends and IoT devices and that MASVS does not replace ecosystem-specific security work. Use it for the client layer, then test the protocols and server-side enforcement separately.
Key app decisions include:
A connected-device API has more dimensions than ordinary user-to-record access. It must determine whether this user may act for this organization, whether this device belongs to the organization, whether the requested command is valid for this device model and software state, whether the command is fresh, and whether another approval is required.
Enforce those rules in a centralized, testable policy layer. A tenant ID supplied by the app is not proof of tenant membership. A device ID in a URL is not proof of device ownership. A support engineer's broad read access is not permission to send a control command. Use deny-by-default behavior and object-level authorization on every request.
Commands should have unique IDs and explicit states such as proposed, authorized, delivered, acknowledged, applied, rejected, expired, and reconciled. The device should validate the command even if the cloud already did. It should reject an unsupported, stale, duplicated, out-of-range, or incorrectly signed command and report a reason without leaking secrets. Rate limits and queues must protect device availability as well as cloud capacity.
Administrative tools deserve the same architecture attention as the patient app. Require strong authentication, narrow roles, step-up checks for consequential actions, bounded support access, approval where appropriate, and an append-only history of configuration and fleet changes.
An update path is a privileged remote-code path. Its security architecture should cover the release source, signing keys, metadata, distribution service, client or gateway, device bootloader, installation process, and recovery behavior. The fact that a package arrived over TLS is not proof that it is an authorized device build.
A robust design should:
FDA's current guidance recommends cryptographically authenticated updates, protection against unauthorized rollback, planning for interrupted updates, and rapid testing and distribution of field patches. It also notes that downgrades may be necessary for safety reasons and should then be logged and documented. That is why a universal “always fail closed” rule is dangerous here. The correct recovery and degraded mode must come from the device's safety analysis.
Security patches should not be forced to wait for a feature train, but faster release does not remove verification. Define the smallest regression and safety evidence required for an emergency patch, rehearse that path, and keep the release authority separate from routine development credentials.
Telemetry should tell an authorized team what security state the fleet is in without becoming an uncontrolled stream of patient data. NIST's IoT device cybersecurity core baseline identifies device identification, configuration, data protection, logical access to interfaces, software update, and cybersecurity state awareness as broadly useful capabilities. The 2026 NIST IR 8259 Revision 1 adds current lifecycle guidance for IoT product manufacturers.
Useful security-state signals may include device and build identity, boot integrity result, update eligibility and result, credential age, repeated authentication failure, pairing changes, disabled protections, unexpected interface use, configuration changes, process restarts, storage pressure, and loss of time synchronization. Choose signals from the threat model; do not collect every event because it might be useful later.
Constrained or intermittently connected devices need a bounded local buffer, sequence or event identifiers, and a defined overflow policy. Record device time and receipt time when clocks may diverge. Authenticate telemetry and handle duplicates. A silence alarm should distinguish an offline device, a disabled transmitter, and a backend ingestion failure where the architecture allows it.
Minimize patient identifiers in security telemetry. Separate clinical data access from security operations when possible, define retention and access, and test what reaches observability, error tracking, customer support, and third-party tools. If the broader product handles electronic protected health information, Horizon's HIPAA readiness checklist for healthcare SaaS engineering teams covers that separate application and operational layer.
Connected features should not gain more authority than they need. Isolate safety-critical control and essential local operation from user-interface rendering, analytics, bulk telemetry, and remote administration where the hardware and product requirements allow it. Use process isolation, memory protection, privilege separation, explicit inter-process messages, and watchdog or recovery mechanisms appropriate to the platform.
A cloud outage, certificate-service problem, or noisy analytics task should not unexpectedly stop an essential local function. That does not mean every device must continue every function indefinitely while disconnected. It means the dependency and degraded behavior are explicit, analyzed, implemented, and tested.
Define failure behavior per function. Confidential data transfer may fail closed. A safety alarm may need a local fallback. A therapy or control function may need to maintain a bounded last-known-safe mode, reject remote changes, or transition according to a hazard-controlled sequence. Security engineering proposes mechanisms; the safety process determines which failure state is acceptable.
FDA's guidance recommends separate but connected safety and security risk assessments and calls for resilience when communication is disrupted. Keep traceability from a cyber threat through the control, residual risk, possible hazardous situation, test, and operational monitor.
An SBOM is not a spreadsheet produced for a submission and forgotten. It should be generated for each release from the actual build, include manufacturer-developed and third-party components and transitive dependencies where applicable, and map to the device model, hardware revision, app version, cloud release, and fielded fleet.
For devices that meet the statutory definition of a cyber device, FDA's medical-device cybersecurity FAQ states that section 524B requires an SBOM covering commercial, open-source, and off-the-shelf components. FDA's guidance also recommends maintaining the SBOM as part of configuration management and updating it when marketed software changes. CISA's SBOM resources library collects current material on minimum elements, production, sharing, consumption, and vulnerability-exploitability exchange.
The operating workflow matters more than the file format:
CVSS alone cannot make that decision. A high-scoring library may be unreachable in the shipped configuration. A lower-scoring weakness may sit on a path to an essential function. Record applicability and rationale, using VEX or another structured form where it improves coordination, and retain the relationship to affected builds and risk records.
Every important security requirement should trace to a threat or assumption, an implementation, and acceptance evidence. FDA's guidance lists boundary analysis, abuse and misuse cases, malformed inputs, fuzzing, attack-surface analysis, vulnerability chaining, software composition analysis, static and dynamic analysis, and penetration testing among the approaches manufacturers should consider.
A connected-product test plan should include:
Use independent testing where the risk and quality process call for it, but do not outsource ownership of findings. Engineering should assess each finding, connect it to the threat and safety records, remediate or justify the decision, and retest.
A senior engineering assessment should produce an evidence-backed backlog, not a generic maturity score. Start with items that can create fleet-wide compromise, unsafe remote authority, or an unpatchable field population:
The deliverables should include current and target architecture views, a trust-boundary register, identity and key lifecycle, command and update protocols, role matrix, telemetry specification, SBOM and vulnerability workflow, test matrix, remediation sequence, and operational runbooks. Those artifacts let the manufacturer's engineering, security, safety, quality, and regulatory teams make decisions from the same system description.
Horizon Labs can provide engineering support across embedded, Android, device-interface, backend, and operational software. Its work for MKProducts includes Android, embedded, USB, kiosk, and device-debugging scope. MKProducts is an industrial manufacturing client; that experience is not medical-device work, a safety outcome, or evidence of regulatory compliance.
For teams that need experienced engineers to inspect a connected-product architecture, clear a specialist backlog, or implement a bounded device/mobile/cloud workstream, Horizon Labs' senior-specialist lane is typically $150–200 per hour. Review the team's strengths and capabilities, or contact Horizon Labs with the current architecture, device constraints, supported fleet, and highest-risk backlog. The engagement can support engineering evidence and delivery while the manufacturer retains its regulatory, safety, quality, and approval responsibilities.
No. Architecture and engineering evidence can support a manufacturer's cybersecurity and quality work, but they do not create regulatory approval or certification. Device classification, submission strategy, statutory obligations, and compliance conclusions belong with the manufacturer and qualified regulatory and legal advisers.
At minimum, examine the device and firmware, physical and local wireless interfaces, the companion mobile or desktop app, cloud APIs and data stores, administrative and support tools, update and signing infrastructure, manufacturing and provisioning systems, and each third-party integration. Boundaries should follow actual data, code, and command paths.
A unique device identity lets the platform authenticate, authorize, inventory, rotate, revoke, and investigate one unit without trusting a fleet-wide shared secret. The identity should be provisioned and protected appropriately for the hardware, while user, service, and workload identities remain separate.
A secure mechanism authenticates update metadata and packages, verifies integrity before execution, controls who may release and install an update, resists unauthorized rollback, survives interruption, records the result, supports staged rollout and recovery, and is tested against the device's safety and availability requirements.
No. An SBOM is an inventory. It becomes operational when each build maps to fielded devices, new advisories are matched to affected components, applicability and exploitability are assessed, patient-safety impact is considered, remediation or compensating controls are tracked, and customers receive appropriate support and end-of-life information.
An engineering-focused HIPAA readiness checklist for ePHI inventory, vendor boundaries, risk analysis, access, logging, recovery, and evidence.
Learn Compliance Requirements for Medical Device Software: IEC 62304, ISO 13485/14971, QMSR, and 524B. 2026 glossary of key terms. Start here.
Implement Privacy‑First Telemetry Collection for Healthtech Products with HIPAA-ready vendors, de-identification, and server-side controls. Get the 2026 guide.
Tell us what you're building. After an intro call with our founders, you'll hear back within 72 business hours: a written scope with an hour range and a hard ceiling, or the questions we need answered first.