Start by aligning the shipping product with a precise Security Target, then verify that every referenced algorithm and module already has current CAVP or CMVP validation. Labs assess evidence, not intent, so configuration control, signed updates, and traceability matter as much as the cryptographic design itself. If the cryptographic baseline is unstable, certification work usually stalls before the lab finishes its review.
Why Common Criteria cryptography work starts with the shipping build
For common criteria, cryptography is judged as part of a specific product configuration, not as a generic design pattern. Security teams need the evaluated build, the exact Security Target, and the cryptographic boundary to line up before the lab can assess anything useful. If the product version, module set, or operating parameters are still moving, the evidence base is already unstable.
The practical implication is that “good cryptography” is not enough. The lab needs to see which algorithm choices are claimed, where those claims apply, and how the implementation is packaged in the release that will actually be certified. That is why baseline control, version traceability, and release discipline become cryptographic prerequisites, not just program management tasks.
In practice, this means the team should treat the Security Target as the contract for the crypto story. Every referenced function, key length, mode, and module boundary should be reproducible in the shipped artefact, with no hidden dependence on an untracked library, a build flag, or a later patch line. If the product and the documentation diverge, the evaluation tends to become a document repair exercise instead of a certification review.
What validation status the lab will expect to see
Common Criteria reviews usually become much easier when the cryptographic components already have current validation evidence, especially where the product claims a validated algorithm or module rather than a purely custom implementation. Security teams should confirm whether the claimed cryptographic module has current validation status, whether the algorithm claim matches that validation, and whether the certificate scope actually covers the way the product uses it.
That distinction matters because validation is not a blanket approval of every deployment context. A lab will care whether the validated component is the same one embedded in the product, whether the operational mode matches the certificate, and whether any integration work changes the security claim. If those details are fuzzy, the team may have to rework the claim set or narrow the evaluation scope before the review can proceed.
Teams should also separate “the algorithm exists” from “the evidence is acceptable.” A cryptographic design can be mathematically sound and still fail evaluation if the module version is unvalidated, the implementation is uncertified, or the product claims more assurance than the evidence supports. For this reason, the right preparation question is often not “is this crypto strong?” but “can we prove the exact crypto we ship is the crypto we claim?”
How to make cryptographic evidence reviewable rather than aspirational
The lab will usually test the strength of the evidence chain, not the enthusiasm of the architecture diagram. Teams should make updates signed, configuration changes controlled, and cryptographic references traceable from the Security Target into build artefacts, test records, and release notes. That traceability is what lets a reviewer connect the claimed algorithm to the implementation that was actually assessed.
This is also where configuration drift becomes a certification risk. If one component is rebuilt from a newer library, if a vendor patch changes the module behaviour, or if a deployment parameter silently alters the crypto mode, the evidence set may no longer describe the product on the bench. Strong teams therefore lock the crypto baseline early, keep change control tight, and preserve proof that the evaluated binary matches the released binary.
For teams that need a reference point on key handling and algorithm lifecycle, NIST SP 800-57 Key Management is useful for framing the lifecycle discipline that underpins stable crypto claims. Where the broader assurance case also depends on organisational control discipline, ISO/IEC 27001:2022 Information Security Management reinforces the need for controlled change, documented responsibility, and security-aware configuration management.
Risk and Threat Considerations
Cryptography preparation fails most often because the claim surface is bigger than the evidence surface. The product may ship with a module that is technically sound, but if the validation is stale, the configuration is mutable, or the certificate scope does not match the deployment, the evaluation can stall or fail even when the underlying design is acceptable.
Failure mechanism: The most common failure is configuration drift, where the evaluated build, the document set, and the live release diverge enough that the lab can no longer verify the cryptographic claim set against a stable artefact.
Impact: The result is usually delay, re-scoping, or a failed assurance argument, and in the worst case the team must restart evidence collection after a release or module change invalidates earlier assumptions.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-57 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-57 | None — Key Management | The question centers on cryptographic lifecycle and validation readiness. |
| Recommendation — Align key lifecycle, algorithm selection, and cryptoperiod evidence with the evaluated product build. | ||
| ISO/IEC 27001:2022 | A.8.24 — Use of cryptography | Common Criteria crypto preparation depends on controlled cryptographic use and documented claims. |
| A.8.32 — Change management | Certification can fail when crypto-relevant builds or parameters drift from the evaluated baseline. | |
| Recommendation — Document cryptographic use and restrict claims to the evaluated configuration. Lock and track changes to cryptographic components and configuration. | ||
| NIST SP 800-53 Rev 5 | CM-2 — Baseline Configuration | The evaluated product must match a controlled cryptographic baseline. |
| CM-6 — Configuration Settings | Crypto modes, parameters, and module settings must be set and preserved consistently. | |
| SA-10 — Developer Configuration Management | Traceable release control is essential when the lab assesses the shipping cryptographic build. | |
| Recommendation — Establish a baseline for the certified build and prevent unauthorised crypto drift. Define and enforce approved cryptographic settings for the evaluated configuration. Track and control the exact software components and release artefacts under evaluation. | ||
Practitioner Guidance
What to prioritise: Freeze the cryptographic story before you engage the lab. The first priority is not tuning algorithms, but proving that the Security Target, module scope, release version, and validation records all describe the same shipping product.
What to verify: Confirm that every cryptographic module and algorithm you cite is current, within scope, and referenced exactly as implemented. If the validation evidence does not cover the shipped configuration, treat that as a certification blocker, not a documentation nuance.
Practitioner takeaway: Common Criteria cryptography succeeds when the team can prove a stable, reproducible, release-level claim, not when it can merely describe a strong design.
