Cryptographic inventory: first-service checklist

Use this worksheet for one service at a time. It is a practical planning aid, not a certification or a claim of complete coverage.

Scope and accountability

• Service:
• Business owner:
• Technical owner:
• Environments:
• Repositories and deployed versions:
• Entry points and network paths:
• Managed services and vendors:
• In-scope boundaries:
• Known exclusions:
• Review date:

Evidence collection

• Identify cryptographic calls and relevant dependencies in source and built artifacts where accessible.
• Review deployment, TLS, proxy, service mesh, SSH, and VPN configuration where applicable.
• Capture certificate properties and key metadata without collecting private key values.
• Review cloud configurations and distinguish customer controls from provider responsibilities.
• Collect authorized protocol observations or runtime evidence where available.
• Record collection method, time, environment, and client profile for observations.
• Label evidence as observed, configured, inferred, or vendor-reported.
• Record inaccessible, unsupported, and untested areas explicitly.

Suggested asset record

asset_id:
service:
environment:
location:
purpose:
algorithm:
parameters:
protocol:
implementation_version:
owner:
data_sensitivity:
required_protection_lifetime:
business_criticality:
dependencies: []
evidence_type:
evidence_reference:
last_observed:
coverage_limits: []
next_action:
validation_criteria:
review_date:

Create related records for separate cryptographic purposes when necessary. A certificate key, handshake key-establishment group, and symmetric cipher are distinct properties (RFC 8446, sections 4.1.2 and 4.2).

Review and prioritization

• Link observations to deployed services and confirmed owners.
• Preserve separate deployment uses when deduplicating repeated observations.
• Review uncertain matches and contradictory evidence.
• Assess confidentiality lifetime separately from signing and authentication needs.
• Identify compatibility dependencies and vendor constraints.
• Track urgent existing weaknesses separately from planned PQC work.
• Give each action an owner, next step, validation criteria, and review date.

Verification and refresh

• Define representative environments and client profiles for testing.
• Check functional behavior, interoperability, and relevant fallback paths.
• Capture post-change evidence from the affected deployment.
• Record what was verified and what remains outside test coverage.
• Refresh on relevant deployments, dependency upgrades, policy changes, and certificate rotations.
• Investigate disappearing findings before marking assets retired.
• Retain prior evidence and unresolved gaps.

Prepared by Qryptive.