Key Management and Governance

A cryptographic key is often viewed simply as something an application creates, stores in an HSM or KMS, and subsequently uses. As long as everything works, there seems to be no reason to give it further thought. Problems arise, however, when we need to answer simple questions: Why does this key exist? Who is responsible for it? What is it used for? What happens if it is compromised? Who can replace it? And what will stop working if we invalidate it?
At that point, it is no longer just about cryptography. Security, operations, accountability, asset management, and—in some cases—regulatory requirements all come into play. Consequently, cryptographic key management is not merely a matter of creation and storage; it is about managing security assets throughout their entire lifecycle.
Most of the terms used here were explained in the article "Secrets Without Secrets." Others will be explained as the series progresses. The fundamental terminology regarding electronic signatures, seals, and trust services is based, among other things, on the eIDAS Regulation and its associated implementing acts.

A Key Is Not Just a Key

One of the most common issues in managing cryptographic material is how it is perceived. Organizations routinely track servers, databases, applications, network components, accounts, and licenses as assets. However, a cryptographic key is often viewed merely as a file stored on a server, an object within an HSM, or a record in a KMS. Such a perspective is insufficient.
Like any other asset, a cryptographic key has an owner, a purpose, a value, a classification, dependencies, and a lifecycle. At the same time, it possesses a crucial characteristic: the key materialitself may be so sensitive that the organization must not expose it to a standard asset management system. Consequently, "tracking" does not mean recording the secret itself. Instead, the focus is on information that enables the key to be managed. For instance, an organization should be able to answer questions such as:

• What key exists, what is its purpose, and which system uses it?
• Who owns it, who manages it, and who or what can use it?
• With which algorithm and parameters was it created?
• Where is it stored, and can it be exported?
• When was it created and activated, and when does its validity or usage period expire?
• How will it be replaced, what happens if it is compromised, and how will it be revoked or destroyed?
• What other objects depend on it?

In its key management methodology, NIST explicitly includes key and certificate inventories, metadata protection, access control, authentication, and other areas related to managing the lifecycle of cryptographic material. This shifts the focus from simple "key storage" to the management of cryptographic assets. It is at this point that cryptographic management begins to resemble traditional asset management. Knowing that a specific object exists is not enough; one must also understand its purpose, the associated responsibilities, its relationships, and its status. As with other methods, standardized inventories are available—specifically, the Cryptography Bill of Materials (CBOM) in the context of cryptography. Unfortunately, their current scope does not yet cover the components that require such inventories.

PKI as a System of Interconnected Assets

The situation is even more complex in a PKI environment. An organization manages more than just private keys; there is a wide range of interconnected objects:

• private keys, public keys, and certificates,
• registration and certification authorities, including root and intermediate authorities,
• trust anchors,
• validation services,
• certificate revocation lists (CRLs),
• certificate repositories,
• HSMs and KMSs,
• systems (services) for certificate issuance and renewal,
• identities and services to which individual keys and certificates are assigned.

These objects cannot be managed in isolation. For instance, the information "Certificate for server XY" is of limited use from an asset management perspective. It is far more important to understand the relationships between the service, the identity, the certificate, the public and private keys, and the mechanism protecting the key. This relationship can be described in simplified terms as follows:
service – identity – certificate – public key – private key – cryptographic module – owner – lifecycle

Such a link makes it possible to determine what happens, for example, when a specific key is compromised or when a certificate expires.

A certificate is not a key

One of the most common misconceptions in the field of PKI is confusing a certificate with a key.
A certificate is not a public key. It contains a public key along with other data and represents a structured statement regarding the link between the public key and an identity or other attributes.

A private key, on the other hand, is secret cryptographic material. Possessing it enables the performance of corresponding cryptographic operations, such as creating digital signatures.

From a record-keeping perspective, therefore, the certificate and the key represent two separate objects linked to one another. This link is practically significant, for instance, during certificate renewal. Renewing a certificate does not necessarily mean generating a new key. In some cases, the existing key can be used, whereas in others, it is advisable—for security or procedural reasons— to generate a new key. It is therefore important to distinguish at least between the following:

• renew – renewal or issuance of a new certificate according to a specific process,
• rekey – creation of a new key or key pair,
• rotation – planned replacement of the key currently in use,
• revocation – withdrawal of trust in a certificate,
• expiration – end of validity,
• destruction – secure destruction of a key or key material,
• compromise – suspicion or confirmation of key compromise.

