KMIP: How It Works, When You Need It, and How Infisical Implements It27kTalk to an expertGet started for free

27k starsTalk to an expertGet started for free

← Back<br>Blog post • 11 min read<br>KMIP: How It Works, When You Need It, and How Infisical Implements It

Published onFriday, July 24, 2026

Rotating a compromised key should take minutes, but can take days at enterprise scale. The key doesn't live in one place. It's in the storage array, the database, the backup system, and the object storage, each one managed by a different vendor with a different API and a different admin portal. So rotating a single key means doing the same job four times, in four systems that don't share a record of who changed what. Miss one, and you've either left a compromised key live or knocked a system offline. When an auditor asks for a single inventory of every key and who touched it, nobody can produce one.

That's what the Key Management Interoperability Protocol (KMIP) was designed to eliminate. KMIP gives every system one shared language for requesting, creating, and managing keys, so a single manager can serve all of them.

What is KMIP and how does it work?

Before KMIP, every key management vendor had their own API. Nothing else could connect to it. Encrypt your storage array with one vendor's key manager and your Oracle database with another's, and you've got two separate key management systems with no connection between them. Not one console, not one policy, not one record of who accessed what. There's no way to centralize any of it, so every key operation, rotation, audit, access review has to be done twice, once in each system. Multiply that across a large enterprise, dozens of systems each with its own siloed key manager, and when an auditor asks for a single account of every key and who touched it, there's no way to produce one.

KMIP is an open standard that gives every system a single language for requesting, creating, and managing keys. If both sides speak KMIP, they work together. The vendor on either end stops mattering.

Figure 1. Without KMIP, every system manages its own keys. With KMIP, they all share one manager.

Take a routine task: your policy says every encryption key gets rotated every 90 days. Here's what that looks like on each side.

Without KMIP, the key exists separately in each system. You log into the storage array's console and rotate it there. Then the database's. Then the backup system's. Three systems, three consoles, three chances to make a mistake. If you rotate two and miss the third, that system is now running an old key while the others have moved on, and nothing tells you they've drifted apart. You find out when something fails to decrypt.

With KMIP, you set the rotation policy once, in the key manager. It pushes the change to every system that speaks the protocol. One action, one place to confirm it worked, one log showing it happened across all three. The 90-day rotation stops being a three-system chore and becomes a setting.

How KMIP works

KMIP's default port is 5696. It's a client-server protocol running over TCP on that port, secured with mTLS (mutual TLS). Because keys are what's moving across this channel, both ends have to prove who they are: the server only serves clients it trusts, and each client has to know it's reaching the real key manager, not an impostor. Ordinary TLS authenticates only the server, mTLS authenticates both, which is what this kind of service-to-service trust requires.

The core operations cover the full key lifecycle: Create, Get, Register, Locate, Activate, Revoke, Destroy, Get Attributes, and Query .

OperationWhat it doesCreate Generates a new key on the server and stores it.Register Brings an existing key under the server's management.Locate Finds a key by its attributes, without needing its ID.Get Retrieves a key, or asks the server to encrypt or decrypt on the client's behalf so the key never leaves.Activate Marks a key usable, so it can start protecting data.Revoke Pulls a key out of active use, either to retire it or because it's compromised.Destroy Permanently deletes the key material.Get Attributes Retrieves a key's metadata without retrieving the key material itself.Query Asks the server which operations and capabilities it supports.<br>Applications can ask the server to encrypt or decrypt data without ever seeing the key itself.

KMIP vs. PKCS#11

KMIP isn't the only standard in this space, and one comes up often enough that it's worth clearing up early. If you've been researching KMIP, you've almost certainly run into PKCS#11 (Public-Key Cryptography Standard #11), and probably wondered whether you need one, the other, or both. They solve different problems at different layers.

PKCS#11 is a low-level API that a single application uses to talk to a cryptographic device, usually an HSM (Hardware Security Module), usually on the same machine or network. It's a library you link against. It answers the question of how one application...