Additional Key Management for Service Providers

PCI DSS v4.0.1 Requirement 3.7.9 requires service providers that share cryptographic keys with customers (for transmitting or storing account data) to document and distribute customer-facing guidance for secure key transmission, storage, and key updates. To operationalize it, you need clear written instructions, a controlled distribution method, and retained evidence that customers received the guidance. (PCI DSS v4.0.1 Requirement 3.7.9)

Key takeaways:

• This applies only if you are a service provider and you share cryptographic keys with customers for account data use cases. (PCI DSS v4.0.1 Requirement 3.7.9)
• Your obligation is customer-facing: documented guidance plus proof it was distributed, not just an internal key management policy. (PCI DSS v4.0.1 Requirement 3.7.9)
• Auditors will look for completeness (transmission, storage, updating) and distribution evidence tied to the specific key-sharing workflows. (PCI DSS v4.0.1 Requirement 3.7.9)

“Additional key management for service providers” is easy to misread as a purely technical requirement. Requirement 3.7.9 is operational and customer-facing: if you share cryptographic keys with customers for transmission or storage of account data, you must provide documented guidance that tells customers how to handle those keys securely across the key lifecycle. (PCI DSS v4.0.1 Requirement 3.7.9)

This comes up in real implementations more often than teams expect: hosted payment pages, encryption gateway services, tokenization services, or any environment where customers are given a key (or a key-encrypting-key, certificate private key, pre-shared key, or API-provisioned wrapping key) to encrypt, decrypt, transmit, or store account data. If customers mishandle keys, the compromise can land back on you during an assessment because the standard explicitly requires you to provide guidance and to distribute it. (PCI DSS v4.0.1 Requirement 3.7.9)

The fastest path to compliance is to (1) map every instance where keys are shared, (2) write short, specific instructions customers can follow, (3) distribute those instructions through controlled channels, and (4) retain evidence that distribution occurred and stays current.

Regulatory text

PCI DSS v4.0.1 Requirement 3.7.9 states: “Additional requirement for service providers only: where a service provider shares cryptographic keys with its customers for transmission or storage of account data, guidance on secure transmission, storage, and updating of such keys is documented and distributed to the service provider's customers.” (PCI DSS v4.0.1 Requirement 3.7.9)

Operator translation (what you must do):

• Trigger condition: You are a service provider and you share cryptographic keys with customers for transmission or storage of account data. (PCI DSS v4.0.1 Requirement 3.7.9)
• Control requirement: Create documented guidance that covers secure transmission, secure storage, and secure updating of those shared keys. (PCI DSS v4.0.1 Requirement 3.7.9)
• Delivery requirement: Distribute the guidance to customers, and be able to show that you did. (PCI DSS v4.0.1 Requirement 3.7.9)

Plain-English interpretation

If customers receive keys from you (or keys you jointly manage) and those keys protect account data, you must give customers clear instructions on:

1. how to receive and transmit those keys securely,
2. how to store them securely, and
3. how to update/rotate/replace them securely. (PCI DSS v4.0.1 Requirement 3.7.9)

This requirement is not satisfied by “our KMS is secure” marketing language or a generic security whitepaper. Assessors expect actionable steps a customer can follow and evidence you provided them.

Who it applies to (entity and operational context)

In-scope entities

• Service providers subject to PCI DSS that share cryptographic keys with their customers for transmission or storage of account data. (PCI DSS v4.0.1 Requirement 3.7.9)

In-scope operational contexts (common patterns)

Treat the requirement as in scope if any of the following are true in your service:

• You provision encryption keys (or wrapping keys) to customers so they can encrypt account data before sending it to you.
• You provide a client-side encryption library and issue keys/certificates used to protect account data.
• You run a hosted vault/tokenization/encryption service where customers must store or manage a key component on their side.
• You issue a certificate/private key pair or pre-shared secret used to protect account data in transit or at rest.

Out-of-scope (usually)

• You do not share cryptographic keys with customers at all.
• Customers bring and manage their own keys entirely and you never provide key material or shared keying guidance tied to your service’s protection of account data.

If you are unsure, treat “share” broadly in your scoping exercise and then document why certain flows are excluded.

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

1) Identify every “key-sharing” workflow

Create a short inventory that answers:

