IoT Security Solutions: Threat Landscape, Architecture, and Engineering Best Practices

Key Takeaways

• The attack surface is exploding. Botnets like Mirai and Aisuru exploit default credentials and unpatched IoT devices to launch massive DDoS attacks and deploy malware [1]. The Aisuru botnet alone used 1 to 4 million hosts and delivered hyper-volumetric assaults that peaked at 29.7 Tbps.

• Threats go beyond DDoS. Attackers and hackers abuse common vulnerabilities in routers, cameras, and NAS devices (CVE-2023-1389, CVE-2020-9054, CVE-2025-4008), conduct ransomware campaigns, and exfiltrate sensitive data. Daily IoT attacks exceeded 820,000 in 2025, and malware incidents increased by 124%.

• Defense-in-depth is essential. Engineers should design layered architectures: device identity, secure boot and hardware root of trust, encrypted data at rest and in transit, network isolation, zero trust segmentation, and continuous monitoring.

• Standards provide a baseline. IEC 62443 and NIST SP 800-213 prescribe security requirements across the lifecycle. ETSI EN 303 645 forbids default passwords, mandates a vulnerability disclosure policy, and demands timely software updates. FDA guidance emphasises cybersecurity as part of medical device safety.

• Modern IoT security platforms help manage risk. Solutions from Palo Alto, Cisco, Microsoft, Armis, Claroty, Nozomi Networks, and Forescout provide agentless asset discovery, risk-based vulnerability management, segmentation, and continuous threat detection.

• Future directions are emerging. Expect AI-driven threat detection, software bill of materials (SBOM) requirements, and post-quantum cryptography to shape IoT security in the next few years.

Introduction

The Internet of Things connects billions of devices (industrial sensors, smart cameras, medical implants, routers, and consumer gadgets) via a vast IoT ecosystem integrated into our critical infrastructure. This ubiquity brings convenience and efficiency, but it also introduces a massive attack surface. In August 2016, the Mirai botnet demonstrated how poorly secured IoT devices could be weaponised. The malware scanned IP ranges for cameras and DVRs using hard-coded default credentials; once authenticated, it enrolled the devices into a botnet and launched network-layer and application-layer DDoS attacks. Since then, the number of connected devices has surged, and so have the cyber threats [1].

Today, engineers face not only opportunistic botnets but also targeted ransomware, cryptomining, and data-exfiltration campaigns. Operational technology (OT) and information technology (IT) networks are converging, which means compromised IoT devices can serve as a bridge between the shop floor and enterprise networks. The attack surface is compounded by remote work, cloud adoption, and the proliferation of consumer IoT in hospitals and factories. To design resilient systems, engineers must treat IoT security as an engineering discipline rather than an afterthought.

The remainder of this article explores the threat landscape, architectural patterns, and practical use cases and implementation strategies for building secure IoT systems. It highlights relevant standards and compares leading IoT security solutions.

The IoT Threat Landscape

Expanding Attack Surface

Every connected device is a potential entry point. Residential routers, IP cameras, network video recorders, and voice assistants are frequently exposed to the internet with default credentials or outdated firmware. Attackers use automated scanners to find these devices within minutes of their deployment. A 2026 threat report observed 820,000 malicious IoT hacking attempts per day in 2025, a 46% increase year-over-year. The same report noted that routers accounted for 75% of IoT attacks because they sit at critical network choke points and are often poorly patched.

The Aisuru botnet illustrates the scale of modern threats and the urgent need to secure IoT devices. According to Cloudflare's Q3 2025 DDoS report, Aisuru recruited an estimated 1 to 4 million infected hosts and launched hyper-volumetric DDoS attacks that routinely exceeded 1 Tbps; the record was 29.7 Tbps. The number of these attacks surged 54% quarter-over-quarter, averaging 14 per day [5].

Beyond DDoS, attackers increasingly exploit IoT devices for persistent intrusion and ransomware. Researchers observed a 124% year-over-year surge in IoT malware, and targeted attacks against operational technology rose by 46%. Nation-state groups have compromised telecom devices to geolocate users in 80 countries, proving that IoT exploitation is not limited to criminals.

Common Vulnerabilities and Exploits

IoT firmware often lacks secure coding practices, exposing remote command-execution flaws. Examples include:

• CVE-2023-1389: command injection in TP-Link Archer AX21 routers allows unauthenticated remote code execution.

