Secure architecture patterns for medical device connected apps

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.

Draw the system before choosing controls

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:

• device hardware, boot chain, firmware, operating system, local storage, and safety-critical functions;
• physical service and debug interfaces such as USB, JTAG, UART, removable media, or a maintenance port;
• local wireless paths such as Bluetooth, Wi-Fi, NFC, or a proprietary radio;
• the patient, clinician, caregiver, or technician application and its local data;
• cloud ingress, APIs, command services, data stores, queues, analytics, and tenant boundaries;
• operator, support, fleet-management, and break-glass consoles;
• build, signing, release, update, and rollback infrastructure;
• manufacturing, provisioning, repair, decommissioning, and key-custody systems;
• external identity providers, hospital systems, third-party services, and notification channels.

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.

Make the threat model system-level and safety-aware

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.

Separate device, human, service, and workload identity

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:

• secure generation or injection during manufacturing;
• proof that a newly enrolled unit is genuine and in an expected provisioning state;
• binding the device to a patient, account, organization, or care setting without trusting an unverified client claim;
• routine rotation and emergency revocation;
• replacement, repair, ownership transfer, factory reset, and decommissioning;
• recovery when the device clock is wrong, connectivity is absent, or a credential expires in the field.

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.

Treat the companion app as a constrained, untrusted client

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:

• store the minimum sensitive data locally and use platform-protected storage for credentials;
• bind sessions to the expected user, organization, device, and permitted actions;
• design pairing around proof of possession and an explicit user or technician action, not proximity alone;
• protect against replay with nonces, counters, command identifiers, or bounded validity appropriate to the protocol;
• define offline behavior and conflict resolution instead of treating reconnection as a normal online request;
• redact health and device data from crash reports, analytics, screenshots, push notifications, and support exports;
• treat root or jailbreak detection as a signal and defense-in-depth measure, not the primary trust boundary.

Keep cloud authorization and command handling explicit

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.

Design secure updates as a safety-critical product capability

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:

• authenticate update metadata, firmware, software, and configuration before installation and execution;
• protect signing keys with restricted roles, approvals, auditable use, rotation, and an incident plan;
• bind authorization to device model, hardware revision, current state, region or cohort, and compatibility constraints;
• resist unauthorized downgrade and rollback while retaining a documented, authorized safety exception where necessary;
• survive download interruption, power loss, low storage, corrupt packages, and a failed first boot;
• support a known-good recovery path, which may use dual images or another hardware-appropriate mechanism;
• stage deployment by cohort, expose pause and stop controls, and record which units accepted, installed, rejected, or missed the update;
• preserve the build tools, dependencies, regression suites, and test environments needed to patch supported field versions.

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.

Collect telemetry that answers fleet-security questions

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.

Separate safety-critical control from internet-facing convenience

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.

Turn the SBOM into a fielded-device capability

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:

1. ingest advisories, supplier notices, researcher reports, and relevant vulnerability feeds;
2. match components and versions to builds and fielded devices;
3. determine whether the vulnerable code is present, reachable, configured, and exploitable in this product;
4. assess security impact together with potential safety impact and fleet exposure;
5. choose a patch, configuration change, compensating control, communication, or documented acceptance path;
6. test and distribute the change, then verify field adoption and residual exposure;
7. maintain coordinated vulnerability disclosure, support, and end-of-support processes.

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.

Test the architecture, not only the code

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:

• attempted device impersonation, credential copying, rotation, revocation, and expired-credential recovery;
• cross-tenant and cross-device authorization failures in mobile, API, support, and fleet interfaces;
• replay, duplication, reordering, corruption, and loss across each command and telemetry protocol;
• malformed USB, Bluetooth, network, file, and update inputs;
• update interruption at each phase, unauthorized rollback, incompatible build, storage exhaustion, and recovery;
• cloud or network outage, delayed telemetry, clock drift, queue overload, and degraded local operation;
• debug-port and manufacturing-mode restrictions on production hardware;
• SBOM-to-build reproducibility and a drill from a new component advisory to the affected field population;
• operator misuse, support escalation, release-signing compromise, and incident-response exercises.

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.

Prioritize a connected-device security backlog

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:

• First: map the system and trust boundaries; inventory fleet-wide secrets, unauthenticated interfaces, update verification, internet-to-control paths, production debug access, and unsupported critical components.
• Next: establish per-device identity and revocation, explicit cloud and admin authorization, a tested update-and-recovery path, minimum security-state telemetry, and a build-linked SBOM workflow.
• Then: harden pairing and offline synchronization, isolate processes, automate advisory matching, expand abuse and fuzz testing, and improve fleet rollout controls.
• Continuously: review threats, dependencies, field versions, incidents, support access, end-of-life commitments, and recovery drills.

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.

Where Horizon Labs fits

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.

Frequently asked questions

Does a secure architecture make a connected medical device FDA compliant?

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.

Which trust boundaries should a connected medical-device threat model include?

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.

Why does each connected device need its own identity?

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.

What makes a medical-device update mechanism secure?

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.

Is an SBOM enough for medical-device vulnerability management?

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.