Cryptographic Protection

SC-13 is deceptively short: “determine” the cryptographic uses and “implement” the required cryptography (NIST Special Publication 800-53 Revision 5). In practice, this becomes a governance-and-engineering requirement: you must make explicit decisions about where encryption and other cryptographic functions are required, select the types of cryptography that satisfy your environment’s risk and compliance needs, and prove they are actually deployed.

For a CCO, GRC lead, or security compliance owner, the fastest path to operationalizing SC-13 is to treat it as a closed loop: (1) document the cryptographic use cases in scope for your system boundary, (2) define a cryptographic standard that engineers can implement without guessing, (3) validate implementations with technical evidence, and (4) sustain it with monitoring and change control.

This page gives you requirement-level guidance you can hand to platform, network, application, and IAM teams. It focuses on what auditors and assessors look for: clear scope, clear standards, consistent implementation, and durable proof.

Regulatory text

Excerpt: “Determine the organization-defined cryptographic uses and type of cryptography required for each use; and implement the required cryptography.” (NIST Special Publication 800-53 Revision 5)

Operator interpretation (what you must do):

1. Determine organization-defined cryptographic uses. You must explicitly list where cryptography is required in your system. This is usually expressed as data flows and control points (for example: TLS for all external connections, encryption for storage, cryptographic integrity for logs, protection for secrets, and encrypted backups).
2. Determine the type of cryptography required for each use. You must specify what “acceptable crypto” means in your environment: approved protocols, cipher suites, key sizes where applicable, certificate requirements, key management approach, and any constraints on libraries or modules.
3. Implement the required cryptography. You must turn the standard into real configurations and code, then verify it is actually enforced (not “supported” or “available”).

SC-13 is not satisfied by a policy statement alone. Your documentation must match technical reality, and your technical reality must be provable.

Plain-English requirement

You need a crypto playbook for your system: where you encrypt, how you encrypt, who manages keys, and how you prevent teams and third parties from quietly weakening crypto over time. Then you need to show it’s deployed across the boundary and stays deployed after changes.

Who it applies to

Entity types: Cloud Service Providers and Federal Agencies operating systems aligned to the FedRAMP Moderate baseline (NIST Special Publication 800-53 Revision 5).

Operational context (where this shows up):

• Cloud environments hosting federal data or federal workloads
• System components inside the authorization boundary: applications, APIs, databases, object storage, message queues, CI/CD systems, logging pipelines, and administrative access paths
• Third parties that connect to or process your in-scope data (for example: SaaS tools, managed service providers, certificate authorities, and key management providers). Treat these as part of your cryptographic design because they can become your weakest link.

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

Step 1: Define the cryptographic “uses” as a scoped inventory

Create a list of cryptographic use cases that maps to your architecture. Keep it simple and auditable. Typical categories:

• Data in transit: browser to edge, service-to-service, admin access, API calls, database connections, remote logging, replication traffic
• Data at rest: databases, object storage, block storage, container images, artifacts, endpoints where applicable
• Backups and snapshots: backup repositories, offsite copies, DR replicas
• Secrets and credentials: API keys, tokens, passwords, private keys, service account credentials
• Integrity and authenticity: code signing, artifact signing, log integrity where you rely on logs for investigations

Deliverable: a “Cryptographic Uses Register” tied to your system boundary and major components.

Step 2: Publish a cryptographic standard engineers can implement

Write a Cryptographic Protection Standard that answers “what type of crypto is required for each use.” Include:

• Approved transport protocols (for example, TLS requirements for external and internal connections)
• Approved encryption approaches for storage (platform-native encryption, application-layer encryption when needed)
• Certificate requirements (issuance, renewal expectations, prohibited weak settings)
• Key management approach (who can create keys, rotate keys, access keys, and how keys are protected)
• Approved cryptographic libraries/modules for application teams, plus rules for third-party SDKs

Make it enforceable:

• State what is required
• State what is prohibited
• State what needs an exception and who can approve it (security + compliance)

Deliverable: Cryptographic Protection Standard approved through your governance process.

Step 3: Translate the standard into platform baselines and “guardrails”

Policies don’t configure systems. Convert your standard into:

• Network and edge baselines: load balancers, API gateways, service mesh, VPNs, and ingress controllers configured to enforce your minimums
• Storage baselines: encryption settings for managed databases and storage services, encryption defaults, and access policies that prevent unencrypted resources where your platform supports that control
• Host/container baselines: disk encryption expectations, secrets handling patterns, hardened images with approved crypto libraries
• CI/CD checks: prevent merging or deploying configurations that weaken crypto settings

Deliverable: baseline configuration artifacts (IaC modules, hardening guides, CI checks) and evidence that they are in use.

Step 4: Implement and validate in each major layer

For each cryptographic use case, collect proof in two forms:

• Design evidence: architecture diagrams and data flow notes showing where crypto is applied
• Technical evidence: screenshots/exports/config snippets, command outputs, or pipeline logs showing the setting is enabled and enforced

Validation examples (adapt to your stack):

• Confirm TLS termination points and minimum protocol/cipher settings at the edge
• Confirm service-to-service encryption settings (service mesh or app config)
• Confirm database connections enforce encryption (not optional)
• Confirm storage encryption is enabled and keys are managed per your standard
• Confirm backups are encrypted and access-controlled

Deliverable: a “Crypto Implementation Evidence Pack” aligned to your Cryptographic Uses Register.

Step 5: Build exceptions and compensating controls that survive scrutiny

You will have legacy constraints. Handle them explicitly:

• Log the exception, scope, business owner, and expiration trigger
• Define compensating controls (segmentation, additional monitoring, restricted access paths)
• Track remediation work as a time-bound risk item

