SC-28(3): Cryptographic Keys

SC-28(3) requires you to provide protected storage for cryptographic keys, meaning keys must be stored in a dedicated, access-controlled, and tamper-resistant way that prevents disclosure or unauthorized use. To operationalize it fast, inventory where keys exist, move them into approved key stores (KMS/HSM/secret managers), enforce least-privilege access, and retain audit-ready evidence. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Key takeaways:

• Protected key storage means keys are not left in code, configs, shared drives, or general-purpose databases. (NIST SP 800-53 Rev. 5 OSCAL JSON)
• Your fastest path is standardizing on approved key storage patterns (cloud KMS, HSM, or enterprise secret manager) and blocking exceptions. (NIST SP 800-53 Rev. 5)
• Auditors focus on “where are the keys, who can access them, and can you prove controls operated,” so evidence design matters. (NIST SP 800-53 Rev. 5)

The sc-28(3): cryptographic keys requirement is easy to misunderstand because many teams equate “encryption at rest” with “key security.” SC-28(3) is narrower and sharper: it is specifically about how you store cryptographic keys so they remain protected even if other systems are compromised. The practical compliance risk is rarely that you lack encryption libraries; it’s that keys are scattered across repos, CI/CD variables, admin laptops, application config files, or “temporary” shared locations.

For a Compliance Officer, CCO, or GRC lead, the operational goal is straightforward: define what “protected storage” means in your environment, require engineering teams to use the approved mechanisms, and collect repeatable evidence that keys are actually stored and accessed correctly. This page gives you requirement-level implementation guidance you can hand to security engineering and platform owners, plus the artifacts you need to retain for assessment readiness against NIST SP 800-53 Rev. 5. (NIST SP 800-53 Rev. 5)

Regulatory text

Requirement (SC-28(3)): “Provide protected storage for cryptographic keys {{ insert: param, sc-28.03_odp.01 }}.” (NIST SP 800-53 Rev. 5 OSCAL JSON)

What the operator must do

You must ensure cryptographic keys are stored in a protected key store, with controls that prevent unauthorized disclosure, extraction, or modification. In operational terms, you need: (1) an approved set of key storage services and patterns, (2) access controls and audit logging around those services, and (3) proof that keys actually live there rather than in ad hoc locations. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Plain-English interpretation (what SC-28(3) really demands)

Protected key storage means keys are treated as high-value secrets with dedicated safeguards, separate from general application storage. If a developer can copy a production key from a repo, a config file, a ticket, or a shared folder, you likely fail SC-28(3) even if data is encrypted.

A workable interpretation for audits:

• Keys are generated, stored, and used through approved key management mechanisms.
• Direct key material access is tightly restricted (least privilege) and monitored.
• Keys are not persistently stored in plaintext in places designed for convenience rather than security. (NIST SP 800-53 Rev. 5)

Who it applies to

Entity scope

SC-28(3) is a NIST SP 800-53 Rev. 5 control enhancement commonly assessed in:

• Federal information systems
• Contractor systems handling federal data (including systems operated by third parties on behalf of a federal program) (NIST SP 800-53 Rev. 5 OSCAL JSON)

Operational scope (where it shows up)

This requirement applies anywhere your organization uses cryptography, including:

• Application encryption keys (database TDE keys, application-layer envelope keys)
• TLS private keys for endpoints, APIs, service meshes, and internal PKI
• Signing keys (code signing, container signing, document signing)
• Token signing/encryption keys (OIDC/JWT)
• Backup and storage encryption keys
• Keys held by third parties that operate systems or manage infrastructure for you (contractors, managed service providers, SaaS with customer-managed keys) (NIST SP 800-53 Rev. 5)

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

Use this as an execution checklist you can assign to control owners.

1) Assign a control owner and define “protected storage” for your environment

Deliverables:

• Named owner (Security Engineering, IAM, or Platform Security is typical)
• A one-page standard that defines approved key stores and disallowed storage locations

Make a clear decision list:

