FDA 510(k) cybersecurity requirements illustrated by a connected medical device case study

Let us return to our connected ECG monitor.

The device records a short ECG, stores it locally, and uploads it directly to KaaIoT through LTE. An authorized healthcare professional later accesses the recording through a secure portal.

The engineering team has already implemented the obvious security controls.

Every production device has a certificate. Communication is encrypted. Users have individual accounts and roles. The cloud rejects unauthenticated connections. An external security company has completed a penetration test.

The system looks secure.

Then the regulatory team asks for the cybersecurity submission package:

• threat model;
• cybersecurity risk assessment;
• four security architecture views;
• security requirements and acceptance criteria;
• product-level SBOM;
• known-vulnerability assessment;
• unresolved-anomalies assessment;
• cybersecurity test reports;
• update and patching design;
• coordinated vulnerability disclosure process;
• postmarket cybersecurity management plan;
• full traceability between threats, controls, architecture, and test evidence.

Encryption was necessary.

It was only the beginning.

FDA’s current cybersecurity guidance was issued on February 3, 2026. It covers cybersecurity design, labeling, quality-management considerations, and the documentation expected in premarket submissions for devices with cybersecurity risk. It also addresses the Section 524B requirements that apply to cyber devices.

This article uses the LTE-connected ECG monitor to show how to build that package step by step—and how KaaIoT helps turn security architecture and platform behavior into structured FDA 510(k) evidence.

The Cybersecurity Package at a Glance

A strong cybersecurity submission tells one connected story:

• Threats
• risks
• security requirements
• architecture
• implemented controls
• cybersecurity testing
• residual-risk assessment
• labeling and postmarket plan

Before submitting the 510(k), the team should have the following elements ready:

The value of this package comes from consistency.

The threat model must describe the actual product. The architecture must show the controls named in the requirements. The test package must verify those controls. The SBOM must match the released software.

A collection of correctly titled documents is not enough when each one describes a slightly different system.

1. Determine Whether the Product Is a Cyber Device

Section 524B defines a cyber device as a device that:

• includes software validated, installed, or authorized by the sponsor;
• can connect to the internet;
• contains technological characteristics that could be vulnerable to cybersecurity threats.

Our ECG monitor meets all three conditions.

It contains embedded software and modem firmware. It connects to KaaIoT through LTE. Its credentials, communication stack, update process, cloud interfaces, firmware, and third-party components can all be affected by cybersecurity threats.

Section 524B applies to cyber devices submitted through pathways including 510(k), De Novo, PMA, PDP, and HDE. It requires the sponsor to provide:

• a plan for monitoring, identifying, and addressing postmarket vulnerabilities and exploits, including coordinated vulnerability disclosure;
• processes and procedures providing reasonable assurance that the device and related systems are cybersecure;
• the ability to make postmarket updates and patches available;
• an SBOM covering commercial, open-source, and off-the-shelf software components.

These requirements immediately affect product architecture.

The team needs to know how devices are identified, how credentials are renewed, which components can be patched, how affected products are found, and how update status is monitored across the installed fleet.

2. Build Cybersecurity Into the Development Process

Cybersecurity works best when it is part of product development from the first architecture decisions.

For the ECG monitor, the Secure Product Development Framework should cover:

• security requirements;
• architecture and design reviews;
• threat modeling;
• secure implementation practices;
• third-party component selection;
• credential provisioning;
• code and dependency analysis;
• cybersecurity verification and validation;
• vulnerability triage;
• secure release management;
• update development;
• postmarket monitoring;
• product retirement and end of support.

The process should be visible in the project records:

• Threat identified
• risk assessed
• requirement created
• control designed
• implementation reviewed
• control tested
• residual risk evaluated
• released version recorded
• postmarket monitoring defined

This aligns cybersecurity with the manufacturer’s quality system and product-risk-management activities.

FDA’s QMSR became effective on February 2, 2026 and incorporates ISO 13485:2016 into the device quality-management framework under 21 CFR Part 820.

For a connected device, security requirements, architecture decisions, tests, software components, and release evidence should move through the same controlled product-development system as other safety-relevant design work.

