AC-19(5): Full Device or Container-based Encryption

AC-19(5) requires you to encrypt information on mobile devices using full-device encryption or a managed encrypted container, so data remains protected even if the device is lost, stolen, or compromised. To operationalize it, standardize an approved encryption method, enforce it through device management, control keys, and retain evidence that encryption is enabled and monitored. ¹

Key takeaways:

• Treat AC-19(5) as an engineering enforcement control: encryption must be technically enforced, not “required by policy.”
• Scope matters: define which devices and which data types are covered, including BYOD and contractor endpoints.
• Audit success depends on evidence: configuration baselines, encryption compliance reports, and exception handling records.

The ac-19(5): full device or container-based encryption requirement is one of the fastest ways assessors gauge whether your mobile device program protects sensitive data outside traditional perimeter controls. The control language is short, but operationalizing it forces decisions that create audit friction: what counts as a “mobile device,” whether BYOD is in scope, what “container-based” means for your app stack, and how you prove encryption is actually enabled.

For a CCO or GRC lead, the goal is simple: make encryption a non-optional state for in-scope devices and be able to demonstrate it on demand. That means (1) a crisp scope statement tied to your system boundary and data flows, (2) an approved technical standard for device encryption or encrypted containers, (3) centralized enforcement through endpoint management, and (4) durable evidence that shows ongoing compliance, not a one-time screenshot.

This page gives requirement-level implementation guidance you can hand to IT/security operators and then test, measure, and defend during an assessment aligned to NIST SP 800-53 Rev. 5. ²

Regulatory text

NIST SP 800-53 Rev. 5 AC-19(5) excerpt: “Employ {{ insert: param, ac-19.05_odp.01 }} to protect the confidentiality and integrity of information on {{ insert: param, ac-19.05_odp.02 }}.” ¹

Operator interpretation of the text

• “Employ …” means you must implement a technical mechanism, not only document an expectation. ¹
• “Protect confidentiality and integrity” means encryption must prevent unauthorized disclosure and reduce risk of tampering with stored data on the device. ¹
• “Information on …” is the practical scoping problem: you must define which devices qualify and what information is stored or cached there, including email, synced files, app data, and offline copies. ¹

Plain-English requirement

For any mobile device that can store or cache your organization’s sensitive information, you must ensure data is encrypted either:

1. across the whole device storage (full-device encryption), or
2. inside a managed encrypted container that holds the organization’s apps/data and enforces encryption regardless of personal use.

Your implementation must be enforceable, measurable, and repeatable.

Who it applies to

Entity scope (typical applicability)

• Federal information systems implementing NIST SP 800-53 controls. ¹
• Contractor systems handling federal data where NIST SP 800-53 controls (or derived requirements) apply contractually. ¹

Operational scope (where teams get caught)

AC-19(5) generally applies when any of the following are true:

• Users access regulated workloads via phones/tablets.
• Corporate email/chat or file sync is configured on a mobile device.
• Line-of-business apps store data offline (intentional or as a side effect of caching).
• A third party workforce (contractors, BPO, field service) uses mobile endpoints to access your data.

Asset scope decision points (write these down)

Document your position for each and make it testable:

• Corporate-owned vs BYOD: Is BYOD allowed, and if yes, must it be containerized?
• Phones/tablets only vs laptops: AC-19 is “mobile devices,” but many programs align mobile encryption expectations with endpoint encryption standards to avoid gaps.
• Wearables/IoT: Usually excluded, but explicitly state exclusions and compensating controls if they connect to sensitive apps.

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

Step 1: Define “in-scope device” and “covered information”

Create a one-page scope statement that includes:

• Device categories (managed iOS/Android, tablets, rugged devices, etc.)
• Access methods (native apps, browser access, VDI, email profiles)
• Data classes (CUI, contract data, internal confidential, etc. as your program defines)

Deliverable: AC-19(5) scope & assumptions paragraph for your SSP/control narrative. ²

Step 2: Choose your approved encryption approach

Build a simple decision matrix:

Scenario	Preferred control	Why it passes AC-19(5) cleanly
Corporate-owned mobile devices	Full-device encryption enforced via MDM	Strongest, simplest evidence trail
BYOD allowed	Encrypted container for corporate apps/data	Reduces privacy conflicts, narrows admin reach
Shared/kiosk devices	Full-device encryption + restricted profiles	Lowers risk from loss and casual access
High-risk roles (execs, admins)	Full-device encryption + additional hardening	Higher consequence if device is compromised

Your standards should specify:

• What “approved encryption” means in your environment (device native encryption vs container crypto).
• Minimum configuration prerequisites (passcode requirements, secure boot, no jailbreak/root).
• How you validate compliance (MDM posture, attestation, compliance reports). ¹

Step 3: Enforce encryption through a management plane

AC-19(5) fails most often when encryption is “supported” but not “enforced.”

Operational requirements to assign:

• MDM/UEM policies that require encryption enabled as a compliance condition.
• Conditional access that blocks email/app access if encryption is off or device health attestation fails.
• Enrollment controls that prevent unmanaged devices from connecting to corporate services when encryption status is unknown.

If you allow container-based encryption:

• Require corporate data access only through managed apps inside the container.
• Disable copy/paste, unmanaged “Open In,” or local exports when feasible.
• Ensure container keys are managed and revoked on termination. ¹

Step 4: Key management and recovery controls (operational reality)

Even for native device encryption, you need a position on:

• Who can recover access (helpdesk workflows, identity verification).
• How you handle lost credentials without weakening encryption (avoid shared “break glass” passcodes for general populations).
• Where recovery keys or escrow artifacts live, if applicable to your platform.

Write this as a standard operating procedure (SOP) so your evidence shows repeatability.

Step 5: Build exception handling that doesn’t become the control

