Common mistakes with mode of operation include using a block cipher mode that does not provide integrity, reusing nonces or IVs, and applying the same key and nonce combination more than once. Defenders should check that encryption design matches the data type, authentication is added where required, and implementation follows the scheme’s exact rules.
What goes wrong when a mode is chosen for convenience instead of security properties?
A mode of operation is not just a technical detail, it determines whether encryption gives confidentiality only, or confidentiality with integrity, and how safely the cipher can be used on repeated data. The most common mistakes are choosing a mode that looks familiar, then assuming it protects against tampering, replay, or misuse without checking the exact security guarantees.
That becomes dangerous when teams treat encryption as a single control rather than a specific construction with strict rules. A mode that is fine for bulk confidentiality may be the wrong choice for data that can be modified in transit or stored in an adversarial environment.
For teams learning the underlying primitives, the Cryptography Basics Guide is a useful reference point because it covers AEAD modes, nonces, IVs, and the difference between encryption and message authentication.
Why nonce and IV reuse breaks the scheme
Reusing a nonce or IV is one of the most common and most damaging implementation errors because many modes require uniqueness, not secrecy. When that requirement is violated, the same plaintext relationships can become visible, ciphertexts can become malleable, and an attacker may be able to recover information or manipulate messages without detection.
The problem is often operational, not mathematical. Systems that generate nonces from counters, timestamps, or shared state can duplicate values after a restart, failover, cloning event, or multi-instance deployment unless the uniqueness rule is engineered end to end.
- Check whether the mode requires uniqueness, unpredictability, or both.
- Verify that nonce generation remains safe across restarts, replicas, and parallel workers.
- Confirm that the implementation rejects accidental reuse rather than silently continuing.
If a design depends on a reused nonce or IV being "unlikely" rather than impossible, it is already too weak for production use.
When integrity is missing, encryption can still be altered
Another common mistake is using a block cipher mode that provides confidentiality but not integrity, then assuming encrypted data cannot be changed. Without authentication, an attacker may be able to tamper with ciphertext and influence the resulting plaintext, or trigger application logic that trusts decrypted output before validating it.
This is why modern practice favours authenticated encryption where the data can be modified by an untrusted party or where correctness matters as much as secrecy. If a scheme does not authenticate the ciphertext, the application usually has to supply that protection separately, and the two pieces must be designed together.
Teams that work with encryption design should compare that requirement with the guidance in OWASP Non-Human Identity Top 10, because secret handling, long-lived credentials, and unsafe reuse often show up alongside weak cryptographic implementation choices.
Why implementation errors matter even when the algorithm is sound
Even a sound mode can fail if the implementation ignores the scheme’s exact rules. Common errors include using the wrong parameters, feeding predictable IVs, decrypting before verifying authenticity, reusing the same key and nonce combination, or applying the mode to the wrong data type and trust boundary.
This is where many failures become invisible in testing. A setup may appear to work, pass functional tests, and still violate the cryptographic contract in ways that only show up under replay, tampering, concurrency, or recovery scenarios.
For cloud and application teams, the operational angle often looks similar to access-control mistakes, which is why the Top 10 Secrets Management Mistakes and Top 10 AWS IAM Mistakes can be helpful adjacent reading when the root issue is unsafe reuse, overbroad trust, or poor lifecycle discipline around sensitive material.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Nonce and IV reuse mistakes often coexist with leaked or mishandled secrets. |
| NHI-07 — Long-Lived Secrets | Repeated key and nonce use is a lifecycle weakness tied to long-lived cryptographic material. | |
| Recommendation — Control secret handling so cryptographic material and related values are not exposed or reused unsafely. Rotate cryptographic secrets and enforce short-lived use where reuse risk exists. | ||
| NIST SP 800-53 Rev 5 | SC-13 — Cryptographic Protection | The question is about correct use of cryptographic modes and required protection properties. |
| IA-5 — Authenticator Management | Mismanaged keys and nonces are lifecycle issues for sensitive authentication material. | |
| Recommendation — Use approved cryptographic protections that preserve confidentiality and, where needed, integrity. Manage cryptographic authenticators with controlled issuance, storage, rotation, and revocation. | ||
| OWASP ASVS | V11 — Cryptography | Mode-of-operation mistakes are directly within application cryptography verification. |
| Recommendation — Verify that cryptographic design uses correct modes, parameters, and authenticated encryption where required. | ||
Practitioner Guidance
What to verify: Confirm the exact security property the mode is supposed to provide, then test the implementation against that rule set rather than against a generic "encrypted" label. If the design does not include integrity where tampering is possible, treat that as a design defect, not an optimization.
Decision rule: If a nonce or IV must be unique, build uniqueness into the system architecture and monitoring, not into developer memory. If the team cannot prove uniqueness across retries, restarts, and parallel processing, the design is not production-ready.
Common mistake: Teams often fixate on the cipher algorithm and ignore the mode, yet the mode is what determines whether the construction is safe for the actual threat model. The implementation can be "using AES" and still be insecure.
Practitioner takeaway: Treat mode selection, nonce discipline, and authenticity as one control surface, because the strongest encryption primitive still fails when its operational rules are broken.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 20, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org