2.1 AES-ECB: Why it should almost never be used
2.2 AES-CBC: The traditional embedded standard
2.3 AES-XTS: Encryption for storage and memory
2.4 AES-CTR: Turning AES into a stream cipher
2.5 AES-CCM: Authenticated encryption for constrained systems
2.6 AES-GCM: The modern standard for secure communication
3. Which AES Mode should embedded teams use today?
AES is one of the most widely used cryptographic algorithms in embedded systems today. It protects industrial gateways, FPGA-based communication systems, automotive networks, VPNs, secure boot chains, firmware updates, and cloud-connected IoT devices. But in real products, engineers rarely use “AES” alone.
AES itself only defines how a single 128-bit block of data is encrypted. Real embedded systems process packets, firmware images, data streams, and memory regions of arbitrary size. This is where AES modes of operation become important.
The selected mode determines how AES behaves in practice:
For engineering teams, choosing an AES mode is therefore not just a cryptographic decision. It is also a system architecture decision. The AES algorithm itself is standardized by the National Institute of Standards and Technology (NIST) in FIPS 197, while the different operating modes are mainly defined in the NIST SP 800-38 series.
This article explains the most important AES modes used in embedded systems and where they are typically applied in practice.
AES itself only defines how individual 128-bit blocks are transformed using a symmetric key. That means it can only encrypt one small block at a time. A lot of embedded systems, however, need to handle ethernet packets, firmware images, FPGA bitstreams, sensor streams, flash memory contents and VPN traffic. Modes of operation define how AES processes larger amounts of data and how consecutive blocks interact with each other.
Different modes solve different engineering problems:
This is why two systems can both use AES but behave completely differently from a security and implementation perspective.
Electronic Codebook (ECB) is the simplest AES mode. Each plaintext block is encrypted independently using the same key. This simplicity makes ECB easy to implement in hardware. Historically, it occasionally appeared in older FPGA or microcontroller designs because it requires very little control logic. But ECB has a major security weakness: Identical plaintext blocks produce identical ciphertext blocks.
As a result, patterns in the original data remain visible after encryption. Structured data can therefore still leak information even though it is technically encrypted.
This becomes especially problematic for:
ECB is therefore generally not recommended for protecting real application data. From an engineering perspective, ECB is mostly relevant today as an example of what modern embedded systems should avoid.
Cipher Block Chaining (CBC) became one of the most widely used AES modes in embedded systems for many years. In CBC mode, each plaintext block depends on the previous encrypted block. This removes the visible pattern problem found in ECB. CBC also introduces an Initialization Vector (IV), which ensures that identical plaintexts encrypted with the same key produce different ciphertext outputs.
CBC was widely used in older VPN and IPsec systems, legacy secure boot architectures, encrypted firmware containers and embedded Linux security implementations. One important limitation is often overlooked: AES-CBC only provides confidentiality and does not provide authentication or integrity protection on its own. Because of this, many systems combined AES-CBC with HMAC-SHA256 to detect manipulation. For years, AES-CBC + HMAC became a standard design pattern in embedded security architectures.
CBC is still approved by NIST and still appears in legacy systems, but many modern designs increasingly migrate toward authenticated encryption modes like AES-GCM.
XTS-AES was specifically designed for storage encryption applications. Unlike communication-oriented modes such as GCM, XTS focuses on protecting data stored in SSDs, eMMC and flash memory, encrypted file systems, FPGA configuration storage and external DDR memory. The mode is standardized in NIST SP 800-38E and is widely used in full-disk encryption systems such as Linux dm-crypt and enterprise storage platforms.
One important difference is that XTS primarily provides confidentiality for stored data, but not authentication or integrity protection. This makes XTS suitable for storage scenarios where random block access is required, but less suitable for network communication protocols. From an engineering perspective, XTS is attractive because sectors can be accessed independently, random reads and writes are supported efficiently, parallel processing is possible and it fits well into storage controllers and memory encryption architectures. Typical embedded applications include:
However, XTS is not intended to replace authenticated encryption modes like AES-GCM for communication security.
Counter Mode (CTR) transforms AES into a stream-like encryption system. Instead of chaining blocks together, CTR encrypts incrementing counter values and combines them with plaintext data. This creates several important advantages for embedded systems. AES-CTR supports parallel processing, low latency, high throughput and efficient FPGA pipelining. Because blocks are independent, CTR fits particularly well into hardware acceleration architectures and DMA-driven datapaths.
Typical applications include:
AES-CTR also has an important limitation: It provides no authentication or integrity protection. And even more critically: Reusing the same counter/nonce combination with the same key can expose relationships between plaintexts and severely compromise confidentiality. If the same key and counter combination is reused twice, attackers may recover information about the encrypted data.
This operational risk is one reason why many modern systems moved toward AES-GCM.
CCM stands for Counter with CBC-MAC and is standardized in NIST SP 800-38C. Like GCM, it provides both confidentiality and integrity in a single construction. Internally, CCM uses AES-CTR for encryption and CBC-MAC for authentication. Both NIST and BSI (TR-02102-1) recommend it for embedded use.
CCM shows up in many protocols built for constrained environments:
The key engineering difference compared to GCM is that CCM processes data in two sequential passes: first the CBC-MAC over the plaintext, then the CTR encryption. This rules out the full parallelization that GCM supports and makes CCM a poor fit for high-throughput FPGA pipelines. But CCM only needs the AES block cipher itself. There is no Galois field multiplier required. That makes it a practical choice where silicon area or code size is tight.
Like GCM, CCM requires unique nonces for every message under the same key. The nonce length is variable and depends on the maximum message size. Tag lengths are also configurable, but BSI TR-02102-1 recommends at least 96 bits.
In practice, the choice between GCM and CCM usually comes down to throughput versus footprint. GCM fits high-speed FPGA and network designs. CCM fits constrained devices where a small implementation matters more than raw performance.
Galois/Counter Mode (GCM) is now one of the most important AES modes in embedded systems. AES-GCM combines confidentiality, integrity protection and authentication in a single construction. Technically, GCM combines AES-CTR for encryption and GHASH for authentication. The mode is standardized in NIST SP 800-38D and has become a common choice for modern secure communication systems. Today, AES-GCM is commonly used in:
From an engineering perspective, AES-GCM is attractive because it supports parallelization, maps efficiently onto FPGA architectures, provides authenticated encryption, avoids separate HMAC processing and offers high throughput with relatively low overhead. This makes it highly suitable for modern embedded communication systems.
AES-GCM also introduces one of the most underestimated engineering challenges in embedded security: IV management. GCM requires that initialization vectors (IVs), often also called nonces, are never reused with the same encryption key. If an IV is reused, both confidentiality and authentication break. The repeated CTR keystream exposes the XOR of plaintexts, and the polynomial structure of GHASH lets an attacker recover the authentication key. At that point, messages can be forged without detection. NIST SP 800-38D and BSI TR-02102-1 therefore require strict IV uniqueness for the entire lifetime of a key.
NIST recommends 96-bit IVs because they simplify implementation, improve interoperability, and avoid extra GHASH processing during IV handling.
Tag length matters too. BSI TR-02102-1 requires at least 96 bits. NIST is moving in the same direction and plans to drop support for shorter tags in the next revision of SP 800-38D. Shorter tags make it easier for an attacker to forge valid ciphertext through brute force.
There are also hard limits on how much data a single key can protect. With 96-bit IVs, one IV/key pair must not encrypt more than 2^32 minus 2 blocks. The total across all IVs under one key should stay below 2^59 blocks. Beyond that, the security guarantees of GCM start to degrade. For embedded systems with long-running keys, this means key rotation has to be part of the system design from the start.
In practice, this becomes a real system design challenge:
In many real-world embedded systems, AES-GCM failures are not caused by weak cryptography. They are caused by incorrect system design around nonce handling.
For systems where nonce uniqueness simply cannot be guaranteed, AES-GCM-SIV is worth considering. It is defined in RFC 8452 and recommended by BSI TR-02102-1 since the 2025-01 revision. GCM-SIV derives a synthetic IV from both the nonce and the plaintext. If a nonce is accidentally reused, the only thing leaked is whether the exact same message was encrypted twice. Confidentiality and integrity of all other messages remain intact. This matters especially for embedded devices that face unexpected reboots or power loss, where maintaining reliable nonce state across restarts is genuinely difficult.
There is no universally “best” AES mode. The correct choice depends on the system architecture and security requirements. In practice:
For FPGA and embedded teams, operational behavior often matters more than cryptographic theory:
These practical considerations often determine the real security and reliability of the final product.
AES remains a foundational building block in embedded security. But in real systems, the selected operating mode largely determines how secure, efficient, and robust the implementation actually becomes.
Modern embedded architectures increasingly move toward authenticated encryption modes like AES-GCM because they combine confidentiality and integrity protection in a single mechanism while still supporting efficient FPGA and hardware acceleration implementations. For engineering teams, understanding how AES modes behave operationally is often more important than understanding the mathematics behind AES itself.
Especially in embedded and FPGA-based systems, operational details like IV generation, state persistence across reboots, and authentication handling often determine whether an implementation is actually secure in practice.