How to Build a Cryptographic Inventory for Post-Quantum Migration

Your security team receives a straightforward request: identify the production services that depend on RSA or elliptic-curve cryptography, and explain what it would take to migrate them.

Application teams scan repositories. Infrastructure teams export certificates. Cloud teams review encryption settings. Procurement asks vendors for roadmaps.

The results arrive, but the migration questions remain. Which certificate belongs to which service? Where does TLS terminate? Which applications depend on a shared key? If a team changes its code, how will you establish that the deployed service changed too?

An inventory that lists algorithms, certificates, and libraries, each found on its own, without their relationships leaves the migration questions unanswered. A list tells you what exists. A migration needs to know what depends on what, so you can see what breaks when something changes.

A useful cryptographic inventory connects these pieces. It records where cryptography appears, what it does, which systems depend on it, and the evidence behind those relationships. That gives teams a basis for deciding what to change and how to verify the result.

NIST’s migration project treats cryptographic discovery as a foundation for understanding cryptographic use and prioritizing the transition to post-quantum algorithms. NIST NCCoE: Migration to Post-Quantum Cryptography

At Qryptive, we organize that work around Find, Fix, Prove. This guide explains how to build an inventory that supports all three.

Start with one service and a clear boundary

Choose a business service whose owners can participate: a customer portal, a document exchange, or a software update service. List the environments, repositories, endpoints, and external dependencies in scope.

For a customer portal, the boundary might include the public connection, load balancer, application, identity provider, database connections, and backup workflow. Each can introduce a separate cryptographic dependency and a different team responsible for changing it.

Record what you examined, what you examined only partially, what you could not access, and what sits outside the review. This makes the first discussion concrete: you can explain which parts of the service you understand and where more evidence is needed.

Scanning finds technical evidence. Only the people who run the service can confirm its boundaries, its owners, and how important its data is.

Find: collect evidence across several layers

Cryptographic behavior is distributed across code and its environment. Combine complementary sources, preserving where each observation came from.

Source code and dependencies. Identify cryptographic calls, algorithm selections, key loading, certificate handling, and relevant libraries. Retain the repository, file location, commit, and dependency version. A declared dependency shows that a library is present, not that its cryptography runs in production.

Configuration and infrastructure. Review TLS policies, reverse proxies, deployment manifests, service meshes, and relevant SSH or VPN configuration. Look for where connections terminate and where encryption begins again. A gateway often decides how the public connection behaves, even when the application code has no TLS settings at all.

Certificates and key metadata. Capture public-key algorithms, key sizes or curves, certificate signature algorithms, expiry, fingerprints, and issuing relationships. Preserve key identifiers and storage references. Keep private-key values and other secrets out of the inventory.

Cloud and managed services. Inspect the configuration exposed by the provider. Record which controls your team can change and which depend on the provider. Separate observed configuration from documented vendor behavior and unresolved questions.

Endpoint observations. Use authorized protocol probes to inspect reachable services. Record the endpoint, observation time, collection method, and relevant client capabilities. A probe tells you what happened in that exchange. Other clients and routes can see something different.

Qryptive brings findings from code, cloud, infrastructure, certificate, and endpoint sources into one inventory. Coverage depends on what you connect, and anything you could not reach belongs on the list as a gap, not off it.

Figure 1. Combine evidence across layers, preserving each source and its coverage limits.

Build relationships between assets and their uses

Consider a fictional customer portal. Its repository contains a certificate reference. A cloud listener is configured to use that certificate. A probe of the public endpoint observes the certificate being served.

Together, these observations link the repository, certificate, listener, and endpoint. Each link needs evidence: a file reference, a resource identifier, a certificate fingerprint, or a confirmed deployment relationship.

The relationship makes the inventory useful for change planning. Before replacing a certificate, the team can see which listeners and services depend on it. Before migrating code, it can identify the deployed endpoints that need fresh checks.

Preserve the distinction between an asset and its uses. The same certificate can appear in several repositories and deployments. Deduplicating the certificate should retain those separate locations and dependencies.

Treat inferred relationships as proposals to review. A shared hostname suggests a connection; it does not prove that two systems form one application. Qryptive proposes application groupings from the linkage evidence it has, and teams confirm them.

A cryptographic bill of materials helps exchange structured findings. CycloneDX CBOM represents cryptographic assets and relationships to software components. Deployment context, ownership, and current observations add the information needed to plan operational changes. CycloneDX: Cryptography Bill of Materials

Record cryptographic purpose and uncertainty

An entry that says “RSA-2048” leaves too much unanswered. Is RSA authenticating a server, signing a software release, or protecting key material? These uses have different dependencies and migration paths.

TLS illustrates why this matters. In TLS 1.3, the cipher suite specifies record protection and a hash; authentication and key exchange are selected separately. Seeing TLS_AES_256_GCM_SHA384 tells you nothing about whether the key exchange is post-quantum. IETF RFC 8446

For each asset or use, record:

