The common mistake is treating cryptography as a design assumption instead of an inventory problem. Assessors need to see which libraries, algorithms, keys, and protocols are embedded across code and dependencies. Without that visibility, teams cannot quickly assess exposure, justify design choices, or respond confidently when a component vulnerability is disclosed in a shipped product.
Why cryptography has to be visible as inventory, not just architecture
Product compliance reviewers are not asking whether encryption exists in principle, they are asking what exactly is present in the shipped product. That means teams need a current view of cryptographic libraries, algorithms, key sizes, protocols, and where those components are embedded through direct code and dependencies. A design diagram is not enough if it cannot be reconciled with what is actually deployed.
The practical reason is that cryptography is often inherited through frameworks, SDKs, platform defaults, and transitive packages. Teams that only document the intended design can miss weak algorithms, obsolete protocol versions, duplicated implementations, or hidden dependencies that create inconsistent assurance across products and releases.
For product compliance, the inventory must be precise enough to support assessment decisions. If the team cannot identify the exact component and version in use, it cannot reliably answer whether a requirement is met, whether an exception is justified, or whether a remediation affects one product line or many.
What assessors need to see when a cryptographic component is shipped
Assessors usually need evidence at the component level, not just a statement that "encryption is enabled." The useful evidence is a map from product features to the cryptographic primitives, implementations, and dependency paths that support them, so reviewers can see what is protected, by what mechanism, and in which release.
This becomes especially important when a library or protocol weakness is disclosed after release. If the team has an accurate inventory, it can quickly determine exposure, identify affected builds, and explain whether the issue is reachable, inherited, or already mitigated by configuration or replacement.
That same visibility also helps justify design choices. If a product uses one algorithm because of interoperability constraints, or a specific library because of hardware support, the team should be able to show the dependency chain and the operational reason for the selection rather than treating cryptography as an abstract policy decision.
Where teams usually lose control of crypto visibility
The most common failure is assuming that a secure design review completed once is still true after dependency churn, platform upgrades, and feature work. Cryptographic posture changes when packages are added, defaults shift, or a vendor component silently changes protocol behavior, so visibility has to be maintained continuously rather than captured as a one-time approval.
Another recurring gap is incomplete ownership. Product teams may know which code they wrote, but not which embedded libraries, shared services, or build-time dependencies actually supply the cryptography. That gap makes it hard to assign remediation, because the team cannot tell whether the fix belongs in application code, platform configuration, or dependency management.
Visibility also breaks down when teams use separate implementations for the same function across products. Different stacks may implement TLS, signing, hashing, or key handling in different ways, which creates uneven assurance and makes compliance answers depend on the exact path a request takes through the product.
Risk and Threat Considerations
When crypto visibility is weak, the main risk is not only noncompliance, it is delayed exposure assessment. A vulnerable or deprecated component can remain in shipped software long enough to widen the blast radius, especially when the affected library is buried in transitive dependencies or shared across multiple releases.
Failure mechanism: Teams lose the ability to trace which algorithms, libraries, keys, and protocols are actually present in production, so they cannot rapidly determine scope, reachability, or remediation priority when a weakness is disclosed.
Impact: The result is slower incident response, weaker audit evidence, poor exception handling, and a higher chance that product releases continue to rely on outdated or unapproved cryptographic material.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, NIST CSF 2.0 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | CM-8 — System Component Inventory | Cryptographic libraries and dependencies must be inventoried to support product compliance evidence. |
| SI-2 — Flaw Remediation | Component visibility is needed to assess and remediate crypto-related vulnerabilities in shipped products. | |
| Recommendation — Maintain an inventory of shipped cryptographic components and dependency paths. Use component inventory data to prioritize cryptographic flaw remediation. | ||
| ISO/IEC 27001:2022 | A.8.9 — Configuration management | Cryptographic settings and dependencies must be controlled as part of product configuration. |
| A.8.8 — Management of technical vulnerabilities | Inventory visibility is required to identify affected crypto components after a vulnerability disclosure. | |
| Recommendation — Track cryptographic configurations and dependency changes through formal change control. Map disclosed vulnerabilities to affected cryptographic components and versions. | ||
| NIST CSF 2.0 | ID.AM-02 — Software, hardware, data, and external service inventories are maintained | Crypto libraries and protocols are part of the shipped software inventory needed for assurance. |
| Recommendation — Include cryptographic components in the product software inventory. | ||
| CIS Controls v8 | CIS-1 — Inventory and Control of Enterprise Assets | Component visibility depends on maintaining an accurate asset and software inventory. |
| Recommendation — Keep an accurate inventory of software components that implement cryptography. | ||
Practitioner Guidance
What to verify: Require an inventory that ties each product and release to the specific cryptographic components it uses, including direct and transitive dependencies, protocol versions, and any managed key or certificate dependencies. If the team cannot point to the exact shipped component, the control is not yet trustworthy.
What to measure: Track whether crypto components are recorded at release time and whether the inventory can answer a disclosure question within hours rather than days. A good signal is whether the team can quickly isolate affected products without manual code archaeology.
Common mistake: Treating a secure architecture diagram as proof of compliance. The compliance question is about evidence of what is deployed, not what the design intended to deploy.
Practitioner takeaway: The test is not whether cryptography was approved once, but whether the organisation can still prove what is in the product when a reviewer or vulnerability notice forces an immediate answer.
Related resources from NHI Mgmt Group
- What do teams get wrong about SaaS visibility and compliance?
- What do teams get wrong about SSDF compliance when they rely on tool sprawl instead of process visibility?
- What do security teams get wrong about data visibility and NHI risk?
- What do teams get wrong about continuous compliance in identity programmes?
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 September 30, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org