Tomorrow’s cryptography starts with your inventory.

Yes. The 6 services can be planned as clearly scoped work packages. Together we clarify the situation, the prerequisites and the result you need first. The subpages show the respective scope and the technical decisions.

Before implementation, we agree on goals, affected systems, involvement, results and acceptance criteria. Open technical questions can first be clarified in a current-state review or a pilot. Additional tasks are assessed for their impact on effort and schedule.

Documentation, briefing and responsibilities are covered in the engagement. If OTOKO® takes on ongoing tasks, we agree on an operating scope for them, including service hours and escalation paths. Your team can also take the results forward itself or with existing partners.

Post-quantum cryptography, or PQC, refers to algorithms intended to remain resistant even against attacks using powerful quantum computers. For companies, the first question is where vulnerable algorithms are used and how long data and signatures need to stay protected. OTOKO® combines inventory, risk assessment and technical implementation. Switching algorithms alone is not enough: libraries, protocols, devices and counterparts must work together.

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.

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

Crypto inventory with provenance and coverage Dependency overview per application Procedure for updating the CBOM

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.

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.

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.

Not every system needs to be migrated at the same time. We assess protection duration, attack surface, technical dependencies and migration effort. This results in a sequence of well-founded measures, responsibilities and decision points.

Assess protection needs for data and signatures together Classify cryptographic dependencies and migration effort Record vendor dependencies and procurement cycles Plan pilot projects and migration waves Document residual risks and open decisions

Well-founded prioritization Migration plan with dependencies Decision paper for business units and IT

Certain information must remain confidential for many years. Recorded encrypted traffic can therefore already be relevant to long-term risk assessment today. At the same time, procurement, software adjustments and changes at counterparts take time. We connect these factors with your protection needs, without treating a speculative date for a powerful quantum computer as a reliable planning basis. Signatures are considered separately, because their long-term verifiability can require different measures than the confidentiality of a connection.

A central library or certificate platform can affect many applications. Conversely, a single legacy device can limit the migration of an entire communication path. We map these dependencies, review vendor information and separate measures that can be implemented in the short term from preparatory work. Pilots receive clear questions to answer, for example the compatibility of a gateway chain or support for a key type. The roadmap contains decision points where measurement results and new information can change further planning.