What do organisations get wrong about using AES to secure business data?

Why This Matters for Security Teams

AES is a strong block cipher, but many organisations mistake cryptography for governance. Encryption can protect data at rest or in transit, yet it does not answer the harder questions: who can decrypt, when decryption is allowed, how keys are protected, and whether plaintext is copied into logs, caches, or downstream services. NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls makes that separation clear by treating access control, key management, and auditability as distinct control problems.

That gap matters because encrypted business data still depends on surrounding identity, policy, and operational controls. If key access is broad, rotation is weak, or application logic exposes decrypted records to too many services, AES only reduces exposure in one layer while leaving the larger attack path intact. NHIMG research shows this pattern is common: the Ultimate Guide to NHIs — Key Research and Survey Results reports that 79% of organisations have experienced secrets leaks, and 96% store secrets outside secrets managers in vulnerable locations.

In practice, many security teams discover the weakness only after an exposed key or over-permissioned service account has already made the encryption irrelevant.

How It Works in Practice

The right way to use AES is to treat it as one control in a broader protection model. First, define the data boundary: what is encrypted, where keys live, and which applications are allowed to request decryption. Second, separate data protection from authorisation. A service may hold a valid key and still need runtime policy checks before it can unwrap a record, especially where business data crosses trust zones.

For most environments, this means combining AES with strong key management, least privilege, and auditable access paths. Security teams should prefer envelope encryption, where a data key encrypts the content and a separate key-encryption key protects the data key. Keys should be stored in a hardened secrets manager or hardware-backed system, rotated on a defined schedule, and tied to clear ownership. Where possible, use short-lived credentials for the systems that call the decrypt service, and ensure that logs, backups, analytics pipelines, and cache layers never retain plaintext longer than necessary.

• Use AES for confidentiality, not as a substitute for access policy.
• Limit decrypt rights to the smallest set of workloads and operators.
• Rotate keys and review which services can request decryption.
• Log decrypt events, key usage, and administrative changes separately.
• Test for plaintext leakage in application traces, exports, and backups.

For sensitive workflows, NHI governance also matters because service accounts and API keys often mediate encryption operations. NHIMG’s Ultimate Guide to NHIs — Key Research and Survey Results highlights that 80% of identity breaches involved compromised non-human identities, which is exactly why key custody and identity controls cannot be separated. These controls tend to break down when legacy applications decrypt data locally and then pass plaintext through batch jobs, ETL tools, or third-party integrations because the key no longer protects the actual exposure path.

Common Variations and Edge Cases

Tighter encryption controls often increase operational overhead, so organisations must balance stronger key governance against application complexity and recovery requirements. That tradeoff becomes most visible in regulated systems, shared data platforms, and high-availability services where too much rigidity can interrupt business continuity.

One common edge case is mode selection. AES-CBC, AES-GCM, and other modes are not interchangeable, and there is no universal standard for misuse resistance across every implementation. In practice, current guidance suggests authenticated encryption modes are usually safer for business data because they provide confidentiality and integrity together, but only if nonce handling and implementation discipline are correct. Another edge case is key scope: a single master key across many datasets creates a large blast radius, while per-tenant or per-application keys improve containment at the cost of more lifecycle management.

Teams also get tripped up by backup and disaster recovery. Encrypted backups are only helpful if key access is tightly controlled during restore, because restore paths often have broader privileges than production paths. Finally, encryption at the database layer does not automatically protect data once it is exported to reports, screenshots, message queues, or external processors. NIST’s control guidance and NHIMG’s SAP Breach analysis both reinforce the same lesson: the control fails when decrypted business data escapes the boundary you thought AES alone would contain.

Related resources from NHI Mgmt Group

• What do organisations get wrong about automated data classification?
• What do security teams get wrong about business-context data classification?
• What do organisations get wrong about cryptographic bill of materials data?
• What should organisations get wrong about using digital wallets for onboarding?