Ideally no. OWASP's key management guidance says application code should not read or handle raw keys, and that key management libraries should perform operations inside the vault. If your app never holds the key, a compromised app server cannot leak it.
The design goal
Most applications fetch a key at startup, keep it in memory and call a crypto library with it. That works, and it means a memory dump, a debug endpoint or a code execution bug on that host exposes the key.
The alternative is to send data, or a small wrapped data key, to a key service and get the result back. The key stays inside a hardware module or a managed service and never reaches your process.
What OWASP says nearby
The Key Management Cheat Sheet makes related points that fit this approach.
- Generate keys inside a cryptographic module validated to FIPS 140-2 or 140-3, with the random bit generator inside that module.
- Hardware modules are preferred over software modules.
- Never store keys in plaintext in volatile or persistent memory.
- Never commit keys to source repositories or build artifacts.
- Use a dedicated secrets manager, key vault or HSM for storage.
The no plaintext in memory line is the hardest to meet fully. Treat it as a direction: reduce how long and in how many places a key exists.
Patterns that keep keys out of your process
- Sign in the service: send a digest to a signing service and receive a signature. The private key never leaves.
- Envelope encryption: ask the service to wrap and unwrap short data keys. The application sees the data key briefly, but never the key encryption key.
- Per-request permissions: give the service identity permission to use the key without permission to export it.
- Short-lived data keys held only for the duration of one operation, then dropped.
Trade-offs
- Latency and availability: each operation depends on a network call. Cache unwrapped data keys carefully with short lifetimes, or batch work.
- Cost and quotas: key services may limit request rates. Envelope encryption reduces the call volume.
- Complexity: the code is a little more involved than calling a local function.
- Portability: moving between key services changes the integration, so wrap it behind a small interface.
Review questions
- Where does each key physically live?
- Which identities can use it, and can any export it?
- Does any log, crash report or debug page include key bytes?
- Could a compromise of a single application host extract it?
- If the answer to the last question is yes, is there a documented reason?
When raw access is acceptable
Some situations require a local key, such as an offline tool or a constrained device. Document why, restrict the host, limit the key's lifetime and plan its rotation.
Quick check
Does a KMS stop an attacker who has taken over my app?
Not entirely. They may still call the service while they control the app. But they cannot take the key away, and you can revoke the app's access and see the calls in logs.
Is a secrets manager the same as not handling raw keys?
No. A secrets manager hands the secret to your code. A key service or HSM performs the operation without handing over the key.
Safeguard's compliance and evidence automation can keep key handling procedures and access reviews as audit evidence, and the free scan at gold.safeguard.sh/scan covers dependencies.
Sources
Last reviewed: 19 October 2026.
