Draft:Embedded systems security

Submission declined on 30 June 2026 by ChrysGalley (talk). This draft appears to contain text generated by a large language model (such as ChatGPT). You cannot use LLMs to generate article content. LLM-generated pages with certain obvious signs of being machine generated may be deleted without notice. Instead, only summarize in your own words a range of independent, reliable, published sources that discuss the subject. See the advice page on large language models for more information. If you would like to continue working on the submission, click on the "Edit" tab at the top of the window. If you have not resolved the issues listed above, your draft will be declined again and potentially deleted. If you need extra help, please ask us a question at the AfC Help Desk or get live help from experienced editors. Please do not remove reviewer comments or this notice until the submission is accepted. Where to get help If you need help editing or submitting your draft, please ask us a question at the AfC Help Desk or get live help from experienced editors. These venues are only for help with editing and the submission process, not to get reviews. If you need feedback on your draft, or if the review is taking a lot of time, you can try asking for help on the talk page of a relevant WikiProject. Some WikiProjects are more active than others so a speedy reply is not guaranteed. How to improve a draft Wikipedia:Contributing to Wikipedia – a basic overview on how to edit Wikipedia. Help:Wikitext – how to use the markup Help:Referencing for beginners – how to include references Wikipedia:Article development – how to develop your article Wikipedia:Writing better articles – how to improve your article Wikipedia:Verifiability – make sure your article includes reliable third-party sources You can also browse Wikipedia:Featured articles and Wikipedia:Good articles to find examples of Wikipedia's best writing on topics similar to your proposed article. Improving your odds of a speedy review To improve your odds of a faster review, tag your draft with relevant WikiProject tags using the button below. This will let reviewers know a new draft has been submitted in their area of interest. For instance, if you wrote about a female astronomer, you would want to add the Biography, Astronomy, and Women scientists tags. Add tags to your draft Editor resources Easy tools: Citation bot (help) | Advanced: Fix bare URLs Declined by ChrysGalley 58 days ago. Last edited by ChrysGalley 58 days ago. Reviewer: Inform author. Resubmit Please note that if the issues are not fixed, the draft will be declined again.

• Comment: This appears to be an AI assisted submission, which means we can't accept it. ChrysGalley (talk) 18:13, 30 June 2026 (UTC)

Embedded systems security is the application of computer security principles to embedded systems, including firmware, microcontrollers, systems on a chip, connected devices, industrial controllers, medical devices, vehicles, and other computing systems that are built into larger electrical, mechanical, or physical products. The field addresses the protection of device hardware, firmware, software, data, communications, update mechanisms, physical interfaces, and supply chains against unauthorized access, modification, disruption, or misuse.^[1]

Embedded systems security differs from general-purpose computer security because embedded devices often have constrained processing power, memory, storage, energy, and user interfaces. Many devices are deployed for long service lives, are difficult to patch, interact with the physical world, or operate in safety-critical environments.^[2] Security failures can affect not only information systems, but also physical processes, equipment availability, user safety, privacy, and operational continuity.^[3]

Embedded systems security applies to both standalone and networked devices. It includes consumer Internet of things devices, routers, cameras, appliances, automotive electronic control units, industrial automation equipment, building controls, medical devices, robotics, aerospace systems, and other cyber-physical systems.^[2][4]

The scope of the field typically includes:

• protection of firmware and boot processes;
• secure device identity and authentication;
• software and firmware update mechanisms;
• protection of secrets, keys, and user data;
• access control for network, physical, and debug interfaces;
• vulnerability disclosure and lifecycle support;
• secure manufacturing, provisioning, and decommissioning;
• supply-chain risk management for hardware, firmware, software, and third-party components.

The main goals of embedded systems security include confidentiality, integrity, availability, authenticity, resilience, privacy, and safety. Because embedded systems often control physical devices, integrity and availability may be as important as confidentiality. For example, unauthorized modification of control firmware, sensor data, actuator commands, or calibration parameters can affect the operation of a physical product or process.^[1]

The National Institute of Standards and Technology defines device cybersecurity capabilities as cybersecurity features or functions that computing devices provide through their own hardware and software. Its core baseline for Internet of Things devices includes capabilities related to device identification, device configuration, data protection, logical access to interfaces, software update, and cybersecurity state awareness.^[2]

Embedded systems may be attacked through hardware, firmware, software, wireless interfaces, wired networks, physical access, supply chains, and maintenance tools. Common attack surfaces include:

• network services and embedded web interfaces;
• wireless protocols, including Bluetooth, Wi-Fi, cellular, and proprietary radio links;
• bootloaders and firmware update mechanisms;
• JTAG, Serial Wire Debug, UART, and other debug or test interfaces;
• insecure storage of cryptographic keys, credentials, or personal data;
• third-party software components, vendor software development kits, and open-source libraries;
• exposed management interfaces and default credentials;
• physical probing, fault injection, and side-channel attacks.

A large-scale academic study of embedded web interfaces found vulnerabilities in many firmware images from commercial off-the-shelf devices, illustrating how embedded web services can expand the attack surface of networked devices.^[5]

Hardware and firmware weaknesses are also tracked by the Common Weakness Enumeration project. MITRE identifies weaknesses such as improper access control for on-chip debug and test interfaces, improper restriction of software interfaces to hardware features, improper access control for register interfaces, and improper protection against physical side channels as hardware-security concerns.^[6][7]

Firmware is a major security boundary in embedded devices because it initializes hardware, configures memory, loads operating systems or applications, and controls low-level device behavior. Firmware compromise can be difficult to detect and may persist across resets or software reinstallation.