• CVE-2020-9054: a vulnerability in Zyxel NAS "weblogin.cgi" permits unauthenticated OS command execution.

• CVE-2024-10914: command injection in legacy D-Link NAS devices' account management script.

• CVE-2025-4008: command injection in Smartbedded Meteobridge,  a weather station gateway — allows unauthenticated remote code execution with root privileges via the device's CGI web interface. Added to CISA's Known Exploited Vulnerabilities catalog in October 2025.

These flaws share a pattern: unvalidated user inputs are passed to system commands, giving attackers direct control. Old vulnerabilities (for example, CVE-2014-3206 in Seagate Black Armor NAS) remain heavily targeted because many devices are never patched.

Recommended Reading: IoT Gateway Architecture: Edge vs. Cloud, Protocol Translation, and Deployment Patterns

Ransomware and Data Breaches

Ransomware actors increasingly target IoT and operational technology environments. Attackers seize control of industrial controllers or healthcare devices to halt operations and demand payment. Over 35% of OT/IoT security alerts in 2025 were related to denial-of-service incidents, but targeted intrusions and ransomware are rising. Medical device breaches are especially concerning: the U.S. FDA emphasises that increased connectivity has led to cyber incidents disrupting patient care [9].

Data breaches are another risk. IoT sensors collect sensitive personal and operational data. When attackers compromise these devices or their cloud backends, they can exfiltrate location information, health data, and intellectual property. Cloud integrations amplify these risks: multi-tenant cloud platforms and poorly protected APIs enable cross-tenant data leakage.

IoT Security Architecture: Defense in Depth

A robust IoT security posture requires strong security through a layered architecture combining device, network, cloud, and application controls.

Device Identity and Authentication

Unique device identity is the foundation of any IoT security architecture. NIST SP 800-213 recommends strong authentication mechanisms, encryption, and secure software updates. Each device should be provisioned with cryptographic keys or certificates during manufacturing. Hardware roots of trust (secure modules that store secret keys and verify software integrity) provide a tamper-resistant anchor. Programmable versions allow updating cryptographic algorithms and isolating resources to prevent key extraction.

Secure Boot, Firmware Integrity, and Patch Management

Secure boot is designed to ensure a device only executes firmware signed by a trusted authority. Industrial IoT devices verify the digital signature of the bootloader and operating system during startup. Trusted Platform Modules (TPMs) or similar hardware elements store the keys. Firmware integrity extends beyond boot; it prevents unauthorized access. Engineers should implement run-time integrity checks and design a secure update mechanism that supports rollback and failsafe modes.

A disciplined patch management process is critical. Organizations should track vulnerabilities via CVE databases and vendor advisories, prioritize based on risk (CVSS, EPSS, business impact), and deploy patches promptly. Automated update systems reduce the window of exposure.

Zero Trust and Network Segmentation

The zero-trust model assumes that no device or user should be implicitly trusted. Every access request must be authenticated and authorized, and all east-west traffic within the network is inspected. Implementing asset inventory, microsegmentation around critical assets, least-privilege access controls, and multi-factor authentication helps reduce the attack surface. Continuous monitoring using passive tools is vital for detecting policy violations.

Network segmentation divides infrastructure into isolated zones. Microsegmentation creates software-defined boundaries around workloads or IoT devices to limit lateral movement and enforce compliance. Firewalls filter inbound and outbound traffic, while intrusion detection systems (IDS) monitor for suspicious behaviour and intrusion prevention systems (IPS) block malicious packets.

Secure Communication and Encryption

Data should be encrypted both at rest and in transit. Strong encryption (AES-256) protects stored data. Protocols such as TLS and IPsec protect transmitted data. End-to-end encryption ensures that data remains confidential across networks and intermediate devices. In multi-tenant cloud environments and data centers, encryption prevents one tenant from accessing another's data.

Monitoring, Detection, and Incident Response

Continuous monitoring is essential for detecting anomalies, policy violations, and attacks. Passive network monitoring collects traffic flows without interfering with operations. Machine learning can establish behavioural baselines for each device and raise alerts when deviations occur. Incident response planning should define identification, containment, eradication, and recovery steps, as well as communication procedures.

Device Security

Hardware Root of Trust

