Secure Key Storage

PCI DSS 4.0.1 Requirement 3.7.3 requires you to implement key-management policies and procedures that include secure storage of cryptographic keys, so keys cannot be accessed, copied, or extracted by unauthorized people, processes, or third parties. Operationally, this means defining approved storage locations (HSM/KMS/vault), locking down access, and keeping evidence that storage and controls match your written procedures. (PCI DSS v4.0.1 Requirement 3.7.3)

Key takeaways:

• Store keys only in approved, access-controlled systems (for example HSM/KMS/vault), not in code repos, configs, tickets, or shared drives.
• Prove secure storage with durable evidence: architecture diagrams, access lists, system settings, and audit logs mapped to the policy.
• Treat third parties and cloud services as in-scope: you still own the policy, configuration requirements, and validation.

“Secure key storage” is easy to describe and often hard to execute consistently. Teams generate encryption keys across cloud KMS services, application secrets managers, CI/CD pipelines, databases with TDE, payment tools, and third-party platforms. PCI DSS 4.0.1 Requirement 3.7.3 tightens the expectation into an operational requirement: your key-management policies and procedures must include secure key storage. (PCI DSS v4.0.1 Requirement 3.7.3)

For a Compliance Officer, CCO, or GRC lead, the practical question is: “What would an assessor expect to see that proves keys are stored securely across our environment?” This page gives you requirement-level guidance you can hand to engineering and infrastructure teams: where keys may live, how access must be controlled, what “secure” means in day-to-day operations (backup, restore, rotation, break-glass access, third-party managed keys), and which artifacts to retain so your next assessment does not devolve into screenshots and guesswork.

The goal is not to pick a single technology. The goal is to make key storage intentional, bounded, and evidenced across systems that store, process, or transmit cardholder data, and any connected services that manage encryption keys supporting that environment. (PCI DSS v4.0.1 Requirement 3.7.3)

Regulatory text

Requirement text (excerpt): “Key-management policies and procedures are implemented to include secure key storage.” (PCI DSS v4.0.1 Requirement 3.7.3)

What the operator must do

You must do two things, and auditors will test both:

1. Define secure key storage in your key-management policy and procedures (not just “we encrypt keys” or “we use KMS”). Your documentation must state where keys are allowed to be stored, who may access them, and how storage is protected from unauthorized access. (PCI DSS v4.0.1 Requirement 3.7.3)

2. Implement what you documented across the environments in scope for PCI. Assessors will look for technical controls and evidence that keys are not sitting in insecure places (source code, plaintext configs, ad hoc scripts, ticket attachments, shared drives) and that access to key material is restricted and logged. (PCI DSS v4.0.1 Requirement 3.7.3)

Plain-English interpretation (secure key storage requirement)

“Secure key storage” means cryptographic keys are kept in systems and configurations that prevent unauthorized disclosure or extraction. Practically, keys should be stored in an HSM, cloud KMS, or hardened secrets/key vault with strict access control, logging, and controlled export. Keys should not be copyable by default, and access should be limited to the smallest set of people and services that must use the key. (PCI DSS v4.0.1 Requirement 3.7.3)

Secure storage is not only about encryption-at-rest. It is also about operational control: preventing engineers, workloads, third parties, malware, or misconfigured automation from retrieving key material outside approved paths. (PCI DSS v4.0.1 Requirement 3.7.3)

Who it applies to

PCI DSS applies to merchants, service providers, and payment processors with environments that store, process, or transmit cardholder data. (PCI DSS v4.0.1 Requirement 3.7.3)

Operationally, this requirement applies wherever cryptographic keys exist that protect data in the PCI scope, including:

• Keys for PAN encryption, tokenization systems, and database encryption features used in-scope.
• TLS private keys terminating in-scope traffic (including load balancers and API gateways) if your key-management procedures cover them as part of cryptographic key control.
• Keys managed by third parties on your behalf (cloud providers’ KMS, managed payment platforms, managed databases, MSP-operated vaults). You still need policy coverage and assurance that storage is secure. (PCI DSS v4.0.1 Requirement 3.7.3)

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

1) Build a key inventory tied to PCI scope

• Identify each key type: data-encryption keys, key-encryption keys, tokenization keys, signing keys, TLS private keys, and secrets that function as keys.
• For each key, record: owner, system, environment, purpose, and storage location (KMS/HSM/vault/db/file).
• Mark which keys are “in-scope” based on whether they protect cardholder data systems or flows. (PCI DSS v4.0.1 Requirement 3.7.3)