Deliverable: exception register entries tied to the crypto standard.

Step 6: Operationalize: monitoring, change control, and drift management

Most failures happen after initial authorization work. Add:

• Continuous configuration monitoring for weak TLS settings, expired certs, and disabled encryption flags
• Change control checks for crypto-affecting changes (edge config, cert rotation, KMS policy edits, database parameter changes)
• Periodic review of the Cryptographic Uses Register after architecture changes and new third parties

Deliverable: monitoring reports/alerts and change tickets that show crypto is managed, not assumed.

Required evidence and artifacts to retain

Keep artifacts in an assessor-friendly bundle. Minimum set:

• Cryptographic Uses Register mapped to system components and data flows
• Cryptographic Protection Standard (approved, versioned)
• Key management procedures (key creation, access control, rotation approach, incident handling for key compromise)
• Architecture diagrams showing encryption boundaries and trust zones
• Technical configuration evidence (exports/screenshots/config files) for transport and storage encryption
• Certificate lifecycle records (inventory, renewal workflow evidence)
• Exception register with approvals and compensating controls
• Change records for crypto-impacting changes (tickets, approvals, test results)

Common exam/audit questions and hangups

Expect assessors to probe for determinism and proof:

• “Show me your list of cryptographic uses. How did you decide what’s in scope?”
• “Where is your approved cryptographic standard documented, and who approves changes?”
• “Prove encryption is enforced, not merely supported. What fails if a client attempts a weak protocol?”
• “How are keys protected from administrators? Who can grant access?”
• “How do you prevent engineers from deploying a misconfigured load balancer or database setting?”

Hangups that slow authorization:

• Teams cannot produce a single, current crypto standard.
• Evidence is scattered across screenshots with no mapping to system scope.
• Internal traffic encryption is inconsistently implemented and undocumented.
• Exceptions are informal (“we’ll fix later”) with no compensating controls.

Frequent implementation mistakes (and how to avoid them)

1. Mistake: “We encrypt everywhere” with no defined uses.
   Fix: Build the Cryptographic Uses Register and tie each item to a component and owner.

2. Mistake: Leaving protocol/cipher choices to defaults.
   Fix: Declare minimums in the standard, then enforce via baselines and CI checks.

3. Mistake: Treating third-party connections as out of scope.
   Fix: Add third-party integration flows to the register and require documented crypto settings or contract terms.

4. Mistake: No sustainable certificate and key lifecycle.
   Fix: Maintain inventories, automate renewal where possible, and prove access control for keys.

5. Mistake: Evidence that doesn’t show enforcement.
   Fix: Provide artifacts that demonstrate “must” behavior (for example, rejected weak connections), not just configuration screens.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement. Operationally, SC-13 failures usually show up as:

• Preventable exposure of sensitive data due to unencrypted channels or storage
• Key compromise leading to broad data access
• Authorization delays due to inability to prove encryption coverage and enforcement

Treat SC-13 as a control that reduces blast radius. Weak crypto choices are rarely isolated; they create systemic access paths for attackers and persistent audit findings.

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

Use this as a sequencing guide; adjust to your system complexity and release cadence.

First 30 days (Immediate stabilization)

• Stand up ownership: assign a control owner for SC-13 and engineering counterparts (platform, network, app security).
• Draft the Cryptographic Uses Register for the full system boundary and major data flows.
• Publish the first version of the Cryptographic Protection Standard with clear required/prohibited items and an exception path.
• Identify the top crypto-risk gaps (external endpoints without enforced TLS policies, storage without encryption controls, unmanaged keys/certs).

By 60 days (Implementation + evidence quality)

• Convert standards into baselines (IaC modules, hardening guides, CI checks).
• Implement priority fixes across edge, internal service comms, storage encryption, and backups.
• Build the evidence pack mapped one-to-one to your Uses Register.
• Formalize exception handling and start a remediation backlog for noncompliant legacy components.

By 90 days (Sustainment and drift control)

• Add monitoring and alerting for crypto drift: weakened TLS configs, expired certificates, encryption-disabled settings, risky key policy changes.
• Integrate crypto checks into change management and release gates.
• Run an internal “assessor-style” review: pick several flows and force teams to prove end-to-end coverage with artifacts.
• If you manage many systems, consider tooling such as Daydream to centralize control requirements, evidence mapping, and exception workflows so SC-13 stays current as architectures change.

Frequently Asked Questions

What counts as a “cryptographic use” for SC-13?

Treat a cryptographic use as a specific protection objective tied to a system flow: data in transit, data at rest, encrypted backups, secrets protection, or integrity/authenticity controls. Your register should name the flow, the component, and the owner.

Do we need one crypto standard or multiple?

Start with one standard for the system (or organization) and allow scoped addenda for special cases. Auditors want consistency; multiple conflicting standards create exceptions you can’t defend.

How do we handle third parties that connect to our system?

Add third-party integrations to your cryptographic uses list and require defined crypto expectations (for example, enforced TLS, certificate validation behavior, and encryption for any stored data they hold for you). Track gaps as exceptions with compensating controls.

What evidence is most persuasive for “implementation”?

Evidence that shows enforcement: configuration exports, policy-as-code checks, and test results that demonstrate weak protocols or unencrypted connections fail. Pair that with diagrams and a register that explains where each control applies.

What’s the fastest way to reduce audit risk on SC-13?

Make the cryptographic uses list complete and make the crypto standard explicit, then align evidence to both. Most audit friction comes from missing decisions and unmapped evidence, not from the absence of encryption features.

How should we manage exceptions for legacy systems?

Document the exception scope, owner, and rationale; add compensating controls; and require an expiration trigger tied to a migration plan. Keep exceptions in a register so they are reviewable and don’t become permanent.