A hardware root of trust provides an immutable anchor for cryptographic operations. It stores secret keys and performs secure boot, attestation, and encryption. Programmable roots of trust can be updated to run new cryptographic algorithms and protect against host compromise, key extraction, and side-channel attacks. Siloed execution ensures that one compromised process cannot access another's keys [6].

Secure Boot and Firmware Updates

Secure boot verifies that firmware images are signed by a trusted authority. Each stage of the boot sequence checks the next stage's signature, preventing booting of untrusted code. During firmware updates, devices should verify the update signature, enforce version control, and support rollback. Hardware-enforced memory protection reduces the risk of memory corruption and code injection [7].

Software Security and Secure Coding

Developers must follow secure coding practices: validate inputs, avoid unsafe functions (for example, strcpy, gets, or sprintf), implement least-privilege access controls, and handle errors securely. Libraries and dependencies should be kept up-to-date. Code should be fuzz-tested and scanned for vulnerabilities using static analysis tools. Where possible, implement memory-safe languages (for example, Rust) to reduce the risk of buffer overflows.

Patching and Lifecycle Management

An IoT product's security is only as strong as its maintenance process. Vendors must commit to timely firmware updates and publish security advisories. Customers should track the lifecycle status of each device and plan for end-of-life replacement. Automated patching should be scheduled during maintenance windows to minimise downtime. Where devices cannot be patched (legacy OT equipment), organisations should implement compensating controls such as network isolation, deep-packet-inspection firewalls, or virtual patching.

Network Security

Firewalls, IDS/IPS, and Microsegmentation

Perimeter and internal firewalls enforce policies on inbound and outbound traffic. Microsegmentation isolates workloads and devices using VLANs, virtual routing, and software-defined network policies. IDS monitors for suspicious traffic patterns; IPS blocks malicious packets before they reach vulnerable devices. Firewall policies should be fine-grained: for instance, a camera should be permitted to send video streams to a recorder but not directly to the internet.

Endpoint and Agentless Monitoring

Many IoT devices cannot run security agents because of resource constraints. Passive, agentless monitoring collects traffic via SPAN/TAP ports without impacting performance. Forescout's eyeSight module uses both passive and active monitoring techniques to deliver real-time asset visibility, with passive-only profiling available for sensitive OT and IoT environments.. Armis uses a virtual appliance that passively observes network traffic and builds a comprehensive inventory. Microsoft Defender for IoT deploys sensors that operate out-of-band using SPAN/TAP ports and perform multi-factor fingerprinting (MAC address, protocol behaviour, device type) to identify devices.

Secure Gateways and VPNs

IoT gateways bridge edge devices to the cloud and corporate networks. Gateways should authenticate devices, enforce protocol translation policies, and encrypt traffic. VPNs or software-defined perimeters can encapsulate traffic between edge sites and cloud services. However, VPNs alone are insufficient; they should be combined with zero-trust policies and continuous monitoring.

Threat Intelligence and Anomaly Detection

Integrating threat intelligence into network monitoring enhances detection. Machine learning models learn normal traffic patterns and detect anomalies in protocol behaviour, timing, or payload size. Engineers should tune detection thresholds to reduce false positives and incorporate context, such as asset criticality and known exploited vulnerability (KEV) status, alongside CVE severity.

Protocol Security

IoT deployments rarely use a single protocol. A typical industrial site runs Modbus over RS-485 on the plant floor, LoRaWAN for remote sensors, MQTT northbound to the cloud, and OPC UA to the SCADA historian. Each protocol carries its own security model and failure modes. Generic network controls, such as firewalls, segmentation, and TLS tunnels, provide a baseline, but engineers must also harden each protocol on its own terms.

MQTT

MQTT is the dominant northbound IoT messaging protocol, used by AWS IoT Core, Azure IoT Hub, and most gateway frameworks. Its publish-subscribe model and lightweight overhead make it well-suited to constrained devices, but older broker versions accept anonymous connections by default, and most impose no topic-level access controls without explicit configuration.

Hardening MQTT starts at the broker. Disable anonymous access and require client certificate authentication or username/password credentials over TLS 1.3. Enforce mutual TLS (mTLS) where devices support it — each device presents a unique X.509 certificate, and the broker validates it against a trusted CA. This prevents credential sharing across devices and makes certificate revocation effective. Configure access control lists (ACLs) to restrict each client to the topics it legitimately publishes to or subscribes from. A temperature sensor has no reason to subscribe to a command topic intended for an actuator.

