A Deep Dive into Real-World Cryptographic Inventories and Their Patterns
Modern organizations rely on cryptography for nearly every business function: securing data, authenticating users, protecting transactions, validating documents, and enforcing trust across internal and external systems. Yet very few can describe with confidence what cryptography they actually use.
When we perform a cryptographic discovery with a systematic scan of certificates, keys, protocols, libraries, configurations, and dependencies, the results are almost always surprising, occasionally alarming, and consistently eye-opening.
This post summarizes the common findings across discovery engagements. It highlights what typically emerges when visibility becomes complete.
Executive Summary (For C-Level Readers)
Across industries, cryptographic discovery consistently reveals:
- Organizations underestimate the scale of cryptographic use.
- Legacy and deprecated algorithms persist deep in infrastructure and supply-chain integrations.
- Quantum-vulnerable cryptography remains the default in most environments.
- Governance is fragmented; ownership is poorly defined.
- Future business impact can be severe: exposure of long-lived data, signature forgery risk, compliance violations, and slow or costly migration paths.
- Without automated visibility, PQC readiness is impossible to measure and even harder to achieve.
Quantum Readiness
One of the most valuable high-level outputs of crypto discovery is the Quantum Readiness Distribution: a snapshot of how many cryptographic assets fall into categories such as:
- Quantum-unsafe: any cryptography not resistant to potential quantum attacks.
- Quantum-resistant: any cryptography resistant to potential quantum attacks.
The chart below represents typical findings of cryptographic discovery across most enterprise environments:
It is possible to break down the quantum-unsafe category into more precise resilience levels, which may be very useful for CISOs and tech managers:
- Legacy-classical: cryptography that is safe today, but unsafe against future quantum attacks.
- Deprecated-weak: cryptography that is not safe today, since it uses deprecated algorithms like MD5, SHA-1, DES, etc.
The chart below represents a typical distribution between legacy and deprecated cryptography:
Although they represent a small percentage of the total, cryptographic artifacts that use deprecated algorithms, such as SHA-1 and MD5, pose an immediate risk to companies, further reinforcing the importance of having a cryptographic inventory.
Cryptographic Objects by Type
Cryptographic discovery uncovers a much wider variety of cryptographic objects than most teams expect. Typical distributions include:
- Certificates: TLS, mTLS, device certificates, internal CA-issued certs
- Keys: RSA, EC, AES, SSH keys
- Protocols: TLS versions, VPN, IPSec, WireGuard
- Application: executable code and libraries containing cryptographic functions, such as OpenSSL, BoringSSL, NSS, Bouncy Castle, and custom code
- Storage: cryptographic artifacts related to the protection of data at rest
The chart below illustrates a typical distribution of cryptographic object types:
Cloud Provider Distribution
Cryptography is no longer just on premises. A discovery typically identifies:
- AWS ACM, KMS, CloudHSM
- Azure Key Vault, Managed HSM
- Google KMS
- HashiCorp Vault
- CI/CD pipelines storing secrets
What is the challenge here?
Cloud cryptography tends to proliferate without governance. Certificates are created by developers, services, DevOps pipelines, and third-party integrations often without lifecycle tracking or expiration monitoring.
The chart below illustrates a typical distribution of cryptography across a multi-cloud environment in financial institutions:
Cryptography Heatmap
The cryptography heatmap visually correlates:
- System criticality
- Cryptographic vulnerability
- Migration complexity
The chart below represents a common cryptographic heatmap for large companies:
Based on this heatmap, we can see that the greatest risk related to the quantum threat lies in keys and certificates.
It is possible to correlate this data with the risk level of each client application in the heatmap. For example, payment systems, e-commerce platforms, and databases that store sensitive customer data have higher risks.
Applications developed with older technologies (COBOL, older Java versions) also present higher risk, among other factors.
Historical Evolution
The Historical Evolution View is a longitudinal analysis that shows how an organization’s cryptographic posture improves (or deteriorates) over time, an impactful output of the cryptography discovery program.
Unlike a one-off snapshot, historical data reveals progress, resilience, and trends in the adoption of modern, quantum-safe, and well-governed cryptography.
Most organizations begin with an environment that looks chaotic: large volumes of legacy keys, outdated TLS protocols and inconsistent certificate governance.
Over time, as discovery becomes continuous and remediation takes place, the picture changes meaningfully.
The chart below represents an expected evolution of quantum resilience in a company:
Cryptography in Use
Discovery tools should reveal how cryptography is actually being consumed within the environment, detailing each specific object type.
Common findings include:
Digital Certificates
Of the data that can be read from a digital certificate, the most important element in relation to quantum resilience is the signature algorithm used in its issuance process. This is what guarantees the authenticity and integrity of the holder’s data.
The chart below represents an example discovery of the different types of signature algorithms used in digital certificates:
Organizations dramatically underestimate the number of digital certificates and assume TLS-type certificates are the only ones, usually signed by RSA-SHA256 or ECDSA-SHA256. This is rarely the case.
For example, RSA-SHA1 certificates, in the example above, were probably issued by an internal CA, usually managed by a single department.
The following chart shows an example of the distribution of quantum resistance in an organization. Quantum-safe certificates are (currently) rare and are generally issued by internal PKIs:
In the table below, we can see two capture records, representing a Quantum-Safe internal test certificate and a classic one, signed with RSA-SHA256.
Keys
Keys are the literal root of trust for every cryptographic operation of authentication, encryption, signing, integrity, and non-repudiation, yet they are also the most inconsistently governed and poorly tracked objects across most environments.
In nearly every organization, keys are far more numerous, more diverse, and more deeply embedded than internal teams expect.
Here are the most common findings:
- Private Key: confidential cryptographic key used in asymmetric cryptography, primarily for data decryption, digital signature creation, and authentication
- Public Key: non-secret half of an asymmetric key pair, primarily used for encryption, signature verification, and identity validation
- Symmetric Key: confidential key used in symmetric cryptography, often used for both encryption and decryption. It is essential for data protection and secure sessions. AES and ChaCha keys, with a minimum of 128 bits, are considered quantum-safe.
The chart above shows a common distribution of the different types of keys found in a large company. Cryptographic inventory tools use sensors that connect to different types of key repositories, such as KMS (Key Management Systems), HSM (Hardware Secure Module), applications, and file systems. The result depends heavily on which sensors are used and the scope of inventory.
The asymmetric RSA and ECDH algorithms used as industry standards are not quantum-resistant. Symmetrical keys, depending on their size, are mostly quantum-resistant.
Ephemeral keys, used in communication protocols such as TLS, are not inventoried in the process; instead, the protocol used is analyzed.
In the table below, we can see an example of 3 types of cryptographic keys inventoried, with the one bordered in red representing an immediate risk.
Protocols
Protocols determine how encryption is applied, and how keys, certificates, and identities are exchanged. They are also one of the most common sources of hidden technical debt, legacy exposure, and migration blockers.
Most organizations assume their environments rely on “modern TLS,” but discovery often surfaces a far more heterogeneous and sometimes outdated mix of protocol implementations.
The chart below shows some categories found across enterprise networks:
HTTPS
Even in modern environments, discovery frequently identifies:
- SSL 3.0 (in legacy systems or embedded devices)
- TLS 1.0 and 1.1 (often still enabled for backward compatibility)
- TLS 1.2 (widely used, but with outdated cipher suites)
- TLS 1.3 (the current safe standard, but adopted inconsistently across internal and external systems)
Typical findings:
- Old Java or .NET applications hard-code deprecated protocols
- Load balancers support insecure fallback modes
- Devices and appliances still negotiate SSL/TLS variants that are no longer compliant with modern standards
IPSec
IPsec remains widely used in:
- Site-to-site VPNs
- Branch office routers
- Data center interconnects
- Cloud-to-on-prem hybrid links
But cryptographic discovery often finds:
- Legacy IKEv1 still active
- Outdated cipher suites (3DES, AES-128 with SHA-1)
- Weak Diffie-Hellman groups
- Vendor appliances locked to old cryptographic profiles
OpenVPN
OpenVPN is a widely deployed VPN protocol, especially in:
- Remote access setups
- Cloud development environments
- Contractor access networks
- CI/CD pipelines and automation clusters
Key findings include:
- Outdated OpenSSL versions bundled with older OpenVPN builds
- Weak TLS cipher suites
- Long-lived static keys
- Shared VPN keys across teams
WireGuard
WireGuard is increasingly adopted for:
- Developer connectivity
- Container-to-container networking
- Mesh VPN overlays
- Cloud dev/test environments
Discovery commonly finds:
- WireGuard running outside official IT governance
- Keys generated on developer machines
- Missing rotation policies
- Peer configuration files stored in repositories or shared folders
- Deployments that bypass enterprise PKI and monitoring
Others (Miscellaneous and Niche Protocols)
The “Others” category usually captures low-visibility or specialized protocols, such as:
- SSH (long-lived host keys)
- RDP (Remote Desktop) with TLS
- SMTPS, IMAPS, LDAPS
- Storage protocols (S3-compatible, NFS with Kerberos)
Many organizations do not realize how many of these protocol variants run in production—and each one may use its own library stack, cipher suite configuration, and certificate trust path.
The chart below shows the proportion of quantum-resistant vs. quantum-unsafe protocol findings:
The discovery process should also be able to show the artifacts found in detail, as in the example table below:
Application Software
Unlike certificates or protocols, application cryptography is embedded inside codebases, libraries, dependencies, containers, build pipelines, configuration files, and proprietary logic.
When we conduct discovery assessments, application cryptography is where the most unexpected, risky, and expensive-to-fix findings usually appear.
The chart below shows an example of common patterns uncovered across modern environments:
Executables
An executable is a compiled application or program that runs directly on a system. Examples include:
- WhatsApp.exe
- Teams.exe
- nginx
- mysqld
These are the top-level artifacts that perform operations, including cryptographic ones.
Why executables matter in cryptography discovery: they often:
- Consume libraries that implement cryptography
- Initiate TLS connections
- Validate certificates
- Sign or decrypt data
- Host APIs with cryptographic dependencies
- Include statically compiled cryptographic logic
Dependencies
A dependency is a library directly linked to or loaded by an executable, where a verifiable relationship can be established.
For example:
- openssl.so as a dependency of the OpenSSL command-line tool
- libcrypto.so used by nginx
- bcrypt.dll used by Teams.exe
- bcpkix-jdk18on-1.83 imported into a custom Java application
Dependencies usually contain actual cryptographic implementations:
- Encryption and decryption functions
- Hashing and MAC algorithms
- TLS handshake logic
- Signature verification
- Random number generation
Dependencies often introduce hidden cryptography because applications may unknowingly inherit outdated, vulnerable, or non-compliant implementations from the libraries they use.
Libraries
A library is a standalone cryptographic file discovered on a system without any established link to an executable. This typically happens during filesystem scans, container inspections, or VM snapshot analysis.
Examples:
- libcrypto.so located in /usr/local/lib
- Bouncy Castle provider (bcprov-jdk18on-1.83), dynamically loaded via Java security settings
These libraries may or may not be active but they represent latent cryptographic capability in the environment.
Standalone libraries usually indicate:
- Historical leftovers from past deployments
- Potential attack surface
- Untracked cryptographic components
- Future upgrade and migration risks
- Risk of accidental reuse
- Unmanaged software supply chain artifacts
They must be categorized properly, so they do not distort the picture of cryptography in use, while still being included in the broader CBOM (Cryptography Bill Of Materials) for lifecycle risk assessment.
The following table shows examples of information typically captured in relation to applications:
Storage
Storage is an important layer of an organization’s cryptographic posture because it determines how data at rest is encrypted, protected, managed, and governed.
Across discovery assessments, storage-layer findings frequently reveal:
- Inconsistent encryption coverage
- Outdated key management practices
- Legacy encryption configurations
- Vendor defaults that no one has reviewed
The chart below shows storage cryptographic artifacts found in a large enterprise multi-cloud architecture:
Cloud Object Storage
Object storage is the backbone of modern cloud architecture. In AWS, this usually appears in discovery as:
- Amazon S3 buckets
- S3 Glacier / Deep Archive
- Account-level storage mechanisms (logs, audit trails, snapshots, artifacts)
Cloud Databases
Services like:
- AWS RDS (MySQL, PostgreSQL, Oracle, SQL Server, MariaDB)
- Azure SQL / CosmosDB
- Google Cloud SQL / Spanner
Block and File Storage
This includes:
- AWS EBS volumes
- Azure Disk Storage
- GCP Persistent Disks
The chart below shows an example ratio between quantum-safe and quantum-unsafe cryptographic storage artifacts:
In a typical scenario, most artifacts are quantum-resistant since they use symmetric cryptography, as shown in the sample findings below:
Cryptography Available
Cryptography Available refers to every cryptographic artifact discovered in an environment that is present but not necessarily in use.
These artifacts often include:
- Libraries
- Configuration files
- Algorithms
- Framework-embedded cryptography modules
- System-level or application-level cryptographic components
These objects are detected because they exist on the system not because an application is actively using them.
This category is essential for visibility, risk identification, and governance maturity, as unused or untracked cryptographic artifacts often reveal blind spots, legacy remnants, or undocumented exposure that may impact future migrations, including PQC transformation.
Library Cryptographic Objects
These are cryptographic libraries discovered through filesystem or package scanning that cannot be attributed to a specific executable or application.
Why they appear:
- Installed as part of a system package
- Left behind from older applications
- Present in unused container layers
- Installed by developers but never used
- Deployed in previous builds but no longer referenced
Examples:
- Multiple OpenSSL versions on the same server image
- Java runtime shipping unused JCE providers
- Python wheels containing inactive cryptography modules
- Old SSH libraries bundled in base OS images
The chart below shows an example of library findings:
Configuration Files
Configuration files can contain:
- Cryptographic parameters
- Cipher suite definitions
- Protocol settings
- Certificate paths
- Key references
- Algorithm preferences
Even if unused, their presence indicates:
- Legacy configurations
- Old development/test pipelines
- Cryptographic defaults that may re-activate
Examples:
- Old Apache or NGINX configs pointing to deprecated cipher suites
- Legacy VPN config files (*.ovpn, ipsec.conf)
- TLS templates in /etc/ssl
- Multiple java.security files across JDK versions
- Kubernetes config maps with unused TLS parameters
Algorithms
Static code analysis (SAST) and scanning tools frequently detect:
- Encryption and hashing functions in source code
- Algorithms referenced in unused modules
- Fallback cryptographic paths
- Hard-coded algorithm names
The chart below shows an example of algorithm findings:
In the example below, we observe the use of SHA-1, a deprecated and insecure algorithm, in the hazmat layer of a Python cryptography library:
Business Impact Assessment
A cryptographic inventory only becomes valuable when it translates technical findings into business understanding, operational priorities, and executive action.
Most CISOs and senior stakeholders do not need raw cryptographic data—they need clarity on what it means for the organization.
The purpose of the Business Impact Assessment (BIA) is to answer that question.
What we usually assess
Confidentiality Impact
- Long-term data (health, financial, national ID, IP) at risk of HNDL (Harvest Now Decrypt Later) attacks
Integrity Impact
- Digital signatures vulnerable to future forgery (Trust Now Forge Later risk)
- Code signing compromise risk
- Workflow, contract, and document integrity risk
Availability Impact
- Systems that may break during migration
- Vendor dependencies that cannot be upgraded
- Cloud service limitations affecting deployment timelines
Regulatory and Compliance Impact
- GDPR, CCPA, HIPAA, PCI DSS, DORA, Monetary Authority of Singapore
- UAE-specific and GCC critical infrastructure requirements
- NIST PQC migration guidelines
- Sector-specific regulations (finance, energy, telecom)
Benchmarking & Compliance
Cryptographic inventories produce thousands of technical findings, but CISOs and risk leaders need a way to interpret those findings in context.
Benchmarking & Compliance provides that context by linking cryptographic visibility to industry standards, regulatory expectations, and peer performance.
Benchmarks typically show:
- Most organizations are in the early stages of quantum-safe transformation
- Cryptography inventories are incomplete or manually maintained
- Migration timelines exceed regulatory expectations
- Vendor readiness varies widely
- Cloud providers are ahead in PQC, while enterprises lag behind
We also map findings to compliance frameworks:
- NIST PQC standards
- ETSI quantum-safe readiness
- NSA CNSA 2.0 timelines
- ISO 27001 cryptography domain
- Sector regulators (DORA, MAS, etc.)
Remediation Plan
CISOs and technology leaders need a plan that converts findings into prioritized action, clear ownership, and a realistic path forward.
The Remediation Plan is where technical discovery becomes an execution roadmap, aligning security, engineering, architecture, cloud, infrastructure, DevOps, and business units around a common objective:
Reducing cryptographic risk and preparing the organization for the post-quantum era.
Phase 1 — Immediate Risks (Classical Cryptography Problems)
- Deprecated algorithms
- Weak keys
- Expired or expiring certificates
- Compromised or unprotected key material
- Legacy protocols in production
Phase 2 — Strategic Modernization and PQC Preparation
- Standardizing cryptographic libraries
- Eliminating hard-coded cryptography
- Migrating to managed key services
- Normalizing certificate governance
- Experimentation with PQC algorithms
Phase 3 — Quantum-Safe Transformation
- PQC readiness roadmap
- Hybrid deployments
- Vendor dependency monitoring
- Continuous cryptographic discovery and governance
Conclusion
Cryptographic discovery consistently shows that organizations are operating on cryptographic foundations that are far more complex and far more vulnerable than they realize.
It reveals legacy artifacts, hidden risks, inconsistent governance, and unknown dependencies that would otherwise undermine security and delay PQC migration.
For executives, cryptographic discovery is not just a security exercise.
It is a strategic visibility program that informs budgeting, risk tolerance, regulatory compliance, and digital transformation planning.
For security and engineering teams, it provides the most accurate and actionable foundation for preparing the organization for a quantum-safe future.