Cryptographic Key Storage

PCI DSS requires you to store any secret or private keys used to encrypt/decrypt stored account data in a protected form at all times: either wrapped (encrypted) by an equally strong key-encrypting key, held inside a secure cryptographic device, or split into full-length components/shares using an industry-accepted method (PCI DSS v4.0.1 Requirement 3.6.1.2). Operationally, this is a key-management architecture decision plus auditable procedures.

Key takeaways:

• Keep encryption keys out of plaintext storage; “at all times” includes backups, images, and logs (PCI DSS v4.0.1 Requirement 3.6.1.2).
• Pick one compliant storage pattern (KEK-wrapping, secure device/HSM, or split knowledge) and document the end-to-end key lifecycle.
• Evidence wins exams: diagrams, configs, key custody records, and repeatable operational runbooks.

“Cryptographic key storage” under PCI DSS is not a generic security best practice; it is a specific control objective tied to the confidentiality of stored account data. If an attacker can retrieve the key from a server file, code repository, or backup archive, encryption of stored account data becomes irrelevant. PCI DSS v4.0.1 Requirement 3.6.1.2 sets a clear bar: secret and private keys that encrypt/decrypt stored account data must always be stored in one (or more) approved protected forms (PCI DSS v4.0.1 Requirement 3.6.1.2).

For a Compliance Officer, CCO, or GRC lead, the fastest path is to (1) inventory where account data is stored and which keys protect it, (2) choose the compliant key storage model that fits your environment (HSM/KMS, key-wrapping with a KEK, or split knowledge), and (3) implement hard controls around backups, access paths, and operational custody. This page gives requirement-level guidance you can hand to engineering and security operations, plus the audit artifacts you should demand to make this control durable.

Regulatory text

Requirement (verbatim excerpt): “Secret and private keys used to encrypt/decrypt stored account data are stored in one (or more) of the following forms at all times: encrypted with a key-encrypting key that is at least as strong as the data-encrypting key, within a secure cryptographic device, as at least two full-length key components or key shares in accordance with an industry-accepted method.” (PCI DSS v4.0.1 Requirement 3.6.1.2)

Operator interpretation (what you must do):

• Identify the secret keys (symmetric) and private keys (asymmetric) that can decrypt stored account data.
• Ensure those keys are never stored in plaintext anywhere in scope (including backups and system images). The requirement says “at all times” (PCI DSS v4.0.1 Requirement 3.6.1.2).
• Store keys using at least one approved pattern:
  1. Wrapped/encrypted under a key-encrypting key (KEK) that is at least as strong as the data-encrypting key.
  2. Stored within a secure cryptographic device (commonly an HSM or equivalent secure cryptographic boundary).
  3. Stored as split knowledge: at least two full-length key components/shares using an industry-accepted method (PCI DSS v4.0.1 Requirement 3.6.1.2).

Plain-English requirement: what “cryptographic key storage” means in practice

You are building a guarantee: “If someone gets filesystem access, database access, backup access, or repo access, they still cannot recover the keys needed to decrypt stored account data.” That means:

• No keys in config files, environment variables captured in crash dumps, scripts, golden images, container layers, IaC state files, ticket attachments, or chat transcripts.
• If keys must exist outside a secure device, they must be wrapped (encrypted) under a KEK with controlled access.
• If you depend on split knowledge (components/shares), you must run a controlled ceremony and keep custody records.

Who it applies to

Entity types: Merchants, service providers, and payment processors handling stored account data and the associated encryption keys (PCI DSS v4.0.1 Requirement 3.6.1.2).

Operational contexts where this becomes urgent:

• You store PAN or other account data and encrypt it at rest.
• You use application-layer encryption (keys live “near” the app).
• You run centralized key management (KMS/HSM), or you manage certificates/private keys used to unwrap or decrypt data.
• You have third parties that host, manage, or can access your key management stack (cloud provider KMS, managed HSM, outsourced operations). Treat them as third parties in due diligence and contracts, because key custody is shared operationally.

What you actually need to do (step-by-step)

1) Build an inventory of “keys that can decrypt stored account data”

Create a register that answers, for each dataset:

• What stored account data exists? (system, DB, bucket, file store)
• What encryption method is used? (app-layer, DB TDE, object storage encryption)
• Which key(s) can decrypt it? (key IDs/aliases, certificate identifiers)
• Where is the key stored today? (KMS, HSM, file, secret manager, code)
• Who/what can access it? (service identities, admin roles, break-glass)