At the payload level, validate message structure and size at the broker before forwarding. Oversized or malformed payloads have been used to exploit broker vulnerabilities. If using MQTT 5, leverage the enhanced authentication flow and reason codes for better error visibility. Retain messages carefully — retained messages persist on the broker and can expose stale sensitive data to new subscribers.

OPC UA

OPC UA is the standard for industrial data exchange between PLCs, SCADA systems, historians, and gateways. Unlike Modbus, OPC UA was designed with security built in, but its security modes must be explicitly configured — the default in many implementations is None.

OPC UA defines three security modes: None (no protection), Sign (message integrity only), and SignAndEncrypt (integrity and confidentiality). Production deployments must use SignAndEncrypt. Select a SecurityPolicy that uses current algorithms — Basic256Sha256, Aes128_Sha256_RsaOaep, or Aes256_Sha256_RsaPss. Avoid Basic128Rsa15 and Basic256, which the OPC Foundation deprecated as of specification version 1.04 due to weak cryptographic primitives.

Authentication in OPC UA is certificate-based. Each client and server holds an application certificate, and connections are only established after mutual certificate validation. Maintain a certificate trust list on each server and reject connections from unknown clients. Implement certificate expiry monitoring and rotate certificates before they lapse — an expired certificate that gets ignored is a misconfiguration waiting to become a vulnerability. Restrict the OPC UA server's exposed node space to what each client actually needs; do not expose the full address space to all clients.

Modbus and Legacy Serial Protocols

Modbus RTU and Modbus TCP were designed in 1979 for isolated serial networks. They have no authentication, no encryption, no message integrity, and no access control. Any device on the network can read or write any register. This is not a fixable limitation — it is a fundamental design characteristic of the protocol.

The security strategy for Modbus is therefore entirely compensating. Place all Modbus devices behind an IoT gateway that terminates the Modbus connection and re-publishes data over an authenticated, encrypted northbound protocol such as MQTT/TLS or OPC UA SignAndEncrypt. Apply allowlisting at the gateway: permit only expected function codes (for instance, function code 03 for read holding registers) and block anything outside the defined set. Log all write commands — function codes 05, 06, 15, and 16 — for audit purposes, since writes to coils or registers are the mechanism by which attackers manipulate physical processes.

At the network level, place Modbus devices on an isolated VLAN with no route to the internet or corporate network. If Modbus TCP is in use, firewall port 502 to permit only authorised gateway IP addresses. Where legacy OT equipment cannot be replaced, these compensating controls are the primary defence.

LoRaWAN

LoRaWAN uses AES-128 for over-the-air encryption, with two session keys: the network session key (NwkSKey), which protects integrity at the network layer, and the application session key (AppSKey), which encrypts the application payload end-to-end between the device and the application server. The two-key architecture means the network operator sees packet metadata but cannot read the payload — important in multi-tenant deployments. LoRaWAN 1.1 further splits the network session key into three separate keys for finer-grained integrity control.

The critical security decision in LoRaWAN is the join procedure. Over-the-air activation (OTAA) generates fresh session keys for each join, using a join server that holds the root key (AppKey). Activation by personalisation (ABP) hardcodes the device address and session keys directly into the device, with no mechanism to rotate them without physical access or reprogramming. A single compromised ABP device exposes its session keys permanently. OTAA is strongly preferred for all production deployments.

Protect the join server and network server. These components hold root keys and session keys for the entire fleet — a compromised join server is a fleet-wide compromise. Restrict join server access to authorised network servers only, and store AppKeys in a hardware security module rather than in software. Monitor for abnormal join activity, which can indicate cloned devices attempting to join the network.

Zigbee

Zigbee secures its mesh network using AES-128 at the network layer (network key) and the application support (APS) layer (link key). The trust center — typically the coordinator — distributes the network key to joining devices and manages key updates. Security weaknesses in Zigbee deployments almost always trace back to key management failures, not cryptographic weaknesses.

The most serious risk is the well-known default Zigbee trust center link key, published in the specification as the ASCII string ZigBeeAlliance09. Devices that use this key during joining transmit the network key encrypted with a value that every attacker already knows. An attacker within radio range during a join event can capture the network key and decrypt all subsequent network traffic. Zigbee 3.0 addressed this by introducing installation codes — factory-assigned secrets used to derive a unique link key per device — but many manufacturers still ship devices using the default key. Ensure devices use installation codes or a dynamically negotiated link key, and configure the coordinator to reject joins using the default key.