3. Create the Cybersecurity Risk Management Report

The Cybersecurity Risk Management Report is the central narrative of the submission.

It brings together:

• threat model;
• cybersecurity risk assessment;
• security requirements;
• architecture and controls;
• SBOM;
• third-party support information;
• known vulnerabilities;
• unresolved anomalies;
• cybersecurity testing;
• mitigations;
• residual-risk conclusions;
• traceability.

For the ECG monitor, the report may assess scenarios such as:

• a copied device credential impersonates a legitimate monitor;
• a forged ECG recording is uploaded under a trusted identity;
• an unauthorized user accesses patient data;
• modified firmware is installed;
• a modem vulnerability creates an attack path;
• an attacker prevents recordings from synchronizing;
• a central cloud compromise affects multiple devices;
• security events are insufficient to investigate an incident;
• an unsupported third-party component remains in production;
• an interrupted update leaves the device in an unsafe or unavailable state.

Each scenario should be connected to safety and effectiveness.

A cybersecurity event may affect:

• confidentiality of patient information;
• integrity of ECG recordings;
• availability of recordings;
• trust in device identity;
• ability to distribute a safety-related update;
• operation of multiple devices through a shared cloud component.

Example: device impersonation

This same scenario should appear throughout the package.

The certificate flow appears in the architecture. Revocation appears in the requirements. The test report demonstrates the result. Platform events show how the incident was detected and contained.

4. Model Threats Across the Complete System

The ECG monitor is more than the physical recorder.

The cybersecurity scope includes:

• ECG monitor
• embedded firmware
• local storage
• LTE modem
• SIM/eSIM
• cellular network
• cloud endpoint
• KaaIoT services
• data storage
• healthcare portal
• identity provider
• update infrastructure
• external integrations

The threat model should identify:

• critical assets;
• user and device identities;
• trust boundaries;
• interfaces that accept data, commands, code, or configuration;
• assumptions about cellular and cloud infrastructure;
• threats to confidentiality, integrity, and availability;
• potential patient or multi-patient impact;
• prevention, detection, containment, and recovery controls.

A useful threat model changes the design.

If the team identifies a risk that one copied certificate could be used indefinitely, the architecture gains certificate revocation and device quarantine.

If compromise of the update-signing service could affect the complete fleet, the design gains separated signing authority, controlled release approval, protected trust anchors, and fleet-wide update monitoring.

The output is not simply a diagram showing where an attacker might appear.

The output is a set of requirements and controls that become part of the product.

5. Prepare the Four Security Architecture Views

FDA’s current guidance recommends four types of cybersecurity architecture views:

• Global System View
• Multi-Patient Harm View
• Updateability/Patchability View
• Security Use Case Views

Together, they show how the system works, where the security boundaries are, and how the product handles high-impact events.

Global System View

The Global System View shows the entire connected environment:

• ECG monitor
• LTE network
• public cloud endpoint
• KaaIoT ingestion
• processing services
• storage
• healthcare portal
• identity and support systems

The view should identify:

• protocols;
• authentication;
• authorization;
• encryption;
• session behavior;
• data types;
• commands and responses;
• trust boundaries;
• administrative interfaces;
• external dependencies;
• security controls at each boundary.

The diagram should allow a reviewer to follow ECG data, operational telemetry, configuration, updates, and user access from one component to another.

Multi-Patient Harm View

This view focuses on components capable of affecting multiple devices or patients.

For the ECG system, these may include:

• firmware-signing service;
• fleet-management functions;
• shared cloud services;
• tenant-separation controls;
• administrator accounts;
• certificate authority;
• central identity provider;
• shared third-party libraries;
• reporting logic used across the fleet.

A copied device certificate may affect one monitor.

A compromised signing key can affect the whole fleet.

The Multi-Patient Harm View shows how high-blast-radius components are separated, protected, monitored, and recovered.

Updateability/Patchability View

The update view shows the complete software-delivery path:

• Change approved
• software built
• package signed
• release stored
• target group selected
• device authenticates
• package downloaded
• signature verified
• compatibility checked
• update installed
• device health confirmed
• result reported

It should explain:

