Access Control for Mobile Devices | Full Device or Container-Based Encryption

To meet NIST SP 800-53 Rev 5 AC-19(5) in a FedRAMP context, you must require full-device encryption or approved container-based encryption on the mobile devices you define as in-scope, and prove it stays enabled. Operationalize this through MDM/UEM enforcement, enrollment gates, exception handling, and continuous evidence that devices accessing controlled data remain encrypted. ¹

Key takeaways:

• Scope the requirement to “organization-defined mobile devices” and document what that means for your boundary. ¹
• Enforce encryption through technical controls (MDM/UEM compliance policies), not user attestation. ¹
• Keep auditor-ready evidence: policy, configuration baselines, device compliance reports, and exceptions with approvals and expirations. ²

AC-19(5) is a requirement about protecting the data on mobile endpoints that your organization allows to access systems or information in your FedRAMP authorization boundary. The control is simple on paper: encrypt the device or encrypt the container that holds your organization’s data. The operational trap is scope and proof. “Organization-defined mobile devices” means you must explicitly decide which categories of devices are allowed (corporate-issued, BYOD, tablets, phones, rugged devices, etc.), where they are allowed to connect from, and what data they can reach. Then you need to make encryption a condition of access and keep evidence that it remains enabled over time. ¹

For most cloud service providers and agency programs, this becomes a mobile device access standard tied to MDM/UEM enrollment, conditional access rules, and remote wipe capability for lost or offboarded devices. Container-based encryption can satisfy the requirement when full-device encryption is not feasible, but only if the container is the enforced boundary for organizational data and you can demonstrate the enforcement and integrity properties. Your assessor will look for a clear story: defined scope, enforced configuration, ongoing monitoring, and controlled exceptions. ¹

Regulatory text

Requirement (AC-19(5)): “Employ full-device encryption or container-based encryption to protect the confidentiality and integrity of information on organization-defined mobile devices.” ¹

What the operator must do

1. Define which mobile devices are “organization-defined” for your environment (the authoritative scope statement that determines what you must enforce). ¹
2. Ensure encryption is in place on those devices, either:
   • Full-device encryption (preferred when the device is managed and supports it), or
   • Container-based encryption (acceptable when the encrypted container is the only location where organizational data is stored/processed and the container controls are enforced). ¹
3. Prove confidentiality and integrity protections are maintained through technical enforcement, monitoring, and evidence retention suitable for FedRAMP assessment and continuous monitoring. ²

Plain-English interpretation

If a mobile device can access your systems or handle your controlled information, the data on that device must be encrypted. You can meet this by encrypting the whole device or by forcing organizational data into an encrypted container that is managed and policy-controlled. Your job is to make encryption non-optional and continuously verifiable.

Who it applies to (entity and operational context)

Applies to

• Cloud Service Providers (CSPs) operating a FedRAMP-authorized system where staff, administrators, developers, or support personnel use mobile devices that can access the authorization boundary or boundary-managed information. ¹
• Federal Agencies consuming the service when agency users access the authorized system through mobile endpoints governed by agency policy and device management. ¹

Common in-scope contexts

• Administrator access to cloud management portals from phones/tablets.
• Incident response on-call access to ticketing, alerting, or chat containing sensitive data.
• Email and collaboration apps that include boundary-relevant data.
• Remote access/VPN or SSO sessions initiated from mobile devices.

Key scoping decision If you allow BYOD, you still need an enforceable method to require encryption (device-level or container-level) before access is granted. If you cannot enforce it, the cleaner compliance path is to disallow BYOD for in-scope access.

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

1) Define “organization-defined mobile devices” in writing

Create a short standard that answers:

• What counts as a mobile device (phones, tablets; clarify laptops separately if your program treats them differently).
• Which ownership models are allowed: corporate-owned only, BYOD allowed with conditions, contractor devices, etc.
• Which connection methods are allowed (native apps, browser-only, VPN, zero trust client).
• What data classes are permitted on mobile and what must stay out.

