SC-12(6): Physical Control of Keys

To meet the sc-12(6): physical control of keys requirement, you must keep cryptographic keys under your organization’s physical custody when an external service provider encrypts your stored information. Operationally, this means you control the hardware and facilities that store or generate the keys (for example, customer-managed HSMs), and you can prove the provider cannot physically access them. ¹

Key takeaways:

• Physical control is a custody requirement: you retain physical possession of the key storage medium, not just “logical” admin access. ¹
• Your third party encryption architecture must be designed so the provider cannot physically obtain or handle your key material. ¹
• Auditors will look for clear ownership, documented procedures, and repeatable evidence that physical custody is maintained over time. ²

SC-12(6) comes up when you outsource storage or processing to a third party but still need strong assurance that encryption keys remain under your control. Many programs stop at “we manage keys in KMS” or “we use BYOK,” then get stuck when an assessor asks the harder question: who physically controls the keys, and what prevents the provider from physically accessing the key material or key storage devices?

This requirement is narrow but operationally sharp. It forces an explicit design choice: either accept provider-managed encryption with provider physical custody (and treat it as noncompliant for SC-12(6) in scope), or implement a customer-controlled key architecture where your organization retains physical custody of the key storage boundary. The practical work is (1) scoping which data is “stored information encrypted by external service providers,” (2) selecting an architecture that preserves physical custody, and (3) documenting and evidencing day-to-day custody controls.

If you need to operationalize quickly, focus on three deliverables: a key custody model decision, a runbook that proves custody stays with you, and an evidence packet that you can reproduce on demand. ¹

Regulatory text

Requirement: “Maintain physical control of cryptographic keys when stored information is encrypted by external service providers.” ¹

Operator meaning (what you must do):

• If a third party encrypts your stored data, you must ensure the cryptographic keys used for that encryption remain in hardware and facilities physically controlled by your organization, not physically controlled by the provider. ¹
• You must be able to demonstrate “physical control” as an ongoing custody condition, not a one-time design claim. ²

Plain-English interpretation

SC-12(6) is a custody rule for keys in outsourced environments: if the provider encrypts your stored information, your organization keeps physical possession of the keys (or the hardware that contains them). “Physical control” usually means you own or control the data center space and the hardware boundary where keys reside, and you restrict who can touch that boundary through physical access controls and custody processes. ¹

A quick decision test:

• Compliant direction: Keys are generated, stored, and used inside hardware you physically control (or in a dedicated arrangement where you have physical custody and the provider does not). ¹
• High-risk direction: Keys are stored in the provider’s shared KMS/HSM infrastructure where the provider controls the facility and hardware, even if you administer key policies. That may satisfy other key-management expectations, but it does not satisfy SC-12(6) as written. ¹

Who it applies to

SC-12(6) applies when:

• Entity context: Federal information systems and contractor systems handling federal data. ¹
• Operational context: You store information with an external service provider and the stored information is encrypted in that provider’s environment. ¹

Common in-scope scenarios:

• Cloud object storage encryption for regulated workloads.
• Managed database services with encryption at rest enabled.
• Hosted backup/archival platforms encrypting customer data at rest.

Out-of-scope in practice (for this enhancement specifically):

• Systems where the provider does not encrypt stored information for you (for example, you encrypt client-side before upload and the provider only stores ciphertext). Your broader encryption/key management controls still apply, but the “when stored information is encrypted by external service providers” condition changes the applicability analysis. ¹

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

1) Define the SC-12(6) scope precisely

Create a short scoping memo or spreadsheet that answers:

• Which third parties store your data?
• For each, is encryption at rest performed by the provider service?
• Which keys are used for that encryption, and where do they live physically?
• Which systems/data types are in your authorization boundary or compliance scope?

Deliverable: SC-12(6) scope register mapping system → provider → encryption-at-rest mechanism → key custody model. ²

2) Choose a custody model that satisfies “physical control”

You need an architecture where your organization retains physical custody of the key boundary. Options vary by environment, but the control expectation stays constant: provider staff cannot physically access the key material or key storage devices because they are not under provider physical custody. ¹

