Navigation

Get in touch
Logo
News

Crypto inventory

You cannot protect what you do not know.

Which of your applications use which encryption, and who can change it? We record cryptographic dependencies and assign them to your systems and owners. The inventory creates a verifiable basis for further planning.

tilt-shift photography of green computer motherboard — illustrative image
Crypto inventory with provenance and coverage · Planning and implementation by OTOKO®

Your brief for OTOKO®

What we take care of for you.

A network scan sees reachable services, but not all of an organization’s cryptography. We combine permitted collection methods: endpoints, certificate inventories, libraries, configuration and interviews with system owners. Offline signatures, mobile devices and embedded components can also be relevant. The results distinguish observed use from capabilities that are merely installed. Every finding is recorded with its source and time, so that later decisions do not rest on unclear assumptions.

The possible scope of services

  • Define the scope of investigation and permitted collection methods
  • Record protocols, certificates, libraries and key usages
  • Consolidate results from scans, code analysis and system exports
  • Flag dependencies and areas not covered
  • Prepare ongoing updates to the inventory and a machine-readable export

We define the specific scope, your involvement and the acceptance criteria before the start.

Technology explained clearly

How we carry out the task.

01

Connect cryptography with data and applications

A Cryptography Bill of Materials, or CBOM, describes cryptographic components and their relationships in a machine-readable form. What matters is the mapping to the intended use: a certificate can protect a connection or secure a signature that must remain verifiable long term. We record owners, changeability and dependencies on vendors. Systems that are unreachable or not examined remain visible as gaps. A large data export without this classification would not be a solid basis for decisions.

02

Keep the inventory up to date after the project

Changes to libraries, certificates and configuration are meant to feed into the ongoing updates. Owners and triggers for updates are defined for this purpose. During acceptance testing, we check samples against real systems and document the scope of investigation achieved. Production scans take place only within the approved scope and with consideration for sensitive components.

Meeting room at the OTOKO® Cologne office

A verifiable result

What you keep working with.

  1. Crypto inventory with provenance and coverage
  2. Dependency overview per application
  3. Procedure for updating the CBOM

The handover brings together implementation and documentation. Together, we review the agreed cases and record any remaining tasks.

Your project in detail

Find cryptography before it becomes a migration obstacle.

We identify where your applications and infrastructure use cryptographic algorithms. The result links technical findings to their business meaning, responsibility and the path by which a change is possible at all.

Cover more than certificates and publicly visible endpoints

Besides TLS certificates, we look at libraries, signature methods, key stores and embedded functions in products. Source code analysis, configuration review and technical surveys can complement each other. No single tool sees all dependencies, so we explicitly document the coverage achieved and the uncertainties that remain.

Each finding is assigned to a system and a responsible team. What matters is the algorithm, its use, the supporting component and the data being protected. A list of algorithms without their purpose is of limited help for later prioritization.

Record changeability and dependencies in the inventory

We distinguish software developed in-house from products that can only be changed through vendor updates. We likewise record devices with long life cycles and external communication partners. The question is not only what is used today, but who can initiate and approve a switch.

A maintenance process is set up for the inventory. New software and material changes are meant to be recorded, so that the inventory does not become outdated within a few months. For inaccessible systems, we record outstanding evidence and concrete questions for suppliers, instead of interpreting a lack of visibility as a lack of cryptography.

Illustrative project scenario

How the service helps in everyday use.

Example: An organization knows its web certificates but not the signature library of an archiving system. The inventory links both to data retention and vendor responsibility. This reveals that the archive dependency needs a longer lead time than the next web server replacement.

This example explains a possible process and is not a customer reference.

Before the first step

Your questions about Crypto inventory.

Does a scan prove that no further cryptography exists?

No. It provides findings within its scope. Code, offline systems and unreachable components require other collection methods.

What is the difference between an SBOM and a CBOM?

An SBOM describes software components. A CBOM adds a targeted view of cryptographic components and dependencies that are relevant for migration planning.

Your project

Which task would you like to solve?

Describe your situation and the desired result. The selected service will be included in the contact request.

Request this service

Our Partners

  • Microsoft
  • Microsoft Azure
  • Amazon AWS
  • Google Cloud
  • Thales Group
  • Arrow ECS
  • Vodafone
  • IBM
  • Veeam
  • Atlassian
  • JetBrains
  • NinjaOne
  • OPSWAT
  • Utimaco
  • Eviden

Accessibility

Adjust the display to suit your needs.

A simple version is not available for this page yet.

Settings currently apply to this visit. Allow saving in Cookie settings to remember them.