Artifact: Mobile Device Standard (or endpoint standard section) mapped to AC-19(5). ¹

2) Choose your compliance approach: full-device vs container-based encryption

Use this decision matrix:

Scenario	Recommended approach	Why auditors accept it
Corporate-owned, managed iOS/Android	Full-device encryption enforced by MDM/UEM	Device encryption is measurable and enforceable
BYOD allowed	Container-based encryption with strict data separation + conditional access	Organization data stays in a managed encrypted boundary
Legacy or constrained devices	Prefer compensating architecture (no local data) plus container if needed	Keeps in-scope data off unmanaged storage

Your assessor will focus on whether the selected approach actually protects organization data stored on the device and whether you can prove it. ¹

3) Implement technical enforcement (MDM/UEM + access gating)

Do not rely on training, user checklists, or “users must enable encryption.” Implement enforcement:

MDM/UEM controls

• Require device encryption (full-device) for managed devices.
• Block access (or quarantine) if encryption is disabled.
• Require secure lock screen (PIN/biometric) so encryption keys are not trivially accessible after loss/theft.
• Enforce OS minimum versions where encryption is supported and stable.
• Enable remote wipe for organizational data (device wipe for corporate-owned; selective wipe for BYOD container).

Conditional access / identity controls

• Require “compliant device” status for SSO to systems in scope.
• Tie compliance to encryption state, management enrollment, and device integrity signals where available.

Evidence to plan for: screenshots/exports of MDM compliance policies and conditional access rules, plus a sample of devices showing compliant encryption status. ²

4) Define provisioning, approval, review cadence, and revocation triggers

Auditors expect an operational lifecycle, not just a config file. Document and run:

• Approval criteria: who can have mobile access to in-scope systems and under what conditions.
• Provisioning steps: enrollment, policy application, verification of encryption status, assignment of allowed apps/containers.
• Periodic review: review the device inventory and compliance exceptions; remove devices that are no longer needed.
• Revocation triggers: termination, role change, device loss/theft, repeated noncompliance, MDM unenrollment.

This is the difference between “we turned it on” and “we control it.” ¹

5) Handle exceptions explicitly (and make them painful)

You will get exceptions: specialized devices, executives, third-party support. Create an exception workflow:

• Document why full-device or container encryption cannot be enforced.
• Require compensating controls (for example, prohibit local storage of sensitive data; restrict access to a narrow set of web apps; require session-only access).
• Require time-bounded approvals and a plan to remediate.

Artifact: exception register with approval, rationale, compensating controls, and expiration. ²

6) Continuous monitoring and evidence collection

For FedRAMP, the control must keep working. Build a repeatable evidence package:

• Device compliance reports showing encryption enabled for in-scope devices.
• Drift detection: alert when devices become noncompliant.
• Offboarding evidence: records that devices were wiped/retired and access removed.

If you manage evidence in a system like Daydream, treat this as a recurring control with a standing evidence request: policy, MDM config exports, and compliance reports captured on a predictable schedule and stored with assessor-friendly labeling.

Required evidence and artifacts to retain

Keep evidence that answers “what is required,” “how is it enforced,” “who is in scope,” and “what happened over time”:

• Mobile Device / Endpoint Encryption Policy mapped to AC-19(5). ¹
• Defined scope statement for “organization-defined mobile devices.” ¹
• MDM/UEM configuration baselines (exported settings) proving encryption enforcement.
• Conditional access policies requiring compliant/encrypted devices for access to in-scope apps.
• Device inventory with ownership model, enrollment status, and compliance status.
• Exception records with approvals and expirations. ²
• Samples of compliance reports demonstrating encryption enabled and enforcement actions on noncompliant devices.

Common exam/audit questions and hangups

Expect assessors and agency reviewers to ask:

• “Which mobile devices are in scope, and how did you define them?” ¹
• “Show me that encryption is enforced, not just recommended.”
• “How do you prevent access from an unencrypted BYOD device?”
• “How do you know encryption remains enabled after OS upgrades or user changes?”
• “What happens when a device is lost, stolen, or a user is offboarded?”
• “Show exceptions. Who approved them, and when do they expire?” ²