Practical patterns (describe your chosen one clearly):

• Customer-controlled HSM in your facilities that performs key generation and cryptographic operations for data stored with a provider.
• Dedicated key infrastructure under your physical custody with controlled lifecycle processes (generation, storage, backup, rotation, destruction).

Avoid hand-wavy phrases in documentation like “keys are customer-managed” unless you can tie it to physical custody evidence. ²

3) Assign ownership and write the operating procedure

Operationalize SC-12(6) as a runbook with named roles:

• Control owner: usually Security Engineering, Crypto Engineering, or IAM/KMS team.
• Physical custody owner: usually Data Center Operations / Facilities Security (even if keys are managed by Security).
• Third party manager: Vendor/third-party risk function for contract controls and attestations.

Your procedure should cover:

• Where keys are stored (device identifiers, location, custody boundary).
• Who has physical access, and how it is granted/revoked.
• How keys are backed up (and where those backups are physically held).
• What happens during provider incidents or service transitions (key continuity and custody). ¹

4) Implement physical access controls around the key boundary

This is the “physical control” core:

• Maintain an approved access list for any room/cage/rack storing key hardware or key backups.
• Require access logging and periodic reviews.
• Add separation of duties for sensitive actions (for example, two-person rule for key material handling) when feasible for your risk profile.

Keep the controls proportionate, but make them auditable. An assessor needs to see that physical custody is real and maintained over time. ²

5) Bind third-party encryption to your physically controlled keys

Document how the third party’s encryption uses keys that remain physically controlled by you:

• Data flow: where encryption is invoked, where keys are called, and where cryptographic operations occur.
• Trust boundaries: what the provider can do (call an API, request encryption) versus what it cannot do (physically access the HSM, extract key material).
• Failure modes: what happens if connectivity to your key service fails, and whether the provider ever falls back to provider-held keys.

Deliverable: Key custody architecture diagram + narrative written for an auditor. ¹

6) Contract and third-party due diligence alignment

Even with physical custody, you still need contractual clarity:

• Require the provider to acknowledge it does not have physical custody or physical access to your keys (as applicable to your design).
• Define responsibilities for incident response, subpoenas/legal demands, and service termination in a way that protects key custody and key continuity.

This is where a third-party risk program supports SC-12(6) without substituting for it. The control is satisfied by your physical custody, but contracts prevent operational drift. ²

7) Evidence it monthly/quarterly so audits are boring

Build recurring evidence collection into operations:

• Export physical access logs for key locations.
• Capture access review sign-offs.
• Record key inventory changes and custody transfers.
• Document exceptions and compensating controls.

Daydream can help by mapping SC-12(6) to an owner, a concrete procedure, and a recurring evidence checklist so you are not rebuilding the same packet every audit cycle. ¹

Required evidence and artifacts to retain

Keep an “SC-12(6) evidence packet” with:

• SC-12(6) scope register (systems/providers in scope, encryption model, custody model). ²
• Key inventory: identifiers, purpose, environment, storage boundary, and lifecycle status. ²
• Architecture diagram and trust boundary narrative showing the third party encrypts stored data while keys remain physically controlled by you. ¹
• Physical access control artifacts: access lists, approval tickets, access logs, periodic access reviews for key storage locations. ²
• Runbooks/SOPs for key handling, backup, rotation, destruction, and emergency access, tied to roles. ²
• Third-party contract excerpts or addenda describing key custody responsibilities and restrictions aligned to your design. ²

Common exam/audit questions and hangups

Auditors and assessors typically press on:

• “Where are the keys physically stored, and who controls that facility and hardware?” ¹
• “Can the external service provider’s staff physically access the HSMs or key backups?” ¹
• “Show evidence from the last review period that physical access is restricted and reviewed.” ²
• “Do you have any fallback mode where provider-managed keys are used if your key system is unavailable?” ¹
• “How do you handle key custody during migrations, returns of media, or hardware replacement?” ²

Hangup to expect: teams often present “KMS policy screenshots” when the assessor asked for physical custody evidence. Fix this by keeping physical access and custody artifacts in the same evidence packet as the crypto diagrams. ²