This distinction might seem like a matter of semantics. However, in the event of an incident, the difference between “renewing a certificate” and “replacing a key” is certainly not merely academic.

PKI is not a product, but a system of processes and technology

Another common oversimplification is viewing PKI merely as a specific technology or the installation of a certificate authority. In reality, PKI is a combination of technical tools, rules, and processes that enable the creation and maintenance of trusted links between an identity, a public key, and cryptographic operations. A certificate authority is just one component of this system.
Therefore, managing PKI involves more than just configuring individual components. Equally important are the processes that dictate what happens to a key and a certificate throughout their lifecycle. These include, for example:

• subject registration and identity verification,
• key generation,
• key activation and usage,
• certificate issuance and distribution,
• certificate renewal,
• key rotation,
• attribute modification,
• revocation,
• handling compromise,
• archiving,
• secure lifecycle termination.

Each such process should have a designated owner. It should also be possible to determine who can initiate the process, who approves it, who executes it, and how its execution is recorded. At this point, PKI begins to closely resemble traditional asset management.

A key owner is not the same as a key administrator

A key may be technically managed by a PKI administrator. However, this does not automatically mean that the administrator is the owner. The owner should be able to determine the key's purpose, be responsible for its use, and decide on its lifecycle. The custodian, on the other hand, ensures the technical execution of the established activities.
This distinction is important, for example, when the system owner changes or when the system is decommissioned.
If a system is being retired, simply removing the server or application is not enough. It is also necessary to identify which cryptographic keys and certificates depend on it and how their lifecycles should be concluded.
Without this link, a situation arises where the organization holds keys known to exist, yet the reason for their continued existence is unclear. This is precisely one of the typical challenges of cryptographic asset management. Therefore, it makes sense to address the detailed division of responsibilities among the owner, custodian, administrator, security role, and audit function separately.

PKI is not the only area of application

Although PKI is a significant area for the use of cryptographic keys, it is certainly not the only one. Keys are used, for example, for:

• protecting data on disks and in file systems,
• encrypting databases,
• protecting backups,
• TLS and other forms of communication protection,
• authentication,
• digital signatures and electronic seals,
• VPNs,
• tokenization,
• API protection,
• deriving additional keys.

In these cases, a certificate authority or a traditional PKI infrastructure may not exist. However, the need to manage key material remains. An organization still needs to know which key is being used, its purpose, who is responsible for it, where it is stored, who can use it, and what happens if it is compromised or its use is discontinued. That is precisely why it is not advisable to base key management solely on certificate tracking. Certificates represent only one part of the broader cryptographic landscape.

Conclusion

Key management is therefore not merely a technical discipline within PKI. PKI represents a significant and often highly visible part of the issue, as there is a direct link between the key, the certificate, identity, and trustworthiness. In some cases, the legal implications of electronic signatures or seals also come into play.
However, cryptographic keys exist outside of PKI as well. From an asset management perspective, it is therefore appropriate to view a key as a security asset with its own identity, owner, purpose, classification, dependencies, and lifecycle. Simply put:
asset - owner - purpose - key - protection - usage - monitoring - change - rotation - invalidation - disposal

In the context of PKI, this model extends to include additional relationships:
identity - key - certificate - certification authority - trust anchor - service - process

Thus, the purpose of key management is not merely to prevent an attacker from accessing a private key. It is equally important to know why the key exists, who is responsible for it, what depends on it, who may use it, when it should be replaced, and what should happen when its trustworthiness or utility comes to an end. Only by integrating cryptography, PKI, asset management, and organizational processes does a truly managed key material infrastructure emerge.
A cryptographic key is therefore not merely a technical tool. It is an asset whose compromise can have technical, operational, economic, and legal consequences. And just as with other critical assets, knowing of its existence is not enough. An organization must know what it is, who owns it, why it exists, where it is used, who may use it, and when it should cease to exist.

Autor článku:

Jan Dušátko

Jan Dušátko has been working with computers and computer security for almost a quarter of a century. In the field of cryptography, he has cooperated with leading experts such as Vlastimil Klíma or Tomáš Rosa. Currently he works as a security consultant, his main focus is on topics related to cryptography, security, e-mail communication and Linux systems.