Prevent the omission by defining cryptographic requirements in design and code review, then testing that each sensitive operation actually encrypts, signs, hashes or verifies as intended. Use approved libraries and wrappers instead of ad hoc code, and add automated checks for missing calls, disabled validation, or plaintext handling in critical paths.
Why Missing Cryptographic Steps Are Usually a Process Failure, Not a Library Failure
A missing crypto call usually happens because the design never made the requirement explicit, or the implementation path was left open to ad hoc handling. The practical risk is not only weak protection, but also false confidence, especially when code compiles and tests pass while encryption, signing, hashing, or verification never actually occurs.
That is why the control point belongs in design review and code review, not only in later testing. If a sensitive operation depends on cryptography, the requirement should be visible enough that reviewers can ask whether the correct primitive is used, whether validation is enabled, and whether plaintext ever appears in a critical path.
Using an approved cryptography wrapper is often better than allowing every team to call primitives directly. A wrapper can standardise safe defaults, reduce bypasses, and make it easier to spot places where the expected step is missing entirely. NHIMG’s Cryptography Basics Guide is useful when teams need to map those primitives to the exact operation being protected.
What to Verify in Code, Tests, and Reviews
The most effective mitigation is to make omission detectable. Add checks that fail when a critical branch omits encryption, signing, hashing, or verification, and make those checks part of the normal build and review flow rather than a separate security afterthought.
That means looking for the absence of expected calls, but also for weaker failure modes such as validation being disabled, a fallback path returning plaintext, or a helper function silently skipping a security step. These are the cases that slip through when reviewers focus only on whether crypto exists somewhere in the codebase.
Automated tests should exercise the security-relevant path, not just the happy path. If the code is supposed to verify a signature or reject unsigned input, the test suite should confirm that invalid or unprocessed data fails closed. Missing coverage here is often how a skipped step survives to production.
A useful secondary check is to confirm that the approved library is actually being used end to end. In practice, teams often import a secure wrapper but still leave one legacy path or exception handler that bypasses it, which defeats the design intent even when the main path looks correct.
How Teams Keep the Omission from Reappearing
Mitigation is strongest when it is structural. Put cryptographic expectations into secure coding standards, reuse approved helpers by default, and make deviations visible in review so developers have to justify them. When the codebase contains many sensitive paths, the goal is consistency, not just correctness in one component.
NHIMG’s CWE Top 25 Guide is a useful companion when you want to understand how missing critical steps, weak validation, and plaintext handling show up as recurring software weaknesses. It helps teams treat a missed cryptographic step as a root-cause pattern rather than a one-off defect.
Where the step protects a cryptographic material or trust boundary, team ownership matters as much as technical enforcement. Developers need a clear pattern to follow, reviewers need a checklist that names the expected operation, and release gates need to block code that leaves the protection implicit instead of explicit.
For teams that also need a governance lens, use a lightweight risk assessment around any user flow or service interaction that depends on cryptography. NHIMG’s AI Risk Assessment Guide is not about cryptography itself, but it illustrates the broader discipline of scoping risks, identifying failure modes, and assigning treatment before they become production surprises.
Risk and Threat Considerations
A missing cryptographic step can turn a control failure into direct exposure of sensitive data, forged messages, or untrusted input being accepted as valid. The danger is often highest in paths that appear routine, because they are less likely to receive the same scrutiny as login or payment flows.
Failure mechanism: A developer omits the required security call, routes around the approved wrapper, or leaves validation disabled in an edge case, so the system processes data without the intended cryptographic protection or trust check.
Impact: Attackers may read plaintext, alter data without detection, replay material that should have been verified, or exploit the unprotected path to undermine higher-level controls that depend on cryptographic assurance.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V15 — Secure Coding and Architecture | Missing crypto steps are prevented through secure design and code review. |
| V11 — Cryptography | The subject is specifically about ensuring required cryptographic operations are actually performed. | |
| Recommendation — Define cryptographic requirements in design and code review, then verify every sensitive path enforces them. Verify that each sensitive operation uses the intended cryptographic primitive and mode. | ||
| NIST SP 800-53 Rev 5 | SA-11 — Developer Testing and Evaluation | Automated checks are needed to detect omitted security steps in implementation. |
| SI-10 — Information Input Validation | Disabled validation or unverified input can let unprotected data flow through critical paths. | |
| Recommendation — Add tests that confirm required cryptographic operations occur and fail closed when they do not. Enforce validation checks so sensitive paths reject unverified or plaintext handling. | ||
| CIS Controls v8 | 16 — Application Software Security | Application security controls should prevent insecure custom crypto and missing security steps. |
| Recommendation — Use approved libraries and secure code review to block custom cryptography and missing checks. | ||
Practitioner Guidance
What to verify: Check that each sensitive operation has an explicit cryptographic requirement and that tests prove the requirement is enforced on every relevant code path, including fallback and error-handling paths.
Common mistake: Treating the presence of a crypto library as sufficient. The real question is whether the code actually invokes the right primitive with the right settings at the right point in the flow.
Decision rule: If a path handles sensitive data, trust, or integrity, fail the review unless the implementation shows the expected encrypt, sign, hash, or verify step clearly and repeatably.
Practitioner takeaway: The best mitigation is to make omission obvious before release, because missing cryptography is usually discovered only after a path has already been trusted.