• What key material is shared (key, certificate private key, wrapping key, derived secret)?
• Which customers receive it (all, certain tiers, certain integrations)?
• What does the key protect (account data transmission, account data storage)?
• How is it delivered (portal download, API, email, ticket, HSM ceremony, customer-generated with your wrapping key)?
• How are updates handled today (rotation, re-issuance, revocation)?
  This inventory becomes your backbone for guidance and audit evidence.

2) Write customer guidance that is specific, not generic

Build a customer-facing “Key Handling Guide” (or similar) with three required sections:

A. Secure transmission (keys moving)

• Approved delivery channels (for example, customer portal requiring strong authentication, mutually authenticated API).
• Prohibited channels (for example, plaintext email or chat).
• How customers should transmit keys internally (for example, within their organization) and who may receive them.

B. Secure storage (keys at rest)

• Where keys may be stored (for example, an HSM or a managed KMS under customer control).
• Minimum access control expectations (for example, least privilege, separation of duties for key administrators).
• Backup and recovery expectations (for example, encrypt backups, control access, test recovery).

C. Secure updating (key lifecycle changes)

• Rotation triggers and process (routine rotation, compromise suspected, staff departure affecting access).
• How to update keys without breaking the integration (versioning approach, overlap windows, re-encryption expectations where relevant).
• Revocation and incident steps (what to do if a key is exposed; how to contact you; what artifacts to provide).

You can keep the guide concise, but it must be concrete enough that a customer security engineer can implement it without guesswork. (PCI DSS v4.0.1 Requirement 3.7.9)

3) Align the guidance to your actual product and support model

A common audit failure is guidance that contradicts reality. Before publishing:

• Validate the guide against how keys are actually provisioned in production.
• Ensure Support and Customer Success can follow it during onboarding and incidents.
• Add product-specific screenshots or API snippets if that is how customers receive keys.

4) Distribute the guidance through controlled channels

Requirement 3.7.9 explicitly requires distribution to customers. (PCI DSS v4.0.1 Requirement 3.7.9) Pick at least one primary distribution channel and one backup:

• Customer trust center or documentation portal with authentication (preferred).
• Contract or order form attachment (works well for enterprise).
• Customer onboarding checklist (ticketing system record helps with evidence).
• Periodic customer security bulletin (for updates).

5) Make distribution provable

You need evidence that customers received the guidance. Practical options:

• Portal access logs and document versioning history.
• Ticketing/onboarding records showing the guide was provided.
• Email distribution logs from a controlled mailing list (avoid sending key material; send the guidance).

6) Put the guidance under change control

Key handling guidance must stay accurate as your product changes:

• Assign an owner (Security, Product Security, or GRC).
• Define review triggers (product changes affecting key flows, security incidents, cryptography changes).
• Version the document and publish release notes aimed at customers.

7) Operationalize with third-party risk management mechanics

Even though the “customer” is receiving the guidance, your compliance posture improves if you treat this as a repeatable third-party governance process:

• Add the guide to your standard customer onboarding package.
• Add an internal control that checks “key-sharing customers have been sent current guidance.”
• If you use a platform like Daydream to manage third-party compliance artifacts and evidence workflows, track the guide as a controlled artifact with an evidence checklist and distribution proofs by customer cohort.

Required evidence and artifacts to retain

Keep evidence tied to the exact language of the requirement: documented guidance + distributed to customers, covering transmission, storage, updating. (PCI DSS v4.0.1 Requirement 3.7.9)

Minimum artifact set:

• Customer Key Handling Guide (current version) covering:
  • secure transmission,
  • secure storage,
  • secure updating. (PCI DSS v4.0.1 Requirement 3.7.9)
• Document control metadata: version history, approver, publication date, change log.
• Scope inventory: list of products/integrations where keys are shared for account data transmission/storage.
• Distribution evidence: portal logs, onboarding tickets, customer notifications, or contract attachments showing delivery.
• Exception handling record: any customers with alternative key exchange methods and the approved compensating guidance provided to them.

Common exam/audit questions and hangups

Expect assessors to probe these areas:

• “Show me where you share cryptographic keys with customers for account data use cases.” (PCI DSS v4.0.1 Requirement 3.7.9)
• “Where is the documented customer guidance that covers transmission, storage, and updating?” (PCI DSS v4.0.1 Requirement 3.7.9)
• “How do you distribute it, and how can you prove customers received it?” (PCI DSS v4.0.1 Requirement 3.7.9)
• “How do you keep guidance current when your implementation changes?”
• “Is the guidance actionable, or is it a high-level whitepaper?”