Frequent implementation mistakes (and how to avoid them)

Mistake 1: Confusing logical admin control with physical custody

If your keys live in a provider-managed HSM fleet, your IAM permissions do not equal physical control. Document a custody boundary you physically control, or explicitly mark SC-12(6) as not satisfied for that system and pursue an alternate architecture. ¹

Mistake 2: No written, testable procedure

A diagram without an SOP fails in real operations. Write a runbook with triggers (new key, rotation, incident, migration) and attach evidence outputs (logs, tickets, sign-offs). ²

Mistake 3: Backups break custody

Teams store HSM backups or key escrow media offsite with a third party and forget that custody moved. Treat key backups as key storage. Apply the same physical custody standard and evidence. ¹

Mistake 4: Weak third-party change management

A provider feature change can shift encryption behavior. Track provider roadmap changes that affect encryption and key handling, and require security review before enabling “managed encryption” options. ²

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for SC-12(6), so you should treat this as an assessment-driven requirement rather than a penalty-cited item in this document. ²

Risk-wise, losing physical custody of keys increases:

• Confidentiality exposure if a provider compromise includes access to key storage hardware or key backup media.
• Legal/regulatory exposure if you represent customer-controlled encryption but cannot substantiate physical custody during audits.
• Operational lock-in if you cannot extract or rewrap keys without provider assistance.

Practical 30/60/90-day execution plan

First 30 days (stabilize scope and design decisions)

• Build the SC-12(6) scope register for all third parties storing regulated data. ²
• Decide, per system, whether you will meet physical custody via architecture changes or treat SC-12(6) as a gap requiring remediation planning. ¹
• Assign a single control owner and publish an initial runbook outline and evidence checklist in your GRC system (Daydream or equivalent). ¹

Next 60 days (implement custody controls and evidence collection)

• Implement or formalize physical access controls for key storage locations, including logging and access reviews. ²
• Produce an auditor-ready key custody architecture diagram and trust boundary narrative for each in-scope platform. ¹
• Update third-party contract language or addenda where needed to prevent drift from the custody model. ²

By 90 days (operationalize and make it repeatable)

• Run your first evidence cycle: access review sign-offs, log exports, key inventory reconciliation, and exception tracking. ²
• Tabletop an incident scenario involving the third party (service outage, breach, legal demand) and confirm key custody and decision rights hold. ¹
• Lock in recurring tasks and owners in Daydream so evidence collection and control testing stay consistent across quarters and staff changes. ¹

Frequently Asked Questions

Does “BYOK” automatically satisfy SC-12(6)?

Not by itself. SC-12(6) is about physical custody of keys; some BYOK models still keep keys inside provider-controlled hardware and facilities. Document where keys physically reside and who controls physical access. ¹

If we encrypt client-side before sending data to a third party, is SC-12(6) still applicable?

SC-12(6) is triggered when stored information is encrypted by external service providers. If the provider only stores ciphertext and does not perform encryption for storage, document that condition and keep the scoping memo. ¹

What evidence is most persuasive to auditors for “physical control”?

Provide a custody boundary description, physical access logs, and periodic access review records tied to the key storage location, plus diagrams showing provider encryption depends on that boundary. Keep it as a single evidence packet. ²

Can a third party ever have emergency access to our key hardware?

If a third party can physically access the key boundary, you have a custody problem for SC-12(6). If you must allow it, document a tightly controlled exception process and treat it as a risk acceptance with compensating controls. ¹

How do we handle key backups without breaking physical control?

Treat backups as key storage media. Keep them in facilities and containers under your physical custody, with logged access and periodic review, and document the chain of custody for any movement. ¹

What should the control owner track in a GRC tool like Daydream?

Track the system/provider scope list, the approved custody model per system, the SOP/runbook, and recurring evidence tasks (access reviews, log pulls, key inventory reconciliation) with assigned owners and due dates. ¹

Footnotes

1. NIST SP 800-53 Rev. 5 OSCAL JSON

2. NIST SP 800-53 Rev. 5