®PQC governance
A cryptography transition takes longer than a single project. We embed inventory, decisions and responsibilities in your existing processes. This keeps changes to applications, suppliers and recommendations manageable and traceable.
Your brief for OTOKO®
A central policy needs people who implement it in the applications. We assign technical owners, business risk decisions and approvals. The policy describes permitted algorithms, selection criteria and the procedure for changes. Each exception receives a justification and a date for its next review. Existing security and change processes are used so that cryptography maintenance does not end up in an isolated project list.
We define the specific scope, your involvement and the acceptance criteria before the start.
Technology explained clearly
During procurement and contract renewal, information on cryptographic dependencies, update paths and planned support can be requested. Statements are documented with their status: announced, available or tested in the specific environment. Metrics distinguish recorded systems, assessed risks and successfully migrated uses. A high number of inventoried certificates must not obscure the fact that critical offline systems are still missing.
We link inventory, decision and test report so that the implementation status can be traced. Technical documentation supports internal or external audits; it does not replace any separately required legal assessment or formal certification. Acceptance reviews responsibilities and an example change or exception case. This shows whether the process works in everyday use.
A verifiable result
The handover brings together implementation and documentation. Together, we review the agreed cases and record any remaining tasks.
Your project in detail
We connect technical results with approvals, procurement and a maintainable body of evidence. This keeps the preparation actionable even as products, standards and internal responsibilities keep evolving.
For algorithms, products and interim solutions, we document the decision, its rationale and its scope. A time-limited exception needs an owner and a trigger for review. Without this information, residual technical issues often become permanent.
We link inventory, risk assessment and measures instead of creating separate lists with no common reference. This makes it possible to explain why a system was prioritized, which tests exist and which prerequisite is blocking the next stage. Business responsibility and technical implementation are named separately.
New products should provide relevant information on cryptographic functions, update capability and migration paths. We formulate specific questions for suppliers that go beyond the “PQC-ready” label. Evidence refers to versions and planned use, not just a general vendor presentation.
Regular reviews reconcile the roadmap with actual progress. The inventory is updated for significant architecture or product changes. The documentation supports internal controls and audits, but does not replace external certification or a binding assessment by the responsible bodies.
Illustrative project scenario
Example: A procurement team receives two proposals both claiming to be “PQC-ready”. We translate the required use cases into verifiable questions on algorithms, interfaces and lifecycle. The decision documents proven capabilities and outstanding commitments, so that later project teams can build on the same basis.
This example explains a possible process and is not a customer reference.
Before the first step
No. Metrics need clear definitions and underlying evidence. Which documents are required is clarified within the specific audit framework.
Owners review relevant changes to standards, products and their own infrastructure. Findings feed into policy, inventory and action planning in a controlled way.
Your project
Describe your situation and the desired result. The selected service will be included in the contact request.
Request this service