• Identity and location: a stable identifier, service, environment, and relevant repository or resource.
• Purpose and technical properties: cryptographic function, algorithm, parameters, protocol, and implementation version where known.
• Business context: data sensitivity, required protection lifetime, and service criticality.
• Ownership and dependencies: who can change it, what uses it, and which vendors or counterparties constrain the change.
• Evidence and limits: source, observation date, collection method, and whether the conclusion is observed, configured, inferred, or vendor-reported.
• Next action: the remaining question, proposed work, and evidence needed to close it.

The following fictional record is a planning example, not Qryptive’s output schema:

asset_id: customer-portal-edge-tls
service: Customer portal
environment: production
endpoint: portal.example.com:443
owner: Platform engineering
purpose: transport security
observation:
  method: authorized active TLS probe
  observed_at: "2026-10-01T10:00:00Z"
  handshake: full, certificate-authenticated
  protocol: TLS 1.3
  key_establishment_group: X25519
  leaf_certificate_public_key: RSA-2048
  cipher_suite: TLS_AES_256_GCM_SHA384
  evidence_ref: evidence/tls-probe-001.json
coverage:
  tested: one client profile, one network vantage point
  unknown: alternate clients, edge-to-origin connection
next_action: review edge policy and test other client profiles

The tested handshake used classical X25519 key establishment. The certificate’s RSA key is a separate property. Neither tells you every mode the endpoint supports, or what happens behind the public edge.

Use unknown deliberately. An empty result can mean missing access, an unsupported code path, or a failed probe. Keep that uncertainty attached to the affected service so it can guide the next investigation.

Fix: turn the map into sequenced migration work

Prioritize cryptographic uses in their business context. Confidential information that must remain protected for years is at risk of being collected today and decrypted later. NIST describes this as “harvest now, decrypt later.” Signing and authentication need their own assessment of trust, validity, and migration dependencies. NIST: What Is Post-Quantum Cryptography?

Then identify what must change together. A library upgrade can force application changes. A certificate migration may depend on an issuer, a hardware device, and every client that validates the certificate. A shared key can connect work across repositories.

Give each action an owner, dependencies, a validation plan, and a review date. Separate work your team can implement now from work waiting on compatibility testing or a vendor release. Existing weaknesses, such as exposed private keys, also need a response independently of the PQC migration schedule.

Qryptive can generate migration pull requests for supported code patterns. Teams review those changes and validate them in their own environments. For supported infrastructure findings, Qryptive provides remediation recommendations and migration steps. Vendor-managed dependencies can be tracked against the provider’s roadmap, and the owning team or vendor makes the change. Record limitations and remaining manual work alongside the proposed migration.

Prove: check the code and the deployed behavior

Verification needs to follow the thing that changed.

For a code migration, check whether the changes build and preserve the required behavior. Include interoperability, existing data, and fallback paths relevant to that application. Compiling is only the first check.

For a deployed connection, collect fresh evidence from the affected endpoint using representative client profiles. A merged change does not mean the deployment picked it up. A post-quantum public edge connection also leaves the edge-to-origin connection to be assessed separately.

Qryptive combines repository findings and endpoint probe results to calculate posture for linked paths. Teams can review the linked repository and endpoint information alongside the linkage evidence. Path status reflects the latest probe and the relevant repository findings.

Attach the validation result to the migration work: what changed, which version was checked, when it was checked, which tests or probes ran, and what remains unresolved. That creates a record engineers, security teams, and reviewers can assess.

Figure 2. Find collects and connects evidence. Fix prioritizes and changes. Prove verifies the result and feeds fresh evidence into the inventory.

Keep the inventory current as the estate changes

Refresh evidence around deployments, dependency upgrades, certificate rotation, gateway policy updates, and vendor releases. Automate scanning where you can, and schedule reviews for sources that need manual attention.

Retain history. When an asset disappears from a scan, investigate whether it was retired, moved, or became inaccessible. After a configuration change, collect fresh evidence from the affected path before closing the work.

Measure progress against the service boundary you declared. Track confirmed owners, unresolved dependencies, coverage gaps, stale observations, and migration actions with verification evidence. These tell you whether the team can actually make and close decisions about the service.

A checklist for your first inventory review

• Choose one service and document its boundaries.
• Confirm owners and identify external dependencies.
• Collect evidence from available code, configuration, certificate, cloud, and endpoint sources.
• Record cryptographic purposes, properties, and observation dates.
• Link assets to their deployment uses, preserving uncertain relationships for review.
• Record inaccessible, unsupported, and untested areas.
• Assign migration work according to risk and dependencies.
• Define code checks and deployment checks for each change.
• Preserve verification evidence and agree on refresh triggers.

Open the expanded inventory checklist to run the review with your team. Adapt it to your own tools and evidence.

Begin with evidence you can act on

Start with one service, bring its owners into the review, and connect the evidence needed to make the next migration decision. As coverage grows, those relationships tell you the impact of a change and which work has to happen together.

Qryptive’s Find, Fix, Prove workflow connects discovery with action: bring cryptographic evidence into a shared map, generate supported code migrations and plan other remediation, then review validation and fresh endpoint observations. The inventory is refreshed as new findings and endpoint observations arrive, and teams should keep the evidence behind their migration decisions with it.

Explore Qryptive to learn about cryptographic discovery and migration, or request access to discuss your environment.