Scope note: include private keys used to decrypt data (not just symmetric keys) (PCI DSS v4.0.1 Requirement 3.6.1.2).

2) Choose a compliant storage pattern (decision matrix)

Pick the pattern that matches your architecture and operational maturity:

Pattern	What it looks like	Good fit	Common failure mode
KEK-wrapped keys	DEK(s) stored only in wrapped form; KEK access tightly controlled	Cloud-native apps, envelope encryption	KEK stored in plaintext or too broadly accessible
Secure cryptographic device	Keys generated/stored in HSM or equivalent; operations happen inside device boundary	High assurance, centralized crypto services	App teams export keys “for convenience,” breaking the model
Split knowledge components/shares	Key exists only when components are combined via ceremony	Offline master keys, break-glass recovery	Poor custody records; components end up co-located

You may use more than one form; the requirement allows “one (or more)” (PCI DSS v4.0.1 Requirement 3.6.1.2).

3) Implement controls for “at all times” storage

Your control design must cover the full lifecycle and every storage surface:

A. Primary storage

• Enforce that keys are stored only in approved systems (KMS/HSM/secret manager designed for key custody) or as wrapped blobs in controlled storage.
• Block plaintext key material from being written to disk on application hosts.

B. Backups and snapshots

• Confirm backups of systems that interact with keys do not capture plaintext keys (for example, home directories, temp folders, exported files).
• If wrapped keys are backed up, verify the KEK is protected separately (the point is separation and access control).

C. Logging/telemetry

• Review app logs, debug endpoints, and error reports for key leakage (key material, base64 blobs, PEM blocks).
• Treat this as a detection problem too: add scanning or alerting for accidental key material in logs and repos.

D. CI/CD and infrastructure-as-code

• Prevent secrets in build logs and pipeline variables that are broadly visible.
• Lock down IaC state files if they can contain secret outputs or encrypted blobs.

4) Restrict access paths to key material and key-wrapping authority

PCI DSS 3.6.1.2 is about storage form, but auditors will test whether access design makes the protection meaningful:

• Limit who can unwrap DEKs (KEK permissions) or invoke private-key operations.
• Separate duties between key administrators and application operators where feasible.
• Use break-glass access with strong approvals and durable logging.

5) Document the key storage design so it is testable

Create artifacts that map the requirement directly to implementation:

• A one-page architecture diagram showing DEKs, KEKs, and where each lives.
• A written statement: “Secret/private keys for stored account data are stored only as: [wrapped under KEK] and/or [inside secure cryptographic device] and/or [split shares], including in backups” (PCI DSS v4.0.1 Requirement 3.6.1.2).
• Runbooks for key recovery, rotation support, and incident response actions involving keys.

6) Validate with an internal control test

Run a simple control test that mirrors what a QSA/examiner will do:

• Attempt to locate key material in file systems, repos, ticketing attachments, and backups.
• Verify that any key blobs found are wrapped and unusable without KEK access.
• Confirm access logs show only authorized service identities or admins can perform unwrap/decrypt operations.

A practical tool move: use Daydream to track each system storing account data, attach the diagram/config evidence, and assign control owners with due dates so the key storage control does not decay during platform changes.

Required evidence and artifacts to retain

Ask for artifacts that prove both the storage form and the operational reality:

1. Key inventory/register for keys that encrypt/decrypt stored account data.
2. Architecture diagram showing DEK/KEK relationship and storage locations.
3. Configuration evidence (screenshots or exports) showing:
   • keys are stored in secure cryptographic device or key manager, or
   • DEKs are stored only as wrapped blobs and KEK access is restricted.
4. Procedures/runbooks:
   • how keys are created, stored, recovered, rotated, and retired,
   • how split components/shares are generated and held (if used).
5. Access control evidence:
   • role/permission listings for KEK use, key export restrictions, and administrative access,
   • break-glass procedure and approvals.
6. Backup and logging reviews documenting checks for plaintext key leakage.

Common exam/audit questions and hangups

Expect these questions and prepare clean answers:

• “Show me all keys that can decrypt stored account data and where they are stored.” (PCI DSS v4.0.1 Requirement 3.6.1.2)
• “Can any administrator export a private key or DEK in plaintext?”
• “Where is the KEK stored, and who can use it?”
• “Do backups/snapshots contain plaintext keys?”
• “If you use key shares/components, show custody records and how you prevent recombination by one person.”

