AI Glossary / Data governance and quality / Intermediate

Key management

Definition

Key management is the set of activities used to create, protect, distribute or establish, use, replace, recover when appropriate, and retire cryptographic keys. It includes the policies, roles, records, and technical systems that govern those activities. Strong encryption depends on suitable key management: losing required keys can make information unavailable, while exposing keys can undermine the protection they provide. Different key types and purposes require different handling.

What it means

A cryptographic key is not just another configuration value. It enables a particular cryptographic operation, and its meaning depends on the algorithm and role. A decryption key, a signing key, and a key used to protect other keys have different consequences if lost or compromised. Key management therefore asks who may use each key, for what purpose, under which conditions, and for how long. The objective includes both protecting confidentiality and keeping authorized operations possible.

How it works

Define key requirements and ownership, generate keys through suitable supported mechanisms, and store them with appropriate access protection. Establish how applications obtain authorized cryptographic operations without unnecessary exposure of key material. Track key identifiers, purpose, status, and dependencies. Plan replacement, compromise response, and recovery where the key's function requires it. Retire keys carefully after assessing data and validation dependencies. Verify the process through controlled exercises and audits, using the relevant platform and cryptographic guidance rather than improvised procedures.

Three practical examples

• Database protection: the team preserves the key material needed to restore encrypted backups and tests the recovery dependency.
• Software release: access to a signing key is limited to the approved release process so a copied key cannot casually authorize new artifacts.
• AI data pipelines: services use approved key-management facilities for encrypted datasets while access to decryption operations remains restricted to the necessary workloads.

Think of it this way

Think of managing a secure collection of keys with records of which lock each opens, who may use it, and what happens when it is replaced. The analogy is limited because cryptographic keys can be copied without visible evidence, can have different mathematical roles, and may protect large amounts of information or other keys rather than one physical lock.

Worked example

In an original simplified archive, dataset version A is encrypted with key K1 and later dataset version B with K2. Switching new writes to K2 does not by itself make K1 unnecessary. If version A must remain readable and has not been safely re-encrypted under another arrangement, the authorized recovery path still depends on K1. The team documents that dependency and tests access before retiring any key material. Conversely, keeping K1 available forever without a reason creates unnecessary exposure. The correct decision follows the data's required lifecycle and the cryptographic design, not a rule that all old keys should be immediately deleted or indefinitely retained.

Illustrative case study

Fictional example: Silver Birch Research can restore its encrypted dataset files but cannot access the required key service during a recovery exercise. The team identifies the missing operational dependency and revises its recovery plan within the platform's supported controls. It retests the complete path. This invented case shows that protecting key material and ensuring authorized availability are both necessary; merely preserving encrypted files does not establish usable recovery.

Common misconceptions and mistakes

Do not place live keys in source code, public examples, or broadly accessible logs. Do not assume changing a password rotates every cryptographic key or that rotating a key automatically re-encrypts all historical data. Avoid treating public keys as secret simply because private keys require confidentiality; their protection requirements differ. Also, key backup is not universally appropriate in the same way for every key purpose. Follow the relevant design and retention rules instead of applying one recovery policy indiscriminately.

Business use

Key management makes encryption and digital-signing controls operationally dependable. Businesses need accountable ownership, an inventory of important dependencies, and a tested response to loss or suspected compromise. For AI projects, consider keys protecting datasets, model artifacts, release signatures, and connected services. Use established platform capabilities and specialist review for consequential designs. Evaluate who can request cryptographic operations as well as who can extract key material, because a protected key can still be misused through an overprivileged service.

People also ask

Is key management only about storing keys?

No. It covers their lifecycle, permitted use, replacement, recovery decisions, and retirement.

Does key rotation always rewrite existing encrypted data?

No. That depends on the system and operation; historical dependencies must be checked.

Are public and private keys handled identically?

No. Private-key confidentiality and public-key authenticity involve different protection needs.

Check your understanding

New data uses K2, but an important older backup still depends on K1. Is deleting K1 automatically safe?

Answer: No. First establish and test how the older backup will remain usable for its required retention period. New-write configuration alone does not resolve historical decryption dependencies.

Related terms

• encryption
• digital signature
• cryptographic key
• key rotation
• key recovery
• hardware security module
• secrets management

Learn next

draw a small key-dependency map for one encrypted dataset and its backup. Identify which key protects the data, what protects that key, and which service or identity can request decryption. Then walk through loss, compromise, and retirement scenarios without exposing or using real secret material in the exercise.

More in Data governance and quality

• Input mask - An input mask is a pattern that guides or restricts how a user enters a value into a field.
• IT risk - IT risk is the possibility that uncertainty involving information technology will affect an organization's objectives.
• IT risk management - IT risk management is the ongoing process of identifying, assessing, responding to, and monitoring risks arising from an organization's use of information...
• Link rot - Link rot is the loss of access to a resource through a previously useful web link, often because the resource has been removed, moved without a suitable...
• Mandatory access control - Mandatory access control, or MAC, is an access-control approach in which a system enforces security policy that ordinary users or resource owners cannot...
• Metadata - Metadata is information that describes, explains, organizes, or helps manage other information resources.

Sources

Sources: NIST CSRC, key management, https://csrc.nist.gov/glossary/term/key_management , definition consulted; NIST SP 800-57 Part 1 Revision 5, https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final , overview and relevant recovery excerpt consulted; NIST key-management guidelines, https://csrc.nist.gov/projects/key-management/key-management-guidelines , publication-status overview consulted; Microsoft TDE documentation, https://learn.microsoft.com/en-us/sql/relational-databases/security/encryption/transparent-data-encryption?view=sql-server-ver16 , recovery-dependency excerpt consulted. No algorithm selection, rotation interval, or production key procedure is prescribed. Examples are original.

Previous: Key Constraint Next: Key - value database