03.13.11: Cryptographic Protection

03.13.11 sits in the NIST SP 800-171 security requirements for nonfederal systems that handle Controlled Unclassified Information (CUI). Operators often treat “encrypt stuff” as a checkbox and then fail assessment because they cannot show three basics: (1) where cryptographic protection is required, (2) what cryptographic standards are approved, and (3) how they know encryption remains in place over time.

This requirement page is written for a Compliance Officer, CCO, or GRC lead who needs to operationalize 03.13.11 quickly with IT and security teams. The goal is a simple, auditable operating model: a clear policy position, hardened technical baselines, and recurring evidence collection. You will also need a clean story for boundary cases (SaaS platforms, endpoints, backups, logs, email, file transfer, and third-party access paths) where CUI can accidentally appear.

If you use Daydream for third-party risk and compliance execution, this requirement maps cleanly into a control record with assigned owners, a crypto standards register, and scheduled evidence tasks tied to your CUI data flow inventory.

Regulatory text

Excerpt (as provided): “NIST SP 800-171 Rev. 3 requirement 03.13.11 (Cryptographic Protection).” (NIST SP 800-171 Rev. 3)

Operator interpretation: You must apply cryptographic mechanisms to protect CUI (and other in-scope sensitive data) and manage those mechanisms so they remain effective. In practice, assessors expect you to (a) define when encryption is required (data at rest, data in transit, backups, portable media, etc.), (b) specify approved cryptographic modules/algorithms and configurations, (c) implement key management and certificate management, and (d) continuously maintain evidence that the control is operating (NIST SP 800-171 Rev. 3).

Plain-English interpretation (what 03.13.11 is really asking)

You need a governed encryption program, not ad hoc encryption settings. That means:

• Coverage: CUI is encrypted wherever it can be exposed (storage, transmission paths, backups, removable media, and common “shadow” locations like exports and logs).
• Correctness: Encryption uses approved configurations (protocol versions, cipher suites, key lengths as defined by your standard).
• Key control: Keys are created, stored, rotated, and revoked under defined roles, with restricted access and auditable lifecycle events.
• Proof: You can show an assessor exactly what is encrypted, how, and how you verify it stays that way.

Who it applies to

Entity scope: Federal contractors and other organizations operating nonfederal systems handling CUI (NIST SP 800-171 Rev. 3).

Operational scope (where this control must work):

• Endpoints used to access or store CUI (laptops, VDI, mobile where permitted).
• Servers, VMs, containers, databases, and file shares containing CUI.
• Network transmission paths for CUI: internal segments, remote access, partner connections, and file transfer mechanisms.
• Backups, snapshots, archives, and disaster recovery copies that may contain CUI.
• Cloud services (IaaS/PaaS/SaaS) that store/process CUI.
• Third parties that can access CUI or systems in the CUI boundary (MSPs, cloud providers, eDiscovery, subcontractors).

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

1) Establish scope and decision rules

1. Confirm the CUI boundary: list the systems, environments, and storage locations that handle CUI.
2. Document data flows: how CUI enters, moves, and exits your environment (APIs, SFTP, email, portals, remote access).
3. Set encryption triggers: write explicit rules such as “encrypt at rest on all endpoints in the CUI boundary” and “encrypt in transit for any connection carrying CUI.”

Deliverable: a short “cryptographic protection applicability” section in your SSP or control narrative tied to your CUI inventory (NIST SP 800-171 Rev. 3).

2) Define your cryptographic standard (what is approved)

1. Approved protocols: define what is acceptable for in-transit protection (for example, TLS for web apps; SSH for admin; IPsec where appropriate).
2. Approved storage encryption methods: full-disk encryption for endpoints; volume/database encryption for servers; object storage encryption for cloud buckets.
3. Cipher/protocol configuration baseline: define minimum protocol versions and disallowed weak ciphers in a standard.
4. Crypto exception process: define how teams request exceptions, who approves, and how compensating controls are applied.

Deliverable: a “Cryptography Standard” (policy + configuration baseline) referenced by system hardening standards (NIST SP 800-171 Rev. 3).

3) Implement encryption at rest (where CUI sits)

1. Endpoints: enforce full-disk encryption via MDM/endpoint management. Block local storage of CUI on unmanaged devices.
2. Servers/VMs: enable volume encryption and ensure keys are centrally managed (KMS/HSM where available).
3. Databases: enable encryption at rest and confirm backups inherit protection.
4. Cloud storage: enable provider encryption controls and restrict public access; ensure key ownership and access logging.

Minimum operational check: your asset inventory should show encryption status for all in-scope assets, not a sampling.

4) Implement encryption in transit (where CUI moves)

1. External connections: require HTTPS/TLS for portals and APIs; restrict older protocols; terminate TLS in controlled zones.
2. Internal service-to-service: require encryption for east-west traffic when it crosses trust boundaries or traverses shared networks.
3. Admin access: require SSH/TLS-based management channels and disable plaintext admin protocols.
4. File transfer: standardize on managed secure transfer (SFTP/HTTPS) rather than ad hoc email attachments.

5) Operate key and certificate management (the part auditors probe)

1. Key ownership and roles: define who can create, use, rotate, and revoke keys.
2. Key storage: store keys in an enterprise KMS/HSM or equivalent protected service; prevent keys in source code or shared drives.
3. Rotation and revocation: implement a recurring rotation standard and immediate revocation process for suspected compromise.
4. Certificate lifecycle: manage issuance, renewal, and expiration monitoring for TLS certificates.
5. Logging: log key access and administrative actions, and route logs to your SIEM or central logging platform.

