Cryptographic posture management is often framed as a post-quantum cryptography (PQC) initiative. Quantum readiness is a major reason to understand enterprise cryptography. It is also one of many reasons to do that work now.
An expiring certificate can interrupt a customer service. An exploited gateway can expose credentials used elsewhere. A vulnerable cryptographic library can appear in several application builds. Replacing a key can affect a partner connection or access to retained data. Security teams need to understand those dependencies before they can decide what to change.
Cryptographic posture management connects keys, certificates, algorithms, protocols, configurations and libraries to the assets, applications, endpoints, workloads and business services that use or depend on them. That context helps teams move from a technical finding to the services affected, the owners responsible and the evidence needed to verify a response.
Five security outcomes
| Outcome | The question it helps answer | Examples |
|---|---|---|
| Keep critical services available | What could interrupt this service, and what will a change affect? | Certificate expiry, rotation, key deletion and recovery readiness |
| Scope and respond to cryptographic incidents | What cryptographic material could be exposed, and where else is it used? | Appliance exploits, exposed keys and supplier compromise |
| Reduce cryptographic exposure | Which weaknesses matter most to the services we operate? | Vulnerable libraries, weak settings, shared keys and visibility gaps |
| Protect trust and machine identity | Which systems rely on this issuer, signing key or credential? | CA changes, workload identity, federation and signing infrastructure |
| Demonstrate cryptographic assurance | What protects this business service, and what evidence supports that view? | Service CBOMs, audit evidence and supplier reviews |
These outcomes overlap. A signing-key incident can affect identity, availability and assurance at the same time. A shared dependency map lets the teams responsible examine the same service from different starting points.
Why dependency mapping changes the decision
A useful cryptographic posture management program discovers cryptography, assesses its condition and maintains the relationships needed to act on findings. Qinsight’s foundations of cryptographic posture management explains this operating model.
Consider an illustrative payments service. Its public gateway presents a Transport Layer Security (TLS) certificate. The application uses a different client certificate to authenticate to a banking partner. Processing workloads contain cryptographic libraries, a cloud key-management service protects stored data, and an identity provider signs the tokens the application accepts.
Each record may already exist somewhere. The certificate authority knows what it issued. Software tools know what went into a build. Cloud APIs expose key metadata. Application records identify owners. Connecting those records lets a team follow an expiring certificate to a payment flow, or start with that payment flow and examine the cryptography it depends on.
A flat inventory can flag expiry, weak algorithms or outdated components when the required fields are available. It may not establish where an object is deployed, which service relies on it, or which consumers need testing after a change. Those decisions require relationships and current operational context.
A Cryptographic Bill of Materials (CBOM) contributes to that context. CycloneDX supports cryptographic assets and relationships to software components, so a CBOM can contain dependency information. Its usefulness for a live decision depends on its scope, evidence and freshness. A snapshot from an earlier release cannot establish what is running today without updated observations.
The practical combination is a maintained dependency map and portable, scoped CBOMs. The map supports ongoing investigation and change planning. A CBOM records a defined view for an application review, incident, supplier exchange or migration milestone. Each relationship should preserve its source and observation time: a system that stores a private key, one permitted to invoke a remote key and one that merely trusts its signatures have different exposure paths.
For more on these complementary roles, see CBOMs and cryptographic inventories.
PQC migration uses the same foundation
PQC remains a major use case for cryptographic posture management. Organizations need to locate key-establishment and signature functions vulnerable to sufficiently capable quantum computers, identify the implementations that provide them, and understand the services and external parties involved in replacing them.
The US National Institute of Standards and Technology (NIST) published its first three finalized PQC standards in August 2024: ML-KEM in FIPS 203 for key establishment, and ML-DSA in FIPS 204 and SLH-DSA in FIPS 205 for digital signatures. Moving to supported implementations requires decisions about protocols, vendors, compatibility and deployment.
For confidentiality, the risk of collecting encrypted information now for future quantum decryption makes data sensitivity and required secrecy periods relevant to prioritization. Signature migration raises different questions about authentication, software verification and the lifetime of devices and signed artifacts.
Dependency mapping supports that work by helping teams:
- Connect cryptographic functions to deployed systems, owners and business services, with discovery gaps visible.
- Prioritize changes using data protection needs, service importance and the time required to change dependent systems.
- Identify client, server, supplier and hardware constraints that prevent applications from migrating independently.
- Group changes around service paths and test interoperability, performance and recovery behavior.
- Verify the deployed result, distinguishing an available capability from an enabled configuration and observed behavior.
A service might use post-quantum key establishment on one external connection while retaining conventional signatures or conventional key establishment elsewhere. Its migration status should describe those boundaries. The ownership and deployment evidence established through everyday certificate and key work makes that assessment easier to maintain.
Qinsight’s five-stage PQC migration framework develops the program sequence. Why PQC migration runs through the configuration management database (CMDB) explains how asset and service records connect findings to accountable teams and controlled change.
Keep critical services available
Cryptography can become an availability dependency long before an algorithm needs replacement. Certificates expire, consumers reject new credentials, and data becomes inaccessible when a required key disappears. Service context helps teams prioritize the changes that could interrupt important operations.
Prevent certificate outages
An expiration date provides a deadline. Preventing an outage also requires knowing where the certificate is deployed, which connections rely on it and how the replacement will reach them.
In the payments example, the certificate manager may show a successful renewal while a secondary gateway still presents the old certificate. A recovery environment may have no recent observation. Each deployment needs an owner and a verification step.
Map discovered certificates to listeners, applications and business services. Prioritize by criticality and the lead time needed for renewal, deployment and client testing. After replacement, verify the expected hostnames, regions and failover paths. An endpoint or application CBOM can record the chain, public-key references, observed settings and deployment timestamps.
The CA/Browser Forum’s public TLS requirements increase the importance of reliable deployment processes. Maximum validity for newly issued publicly trusted TLS server certificates is 200 days from March 15, 2026, falling to 100 days from March 15, 2027 and 47 days from March 15, 2029. Those limits do not apply universally to private enterprise certificates.
Useful measures include critical deployments with unresolved expiry risk, time to identify an owner and the proportion of expected deployments verified after renewal.
Read the workflow: Prevent certificate outages with service context.
Plan safer key and certificate rotation
A rotation can succeed at the system issuing a credential while a consumer still expects the old material. The change plan needs to account for both.
Define the operation first. Certificate renewal may retain the same key. Key rotation introduces new material. A certificate authority (CA) change may require trust-store updates. A token-signing transition depends on verification-key distribution and acceptance rules.
Map known consumers and owners before the change. For a banking connection, establish whether the partner trusts an issuer, a certificate or a specific public key. Include scheduled jobs and recovery environments, then plan the update sequence, any overlap and the tests that establish continued service. Incident recovery may require faster removal of old trust.
Key services have their own semantics. AWS Key Management Service (KMS) key-material rotation can retain the logical key and material needed to decrypt older ciphertext. It does not automatically rotate generated data keys or re-encrypt protected data.
Before-and-after CBOMs document the intended scope and observed result. The CA, key manager or deployment system executes the change; cryptographic posture information supports planning and validation. Track consumer verification coverage and exceptions that keep old material active.
Read the workflow: Safer key and certificate rotation.
Extend availability planning
Incomplete certificate renewal and deployment. Compare intended rollout scope with observed fingerprints across load-balancer members, regions, hostnames and recovery paths. This reveals old deployments that an issuance record or a single successful probe can miss.
Key disablement and deletion impact. Trace resources and historical data dependencies before disabling a key, deleting a version or removing access. AWS’s guidance on determining key usage explains why some dependent resources invoke KMS infrequently. Usage records alone cannot establish that a key is safe to delete.
Backup and archive decryption readiness. Connect retained datasets and backup catalogs to historical key versions and recovery procedures. Use that scope to select restore tests. Current production discovery alone cannot prove that an older archive remains decryptable.
Shared dependencies in critical services. Identify services that rely on the same issuer, signing key, hardware security module (HSM) cluster or KMS service. Review the resulting concentration alongside redundancy and recovery design; a highly connected component is not automatically a single point of failure.
Scope and respond to cryptographic incidents
An incident creates an urgent need to understand what the affected system could access and where that authority extends. Cryptographic dependencies help responders assemble a candidate scope, while forensic and access evidence establish what was actually compromised.
Assess cryptographic impact after an exploit
After exploitation of an appliance or application, including a zero-day, patching the software may leave credentials and trust relationships that require attention. The starting question is which cryptographic material the attacker could have reached during the exposure window.
Examine private material stored locally, credentials used to authenticate elsewhere and permissions to invoke remote signing or decryption. A public certificate in a trust store describes a trust relationship; its presence does not establish that the corresponding private key was exposed.
Follow relevant objects to other deployments and dependent services. A shared key may require investigation beyond the original gateway. An incident-scoped CBOM can preserve the affected asset, candidate objects, known consumers and evidence before remediation, followed by a recovery snapshot.
The CISA response to affected Ivanti products in 2024 provides a historical example: its direction to covered federal agencies included revoking and reissuing connected or exposed certificates and keys. Actions in another incident depend on its findings and vendor guidance.
Atlas can support this investigation through collected relationships. Track time to assemble the scope and assign owners, keeping suspected exposure distinct from confirmed compromise.
Read the workflow: Appliance exploits and cryptographic impact.
Respond to an exposed or compromised key
Removing a private key from a repository does not end its authority. Copies may remain in deployments or backups, and other systems may continue accepting its signatures.
Validate the finding and identify the key safely. Public-key fingerprints and authoritative key-service identifiers can correlate records without collecting private values into an inventory. Then follow the key’s purpose. A TLS authentication key raises service impersonation questions. A token-signing key points to relying applications. A code-signing key requires release and artifact evidence. An encryption key requires investigation of protected data and historical access needs.
A key-centered CBOM links the object to associated certificates, evidenced reuse, consumers and services. Responders can organize replacement, revocation or trust removal through the responsible teams, then recheck known dependencies. Session and token invalidation may require separate action, and rotation cannot reverse plaintext disclosure that has already occurred.
Measure time to enumerate verified reuse and the proportion of identified deployments rechecked after the response.
Read the workflow: Exposed private keys and service impact.
Extend incident scoping
Third-party compromise impact. Start with the supplier advisory and trace relevant integration credentials, trust relationships and service owners. A supplier-linked service CBOM helps coordinate investigation and replacement within the known integration scope.
Business email compromise investigation support. Where incident evidence indicates cryptographic exposure, examine application authentication certificates, S/MIME keys or federation credentials and their consumers. Many BEC incidents involve passwords, sessions, OAuth abuse or social engineering instead. Cryptographic scoping complements mailbox and identity response; it does not detect fraudulent invoices or establish that a mailbox incident exposed a key.
Trust restoration after ransomware. Use forensic scope and the recovery plan to identify credentials and trust relationships requiring replacement, then retest restored service paths. Before-and-after evidence tracks the cryptographic recovery work; it does not establish that a restored system is clean or decrypt attacker-encrypted files.
Reduce cryptographic exposure
Security teams need to distinguish a weak or vulnerable component from the deployed services that require action. Mapping findings to applications and owners helps prioritize remediation and check whether it reached the intended environment.
Assess a vulnerable cryptographic library
A library name in a software inventory is a starting point for a vulnerability assessment. The response also needs the affected build, the advisory’s conditions and the workloads where that build runs.
Connect software evidence to application releases, image identities and deployed workloads. Distinguish a system package from a bundled or statically linked copy. Vendor patch information matters because a version string may not reveal a backported fix. A network handshake usually cannot establish the exact underlying library build.
The November 2022 OpenSSL advisory illustrates why applicability matters. Its X.509 issues affected versions 3.0.0 through 3.0.6 and involved specific certificate-verification conditions. It did not establish that every system using TLS was exploitable.
An application or workload CBOM can link the implementation to cryptographic functions and deployments, with an associated Software Bill of Materials (SBOM) and vulnerability assessment. Application owners can prioritize affected service paths, arrange patches and confirm that replacement builds reached the intended workloads.
Track time to establish applicability and verify deployed remediation. A component match, an affected configuration and observed exploitation remain different findings.
Read the workflow: Cryptographic library CVEs and service impact.
Prioritize weaknesses across the estate
Weak protocols and cryptographic configuration. Connect prohibited TLS, Secure Shell (SSH) or virtual private network (VPN) settings to exposed endpoints and important services. Assess the complete configuration against the applicable policy, and distinguish supported capabilities from observed negotiation. TLS 1.2 alone is not evidence of a vulnerability.
Unknown cryptography and missing ownership. Reconcile discovered objects with asset and application records to identify unmanaged issuers, unowned certificates and unassessed systems. Confirm uncertain associations with owners so the output becomes a worklist with a defined coverage boundary.
Shared keys across systems or environments. Locate evidenced reuse across production, test, tenants or business units and review whether it is justified. Key identity and deployment evidence matter here; matching aliases do not establish shared key material.
Unauthorized cryptographic changes. Compare dated observations for unexpected issuers, keys or protocol settings, then reconcile differences with approved work. Reliable history and change records help distinguish normal renewal from changes that need investigation.
Encryption gaps behind gateways and load balancers. Assess each relevant connection segment to establish where encryption terminates and whether the next hop meets policy. Backend topology and internal observations are required; public HTTPS evidence does not establish protection between the gateway, application and database.
Encryption at rest and key ownership. Connect classified databases, storage and backups to configured encryption and key owners using cloud or database evidence. Missing discovery remains unknown coverage. At-rest encryption does not prevent an authorized or compromised application from accessing decrypted data.
Kubernetes and ephemeral workload visibility. Relate deployment identities, image digests, ingress resources and service credentials to applications. Observation time and collection cadence matter because pod addresses change and periodic discovery can miss short-lived workloads.
Cryptographic review in the release process. Compare release CBOMs and approved baselines to identify new dependencies or regressions, then check deployed behavior. Build evidence and a tested delivery integration are needed before using findings as an automated release gate.
OT and embedded device cryptographic debt. Relate long-lived device certificates, shared identities, legacy protocols and firmware dependencies to operational services. Use vendor evidence and approved collection methods suited to operational technology (OT); support constraints and maintenance windows shape remediation.
Protect trust and machine identity
Certificates and keys establish which systems can authenticate, sign software or assert identities. A trust-focused view follows those relationships from the issuer or credential to the systems that accept them. It requires evidence about trust and authorization as well as the objects themselves.
CA compromise and trust changes. Connect a compromised or retiring certificate authority to leaf certificates, deployments and evidenced client trust. Use the applicable advisory to scope replacement and trust distribution. An issuance chain alone cannot show how every client validates it.
Mutual TLS and workload identity coverage. Relate client and server identities to service connections, issuers and acceptance rules. Combine configuration with representative positive and negative tests; a server requesting a client certificate does not by itself establish enforcement or authorization.
Token signing and federation compromise. Map signing keys to relying applications and validation policies to plan trust replacement. Identity configuration and logs are essential. Microsoft’s Storm-0558 analysis provides a historical example of forged-token access involving a signing key and validation behavior.
SSH trust and administrative key sprawl. Keep server host keys distinct from user authentication keys. Network observations can reveal host identities and algorithms; assessing who can log in requires authorization records, certificate policy or host evidence.
Cloud KMS and HSM protection gaps. Connect keys to their consumers, lifecycle controls and effective access. Hardware protection is one part of the assessment: a non-exportable key can still be misused through signing or decryption operations an identity is allowed to invoke.
Certificate issuance and AD CS exposure. Associate validated Active Directory Certificate Services findings with affected identities and services. Assessing escalation paths requires certificate templates, directory permissions and enrollment settings, or findings supplied by specialist identity tooling.
Code signing and software release trust. Connect signing identities to pipelines, signed artifacts and consuming applications to scope a compromised release process. Signing records, timestamping and verification policy determine the assessment; a certificate’s expiration date alone cannot establish the status of every signed release.
CA and key management migration. Map consumers, owners, trust distribution and historical requirements before moving a CA, vault, HSM or KMS. Compare scoped CBOMs before and after cutover, accounting for platform compatibility, exportability and retention requirements.
Secure decommissioning and offboarding. Trace residual credentials, trust entries and shared dependencies when retiring an application, asset or supplier connection. Remove authority through the responsible lifecycle systems while preserving material required for historical decryption.
Domain and email signing infrastructure. Map Domain Name System Security Extensions (DNSSEC) signing, DomainKeys Identified Mail (DKIM) keys and S/MIME certificates to domains, providers and applications. Plan ownership and rollover around each mechanism’s lifecycle. A valid signature or encrypted channel does not by itself establish that a message is legitimate.
Demonstrate cryptographic assurance
Security leaders, architects and reviewers need an evidence-based account of what protects a service. A scoped view makes the question manageable and exposes the parts of the environment that still need investigation.
Build a CBOM for a critical business service
Begin with the service boundary: applications, environments, regions, internal interfaces and relevant suppliers. Use asset and application records to define the expected scope, then compare it with discovery. Add software, cloud, key-manager and configuration evidence according to the decision being made.
For the illustrative payments service, a service CBOM would connect the public gateway, partner authentication, processing libraries, storage-key references and identity dependencies. A certificate review could focus on the relevant endpoints. A key-retirement review could follow data dependencies. Both use the same service context while requiring different evidence.
The cryptographic estate can be described at several levels:
| Scope | Evidence to connect | Question supported |
|---|---|---|
| Asset or device | Host identity, stores, installed software and local configuration | What cryptography is associated with this system? |
| Network endpoint | Target identity, hostname or SNI, port, chain and observed protocol settings | What protection was observed on this connection? |
| Application | Release identity, libraries, cryptographic functions and external dependencies | What does this application contain or depend on? |
| Workload | Deployed build or image, environment, key references and service relationships | What cryptography is associated with this deployment? |
| Business service | Linked applications, workloads, endpoints and shared or supplier dependencies | Which cryptographic issues could affect this business function? |
| Incident or change | Selected objects, known consumers and before-and-after observations | What requires action, and what has been verified? |
Record the snapshot time, provenance and unresolved areas. Preserve shared dependencies across exports and distinguish an asset or device from a network service endpoint. Business ownership and criticality may sit in linked records alongside the CBOM. Confirm that the export preserves the relationships needed by the recipient’s tooling and decision.
Measure the proportion of expected components with current evidence and the time needed to assemble an assurance view. A larger object count does not prove more complete coverage.
Read the workflow: Build a CBOM for a critical business service.
Apply the evidence to reviews and decisions
Audit and cryptographic control evidence. Connect a defined control to in-scope systems, dated findings, owners, exceptions and remediation records. A CBOM contributes technical evidence; the broader assessment also needs the applicable policies and operating processes.
Supplier cryptographic due diligence. Request a scoped supplier CBOM and compare it with the purchased product’s deployment. Review implementations, lifecycle responsibilities and unresolved dependencies, preserving the distinction between supplier statements and independent observations.
Merger and acquisition integration. Assess issuers, ownership, shared keys and legacy configurations before joining trust domains or consolidating platforms. Maintain separate environment identities and reconcile service dependencies before treating similarly named objects as the same system or key.
FIPS module assurance and implementation evidence. Compare the deployed module, version, configuration and operating environment with vendor documentation and the relevant NIST Cryptographic Module Validation Program record. An algorithm name or TLS cipher suite does not establish module validation or approved-mode operation.
How Atlas supports these outcomes
Qinsight Atlas is designed to discover, inventory and contextualize enterprise cryptography. Its graph-based model connects cryptographic objects with the systems and services that use them, helping teams investigate a finding, understand known dependencies and plan a response.
The distinction becomes visible in the questions a team can ask. Starting with an expiring certificate, it can examine associated deployments and services. Starting with a critical application, it can review the cryptographic objects and implementations within the collected scope. Owners and service context help turn those findings into coordinated work.
Atlas operates alongside the systems that already manage the environment. Certificate authorities and key services perform lifecycle operations. Software and vulnerability tools supply implementation and advisory evidence. Identity platforms and incident responders contribute permissions and investigation findings. CMDB and service records supply ownership and business relationships.
Coverage determines which workflows an assessment can support. Network discovery can establish observed certificate and protocol behavior. Library applicability, AD CS exposure, historical backup dependencies and artifact trust require additional sources. During scoping, validate the collectors, fields and relationships needed for the chosen decision. This keeps the assessment useful to the customer and gives partners a clear scope for discovery, validation and remediation work.
Maintaining those observations allows the work to accumulate: a renewal verifies a deployment, an investigation clarifies a trust relationship, and a migration records a new configuration. Qinsight’s enterprise cryptographic posture management lifecycle explains how to sustain that process.
Start with a critical service
Choose one service and a decision already on the calendar: a certificate deadline, a planned rotation, a library advisory or a PQC migration step. Agree the expected systems and owners, collect complementary evidence, and assemble a scoped CBOM with the relationships needed to make that decision.
Set the measures before collection begins. Track time to identify affected services and owners, the proportion of expected components with current evidence, and the share of changed deployments verified afterward. Compare the resulting map with the service owner’s understanding and investigate the differences.
That exercise addresses an immediate operational need while building ownership, dependency information and validation practices for future cryptographic change. Plan an Atlas assessment around a critical business service.
Explore the use case series
- Prevent certificate outages with service context
- Appliance exploits and cryptographic impact
- Exposed private keys and service impact
- Cryptographic library CVEs and service impact
- Safer key and certificate rotation
- Build a CBOM for a critical business service
Related reading
Build the evidence behind the argument.
Start with one accredited boundary or one delivered system and produce evidence a reviewer will accept.