• who authorizes the update;
• which components can be updated;
• how packages are signed;
• how devices verify authenticity and integrity;
• what happens if connectivity or power is lost;
• how failure and rollback are handled;
• how rollout is limited to selected devices;
• how offline devices are identified;
• how fleet adoption is measured.

Security Use Case Views

Security Use Case Views describe important workflows in detail:

• manufacturing and onboarding;
• first production connection;
• ECG upload;
• certificate renewal;
• credential revocation;
• user access to ECG data;
• configuration change;
• firmware update;
• device quarantine;
• incident investigation;
• retirement and deprovisioning.

Each view should show actors, states, interfaces, controls, failure paths, and generated evidence.

6. Define Testable Security Requirements

Security statements need measurable acceptance criteria.

A vague requirement says:

The device shall communicate securely.

A testable requirement says:

Each production device shall authenticate the KaaIoT endpoint and establish an encrypted session using the approved protocol and cryptographic configuration before transmitting ECG or operational data. Connections using expired, revoked, untrusted, or mismatched certificates shall be rejected and recorded as security events.

The second requirement defines a behavior that can be implemented, reviewed, and tested.

The cybersecurity guidance organizes controls into eight broad areas:

Authentication

• unique device identities;
• server authentication;
• user authentication;
• credential renewal and revocation;
• update-package authenticity.

Authorization

• device-level permissions;
• least-privilege user roles;
• administrative separation;
• restricted update and configuration operations;
• default denial of unspecified access.

Cryptography

• approved protocols and algorithms;
• key generation and protection;
• certificate validation;
• rotation and expiration;
• cryptographic-agility strategy.

Code, Data, and Execution Integrity

• firmware signature verification;
• secure boot or equivalent controls where appropriate;
• ECG-record integrity;
• configuration integrity;
• protection against replay and manipulation.

Confidentiality

• protection of sensitive data in transit;
• storage and backup controls;
• controlled exports;
• role-based visibility.

Event Detection and Logging

• failed authentication;
• certificate errors;
• privilege violations;
• administrative actions;
• software updates;
• device and configuration changes;
• consistent timestamps.

Resiliency and Recovery

• local recording during LTE outages;
• recovery from interrupted uploads;
• cloud-service failure handling;
• update recovery;
• isolation of affected identities;
• preservation of essential functions.

Updateability and Patchability

• update authorization;
• package signing;
• targeted rollout;
• success and failure reporting;
• emergency updates;
• handling of offline devices.

Every important security requirement should connect to an architecture element, implementation control, test case, and result.

7. Build a Product-Level SBOM

The SBOM provides visibility into the software supply chain.

For the ECG system, the product-level inventory may include:

• embedded firmware components;
• RTOS or embedded operating system;
• bootloader;
• modem firmware;
• device drivers;
• communication stack;
• TLS and cryptographic libraries;
• update client;
• KaaIoT platform components;
• cloud containers and dependencies;
• healthcare-portal components;
• identity-provider integrations;
• relevant third-party services.

The KaaIoT platform SBOM becomes a major building block of the product-level inventory. It provides the component and version information for the connected-platform scope, while the device, modem, and portal inventories complete the system view.

For every component, the team should know:

• supplier;
• component name;
• version;
• dependency relationship;
• support status;
• end-of-support date;
• known vulnerabilities;
• affected product releases;
• current mitigations;
• planned remediation.

The real business question is not whether an SBOM file exists.

It is whether the team can determine quickly which released products are affected when a new vulnerability is disclosed.

8. Assess Vulnerabilities and Unresolved Anomalies

A CVE list without product context creates noise.

The vulnerability assessment should determine:

• whether the component and version are present;
• whether the vulnerable function is enabled;
• whether the attack path exists in the product architecture;
• whether existing controls reduce exploitability;
• whether safety, effectiveness, or data can be affected;
• which releases and devices are exposed;
• whether remediation is required.

The same discipline applies to unresolved software anomalies.

Suppose the modem may open two rapid sessions after recovering from poor coverage.

The security assessment should ask:

• Can this bypass session controls?
• Can it create duplicate authentication state?
• Can it contribute to denial of service?
• Can it exhaust logs or connection limits?
• Can it interfere with duplicate-identity detection?
• Are the existing controls sufficient?
• Is the residual risk acceptable?

A well-documented anomaly demonstrates that the team found the issue, understood its security impact, and incorporated it into the risk decision.

9. Test the Complete Cybersecurity Story

A penetration test is one part of the testing package.

A strong program also includes:

• security-requirements verification;
• boundary and interface testing;
• threat-mitigation testing;
• abuse and misuse cases;
• malformed and unexpected inputs;
• robustness and fuzz testing;
• attack-surface analysis;
• vulnerability chaining;
• known-vulnerability scanning;
• software-composition analysis;
• static and dynamic code analysis;
• credential checks;
• independent penetration testing.

Example test matrix

Every finding should return to the risk-management process.

The team determines applicability, potential impact, affected releases, remediation, retesting, and residual risk.

The result is a documented chain from discovery to disposition.

10. Prepare Cybersecurity Labeling

Cybersecurity labeling turns architecture assumptions into clear operating instructions.

For the ECG system, controlled documentation may explain:

• required network and cellular conditions;
• supported user roles;
• account and credential responsibilities;
• device provisioning;
• software-version identification;
• update behavior;
• communication of security updates;
• vulnerability reporting;
• end-of-support dates;
• behavior during connectivity loss;
• responsibilities of healthcare providers and administrators.

Clear labeling helps the customer deploy and operate the product in the environment assumed by the security design.

It also gives the manufacturer a consistent way to communicate updates, limitations, and security responsibilities throughout the product lifecycle.

11. Build the Postmarket Cybersecurity Management Plan

The premarket package should already show how the manufacturer will manage security after clearance.

The plan should identify:

• responsible teams;
• vulnerability-monitoring sources;
• monitoring frequency;
• supplier advisories;
• NVD and CISA KEV monitoring;
• vulnerability-triage process;
• periodic security testing;
• patch-development timelines;
• regular and emergency release processes;
• coordinated vulnerability disclosure;
• customer communication;
• handling of offline devices;
• end-of-support and end-of-life activities.

Consider a critical vulnerability in the ECG monitor’s TLS library.

The response process should already be defined:

• Component identified in SBOM
• affected releases mapped
• exploitability assessed
• safety and security impact evaluated
• remediation selected
• patch developed and tested
• rollout approved
• devices updated
• failures and offline devices monitored
• customers informed
• evidence retained

KaaIoT provides the fleet-level visibility required to execute this process efficiently:

• device and software-version inventory;
• affected device groups;
• rollout targeting;
• update progress;
• failed updates;
• offline devices;
• post-update events;
• evidence reports.

12. Demonstrate Update and Patching Capability

“Supports OTA” is a product feature.

The submission needs the complete control model behind it.

The team should be able to explain:

• which software components can be updated;
• who approves the release;
• how the package is signed;
• how the update source is authenticated;
• how device compatibility is checked;
• how integrity is verified;
• what happens if installation is interrupted;
• how recovery or rollback works;
• how rollout is restricted to selected groups;
• how emergency patches are handled;
• how success and failure are recorded;
• how offline devices are tracked;
• how fleet adoption is confirmed.

KaaIoT turns this process into an observable fleet operation. Engineering, quality, cybersecurity, and regulatory teams can see which version is running, which devices received the release, which updates failed, and which units still require action.

13. Keep Traceability Across the Package

The cybersecurity submission should read as one technical case.

For example:

• Threat: A forged update is delivered to the ECG monitor
• Risk: Unauthorized software may alter device behavior or expose ECG data
• Requirement: The device shall install only authorized and integrity-verified firmware
• Architecture: Signed package, controlled release service, protected trust anchor
• Controls: Signature verification, version policy, compatibility check, recovery handling
• Tests: Tampered package, invalid credential, interrupted installation, rollback attempt
• Evidence: Device events, update result, audit log, cybersecurity test report
• Residual risk: Evaluated in the Cybersecurity Risk Management Report

Traceability exposes gaps early.

A threat without a requirement is unfinished.

A requirement without architecture is theoretical.

A control without a test is an assumption.