• Approved: cloud KMS, HSM-backed KMS, enterprise secrets manager, dedicated key vault with RBAC + audit logs.
• Disallowed (default): source code repositories, CI/CD logs, plaintext config files, shared drives, general databases, ticket attachments, personal devices.

If you use Daydream for control operations, this is where you map SC-28(3) to the owner, implementation procedure, and recurring evidence artifacts so it stays assessable over time. (NIST SP 800-53 Rev. 5 OSCAL JSON)

2) Inventory keys and key “touchpoints”

You need an inventory that is good enough to answer: “Where are production keys stored today, and which systems use them?”

• Identify key types: TLS, signing, encryption-at-rest, application secrets that function as keys.
• Identify locations: KMS/HSM, secret managers, repos, environment variables, container images, config management tools.
• Identify access paths: which roles/accounts can read or use keys.

Practical tip: treat “unknown key locations” as a tracking issue with an owner and due date. Auditors will accept a managed remediation plan more readily than uncertainty.

3) Standardize storage patterns (and remove exceptions)

Pick your standard patterns and enforce them:

• Cloud-first: store keys in cloud KMS and restrict key usage via IAM policies; use envelope encryption where applicable.
• HSM requirement (when applicable in your environment): store root or high-impact keys in HSM-backed stores.
• Secrets manager for non-KMS items: for credentials, API keys, or tokens that are cryptographically sensitive but not KMS-managed, use a secrets manager with access logging and rotation support.

Then remove exceptions:

• Migrate keys out of apps and into the approved store.
• Replace hardcoded keys with runtime retrieval.
• Rotate keys after migration if key exposure is plausible.

4) Enforce least privilege and separation of duties for key access

Minimum operational expectations you can implement quickly:

• Limit who can read/export key material (ideally nobody for non-exportable keys).
• Separate roles for key administration (create/rotate/disable) vs key usage (encrypt/decrypt/sign).
• Use dedicated service identities for applications; no shared human accounts for production key access.

5) Enable logging, alerting, and review for key access

Protected storage is hard to defend in an audit without logs.

• Turn on audit logs for KMS/HSM/secrets manager access.
• Define review triggers: access from unusual principals, cross-environment use (dev principal touching prod keys), policy changes that widen access.
• Run periodic access reviews focused on “who can administer keys” and “who can use keys.”

6) Implement SDLC guardrails to prevent regressions

This is where teams commonly backslide.

• Add secret scanning and pre-commit checks for keys and private material.
• Block merges that introduce private keys or key-like secrets into repos.
• Add IaC policy checks to prevent provisioning key stores without logging or with overly broad IAM permissions.

7) Validate with an assessor-style test

Before an exam, run three proof checks:

• Spot check: pick a few critical apps and trace how keys are retrieved at runtime.
• Access proof: show who can administer and who can use keys, and demonstrate it matches policy.
• Negative proof: show repos and configuration stores are not holding keys (or show an exception register with remediation). (NIST SP 800-53 Rev. 5)

Required evidence and artifacts to retain

Auditors will ask for proof that the design exists and that it operates. Retain:

• Key management standard defining protected storage and approved services/patterns
• Key inventory (at least for production/high-impact systems): key type, system, storage location, owner, access model
• Architecture diagrams or runbooks showing how apps retrieve and use keys
• Access control evidence: IAM policies/roles/groups for KMS/HSM/secrets manager, with admin vs usage separation
• Audit log samples for key access and admin actions (export where possible)
• Exception register documenting any keys not yet migrated, compensating controls, and remediation plan
• Change tickets or pull requests showing migrations completed and hardcoded keys removed

Daydream fits well here as the system of record for control ownership, procedures, and the recurring evidence set you will re-collect each assessment cycle. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Common exam/audit questions and hangups

Expect these questions from assessors:

1. “Show me where cryptographic keys are stored for System X.”
2. “Can any developer export production keys?”
3. “Do you have non-exportable keys where appropriate?”
4. “How do you prevent keys from being committed to source control?”
5. “How do you review key access over time?”
6. “What happens when a third party operates part of the stack; who controls the keys?” (NIST SP 800-53 Rev. 5)

