Roles Involved

In previous sections, we distinguished between a key's purpose, its classification, authorization for its use, and the various stages of its lifecycle. Another question is who is responsible for specific activities. Key material management is not merely a technical discipline; it encompasses decisions regarding the key's purpose and usage, KMS or HSM administration, renewal, response to compromise, and independent oversight. If all these activities are concentrated in a single identity, the compromise of that account could bypass a significant portion of security controls. Therefore, it is advisable to distinguish between organizational roles and their respective responsibilities. However, this does not mean that every role must be assigned to a different person in every organization; what matters is the resulting model of authorizations and checks and balances.

Basic Roles

For a basic model, three main responsibilities can be distinguished:

• Key Owner – determines the key's intended use, classification, and required level of protection, and is responsible for ensuring the key is used in accordance with its defined purpose;
• Key User / Key Holder – an entity authorized to use the key for defined cryptographic operations. In the case of a personal signing key, this is typically a specific individual;
• Administrator / Operator – ensures the technical operation of the KMS, HSM, PKI, and related infrastructure within the scope of their assigned privileges.

These roles may overlap in smaller environments. For sensitive keys, however, it is advisable to further separate the associated responsibilities. The reason is not merely to prevent intentional misuse. It is equally important to limit the impact of a privileged account compromise, an administrator error, or a misconfiguration. The goal is to ensure that the compromise of a single identity does not allow for the independent execution of a critical operation or the acquisition of excessive control over key material.

Separation of Duties and the Four-Eyes Principle

A fundamental principle is the Separation of Duties (SoD). For instance, the person deciding on the use of a key should not simultaneously hold administrative privileges that would allow them to bypass that decision. For critical operations, this principle can be supplemented by the Four-Eyes Principle. A critical operation then requires the participation or approval of at least two independent individuals. Examples include:

• creation or activation of a CA key,
• export or recovery of key material, if such an operation is permitted,
• modification of cryptographic policy,
• modification of permissions for a highly sensitive key,
• deactivation or destruction of a key,
• key recovery following a disaster,
• modification of HSM or KMS configuration with security implications.

For the most sensitive operations, even simple approval by two individuals may not be sufficient. The M-of-N principle—such as 2-of-3 or 3-of-5—can be employed. Under this approach, an operation can proceed only if the specified minimum number of authorized individuals participate in it. It is crucial to distinguish between approving an operation and technically executing it. If a single person approves and executes an operation while also having the ability to delete or alter the audit log, the separation of duties is merely nominal.

Roles are not universal

The names of specific roles vary among manufacturers of KMS/HSM and PKI products, as well as across security methodologies. Therefore, one should not assume that roles such as Cryptographic Officer or Key Custodian carry the same privileges in every context. More important than the role name itself is the specific set of:

• permissions,
• responsibilities,
• limitations,
• approval mechanisms,
• and audit capabilities.

In practice, the following model can be used, for example:

This is not a universal catalog that must be implemented in full by every organization. Some roles may be combined, depending on the organization's size and risk profile. Conversely, for critical infrastructure, it is advisable to further segregate responsibilities.

Key Owner vs. Key Custodian

The distinction between a Key Owner and a Key Custodian warrants special attention. Ownership does not imply physical or technical possession of the key. For instance, a Key Owner might be an organizational unit responsible for using the key for a specific application or business process. The key itself may be stored in an HSM to which the Key Owner has no administrative access. Conversely, the Key Custodian does not necessarily determine the key's purpose; their role is to ensure that key material is handled in accordance with approved procedures. This may include, for example, participation in a key ceremony, key renewal, or working with a secret-sharing mechanism.
This separation is particularly important for highly sensitive keys. A person with the technical ability to manipulate the key should not automatically decide how that key will be used.

CA and PKI

A clear separation of roles is typical for a Certificate Authority (CA). A CA's private key can be one of an organization's most critical cryptographic assets; depending on the CA's position in the hierarchy, its compromise could allow for the unauthorized issuance of certificates trusted within the given PKI. Therefore, critical CAs employ a combination of HSMs, role separation, and controlled procedures known as key ceremonies. Generating, activating, backing up, renewing, or destroying a CA key may require the presence of multiple authorized individuals.
A CA Officer need not be an HSM Administrator. An HSM Administrator might manage the HSM's technical configuration, while a CA Officer is authorized to perform specific operations involving the CA key. This separation reduces the risk that the compromise of a single administrator account could lead directly to the compromise of the CA.