Output: Key inventory register (spreadsheet or GRC record) with system-of-record references.

2) Define “approved key storage” in policy and procedures

Write rules an engineer can follow without interpretation:

• Approved storage mechanisms (examples: HSM, cloud KMS, dedicated key vault with access control and audit logging).
• Explicitly prohibited locations (source repositories, container images, local developer machines, plaintext config files, shared network drives, ticket attachments).
• Access control principles (least privilege, separation of duties for key admins vs key users, controlled break-glass).
• Key export rules (when export is allowed, how it is protected, who approves, and how it is logged).
• Backup/restore handling for keys and any wrapped key material. (PCI DSS v4.0.1 Requirement 3.7.3)

Output: Key-management policy + procedure(s) with a “Secure Key Storage” subsection.

3) Standardize storage patterns per platform

Pick a small set of sanctioned patterns and publish them:

• Cloud: Use the cloud KMS and restrict key policy to specific workloads and administrators.
• On-prem: Use an HSM or centralized vault; avoid distributing raw key files to app servers.
• Kubernetes: Use an external secrets manager integration rather than embedding secrets in manifests or Helm values.
• CI/CD: Use a secrets manager integration; prevent printing secrets into build logs. (PCI DSS v4.0.1 Requirement 3.7.3)

Output: Reference architectures and “how to request a key” runbooks.

4) Lock down access to key storage

Implement controls that auditors can test:

• Role-based access to keys (admin, user, auditor roles).
• Strong authentication for administrators.
• Network controls so only intended systems can reach the vault/KMS endpoints.
• Log access to keys and administrative actions; retain logs per your security logging approach. (PCI DSS v4.0.1 Requirement 3.7.3)

Output: Access control lists/policies, role definitions, and logging configuration evidence.

5) Detect and eliminate insecure key storage

• Scan code repositories for secrets and key material; treat findings as incidents or control failures.
• Review shared storage and knowledge bases for accidental key uploads.
• Ensure key material is not present in AMIs/images, backups, or golden templates. (PCI DSS v4.0.1 Requirement 3.7.3)

Output: Remediation tickets, scanning outputs, and root-cause fixes (pipeline controls, pre-commit hooks, secret scanning rules).

6) Extend requirements to third parties

If a third party stores or manages keys:

• Require written confirmation of where and how keys are stored (HSM/KMS/vault), access control model, and logging.
• Contractually require notification and approval for any key export or migration events.
• Ensure you can obtain evidence during assessment (attestation package, configuration excerpts, or equivalent artifacts). (PCI DSS v4.0.1 Requirement 3.7.3)

Output: Third-party due diligence package mapped to your key-storage requirements.

Required evidence and artifacts to retain

Keep evidence that ties policy → implementation → operation:

Governance artifacts

• Key-management policy and procedures covering secure key storage. (PCI DSS v4.0.1 Requirement 3.7.3)
• Key inventory with ownership and storage locations.
• Data-flow or crypto architecture diagrams showing where keys live and how they are accessed.

Technical evidence

• KMS/HSM/vault configuration exports or screenshots: key access policies, role assignments, key export settings.
• IAM role mappings for workloads that use keys.
• Network/security group rules limiting access to vault/KMS endpoints (where applicable).
• Logging evidence: sample audit logs for key access and admin actions. (PCI DSS v4.0.1 Requirement 3.7.3)

Operational evidence

• Break-glass procedure and approvals (if applicable).
• Tickets/records showing remediation of any discovered insecure key storage.
• Third-party evidence packages and contract clauses relevant to key storage. (PCI DSS v4.0.1 Requirement 3.7.3)

Common exam/audit questions and hangups

Assessors tend to probe predictable fault lines:

• “Show me where keys are stored.” Expect to produce the inventory and the system configurations proving it. (PCI DSS v4.0.1 Requirement 3.7.3)
• “Can anyone export the key?” If export is enabled, you need a clear business rationale, strong controls, and logs.
• “Do developers have access to production keys?” If yes, you need separation-of-duties justification and compensating controls; most teams aim to avoid this.
• “How do you prevent keys from ending up in Git or tickets?” You need preventive controls (secret scanning, pipeline checks) and detective controls (periodic scanning). (PCI DSS v4.0.1 Requirement 3.7.3)
• “What about keys managed by a third party?” “They handle it” will fail. You need documented requirements and evidence collection paths. (PCI DSS v4.0.1 Requirement 3.7.3)