Rotate the network key periodically and after any device decommissioning — a removed device retains its copy of the network key until rotation occurs. In high-security environments, prefer the centralised trust center mode over the distributed security mode, as it gives tighter control over network membership. Audit the device join log regularly to detect unauthorised devices attempting to join the mesh.

Cloud and Platform Security

API Security and Access Control

IoT devices rely on cloud APIs for configuration, data ingestion, and remote control. API security involves authentication (OAuth2.0, mutual TLS), authorization (RBAC or attribute-based access control), input validation, and rate limiting. Engineers should minimise API privileges and use least-privilege tokens. Logging and monitoring of API calls enable the detection of misuse.

Data Encryption and Privacy

Encrypt data at rest using full-disk, file, or database encryption (AES-256). Encrypt data in transit using TLS 1.3 or IPsec. Implement key management systems that rotate keys regularly and support revocation. Privacy laws (GDPR) require data minimization and clear consent for personal data.

Cloud Security Posture Management

Cloud platforms should be configured securely: disable unnecessary services, enforce network segmentation via virtual networks, and use security groups and firewall rules to restrict access. Continuous cloud security posture management (CSPM) tools scan configurations against best practices and compliance requirements.

Audit Logging, Incident Response, and Resilience

Collect logs from devices, gateways, APIs, and cloud services. Use centralized logging (SIEM) to correlate events. Resilience is key: design systems to tolerate partial outages, use redundant cloud regions, and back up critical data.

Standards and Compliance

IEC 62443 Series

The ISA/IEC 62443 series provides requirements and processes for securing industrial automation and control systems (IACS). It bridges OT and IT domains and defines common terms, risk assessment processes, and certification methodologies. The standard emphasises shared responsibility among asset owners, system integrators, and suppliers across the entire lifecycle [3].

NIST SP 800-183

NIST SP 800-183 (Networks of 'Things') is a foundational document that defines five core primitives of IoT systems: sensor, aggregator, communication channel, eUtility, and decision trigger — and frames reliability and security risk tradeoffs across them [2]. For prescriptive IoT device security guidance covering authentication, encryption, and secure updates, engineers can touch upon NIST SP 800-213. 

ETSI EN 303 645

ETSI EN 303 645 is the first globally applicable consumer IoT security standard. Key provisions include prohibiting default passwords, requiring a vulnerability disclosure policy, and mandating that software be kept updated. The standard forms the basis for regulatory certification schemes, including the UK's PSTI Act and the EU Cyber Resilience Act [4].

FDA Cybersecurity Guidance for Medical Devices

The U.S. FDA recognises cybersecurity as a component of device safety. Its 2023 final guidance urges manufacturers to integrate security into their Quality Management System, using a secure product development framework (SPDF). It requires controls such as authentication, authorization, cryptography, event logging, resiliency, and secure updates.

IoT Security Solutions Landscape

IoT Security Best Practices

1. Perform asset inventory and risk assessment. Maintain a real-time inventory of all devices and their attributes. Use automated discovery tools to identify unmanaged and rogue devices. Risk scoring should consider CVSS/EPSS, asset value, and exploitation status [8].

2. Segment networks and enforce least privilege. Implement microsegmentation around critical assets. Apply zero trust principles: authenticate every device and user and enforce granular access controls.

3. Secure the device lifecycle. Provision devices with unique credentials and secure keys; validate firmware integrity at boot; implement secure update mechanisms with cryptographic signatures. Maintain patch management processes and decommission devices at end-of-life.

4. Encrypt data and protect APIs. Encrypt data at rest and in transit using strong algorithms and protocols. Implement API authentication and authorization; limit tokens by scope and time [8].

5. Integrate threat intelligence and behavioural analytics. Enrich detection with threat intelligence feeds and analytics to identify abnormal behaviour.

6. Plan incident response and resilience. Develop an incident response plan and test it regularly. Build redundancy into systems and design for fail-safe modes.

7. Ensure compliance with standards. Align designs and processes with IEC 62443, NIST SP 800-183, ETSI EN 303 645, and industry-specific guidance.

8. Cultivate a security culture. Train engineers and operators on secure coding, threat awareness, and proper device management.