KMS and HSM

A similar separation can be applied to KMS and HSM systems. A KMS Administrator should be able to manage the KMS configuration, key lifecycles, and access policies, but should not automatically gain the ability to export or directly access HSM-protected key material.
Conversely, an HSM Administrator may possess extensive privileges regarding the technical configuration of the HSM but should not automatically own all the keys stored within it.
It is important to recognize that while an HSM protects key material, it does not in itself resolve the entire issue of authorization. For instance, if a KMS Administrator has the authority to instruct the KMS to perform a cryptographic operation using a specific key, they may not need know the key itself. Nevertheless, they may be able to influence its use. Therefore, it is necessary to control not only the possibility of obtaining key material but also the possibility of unauthorized initiation of a cryptographic operation.

Audit and Independent Review

The Cryptographic Auditor plays a distinct role. An audit should not merely verify whether roles are correctly configured within the system. The auditor should be able to verify, for example:

• who can create the key,
• who can activate it,
• who can use it,
• who can modify its policy,
• who can deactivate or destroy it,
• who can change permissions,
• who can perform recovery,
• whether critical operations are performed under a four-eyes or M-of-N regime,
• whether operations are recorded in audit logs,
• whether logs are protected against unauthorized modification,
• whether the actual configuration complies with the security policy.

At the same time, the auditor should not be able to modify the system configuration they are auditing during their routine work. Audit independence is therefore another practical application of the principle of Separation of Duties.

The Role of Applications and AI Agents

In modern environments, it is no longer possible to model all users solely as physical persons. A significant portion of cryptographic operations is performed by applications, services, and other workloads; in some environments AI agents as well.
An application should have its own technical identity and its own set of permissions. It should not use a personal administrator account or an account shared among multiple services. Similarly, from the perspective of the KMS, an AI agent should be treated as a distinct workload identity. The agent's permissions must be restricted based on its specific purpose. For example, it might be granted permission to perform a decryption operation with a specific key, but lack the permission to export the key, modify its policy, or destroy it. Furthermore, for sensitive operations, additional human authorization may be required. This is particularly important in situations where the autonomous execution of an operation could have a significant impact on data or infrastructure.

Roles versus technical permissions

It is advisable to distinguish between an organizational role and a technical role within a specific system. A person might be the organizational "Key Owner" for a particular application but hold no administrative permissions within the KMS. Conversely, a KMS Administrator might possess the technical permissions necessary to operate the system without owning a single key within the KMS. Likewise, a single person need not correspond to only one role; in a small environment, multiple roles might be consolidated into one person. However, such consolidation must be explicitly assessed for risk and, in the case of critical operations, mitigated by additional control mechanisms.
Thus, the result of a properly designed system is not necessarily the greatest possible number of roles. The goal is to distribute responsibilities such that no single person, account, or service possesses more privileges than strictly necessary, and so that the compromise of a single identity does not allow the entire security model to be bypassed. For critical cryptographic operations, it is advisable to combine the separation of duties, the principle of least privilege, multi-factor authentication, "four-eyes" or M-of-N authorization, and independent auditing. In this context, KMS and HSM solutions serve not merely as technical means for key storage, but as components of a broader system of organizational and technical controls.

Conclusion

Roles in key material management are not merely an arbitrary organizational scheme. They exist to ensure that decision-making, technical implementation, key usage, and independent oversight are not concentrated in a way that creates undue risk through their combination. At the same time, there is no need to create dozens of roles simply for the sake of formal separation; what matters is the specific privileges a role actually holds and how the exercise of those privileges can be controlled.
This is also important for subsequent parts of the series. Roles determine who can intervene in the key lifecycle, who can alter its state, and who can perform specific cryptographic operations. Conversely, the technical implementation within a KMS or HSM determines how these rules are actually enforced. Thus, key management is shifting from a question of "where do we store the key" to a question of who can do what, under what conditions, and how that can be proven after the fact.

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.