Hangups that stall audits:

• Teams confuse “encrypted at rest” for data with “key storage is protected.” Examiners will separate these.
• Lack of clarity on which keys qualify. The requirement is scoped to keys used to encrypt/decrypt stored account data (PCI DSS v4.0.1 Requirement 3.6.1.2).

Frequent implementation mistakes (and how to avoid them)

1. Storing keys in app config or environment variables that end up in dumps/backups.
   Fix: enforce key retrieval via KMS/HSM calls; scan repos and artifacts for key patterns.

2. Wrapping DEKs but leaving the KEK accessible to too many principals.
   Fix: treat KEK permissions as “decrypt authority.” Minimize to required service identities and a small admin group.

3. Exporting private keys from secure devices for “temporary debugging.”
   Fix: block export where possible; add change control and incident-style approvals for exceptions.

4. Split knowledge on paper, but components end up co-located (same vault, same admin).
   Fix: separate custody by person and storage system; record transfers and access.

5. No evidence trail.
   Fix: create a standard evidence package per key domain (DB encryption, file/object storage, app-layer encryption) and keep it current in Daydream or your GRC system.

Enforcement context and risk implications

No public enforcement cases were provided in the approved source catalog for this requirement, so this page does not cite case outcomes. Practically, failure modes are straightforward: if keys are retrievable in plaintext (or easily unwrapped), stored account data becomes decryptable after a single system compromise. That can expand an incident from “encrypted data exposure” to “account data disclosure,” which changes notification, brand impact, and PCI program consequences.

Practical execution plan (30/60/90-day)

A dated plan depends on your environment and resourcing. Use phases that map to control maturity.

Immediate phase: stop obvious key leakage

• Freeze creation of new ad-hoc key storage locations (files, repos, shared drives).
• Start a key discovery sweep: repos, secrets managers, backups, ticket attachments.
• Require every app storing account data to identify its decrypt-capable keys and owners.

Near-term phase: implement the approved storage model everywhere

• Standardize on one primary pattern per platform (KEK-wrapping via KMS/HSM is the common operational choice; split shares for offline master recovery).
• Migrate plaintext-stored keys into compliant storage.
• Tighten permissions for KEKs and private-key operations; document break-glass.

Ongoing phase: make it durable

• Add CI/CD and logging guardrails to prevent key reintroduction.
• Establish recurring control tests (spot checks against backups and repos).
• Keep the key register and diagrams updated as part of change management.

Frequently Asked Questions

Does this apply to TLS private keys for websites?

It applies to secret/private keys used to encrypt/decrypt stored account data (PCI DSS v4.0.1 Requirement 3.6.1.2). If a TLS key is also used to decrypt stored account data (uncommon), it is in scope; otherwise, treat it under your broader key management standards but don’t claim it satisfies this specific requirement without that linkage.

If we use a cloud KMS, are we automatically compliant?

Only if the decrypt-capable keys are stored in an approved form at all times and you can prove it with configuration and access evidence (PCI DSS v4.0.1 Requirement 3.6.1.2). Auditors still test for plaintext copies in hosts, repos, backups, and whether KEK/key permissions are overly broad.

What does “KEK at least as strong as the data-encrypting key” mean operationally?

You must ensure the KEK provides protection that is not weaker than the DEK it wraps (PCI DSS v4.0.1 Requirement 3.6.1.2). In practice, document your chosen algorithms/strengths and show that wrapping keys meet or exceed the protected key’s strength in your crypto standards and configs.

Can we store wrapped keys in a database table?

Yes, if the stored value is only the wrapped (encrypted) key and unwrap requires controlled access to the KEK (PCI DSS v4.0.1 Requirement 3.6.1.2). The audit risk is accidental storage of plaintext keys in adjacent fields, logs, migrations, or backups.

Do we need split key components/shares if we already have an HSM?

No. Split knowledge is one compliant option, not a mandate (PCI DSS v4.0.1 Requirement 3.6.1.2). Some teams use shares for offline recovery of a root/backup key even when daily operations rely on an HSM.

What evidence is most convincing to an assessor?

A clear key inventory, a diagram showing DEK/KEK storage, and exported configuration/access controls from your key management system that demonstrate keys are stored in approved forms “at all times” (PCI DSS v4.0.1 Requirement 3.6.1.2). Pair that with a backup/log review showing no plaintext key material is captured.