Conclusion

IoT security is no longer optional. The explosion of connected devices, coupled with high-profile botnets, ransomware campaigns, and data breaches, demands rigorous, engineering-driven security. Engineers must design systems with defense-in-depth, secure device lifecycles, network segmentation, and continuous monitoring. Standards like IEC 62443, NIST SP 800-213, and ETSI EN 303 645 provide structured guidance, and modern platforms help manage the complexity of diverse devices and protocols [2].

Looking ahead, AI-driven threat detection will become more sophisticated. Machine learning models will not only detect anomalies but also anticipate attack patterns and automatically adjust policies. Software Bill of Materials (SBOM) requirements will force vendors to disclose components and known vulnerabilities, enabling supply-chain risk management. Post-quantum cryptography will begin to replace classical algorithms to protect long-lived devices against future quantum attacks. Regulations will continue to evolve, pushing manufacturers to build secure, updatable products by design.

FAQs

How is IoT security different from traditional IT security?

Traditional IT security focuses on servers, desktops, and enterprise networks. IoT security must account for constrained devices with limited processing power, heterogeneous protocols (Modbus, Zigbee, BACnet), physical safety implications, and long device lifecycles. IoT devices often lack patching mechanisms and cannot run agents. Engineers must rely on hardware roots of trust, secure boot, agentless monitoring, and network segmentation. Standards like IEC 62443 provide OT-specific guidelines.

What is zero-trust segmentation, and why is it important for IoT?

Zero-trust segmentation divides networks into small zones and requires authentication and authorization for every connection. It treats all devices and users as untrusted by default. In IoT environments, a compromised sensor or controller resulting from a security breach should not have unrestricted access to other systems. Segmenting by device type, function, and risk level reduces the impact of breaches.

How can engineers manage unpatchable legacy devices?

Legacy devices may lack vendor support or secure update mechanisms. Implement compensating controls such as network isolation, virtual patching via intrusion prevention systems, strict firewall rules, and continuous monitoring for anomalies. Plans should be made to replace legacy devices over time.

What role does vulnerability disclosure play?

Vulnerability disclosure policies allow researchers to report flaws ethically. ETSI EN 303 645 requires a vulnerability disclosure policy for consumer IoT devices. A coordinated response ensures vulnerabilities are addressed promptly and patches are released. Effective programs follow coordinated vulnerability disclosure (CVD) principles, where researchers and vendors collaborate on remediation timelines before public release. Delayed remediation increases exposure, while premature disclosure without available patches can accelerate exploitation.

How do IoT security solutions differentiate themselves?

Platforms vary in discovery methods, risk scoring, deployment models, and integrations. Palo Alto uses ML with 2000 attributes. Cisco embeds sensors in switches. Microsoft uses multi-factor fingerprinting with Azure Sentinel. Armis provides agentless, out-of-band discovery. Claroty offers deep OT/medical visibility. Nozomi and Forescout provide unified IT/OT/IoMT coverage. Engineers should assess which capabilities align with their assets and risk tolerance.

Why is encryption critical even for seemingly innocuous data?

Attackers can derive significant insights from seemingly benign telemetry. Device location, usage patterns, and sensor readings can reveal operational secrets or personal habits. Encrypting data at rest and in transit prevents eavesdropping and tampering. Even within a secure network, insider threats or misconfigurations could expose data.

References

[1] Imperva, “Breaking Down Mirai: An IoT DDoS Botnet Analysis,” 2016. [Online]. Available: Link

[2] NIST SP 800-183, “Networks of ‘Things’.” [Online]. Available: Link

[3] IEC 62443, “Security for Industrial Automation and Control Systems.” [Online]. Available: Link

[4] ETSI EN 303 645, “Cyber Security for Consumer Internet of Things.” [Online]. Available: Link

[5] Cloudflare, “2025 Q3 DDoS Threat Report.” [Online]. Available: Link

[6] Rambus, “Hardware Root of Trust: Everything You Need to Know.” [Online]. Available: Link

[7] Promwad, “Secure Boot and Firmware Integrity in Industrial IoT Devices.” [Online]. Available: Link

[8] Link11, “IoT Security in the Cloud: 2024 Guide.” [Online]. Available: Link

[9] U.S. Food and Drug Administration, “Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions.” [Online]. Available: Link