Most hangups come from weak scoping language (“all mobile devices”) paired with incomplete enforcement (no inventory, no access gating, no exception discipline).

Frequent implementation mistakes and how to avoid them

1. Mistake: Policy says “encryption required,” but access still works from unmanaged devices.
   Avoid: make compliant/encrypted device status a condition of authentication to in-scope systems.

2. Mistake: BYOD “container” exists, but users can copy data into personal storage/apps.
   Avoid: enforce managed open-in restrictions, data loss prevention controls where supported, and restrict which apps can access organizational data inside the container.

3. Mistake: No written definition of “organization-defined mobile devices.”
   Avoid: add a one-page scope definition and align it to your access paths (SSO apps, VPN, admin portals). ¹

4. Mistake: Exceptions are informal (email threads) and never expire.
   Avoid: require a ticket, security approval, compensating controls, and an expiry date with re-approval required. ²

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement. In FedRAMP practice, the operational risk is straightforward: loss/theft of a device or uncontrolled BYOD access can expose sensitive data and create assessor findings if you cannot show encryption enforcement and ongoing compliance evidence. ¹

Practical 30/60/90-day execution plan

First 30 days (stabilize scope and enforcement path)

• Publish the “organization-defined mobile devices” scope and allowed use cases. ¹
• Inventory current mobile access paths (SSO apps, admin portals, VPN) and identify which require encrypted device compliance.
• Configure or tighten MDM/UEM encryption compliance policies for managed devices.
• Draft the exception workflow and register format. ²

By 60 days (close access gaps and generate evidence)

• Turn on conditional access rules that block noncompliant devices for in-scope systems.
• Implement container-based controls for any approved BYOD population, with restrictions that keep organizational data inside the container.
• Start producing monthly evidence exports: device inventory, encryption compliance reports, and exception register snapshots. ²

By 90 days (operate as a durable control)

• Run your first formal review of mobile device access: remove stale devices, close or renew exceptions, and document outcomes. ²
• Validate offboarding and lost-device response with a tabletop exercise and capture the artifacts (tickets, wipe logs, access revocation).
• Centralize evidence collection in Daydream (or your GRC system) so each monitoring cycle produces consistent, assessor-ready artifacts.

Frequently Asked Questions

Do we have to use full-device encryption, or is container-based encryption enough?

AC-19(5) allows either full-device encryption or container-based encryption, as long as it protects confidentiality and integrity for information on your organization-defined mobile devices. Pick the approach you can enforce and prove with evidence. ¹

How do we define “organization-defined mobile devices” without over-scoping ourselves?

Define scope based on access to in-scope systems and data, not on every phone a person owns. Write down which device types and ownership models are allowed to connect, then enforce that definition through MDM enrollment and conditional access. ¹

If we prohibit BYOD, is that acceptable for AC-19(5)?

Yes. If only corporate-managed devices can access in-scope systems, you reduce complexity and can enforce full-device encryption consistently. Document the prohibition and show technical controls that prevent unmanaged access. ¹

What evidence is most persuasive to a FedRAMP assessor?

Configuration evidence (MDM and conditional access settings) plus operating evidence (device compliance reports and an exception register). Tie the evidence to your written scope statement and show that noncompliant devices are blocked. ²

How should we handle third-party support personnel who need mobile access?

Treat them as a third party population subject to the same device encryption requirements, or restrict their access to non-mobile pathways. If you grant an exception, document compensating controls and require time-bounded approval. ²

Does selective wipe meet the requirement?

Selective wipe is a helpful operational control, but it does not replace the requirement to use full-device or container-based encryption. Use wipe capability as part of your loss/theft and offboarding process, with encryption still enforced as the baseline. ¹

Footnotes

1. NIST Special Publication 800-53 Revision 5

2. FedRAMP documents and templates