Common controls include secure boot, measured boot, signed firmware images, rollback protection, hardware roots of trust, write protection for critical regions, and integrity monitoring. NIST Special Publication 800-193 describes platform firmware resiliency in terms of mechanisms that protect firmware and critical data from unauthorized changes, detect unauthorized changes, and recover rapidly and securely from attacks.^[8]

Secure update mechanisms allow manufacturers and operators to patch vulnerabilities, correct operational defects, and maintain devices during their service lives. Update mechanisms may include local update tools, remote management systems, or over-the-air firmware updates.

Secure update systems generally authenticate update packages, verify cryptographic signatures, protect update metadata, prevent rollback to vulnerable versions, and provide recovery mechanisms if an update fails. Research on secure embedded-device updates has emphasized that update systems must account for the constraints of realistic Internet of Things deployments, including low-end hardware, intermittent connectivity, multiple stakeholders, and long device lifecycles.^[9]

Embedded devices often require device-unique identities for authentication, authorization, fleet management, and secure communication. These identities may be provisioned during manufacturing or first boot and may be implemented using hardware security modules, secure elements, trusted execution environments, or protected flash storage.

Access control must cover not only user-facing interfaces but also service ports, maintenance accounts, remote management protocols, cloud connections, application programming interfaces, and internal debug interfaces. Data-protection controls may include encryption of data at rest and in transit, secure storage of keys, minimization of collected data, and deletion or reset mechanisms when devices are transferred, serviced, or retired.^[2]

Many embedded products include debug, test, or manufacturing interfaces that are useful during development and production but risky in deployed products. Interfaces such as JTAG, Serial Wire Debug, UART consoles, bootloader shells, boundary-scan ports, and factory test modes can expose memory, registers, firmware, secrets, or privileged commands if left enabled or insufficiently protected.^[6]

Typical controls include disabling unnecessary interfaces, requiring authenticated debug access, limiting debug authorization by lifecycle state, blowing or locking security fuses, protecting bootloader command modes, and separating manufacturing credentials from production credentials.

Embedded systems security is increasingly treated as a lifecycle process rather than a feature added at the end of development. Secure development activities may include threat modeling, security requirements, code review, static and dynamic analysis, fuzz testing, dependency management, vulnerability disclosure processes, incident-response planning, and end-of-life policies.

ENISA describes secure software development guidelines as a fundamental building block for Internet of Things security and emphasizes that security measures should apply across the device, communication, network, and service ecosystem throughout the product lifetime.^[4] The Cybersecurity and Infrastructure Security Agency promotes "secure by design" and "secure by default" practices intended to shift more responsibility for security outcomes toward technology manufacturers.^[10]

Embedded devices commonly integrate hardware components, third-party firmware, open-source software, real-time operating systems, vendor libraries, cloud services, manufacturing tools, and device-management platforms. Security therefore depends on both the product design and the integrity of the supply chain.

Supply-chain controls may include supplier security requirements, provenance tracking, reproducible builds, signed artifacts, secure provisioning, component vulnerability monitoring, and software bills of materials (SBOMs). SBOMs are used to identify software components and dependencies so that manufacturers and operators can assess exposure when vulnerabilities are disclosed.

Consumer Internet of Things products include cameras, smart speakers, appliances, home automation systems, routers, toys, and wearable devices. Security concerns include default passwords, insecure cloud connections, unnecessary network services, poor update support, data collection, and weak privacy controls. ETSI EN 303 645 provides a baseline cybersecurity standard for consumer IoT devices, including provisions related to default passwords, vulnerability disclosure, software updates, secure storage of credentials, communication security, attack-surface reduction, data protection, and user-data deletion.^[11]

Industrial embedded systems are used in industrial control systems, SCADA, programmable logic controllers, sensors, drives, robots, building controls, and process automation. These systems often prioritize availability, safety, deterministic timing, and long service life. The ISA/IEC 62443 series defines requirements and processes for implementing and maintaining secure industrial automation and control systems and addresses security across operations, product development, integration, and lifecycle management.^[12]

Medical embedded systems include implantable devices, patient monitors, diagnostic equipment, drug-delivery systems, surgical systems, and connected health devices. Security issues in medical devices can affect patient safety, privacy, device availability, and clinical operations. The United States Food and Drug Administration publishes guidance on medical device cybersecurity considerations and information to include in premarket submissions for devices with cybersecurity risk.^[3]

Modern vehicles contain many embedded systems, including electronic control units for powertrain, braking, steering, infotainment, body control, driver assistance, and telematics. Security concerns include remote interfaces, in-vehicle networks, over-the-air updates, supply-chain components, and the potential safety consequences of compromised control systems.

Commonly referenced standards, frameworks, and guidance include:

• NISTIR 8259A, which defines a core baseline of Internet of Things device cybersecurity capabilities;^[2]
• NIST SP 800-193, which provides platform firmware resiliency guidelines;^[8]
• ETSI EN 303 645, which provides baseline cybersecurity requirements for consumer Internet of Things devices;^[11]
• ISA/IEC 62443, which defines cybersecurity requirements and processes for industrial automation and control systems;^[12]
• FDA medical-device cybersecurity guidance for premarket submissions and device lifecycle security;^[3]
• ENISA guidance on secure software development lifecycle practices for Internet of Things products;^[4]
• MITRE CWE hardware and firmware weakness classifications.^[7]

• Cyber-physical system
• Firmware
• Hardware security
• Industrial control system
• Internet of things
• Secure boot
• Software bill of materials
• Supply chain attack
• Trusted execution environment

Category:Embedded systems Category:Computer security Category:Firmware Category:Hardware Category:Internet of things Category:Cyber-physical systems Category:Industrial automation