Encryption is usually one of the first things we think about when protecting sensitive data. We encrypt database fields, API credentials, files, backups, and communication between systems. But there is another question that is sometimes discussed much later:
How are we protecting the encryption keys themselves?
This is where key management becomes important.
Having strong encryption does not automatically mean that the system is secure. If an attacker can obtain the encryption key, the encrypted data may become readable. From a security and audit perspective, the encryption algorithm is only one part of the solution. Auditors also want to understand how keys are created, stored, accessed, rotated, backed up, and eventually destroyed.
For developers, this can sometimes feel like an infrastructure or compliance problem. In practice, it affects application architecture too. The decisions we make about configuration, cloud services, permissions, logging, and deployment can all become part of the key management story.
Encryption Is Only as Safe as the Key
Consider a simple application that encrypts customer information before storing it in a database.
The database contains encrypted values, so at first this looks secure. But imagine that the encryption key is stored directly inside appsettings.json:
{
"Encryption": {
"Key": "my-secret-encryption-key"
}
}If that configuration file is committed to source control, copied to a developer machine, included in a deployment package, or exposed through a server compromise, the protection provided by encryption becomes much weaker.
The problem is not necessarily the encryption algorithm. The problem is that the encrypted data and the secret needed to decrypt it may be too easy to obtain together.
This is why key management planning should answer more than, “Are we using encryption?”
A better question is:
What happens to the key throughout its entire life?
That includes the moment it is generated until the day it is no longer needed.
Auditors Usually Look at the Whole Key Lifecycle
When reviewing key management, an auditor normally wants to understand the process around the key, not only where it currently exists.
A useful way to think about this is as a lifecycle:
Generate → Store → Distribute → Use → Rotate → Revoke → Archive or DestroyEach stage introduces different risks.
For example, a key may be generated securely and stored inside a proper key management service, but if every administrator has unrestricted access to retrieve it, there is still a problem. Another system may have very strict permissions but never rotate its keys. A third system may rotate keys correctly but have no procedure for handling a compromised key.
Good key management means these pieces work together.
1. How Are Keys Generated?
The first thing to understand is where encryption keys come from. Keys should not be created using predictable values such as company names, passwords, timestamps, GUIDs used for business identifiers, or strings manually typed by developers.
Cryptographic keys require strong randomness.
In many modern environments, the easiest approach is not to generate and manage the raw key inside the application at all. A managed Key Management Service, or KMS, can generate and protect cryptographic keys for the application.
This also changes an important part of the architecture. Instead of asking:
“Where should we save the encryption key?”
we can ask:
“How should the application receive permission to use the key?”
That is usually a much better security problem to manage.
The application may be authorized to perform an encryption or decryption operation without being allowed to export the underlying key material.
2. Where Are Keys Stored?
Storage is one of the areas where developers can easily make mistakes.
Putting a secret inside source code is obviously dangerous, but configuration files deserve the same attention. Moving a key from C# code into appsettings.json does not automatically make it secure.
For example:
private const string EncryptionKey = "super-secret-key";is clearly something we should avoid.
But this:
{
"Security": {
"EncryptionKey": "super-secret-key"
}
}may create almost the same risk if the configuration file is committed to Git.
A better design normally keeps sensitive key material outside the application repository and normal deployment configuration.
Depending on the environment, this could involve a dedicated KMS, hardware security module, managed secret service, or another protected key store.
There is an important distinction here between secret management and key management. They are related, but they are not exactly the same thing.
A secret manager can safely store values such as database passwords and API credentials. A key management system is designed specifically around cryptographic keys and usually provides additional capabilities such as controlled cryptographic operations, key versions, rotation, and auditing.
For systems handling important or regulated data, that difference can matter.
3. Who Can Access the Key?
This is where identity and access management becomes part of key management.
Suppose an organization uses a secure KMS, but every developer, administrator, application, and deployment pipeline has full access to every key.
Technically, the keys are stored securely. Operationally, the design is still weak.
Auditors will normally want to understand who or what can use a key and why that access is necessary.
A production application may need permission to use a specific encryption key. That does not mean a developer’s personal account needs the same permission.
Similarly, a deployment service may need permission to configure which key an application uses, but it may not need permission to decrypt production customer data.
This is the principle of least privilege applied to cryptography.
Permissions should be narrow enough that compromising one account or service does not automatically expose every key in the environment.
For larger systems, separation of duties also becomes useful. The person who administers keys does not always need access to the encrypted business data, and the person operating the application does not necessarily need administrative control over the keys.
4. Key Rotation Needs a Real Plan
“Keys should be rotated” sounds simple until you actually implement it.
Imagine that version 1 of a key encrypted one million database records. Tomorrow, the security team creates version 2.
What happens to the existing records?
If the application simply starts using version 2, it still needs some way to decrypt data encrypted using version 1.
One common approach is to associate encrypted data with a key version.
A simplified record might conceptually contain:
EncryptedValue
KeyVersion = 3When reading the record, the application determines which key version is required for decryption.
When writing new information, it uses the current key version.
Older data can then be migrated gradually if required instead of forcing the entire database to be re-encrypted in a single deployment.
This is an architectural decision that is much easier to make before the system contains years of encrypted data.
Rotation planning should therefore answer practical questions. How often do we rotate? Who initiates it? Can the process be automated? How do we decrypt older data? When can an old key safely be disabled? What happens if rotation fails halfway through?
The exact answer depends on the system and its security requirements. The important part is that there is an answer.
5. What Happens When a Key Is Compromised?
Normal rotation and emergency response are different problems.
Rotation is planned.
Compromise is not.
Suppose monitoring indicates that credentials belonging to an application were stolen and those credentials had permission to use a production encryption key.
The team needs to know what to do next.
Can access to the key be revoked immediately? Can a new key be activated without taking the entire application offline? Which data may have been affected? Can logs identify suspicious decryption activity? Does the team know which services depend on the compromised key?
This is where documentation becomes operationally important.
A key inventory should provide enough information to identify at least the key’s purpose, owning system, environment, responsible team, permitted identities, current status, and dependencies.
Without this information, an incident can quickly turn into people searching repositories and configuration files trying to understand what a key is used for.
6. Logging Is Part of Key Management
Security controls are difficult to verify when there is no evidence that they happened.
This is why audit logging matters.
For important keys, organizations should be able to investigate events such as administrative changes, permission changes, key creation, rotation, disabling, deletion, and cryptographic operations where appropriate.
The logs should also be protected.
If someone can misuse a key and then delete the related audit records, the logs provide limited security value.
This does not mean logging the actual encryption key. Keys and sensitive plaintext should never be written into application logs just to make troubleshooting easier.
Instead, record useful metadata such as the key identifier, operation, requesting identity, timestamp, result, and relevant system context.
A log entry might conceptually look like this:
Operation: Decrypt
KeyId: customer-data-key
KeyVersion: 4
Service: CustomerProfileAPI
Result: Success
Timestamp: 2026-09-10T10:15:30ZThis tells us what happened without exposing the key itself or the decrypted customer information.
7. Environment Separation Matters
Development, testing, staging, and production should not casually share encryption keys.
This may sound obvious, but environment boundaries sometimes become blurry because sharing configuration makes development easier.
For example, a developer might request access to the production key because a copy of production data was placed in a testing environment. Now the development workflow has created another path to production secrets.
A better design keeps keys separated by environment and avoids placing sensitive production data in lower environments unless there is a controlled reason to do so.
Environment separation also limits the impact of compromise.
If a development credential is stolen, it should not automatically provide the ability to decrypt production information.
8. Backup and Recovery Can Be Forgotten
Protecting a key too aggressively can create another problem.
You may successfully prevent unauthorized access and still lose the data because nobody can decrypt it anymore.
Imagine an encrypted backup that must be restored several years later. If the corresponding encryption key has already been permanently destroyed, the backup may be technically intact but practically useless.
This is why retention planning for encrypted data and retention planning for keys must work together.
If encrypted records must remain recoverable for seven years, for example, the organization needs to consider whether the required historical keys will remain available for that period.
At the same time, old keys should not simply remain active forever.
There needs to be a controlled distinction between a key that can still be used for new encryption, one that is retained only for decrypting historical information, and one that is safe to permanently destroy.
What Evidence Will an Auditor Ask For?
A common misunderstanding is that passing an audit means showing a security policy document.
Documentation matters, but auditors often need evidence that the documented process actually exists in the system.
For example, if the policy says production keys are accessible only by specific application identities, the auditor may want to review the actual access policy.
If the policy says keys are rotated, there should be records showing previous rotations.
If emergency access requires approval, there should be evidence of how that approval is controlled and recorded.
This is an important lesson for engineering teams:
A security control that cannot be demonstrated can become difficult to defend during an audit.
Instead of preparing evidence only when an audit begins, it is better to design systems that naturally produce evidence through access policies, configuration history, audit logs, change records, and automated controls.
Common Mistakes I Would Watch For
One common mistake is treating encryption as finished once the application successfully encrypts and decrypts data. The cryptographic operation works, so the feature is considered complete.
Another is putting encryption keys together with application configuration because it is convenient for deployment.
Teams can also introduce unnecessary exposure by giving human users direct access to keys when applications could use workload identities instead.
Rotation is another area that is frequently underestimated. Creating a new key is easy. Supporting old encrypted data, migration, rollback, and emergency revocation requires more planning.
Finally, avoid building a custom key management platform unless there is a very strong reason. Cryptographic key management has many details that are easy to underestimate. Using established platform capabilities can reduce the amount of sensitive security logic that an application team must maintain themselves.
A Practical Way to Plan Key Management
When designing a new system, I find it useful to start with the data rather than the encryption technology.
First identify what information actually requires encryption and why. Then identify which applications need to use that information.
From there, define the key boundary. Decide whether different applications, tenants, environments, or data classifications require separate keys.
Next, define access. Determine which workload identities can perform cryptographic operations and which administrators can manage the key configuration.
After that, design rotation and recovery before production deployment. It is much easier to introduce key versioning when the database contains a few test records than when it contains millions of production records.
Finally, make sure the system produces enough audit information to reconstruct important events.
At that point, the key management plan becomes more than a compliance document. It becomes part of the actual architecture.
Conclusion
Key management is not only about finding a safe place to store an encryption key.
A complete plan considers how keys are generated, protected, accessed, rotated, revoked, monitored, recovered, and eventually destroyed. It also defines who is responsible for those activities and provides evidence that the controls are actually working.
For developers, one of the most useful changes in thinking is to stop asking only:
“Is the data encrypted?”
Instead, also ask:
“If someone wanted to decrypt this data, what would they need to compromise?”
If the answer is one configuration file, one developer account, or one shared credential, there is probably more work to do.
The strongest key management designs make keys difficult to obtain, limit who can use them, record important activity, support safe rotation, and provide a clear recovery path when something goes wrong.
Key Takeaways
Encryption and key management should be designed together. Protecting encrypted data while exposing its key gives limited security value.
Prefer dedicated key management capabilities for important cryptographic keys instead of storing raw keys in source code or ordinary configuration.
Apply least privilege to both people and applications. Being able to deploy an application should not automatically mean being able to decrypt its production data.
Plan key rotation before you need it. Historical encrypted data, key versions, migration, rollback, and emergency revocation all need consideration.
Keep development and production key boundaries separate, and make sure backup retention matches the availability of the keys required to decrypt those backups.
Finally, design for evidence. Access policies, rotation records, configuration history, and protected audit logs make security controls easier to operate and much easier to demonstrate during an audit.