A test without a controlled result is difficult to use in the submission.

14. Final Submission-Readiness Checklist

Before submitting the 510(k), the team should be able to answer yes to the following.

Scope and Section 524B

• Cyber-device determination is documented.
• The complete connected product is in scope.
• Section 524B monitoring, patching, and SBOM requirements are addressed.

Development and risk management

• Cybersecurity is integrated into the product-development process.
• Threat modeling covers the complete system.
• Cybersecurity risks and residual risks are documented.
• Security and safety assessments are connected.

Architecture and requirements

• Security requirements are testable.
• Acceptance criteria are defined.
• All four architecture views are complete.
• Diagrams show trust boundaries, interfaces, protocols, roles, and controls.

Software supply chain

• The product-level SBOM matches the released configuration.
• Component support and end-of-support dates are known.
• Applicable vulnerabilities are assessed.
• Open anomalies have a cybersecurity assessment.

Testing

• Every critical security requirement has test evidence.
• Identified mitigations have been challenged.
• Malformed inputs and abuse cases have been tested.
• Dependency, code, binary, and vulnerability analyses are complete.
• Penetration-test findings are dispositioned and retested where required.

Postmarket readiness

• Cybersecurity labeling is complete.
• The Cybersecurity Management Plan is operational.
• Coordinated vulnerability disclosure is defined.
• Regular and emergency patching processes are demonstrated.
• Affected devices and versions can be identified.
• Update adoption and failures can be monitored.

Submission consistency

• Architecture reflects the released product.
• SBOM reflects the released software.
• Tests cover the controls identified in the risk analysis.
• Platform, device, modem, portal, and third-party evidence fit together.
• Traceability reaches from each important threat to a controlled result.

Most 510(k) and De Novo submissions must use eSTAR. FDA states that a cyber-device submission can be placed on Technical Screening hold when the Cybersecurity section lacks accurate responses or relevant attachments.

Cybersecurity package readiness is therefore submission readiness.

How KaaIoT Accelerates the Cybersecurity Package

KaaIoT provides the connected cybersecurity foundation for the medical device.

The platform combines:

• unique device identity and lifecycle context;
• secure device-to-cloud communication;
• device and user access control;
• project, tenant, and environment separation;
• certificate and credential integration;
• device quarantine and revocation workflows;
• security-event collection;
• audit trails;
• firmware and configuration inventory;
• update rollout visibility;
• platform vulnerability evidence;
• platform SBOM;
• technical reports;
• APIs and evidence exports.

For the FDA package, KaaIoT contributes directly to:

KaaIoT engineers work with product, firmware, quality, cybersecurity, and regulatory teams to assemble these elements into one coherent connected-device security story.

The result is more than secure connectivity.

The manufacturer gains:

• a known identity for every connected device;
• clear visibility into software versions;
• controlled access to device and patient data;
• traceable security events;
• evidence that credentials can be revoked;
• visibility into vulnerable product populations;
• measurable update adoption;
• reproducible technical reports;
• platform documentation ready for the 510(k) package.

Conclusion

A connected medical device is not ready for FDA cybersecurity review simply because its traffic is encrypted and a penetration test found no critical issues.

The submission needs to show the complete lifecycle:

• threats were identified;
• risks were assessed;
• requirements were defined;
• controls were designed;
• architecture was documented;
• software components were inventoried;
• vulnerabilities and anomalies were evaluated;
• controls were tested;
• updates can be delivered;
• postmarket monitoring is operational;
• evidence remains traceable.

For our ECG monitor, the final question is broader than:

Can the device connect securely?

The real question is:

Can the team demonstrate that the device, cloud platform, software supply chain, update process, and postmarket operations form one controlled and resilient cybersecurity system?

KaaIoT gives manufacturers the connected foundation needed to answer that question.

It brings device identity, secure communication, access control, software visibility, security monitoring, update tracking, vulnerability evidence, platform SBOM, and technical reporting into one system.

That foundation helps engineering teams build a more secure product, gives quality and cybersecurity teams clear operational evidence, and enables regulatory teams to prepare a stronger, more complete FDA 510(k) cybersecurity package.