How should security teams choose an AES mode for protecting sensitive data at rest and in transit?

Why This Matters for Security Teams

Choosing an AES mode is not a purely cryptographic preference exercise. It determines whether sensitive data is only hidden, or also protected against silent tampering. For data at rest and in transit, that distinction matters because attackers often care less about decrypting everything immediately and more about altering records, replaying values, or exploiting weak implementation boundaries. NIST’s Cybersecurity Framework 2.0 and control-based programs such as NIST SP 800-53 Rev 5 Security and Privacy Controls both reinforce that cryptography must be selected and operated in context, not treated as a checkbox.

That context is often missed when teams standardise on “AES” without specifying the mode, padding, IV handling, or integrity requirements. ECB can leak structure, CBC can protect confidentiality but not integrity on its own, and authenticated modes such as GCM reduce the chance that altered ciphertext is accepted as valid. The operational risk is even higher where secrets, service tokens, and API keys are involved, because compromise frequently spreads through systems that reuse the same encryption pattern across many assets. NHIMG research shows how often poor identity and secret handling becomes an enterprise problem, with the Ultimate Guide to NHIs — Key Research and Survey Results highlighting how widespread leaked or mismanaged credentials remain. In practice, many security teams discover weak mode choices only after data has already been copied, modified, or replayed in production.

How It Works in Practice

The right AES mode depends on what the control objective is at the point of use. If the requirement is confidentiality plus tamper detection, authenticated encryption is usually the best fit, which is why GCM is commonly preferred in modern deployments. If the requirement is only to hide content in a narrow legacy path, CBC may still appear in older systems, but it should not be treated as sufficient protection unless integrity is added separately and correctly. ECB should generally be avoided for structured records because repeated plaintext patterns can expose business logic, identifiers, or data shape.

For practical selection, teams should first decide whether the data is at rest, in transit, or both, then choose the mode that matches the threat model:

• Use authenticated encryption when receivers must detect tampering before accepting data.
• Use unique, unpredictable IVs or nonces exactly as required by the mode.
• Separate encryption design from key management, rotation, and access control.
• Validate library defaults, because insecure parameter choices often negate a sound algorithm.

This is especially important when secrets protect access to services rather than just files. NHIMG’s State of Non-Human Identity Security shows that weak rotation and visibility remain common, which means encryption choices often sit inside a wider identity and secrets-management problem. When AES is used for transport, the implementation should also align with protocol-level protections such as TLS rather than relying on application encryption alone, because layering mistakes can create false confidence. These controls tend to break down when developers mix legacy CBC code, custom padding, and inconsistent nonce handling across services because the cryptography is then correct in theory but fragile in production.

Common Variations and Edge Cases

Tighter encryption choices often increase implementation complexity, requiring organisations to balance stronger integrity guarantees against compatibility and operational risk. That tradeoff is why current guidance suggests treating “AES mode selection” as part of a broader secure-design review rather than a one-time library decision. In some regulated or legacy environments, CBC may remain in place because a protocol, hardware module, or vendor interface cannot easily be changed, but that should be accompanied by explicit integrity controls and a migration plan toward authenticated encryption.

There is no universal standard for this yet across every application stack, especially where developers are mixing application-layer encryption with database encryption, message security, and transport security. The biggest edge case is not the mode itself but the surrounding discipline: poor nonce reuse, weak random number generation, and key reuse across systems can undermine even a strong mode like GCM. Teams should also be cautious about assuming that “at rest” and “in transit” need the same pattern; a storage layer may need envelope encryption and access segregation, while a messaging layer may need authenticated packets and replay resistance. Where sensitivity is high and tampering would be operationally dangerous, the decision should favour authenticated encryption and strict key lifecycle controls over legacy compatibility.

Related resources from NHI Mgmt Group

• How should security teams prioritize sensitive data findings without relying on volume alone?
• How should security teams govern access when sensitive data is spread across multiple systems?
• How should security teams govern sensitive data in file types that cannot be labeled?
• How should security teams handle AI interactions that can expose sensitive data in real time?