Embedded Systems Constraints | CompTIA Security+ SY0-601 | 2.6d

In this video you will learn about embedded systems constraints such as: power, compute, network, cryptography & authentication, inability to patch, range, cost, & implied trust.


Embedded systems are built for specific purposes and are optimized to meet different kinds of constraints, such as performance, timing, power, & cost.[1]  Power consumption is one of the main design constraints for embedded systems to which a designer must balance power consumption with features & capabilities.[2]  Attackers can exploit systems by causing a system to shut down or crash by simply causing loop instructions somewhere on the system to consume all power.  So when these devices are deployed, securing power sources & ensuring adequate power during the device’s highest utilization periods should be a consideration.[2]


Embedded systems typically have tight constraints on both functionality & implementation.  In particular, they must guarantee real time operation reactive to external events, conform to size and weight limits, budget power & cooling consumption, satisfy safety & reliability requirements, and meet tight cost targets.  Many embedded systems are physically located within some larger artifact.  Therefore, their form factor may be dictated by aesthetics or form factors existing in pre-electronic versions.  In transportation & portable systems, weight may be critical for fuel economy or human endurance.  So for example, a mission critical system like a blackbox would have more stringent size & weight requirements than others because of its use in flight vehicles.[3]


An embedded system is often used to interact with the environment for the purpose of monitoring & controlling external devices.  To do this, analog inputs & outputs must be transformed to & from digital signals.  In some systems, smart sensors & actuators that contain their own analog interfaces, power switches, & small CPUs are often used to offload interface hardware from the central embedded computer.  This brings an additional advantage of reducing the amount of system wiring & number of connector contacts by employing an embedded network rather than a bundle of analog wires.[2]

Cryptography & Authentication

Cryptography is the art & science of manipulating data so that outside parties cannot undo or mimic the manipulation without knowledge of a secret.  It enables high-level functions such as:[4]

  • Confidentiality of information during storage & transmission
  • Authentication of users
  • Integrity of received/retrieved information
  • Non-repudiation of transactions
  • Availability of data & resources
  • Controlled access to information & resources

While there are many benefits in terms of security offered by cryptography, there is a downside.  Cryptography is very computationally intensive.  The extra processing steps involved in security protocols create a heavy CPU utilization tax on systems that use cryptographic security frequently.[4] 

Inability to Patch

A patch is a set of changes to a computer program or its supporting data designed to update, fix, or improve it.[5]  However, not all patches resolve issues they were designed to address.  As a matter of fact, upwards of 25 percent of all patches fail to fix the issue & directly cause problems for an end user.  To make matters worse, 40 percent of these faulty patches result in crashes, hangs, data corruption, or additional security issues.[2]  When it comes to embedded systems, a bad actor could just simply break or remove some functionality that was previously relied on by the control system patch in order to cause problems with the system.[2]


Embedded systems are typically constrained in terms of 3 system performance criteria:  space, time, & energy.  Performance requirements are directly translated into constraints imposed on the system’s resources, such as code size, execution time, & energy consumption.  These resource constraints conflict with each other in a complex manner, making it difficult for a system developer to apply a well-defined design methodology in developing a real-time embedded system.  The smaller the device, the more direct relationship to the size of the transmitter, thereby dictating the frequency & distance range the device supports.  So, the smaller the transmitter, the shorter the range distance.[2]


Even though embedded systems have stringent requirements, cost is almost alway an issue.  Although designers of systems large & small may talk about the importance of cost with equal urgency, their sensitivity to cost changes can vary dramatically.  A reason for this may be the effect of system costs on profitability is more a function of the proportion of cost changes compared to the total system cost, rather than compared to the digital electronics cost alone.[3]

Implied Trust

Implied trust is where a specific section of code or a component depends on the previous code or component for its security, thereby making it reliant on that code to have appropriately performed the security measures required to make the entire system safe.  When it comes to cyber security, implied trust should be used sparingly as it relates to embedded systems.  There are constraints that limit what full-fledged trust can be implemented, let alone what can be operationally expedient; therefore, certain aspects of the design rely on an implied trust, even if that is “assuming” a wireless network will be secure so that there is no need to protect plaintext protocols.[2]


  1. Kuchcinski, K. (2019). Constraint Programming in Embedded Systems Design: Considered Helpful. Microprocessors and Microsystems.
  2. Santos, O.; Taylor, R.; Mlodziannowski, J. CompTIA Security+ SY0-601 Cert Guide.
  3. Koopman, P. Embedded System Design Issues (The Rest of the Story).
  4. (2009, July 7). Understanding Crypto Performance in Embedded Systems: Part 1. Embedded.
  5. (2009, Oct 14). Microsoft Issues Biggest Software Patch on Record. News.com