You will have edge cases: legacy devices, specialized hardware, or a third party that can’t enroll.

Define:

• Exception criteria (business justification, data types allowed, compensating controls)
• Approval authority (system owner + security)
• Time bound exceptions with re-validation
• Required compensating controls (VDI-only access, no offline storage, additional monitoring)

Auditors accept exceptions when they are controlled; they fail programs where exceptions are informal.

Step 6: Monitor continuously and produce evidence on demand

Operationalize two rhythms:

• Ongoing monitoring: a live compliance dashboard (or exported report) of encryption status for in-scope fleet.
• Periodic control attestation: documented review that verifies enforcement rules still apply and exceptions are still valid.

Daydream (used appropriately) fits here as the control “binder”: map AC-19(5) to a named control owner, link the SOPs and baselines, and schedule recurring evidence pulls so audits don’t turn into a screenshot fire drill. ¹

Required evidence and artifacts to retain

Aim for artifacts that prove design and operating effectiveness:

Governance + design evidence

• Mobile device encryption standard (full-device and/or container-based)
• Device eligibility/scope statement for AC-19(5)
• MDM/UEM configuration baseline showing encryption required
• Conditional access policy configuration tied to device compliance
• Exception process document + approval workflow

Operating evidence (assessor-grade)

• Current device inventory with “encryption enabled” field populated (exported report)
• Compliance reports showing enforcement and noncompliant device actions (blocked/quarantined)
• Sample of enrolled device records (showing encryption on, last check-in, compliance state)
• Exception register with approvals, compensating controls, and closure evidence
• Termination/offboarding records showing access removal and container wipe where applicable

Common exam/audit questions and hangups

Expect these and pre-answer them in your control narrative:

• “Show me how you know devices are encrypted, not just capable of encryption.”
• “Is BYOD allowed? If yes, how do you prevent corporate data from landing outside the container?”
• “What happens if a device is jailbroken/rooted or stops reporting compliance?”
• “How do you handle offline data created by email, file sync, and collaboration apps?”
• “Show exceptions, and explain why compensating controls keep risk acceptable.”

Frequent implementation mistakes and how to avoid them

1. Policy-only compliance.
   Fix: require encryption through MDM/UEM compliance rules and block access when unknown.

2. Unscoped mobile data flows.
   Fix: document where mobile apps cache data and enforce managed-app storage controls when you choose container-based encryption.

3. BYOD without containment.
   Fix: require a managed encrypted container for corporate apps, or prohibit BYOD access to sensitive data.

4. No durable evidence.
   Fix: automate evidence pulls (inventory + encryption posture) and store them with date/time, owner, and system boundary context.

5. Exceptions that never expire.
   Fix: time-bound approvals, periodic re-authorization, and a decommission plan for devices that can’t comply.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so you should treat AC-19(5) primarily as an assessment and incident-impact control rather than a “case law” control.

Practically, weak mobile encryption increases breach severity because lost or stolen devices become data exposure events. It also creates contractual risk for contractor systems handling federal data, where failure to meet required controls can trigger findings, corrective action plans, or contract consequences depending on your terms. ²

A practical 30/60/90-day execution plan

First 30 days (stabilize scope and enforcement path)

• Name the control owner and backup owner; confirm system boundary owners.
• Publish the AC-19(5) scope statement: in-scope device types, allowed access methods, BYOD position.
• Select the standard: full-device encryption, container-based encryption, or both by scenario.
• Validate MDM/UEM can report encryption status reliably for the in-scope fleet.
• Stand up an exception register and approval workflow.

By 60 days (enforce and block)

• Roll out MDM/UEM policies that require encryption and strong unlock configuration.
• Implement conditional access rules that block noncompliant or unknown devices from corporate apps/email.
• Validate container controls for BYOD (managed apps, data movement restrictions, remote wipe).
• Produce your first “assessment pack”: baseline configs + encryption posture report + exception log.

By 90 days (operate and prove)

• Add continuous monitoring: scheduled exports, alerts for noncompliance, and response SLAs.
• Run a tabletop test: lost device scenario, offboarding scenario, and exception approval scenario; capture artifacts.
• Review and tighten scope based on real device inventory findings (shadow BYOD, unmanaged tablets).
• Put evidence collection on a calendar and store it centrally (Daydream works well as the system of record for control mapping, evidence tasks, and auditor-ready packaging). ¹

Frequently Asked Questions

Does AC-19(5) require full-disk encryption, or is a secure container enough?

The control allows full-device or container-based encryption; the key is that information on the mobile device is protected with an approved method and you can prove enforcement. Your scope statement should specify which scenarios use which approach. ¹

How should we handle BYOD without taking over an employee’s personal phone?

Use container-based encryption with managed apps and conditional access. Restrict corporate data movement to unmanaged apps and require remote wipe of the container on termination. ¹

What evidence is strongest for auditors?

MDM/UEM policy baselines that require encryption plus a current compliance report showing encryption status across the fleet. Pair that with an exception register and proof that noncompliant devices are blocked or quarantined. ¹

Do we need to encrypt data inside every mobile app we build?

If you rely on full-device encryption, you still need to prevent sensitive data from being copied into unprotected areas via app behavior. For BYOD/container models, require managed app frameworks that store corporate data inside the encrypted container. ¹

What if a specialized field device can’t support encryption?

Treat it as an exception with written justification, compensating controls, and a plan to replace or redesign the workflow to avoid local storage. Keep approvals and re-authorization evidence. ¹

How do we show we protect integrity, not just confidentiality?

Demonstrate platform controls that prevent tampering such as OS integrity checks (root/jailbreak detection), enforcement actions for noncompliance, and configuration baselines that require secure device states. ¹

Footnotes

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

2. NIST SP 800-53 Rev. 5