MP-2(2): Cryptographic Protection

MP-2(2): Cryptographic Protection sits in the Media Protection family and is aimed at a simple failure mode: sensitive data walking out the door on portable media. For a Compliance Officer, CCO, or GRC lead, the fastest path to readiness is to translate this control into three things your teams can execute without ambiguity: (1) a clear definition of “portable media” and what data types trigger encryption, (2) a small set of approved encryption mechanisms and key-handling rules, and (3) durable evidence that endpoints and removable media are actually encrypted in day-to-day operations.

This requirement often fails in audits for a non-technical reason: organizations can describe encryption standards but cannot prove consistent enforcement across laptops, USB storage, external drives, and “temporary” use cases (eDiscovery, incident response, engineering transfers, field work). MP-2(2) is also a third-party risk issue because contractors and service providers frequently touch federal or regulated data using their own endpoints and media.

This page gives requirement-level implementation guidance: who owns what, what to configure, what to log, what to test, and what evidence to keep so you can answer assessor questions quickly and credibly. ¹

Regulatory text

Regulatory excerpt: “NIST SP 800-53 control MP-2.2.” ²

Operator interpretation of what this means: MP-2(2) is the enhancement for cryptographic protection under media access/handling. In practice, the operator obligation is to ensure that portable media containing covered data is encrypted using approved cryptography, and that the encryption is implemented in a way you can verify and sustain. Your program should treat encryption as a control with defined scope, technical enforcement, key management, and exception handling, not as a one-time configuration choice. ¹

Plain-English interpretation (what the requirement expects)

MP-2(2) expects that if data is placed on portable media, the organization prevents readable exposure by applying cryptography. That includes common scenarios like:

• A user copying files to a USB drive to work offline
• A contractor moving data between enclaves
• Backups or exports written to removable storage
• A laptop that functions as “portable media” in the real world because it leaves controlled facilities

Your success criteria are simple to state and hard to fake:

1. If portable media is used, encryption is the default.
2. Only approved encryption methods are allowed.
3. Keys are protected and recoverable under controlled processes.
4. You can produce evidence that the control is operating. ¹

Who it applies to (entity and operational context)

MP-2(2) applies to:

• Federal information systems and their operators, including system owners and ISSOs/ISSMs. ¹
• Contractor systems handling federal data, including cloud and managed service environments, endpoints, and workflows where staff use removable media or portable endpoints to store or transport covered data. ²

Operationally, this requirement touches multiple teams:

• GRC / Compliance: define scope, approve standards, manage exceptions, evidence, and assessment readiness.
• Security Engineering / Endpoint Management: enforce encryption on endpoints and removable storage; monitor compliance.
• IT / Service Desk: provisioning, recovery workflows, device inventory, break-glass.
• Legal / Privacy / Data Owners: classify data types that trigger encryption and set rules for exports.
• Third-party owners / Procurement: ensure third parties meet the same media protection expectations.

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

1) Define “portable media” and “covered data” for your environment

Create a short scoping statement that removes ambiguity:

• Portable media examples: USB mass storage, external HDD/SSD, SD cards, optical media, portable encrypted drives, and portable endpoints that store data locally.
• Covered data: data categories your system is required to protect (for federal contexts, align to your system’s data types and impact level).

Deliverable: a one-page “MP-2(2) scope” note that ties to your data classification and system boundary. ¹

2) Set the cryptographic standard and approved implementations

Document what “encrypted” means in your program:

• Approved encryption approach (full-disk encryption for endpoints; encryption-required removable storage).
• Approved tools/technologies (name the enterprise standard options your IT supports).
• Minimum configuration expectations (encryption enabled, boot/auth requirements, recovery, and tamper controls as applicable).

Keep this tight: too many “approved” options increases exception volume and weakens enforcement.

Deliverables: encryption standard, approved product list, baseline configuration standards. ¹

3) Establish key management and recovery rules (assessment-critical)

Assessors will probe key handling because weak key processes can undermine media encryption. Define:

• Where keys are stored/managed (enterprise key escrow if you use it)
• Who can recover keys and under what approvals (ticket, manager approval, dual control where appropriate)
• What happens at offboarding, device reassignment, and loss/theft events

Deliverables: key recovery SOP, access control list for recovery admins, recovery event logging requirements. ¹

4) Enforce technically: prevent “unencrypted portable media” from working

Policy alone is fragile. Use endpoint controls to enforce, such as:

• Device control rules that block unapproved USB storage
• Allow-listing for approved encrypted drives
• Mandatory encryption prompts/workflows for removable storage
• Full-disk encryption compliance enforcement for laptops/workstations

Evidence goal: you can show enforcement rules and a compliance report, not a training slide. ²

5) Build an exception process that doesn’t become the norm

You will have legitimate edge cases (lab devices, embedded systems, incident response transfers). Define:

• Who can approve an exception (control owner plus data owner)
• How exceptions expire (time-bound)
• Compensating controls (custody logs, secure transfer alternatives, dedicated encrypted media)

Deliverables: exception register, approvals, and compensating control documentation. ¹

6) Monitor and test operation (prove it works)

Operational checks should include:

• Periodic endpoint encryption compliance reporting (fleet coverage and drift)
• Spot checks for removable media controls (blocked events, allow-listed devices)
• Incident linkage: any lost device/media event triggers verification that encryption was enabled and keys were protected

Deliverables: recurring compliance reports, sample logs of blocked/allowed device events, incident tickets with encryption verification. ¹

7) Map ownership and evidence so audits do not become archaeology