Common hangup: teams show an internal key management policy. That is helpful, but it does not meet the “distributed to customers” part. (PCI DSS v4.0.1 Requirement 3.7.9)

Frequent implementation mistakes and how to avoid them

Mistake: Guidance exists but doesn’t cover all three areas

Fix: Use a simple checklist: transmission, storage, updating. If any section is missing, add it before publishing. (PCI DSS v4.0.1 Requirement 3.7.9)

Mistake: Distribution is informal and not provable

Fix: Choose systems that generate logs (documentation portal, onboarding ticketing). Store distribution evidence with your compliance artifacts.

Mistake: One-size-fits-all guidance for multiple key models

Fix: Publish a base guide plus integration-specific addenda (for example, “API key wrapping flow” vs “certificate-based mTLS flow”). Customers need the right instructions for the keys they actually receive.

Mistake: Mixing key material handling with guidance distribution

Fix: Never embed actual key material in the guidance distribution process. The requirement is about guidance, not transmitting keys through risky channels. (PCI DSS v4.0.1 Requirement 3.7.9)

Enforcement context and risk implications

No public enforcement cases were provided in the available source catalog, so you should treat this requirement primarily as an assessment and assurance risk. The practical risk is predictable: if customers mishandle shared keys, account data protection fails, and you may be unable to demonstrate that you met the documented-and-distributed guidance obligation. (PCI DSS v4.0.1 Requirement 3.7.9)

Practical execution plan (30/60/90)

First 30 days (Immediate)

• Confirm whether you share cryptographic keys with customers for account data use cases. (PCI DSS v4.0.1 Requirement 3.7.9)
• Build the workflow inventory (systems, delivery methods, customer cohorts).
• Draft a customer Key Handling Guide with the three required sections. (PCI DSS v4.0.1 Requirement 3.7.9)
• Pick distribution channels that create evidence (portal and onboarding ticketing are the usual winners).

By 60 days (Near-term)

• Publish the guide with version control and an owner.
• Push distribution to all in-scope customers (bulk communication plus onboarding integration).
• Train Support/CS on what to send and where evidence is captured.
• Implement an internal check that new customers receiving keys also receive the current guide.

By 90 days (Operationalize)

• Run an internal audit: sample customers and confirm distribution evidence exists.
• Close gaps: missing cohorts, undocumented exceptions, outdated integration instructions.
• Add change triggers so product releases that modify key flows force a guidance review.
• If you manage many customer cohorts and evidence requests, track artifacts and distribution proofs in Daydream so your QSA evidence pack is consistent and repeatable.

Frequently Asked Questions

Does this apply if customers bring their own keys (BYOK)?

It applies if you “share cryptographic keys with customers” for account data transmission or storage. (PCI DSS v4.0.1 Requirement 3.7.9) If customers fully manage keys without receiving key material from you, document that scoping decision and keep it with your inventory.

Can we satisfy this requirement with a security whitepaper?

Only if it provides customer-actionable guidance on secure key transmission, storage, and updating, and you can show it was distributed to customers. (PCI DSS v4.0.1 Requirement 3.7.9) Most generic whitepapers fail the “how to” test.

What counts as “distributed” to customers?

Distribution needs to be real and provable: a controlled documentation portal, onboarding tickets showing delivery, or contract attachments are common approaches. The assessor will ask you to demonstrate it happened. (PCI DSS v4.0.1 Requirement 3.7.9)

Do API keys count as cryptographic keys for this requirement?

The requirement language is “cryptographic keys” used for transmission or storage of account data. (PCI DSS v4.0.1 Requirement 3.7.9) If an “API key” is functioning as a cryptographic secret that protects account data (for example, key material for encryption or wrapping), treat it as in scope and write guidance accordingly.

We have multiple products with different key exchange methods. Do we need separate guidance?

You can publish one base guide plus product- or integration-specific addenda. The key is that each customer can find the exact instructions for their key-sharing workflow, including transmission, storage, and updating. (PCI DSS v4.0.1 Requirement 3.7.9)

How do we prove ongoing compliance after initial distribution?

Keep version history and distribution evidence for both initial publication and updates. Tie your publication process to change control so new versions are automatically pushed through your chosen distribution channels with retained logs. (PCI DSS v4.0.1 Requirement 3.7.9)