Hangups that slow audits:

• No authoritative inventory (teams answer from memory).
• Confusion between encryption configuration and key custody.
• “Temporary” keys in CI/CD variables with broad access.

Frequent implementation mistakes (and how to avoid them)

1. Storing keys in “encrypted” files without strong access control
   Fix: treat file-based key storage as an exception that requires a dedicated secure enclave or vaulting mechanism.

2. Using secret managers but allowing broad read access
   Fix: restrict by app identity; avoid human read access in production unless break-glass with logging.

3. No evidence of operational review
   Fix: keep periodic access review outputs and samples of KMS/secrets audit logs.

4. Letting third parties generate/store keys without clarity
   Fix: document the shared responsibility model and confirm the third party’s controls meet your protected storage standard. (NIST SP 800-53 Rev. 5)

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this specific control enhancement, so you should treat this primarily as an assessment-readiness and breach-risk control rather than a “case-law” driven requirement.

Risk is concrete:

• If an attacker extracts keys, encryption at rest and signing controls collapse.
• Key compromise creates incident scope expansion because you must assume exposed data, forged signatures, or undetected tampering until keys are rotated and trust is re-established. (NIST SP 800-53 Rev. 5)

Practical 30/60/90-day execution plan

First 30 days (stabilize and stop the bleeding)

• Assign control owner and publish “protected storage” standard for keys. (NIST SP 800-53 Rev. 5 OSCAL JSON)
• Start a production key inventory with system owners; focus on crown-jewel systems first.
• Turn on logging for existing KMS/secrets platforms; confirm logs are retained and retrievable.
• Put guardrails in place: secret scanning in repos and CI/CD.

Days 31–60 (migrate and prove)

• Migrate the highest-risk keys (hardcoded, file-based, shared) into approved KMS/HSM/secrets manager patterns.
• Implement least-privilege roles for key administration vs key usage.
• Create an exception register for anything not migrated, with compensating controls and a target remediation date.

Days 61–90 (operationalize and make it repeatable)

• Run an access review for key admin and key usage roles; fix overbroad access.
• Build a standard evidence pack: policies, screenshots/exports of IAM bindings, log samples, and architecture notes.
• Add recurring controls in Daydream: ownership, procedure, and evidence cadence so SC-28(3) stays audit-ready between assessments. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Frequently Asked Questions

Does SC-28(3) require an HSM?

The text requires “protected storage for cryptographic keys,” but it does not explicitly mandate an HSM in the excerpt provided. Define which key categories in your environment require HSM-backed storage, and document the rationale and standard. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Are secrets (API tokens, passwords) in scope as “cryptographic keys”?

If a secret functions as key material for encryption, signing, or token issuance, treat it as in-scope. If you exclude certain secrets, document your scoping logic and ensure those items still meet your organization’s secret handling standard. (NIST SP 800-53 Rev. 5)

What evidence is usually enough to satisfy an assessor?

Provide a key management standard, a key inventory for in-scope systems, access control exports for the key store, and audit log samples showing key access and admin events. Add an exception register if any keys are still migrating. (NIST SP 800-53 Rev. 5)

We use a third party SaaS. How do we meet SC-28(3)?

Confirm where keys are stored and who controls them (provider-managed vs customer-managed keys). Capture the arrangement in your third-party due diligence and document how the SaaS meets your “protected storage” definition. (NIST SP 800-53 Rev. 5)

Is storing keys as Kubernetes Secrets compliant?

It depends on whether the Kubernetes Secrets implementation in your environment meets your protected storage definition (access control, encryption, and auditability). Many teams treat it as an exception unless backed by stronger controls and restricted access paths. (NIST SP 800-53 Rev. 5)

How should we handle break-glass access to keys?

Allow it only through a documented, time-bound process with strong authentication, ticketed approval, and logging review after use. Keep evidence of each break-glass event and the post-event review. (NIST SP 800-53 Rev. 5)