This control commonly fails due to missing implementation evidence. Assign:

• Control owner (accountable)
• Technical owners (endpoint, IAM/key management)
• Evidence producers (service desk, security operations)
• Review cadence for artifacts (aligned to your audit cycle)

If you use Daydream, treat this as a requirements-to-evidence mapping exercise: assign the owner, link procedures, and schedule recurring evidence collection so you always have current artifacts ready for assessment. ²

Required evidence and artifacts to retain

Keep evidence that shows design, implementation, and operation:

Design (what you intended)

• Media protection policy and encryption standard (portable media section)
• Approved encryption/tooling list and configuration baselines
• Key recovery SOP and access approvals ¹

Implementation (what you configured)

• Endpoint management configuration screenshots/exports (encryption enforcement, device control rules)
• Removable media control settings (block/allow rules; encryption-required policies)
• System boundary notes showing where portable media is permitted/forbidden ²

Operation (proof it’s happening)

• Reports showing endpoint encryption status
• Logs showing removable storage events and enforcement outcomes
• Exception register with approvals and expirations
• Service desk tickets for key recovery, with approvals and audit trail
• Incident records for lost/stolen devices demonstrating encryption verification ¹

Common exam/audit questions and hangups

Auditors and assessors tend to ask:

• “Define portable media in your environment. Is a laptop included?”
• “Show me how you prevent users from writing sensitive data to unencrypted USB drives.”
• “How do you know encryption is enabled today, not last quarter?”
• “Who can recover encryption keys, and how is that access controlled?”
• “Show exceptions. How many exist, why, and when do they expire?”
• “Do contractors and third parties follow the same requirements when handling federal data?” ¹

Hangups you should plan for:

• Evidence is scattered across endpoint tools, ticketing systems, and SOPs.
• The control is implemented for corporate endpoints but not for privileged users, developers, or field teams.
• Third parties are contractually obligated but not technically verified.

Frequent implementation mistakes (and how to avoid them)

1. Mistake: “We have encryption” without proving scope.
   Fix: maintain an in-scope asset inventory for endpoints and approved removable media, and tie reports to that inventory. ¹

2. Mistake: Allowing “temporary” unencrypted transfers.
   Fix: create a sanctioned method for transfers (approved encrypted media, secure managed file transfer) and require exceptions for anything else. ¹

3. Mistake: Weak key recovery controls.
   Fix: restrict recovery roles, require documented approvals, and log all recoveries with ticket references. ¹

4. Mistake: Third-party endpoints are ignored.
   Fix: contractually require cryptographic protection for portable media and validate via onboarding attestations and periodic evidence requests tied to the engagement risk. ²

Enforcement context and risk implications

No public enforcement sources were provided for this requirement in the supplied source catalog, so this page does not list enforcement cases. The practical risk is straightforward: loss or theft of portable media is a common breach pathway, and failing to enforce encryption turns a physical control lapse into a reportable confidentiality event. ¹

Practical execution plan (30/60/90)

First 30 days (stabilize scope + standards)

• Name the control owner and technical owners; document RACI.
• Publish the portable media scope statement and covered data triggers.
• Standardize approved encryption methods and key recovery rules.
• Stand up an exception register with an approval workflow. ¹

By 60 days (enforce + start evidence)

• Implement or tighten endpoint enforcement for full-disk encryption compliance.
• Implement removable media controls (block unapproved USB storage; allow only approved encrypted options).
• Start recurring compliance reporting and store outputs in your audit repository.
• Validate third-party handling expectations in contracts and onboarding checklists. ²

By 90 days (operate + test + be assessment-ready)

• Run a tabletop for “lost encrypted USB / lost laptop” and verify evidence capture.
• Sample-test exceptions: confirm expiry, compensating controls, and closure.
• Produce an assessor-ready evidence pack: policy, configs, reports, logs, exceptions, and recovery tickets.
• In Daydream, map MP-2(2) to the owner, procedure, and recurring artifacts so evidence stays current between audits. ²

Frequently Asked Questions

Does MP-2(2) apply if we ban USB drives entirely?

Yes, but you still need evidence of the ban and technical enforcement. Assessors will expect you to show device control settings, not only a written prohibition. ¹

Are laptops considered “portable media” for this requirement?

In many operating environments, laptops function as portable storage because they leave controlled areas and store data locally. Treat full-disk encryption as part of your MP-2(2) story when endpoints are in scope for covered data. ¹

What evidence is strongest for “cryptographic protection”?

Configuration exports from endpoint management and device control tooling, plus recurring compliance reports that list encryption status for in-scope assets. Pair that with key recovery SOPs and logged recovery events tied to tickets. ¹

How should we handle third parties who use their own devices?

Put cryptographic protection for portable media into contractual requirements and onboarding controls, then request periodic evidence (policy, configuration proof, or attestations) based on engagement risk. Track exceptions and remediation actions like any internal gap. ²

What’s the right way to manage encryption key recovery without creating insider risk?

Limit recovery privileges to named roles, require documented approvals in a ticketing system, and retain logs for each recovery event. Review recovery access periodically as part of access governance. ¹

We have encrypted USB drives, but users sometimes copy data to personal cloud storage instead. Is that covered?

That’s adjacent risk: MP-2(2) targets portable media, but the same data loss outcome can occur through unsanctioned transfer paths. Close the gap with data handling rules and technical controls for approved transfer channels, and document how those controls complement media protection. ¹

Footnotes

1. NIST SP 800-53 Rev. 5

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