Frequent implementation mistakes (and how to avoid them)

1. Policy says “use KMS,” reality includes key files on servers.
   Fix: force migration to sanctioned storage and block redeployments with embedded key material via CI checks. (PCI DSS v4.0.1 Requirement 3.7.3)

2. No clear rule on key export.
   Fix: define export as prohibited by default, require approvals and logging where allowed, and test it during internal control reviews.

3. “Secrets manager” treated as a dumping ground.
   Fix: classify secrets vs cryptographic keys, define ownership, and require naming/metadata standards so you can audit.

4. Third-party key handling left out of scope.
   Fix: include third parties in your key inventory and due diligence checklist; require evidence artifacts you can present during assessment. (PCI DSS v4.0.1 Requirement 3.7.3)

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page focuses on audit and operational risk.

Risk-wise, insecure key storage collapses the value of encryption. If an attacker can access encryption keys (or if a third party can export them without your control), encrypted cardholder data can become readable, incident response becomes harder, and scope containment arguments weaken. Under PCI assessments, weak key storage often surfaces as a systemic failure: access control, change management, and third-party governance problems show up in the same evidence set. (PCI DSS v4.0.1 Requirement 3.7.3)

Practical 30/60/90-day execution plan

Use this as an operator checklist. Adjust sequencing to your environment’s change windows.

First 30 days (triage and definition)

• Assign an executive owner for key management and name technical owners per platform.
• Build a key inventory for in-scope systems, including third-party-managed keys. (PCI DSS v4.0.1 Requirement 3.7.3)
• Publish “approved storage locations” and “prohibited locations” in a short interim standard.
• Turn on or validate audit logging for the vault/KMS/HSM and centralize log access for review.

Days 31–60 (implementation and control hardening)

• Migrate highest-risk keys out of files/repos into sanctioned storage.
• Implement access roles (admin/user/auditor) and remove broad human access to production keys where possible.
• Add secret scanning and CI guardrails to reduce reintroduction of key material into code or build artifacts. (PCI DSS v4.0.1 Requirement 3.7.3)
• Update third-party contracts or security addenda to require secure key storage evidence and constraints on export.

Days 61–90 (evidence, testing, and audit readiness)

• Finalize the key-management policy and procedures with a complete “Secure Key Storage” section. (PCI DSS v4.0.1 Requirement 3.7.3)
• Run an internal “show me” drill: pull the exact evidence package an assessor would request for a sample of keys.
• Close documentation gaps: diagrams, inventories, access review records, and logging examples.
• If you manage many systems, consider a workflow tool such as Daydream to track key inventory, third-party evidence requests, and recurring access reviews in one place without turning PCI work into an email hunt.

Frequently Asked Questions

Does “secure key storage” require an HSM?

PCI DSS 4.0.1 Requirement 3.7.3 requires secure key storage in your policies and procedures, then implementation that matches. (PCI DSS v4.0.1 Requirement 3.7.3) An HSM is one common way to meet the intent, but cloud KMS or a hardened vault can also work if access and export are tightly controlled.

Are TLS private keys included?

If TLS private keys protect in-scope cardholder data transmissions and fall under your key-management procedures, treat them as in-scope key material for secure storage. (PCI DSS v4.0.1 Requirement 3.7.3) Document where they live, who can access them, and how extraction is prevented or governed.

What evidence is most likely to fail an audit?

Gaps between policy and reality fail fast: a policy that mandates vault storage while keys are found in config files, repositories, or shared drives. (PCI DSS v4.0.1 Requirement 3.7.3) Missing access logs or unclear key export controls are also common hangups.

How do we handle break-glass access to keys?

Document break-glass in the procedure, restrict it to a small set of admins, require approval, and ensure it produces audit logs you can retrieve. (PCI DSS v4.0.1 Requirement 3.7.3) Test the process so it works during an incident without bypassing controls.

What if a third party manages our keys in their platform?

You still need your key-management policy to cover secure storage expectations and your due diligence to collect evidence that the third party meets them. (PCI DSS v4.0.1 Requirement 3.7.3) Require clarity on storage mechanism, access controls, logging, and export restrictions.

Can developers have access to production keys if they’re stored in KMS?

Storage in KMS does not automatically make access appropriate. (PCI DSS v4.0.1 Requirement 3.7.3) Limit human access to production keys, grant applications access via narrowly scoped service identities, and document any exceptions with justification and compensating controls.