Manage keys. Limit access.

A new key does not mean the old one can be deleted immediately. We record which data, signatures or backups still depend on earlier versions. Applications need a clear mapping to the key version. Generation, activation, revocation, archiving and deletion are given separate states and approvals. Errors such as exhausted sessions, expired logins or interrupted connections are surfaced and handled explicitly. Retries must not create unwanted key duplicates or duplicate business transactions.

In testing, we check not only successful calls but also rejected roles and operations that are not permitted. Access credentials and secrets must not end up in source code, logs or general backups. Your team receives the configuration, example scenarios and a procedure for diagnostics. To get started, we need to know which libraries and runtime environments you use and which keys you already hold.

PKCS #11 describes access to cryptographic tokens and their functions. KMIP addresses the management of cryptographic objects between a client and a key management system. A cloud service, in turn, can offer its own REST API. This does not make them automatically interchangeable. OTOKO® documents where an operation is executed, which key material an interface actually transmits and which attributes are preserved. This turns a list of protocols into a traceable integration path.

In hierarchical encryption, data keys can protect the actual data while a higher-level key protects these data keys. This avoids having every large data block processed by an HSM. What matters is where a data key is needed in plaintext and how long it stays available there. We clarify caching behavior, rotation and access within the application. The statement “the key stays in the HSM” only holds for the specific key role under consideration and its attributes.

Several services have so far used their own key files. OTOKO® first maps owners, purposes and data dependencies. We then test the supported integration of one representative service and define permissions per application. The changeover happens step by step, with controlled reading of existing data and writing of new data. Old keys are only removed once retention, backups and recovery have been considered. The result is a documented key inventory with tested usage and rotation procedures.