6) Validate continuously and collect evidence on a schedule

1. Configuration validation: run recurring scans for TLS configuration, disk encryption status, and cloud encryption settings.
2. Change management hooks: require review for changes that could downgrade cryptographic protections (e.g., load balancer changes, storage policy changes).
3. Third-party confirmation: obtain evidence from third parties that store/process CUI showing their encryption and key management approach, aligned to your CUI contract terms.

Practical tip: Put evidence collection on a calendar. If you wait for an assessment request, you will scramble and miss historical proof.

Required evidence and artifacts to retain

Keep artifacts that prove both design and operation:

• Cryptography policy/standard (approved algorithms/protocols, configuration baseline, exceptions).
• System Security Plan (SSP) section mapping where encryption is required and implemented (NIST SP 800-171 Rev. 3).
• CUI asset inventory and data flow diagrams (show encryption points).
• Endpoint encryption reports (MDM/EDR export showing compliant status for in-scope devices).
• Server/database/cloud configuration snapshots (screenshots or exports showing encryption enabled, key source, and access controls).
• KMS/HSM configuration and access logs (roles, permissions, audit logging).
• Certificate inventory (issuance, expiration monitoring evidence, renewal records).
• Exception register (approvals, expiry dates, compensating controls).
• Third-party due diligence package for CUI handlers (contract clauses, security attestations, and technical evidence summaries).

Daydream can track these as named evidence objects with owners and recurrence so you do not rebuild the binder for each assessment.

Common exam/audit questions and hangups

Expect direct, pointed questions:

• “Show me where CUI is stored and the encryption method for each location.”
• “How do you prevent CUI on unmanaged endpoints or personal cloud drives?”
• “Who can access encryption keys, and how do you review that access?”
• “Where is TLS terminated, and what controls protect that termination point?”
• “How do you detect accidental downgrade of cipher suites or disabled storage encryption?”
• “Which third parties touch CUI, and what proof do you have they encrypt it?”

Hangups that cause findings:

• Teams can describe encryption but cannot produce current configuration evidence.
• Key management is informal (keys in app configs, shared accounts, no access reviews).
• Encryption is enabled, but scope is incomplete (backups, exports, analytics copies).

Frequent implementation mistakes (and how to avoid them)

1. Mistake: “We use HTTPS” with no standard.
   Fix: publish a TLS baseline and keep a scan report that validates it.
2. Mistake: Encrypting disks but ignoring backups/snapshots.
   Fix: inventory backup stores; verify encryption and key ownership for each repository.
3. Mistake: Storing keys in code or CI/CD variables without governance.
   Fix: require KMS-backed secrets management and audit access.
4. Mistake: Exceptions that never expire.
   Fix: time-box exceptions and require compensating controls plus documented risk acceptance.
5. Mistake: Assuming SaaS “encrypts by default.”
   Fix: collect SaaS encryption and key management statements and map them to where your CUI sits in that SaaS.

Enforcement context and risk implications

Public enforcement cases were not provided in the source catalog for this requirement, so this page does not cite specific enforcement actions. Practically, failure of cryptographic protection increases the impact of common incident types (lost devices, misrouted files, exposed backups, intercepted sessions) and often converts a security event into a reportable exposure because data is readable.

Practical 30/60/90-day execution plan

First 30 days (stabilize scope and standards)

• Confirm your CUI boundary, system list, and top data flows (NIST SP 800-171 Rev. 3).
• Publish an approved cryptography standard and exception process.
• Identify the highest-risk gaps: unmanaged endpoints, external file transfer, backups, and SaaS locations.

Days 31–60 (implement and instrument)

• Enforce endpoint full-disk encryption and block noncompliant devices from the boundary.
• Turn on encryption at rest for servers, databases, and cloud storage in scope.
• Standardize secure transfer paths and admin access methods.
• Centralize key management and restrict key admin roles.

Days 61–90 (evidence, monitoring, third parties)

• Set recurring validation: encryption status reports, TLS scans, and cloud config checks.
• Build your evidence pack: snapshots, exports, logs, exception register.
• Pull third-party proof for any provider handling CUI and record it in your third-party risk workflow.
• Run an internal mini-assessment: pick a CUI dataset and trace it end-to-end, showing encryption and key control at every hop.

Frequently Asked Questions

Does 03.13.11 require encryption everywhere?

Treat it as “encrypt wherever CUI could be exposed.” Start with data at rest and data in transit, then cover backups, exports, and third-party transfer paths (NIST SP 800-171 Rev. 3).

What’s the fastest way to scope cryptographic protection for an assessment?

Build a CUI system inventory and a simple data flow map, then mark each hop as “encrypted in transit,” “encrypted at rest,” or “not applicable.” Your encryption evidence should align to that map.

How do auditors test cryptographic protection in practice?

They ask for configuration proof: endpoint encryption status reports, database/storage encryption settings, TLS configuration outputs, and key management access records. They also look for gaps like unencrypted backups and uncontrolled keys.

If a SaaS provider says “we encrypt data,” is that enough?

Usually not by itself. You need documentation and operational evidence that matches your use case: where your CUI resides in the SaaS, how encryption is implemented, and how keys are protected and accessed.

What evidence matters most for key management?

Role-based access to keys, logs of key access/admin actions, and documented procedures for rotation and revocation. Assessors want to see that keys are controlled as tightly as the data they protect.

How should we track this requirement over time?

Treat it as a recurring control with scheduled evidence collection and exception reviews. Tools like Daydream help by assigning owners, collecting artifacts, and keeping a time-stamped record for audits.