Access Control for Mobile Devices

To meet the access control for mobile devices requirement (NIST SP 800-53 Rev. 5 AC-19), you must define and enforce approved configurations and connection rules for organization-controlled mobile devices, including offsite use, and formally authorize which mobile devices may connect to your systems. The fastest path is an MDM-enforced baseline plus an allowlist-based connection approval workflow with auditable records. ¹

Key takeaways:

• You need two things auditors test: enforced mobile configuration standards and enforced connection authorization. ¹
• “Outside controlled areas” means your rules must hold on home Wi‑Fi, travel, and unmanaged networks, not just on-prem. ¹
• Evidence matters as much as design: keep approvals, inventories, exceptions, and periodic revalidation records. ¹

Access Control for Mobile Devices is a requirement-level control that often fails for one simple reason: teams treat it as “we have MDM” and stop there. AC-19 expects you to (1) establish configuration requirements and connection requirements for organization-controlled mobile devices, including when those devices are offsite, and (2) authorize which mobile devices are permitted to connect to organizational systems. ¹

For FedRAMP-scoped environments, assessors will look for a clear, written standard, technical enforcement, and proof that mobile access is approved and revalidated over time. Your biggest operational goal is to prevent “quiet drift”: a mobile fleet that slowly accumulates unmanaged devices, exceptions without expiry, and ad hoc access paths (VPN profiles, mail clients, Wi‑Fi, admin apps) that nobody can fully explain during assessment.

This page translates the requirement into concrete operating steps you can assign to IT, Security, and Identity teams. It also lays out the minimum artifacts to retain so you can answer assessor questions quickly and consistently, using FedRAMP-friendly documentation patterns. ²

Regulatory text

Requirement (AC-19): “Establish configuration requirements, connection requirements, and implementation guidance for organization-controlled mobile devices including when such devices are outside of controlled areas; and authorize the connection of mobile devices to organizational systems.” ¹

Operator interpretation (what you must do):

• Define a mobile baseline (secure configuration requirements) that applies to company-controlled phones/tablets and any other “mobile” endpoints you manage. The baseline must explicitly address offsite use. ¹
• Define connection rules for how those devices may connect (examples: VPN requirements, certificate requirements, which device states are allowed, and which services are in-scope). ¹
• Implement guidance so the organization can consistently provision, support, monitor, and revoke mobile access (not just a one-time setup). ¹
• Authorize device connections so you can show that only approved mobile devices are permitted to connect to organizational systems, and that approvals are governed and reviewable. ¹

Plain-English requirement (quick translation)

You need a documented, enforced rulebook for company mobile devices that covers (a) how they must be configured, (b) how they are allowed to connect, especially when they’re offsite, and (c) who approves their access to your systems. Then you need to keep the receipts: inventory, approvals, and exceptions that prove the rulebook is real.

Who it applies to (entity and operational context)

Applies to:

• Cloud Service Providers and Federal Agencies operating a system within a FedRAMP authorization boundary (or aligning to the FedRAMP Moderate baseline). ¹

Operational context where AC-19 shows up in testing:

• Any mobile device used by administrators, engineers, support staff, or business users to access boundary systems (email, ticketing, admin portals, CI/CD, cloud consoles, privileged remote access).
• Any mobile device management scope decision: corporate-owned only, corporate-owned plus corporate-managed BYOD, or restricted “no mobile access” rules. AC-19 does not force BYOD; it forces governance over what you do allow. ¹

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

Step 1: Define your “mobile device” scope and your allowed access paths

1. List device types you treat as mobile (phones, tablets; include any specialized handhelds if present).
2. List organizational systems reachable from mobile (SSO, email, VPN, admin tools, cloud consoles, internal apps).
3. Pick an access pattern per system:
   • “No mobile access”
   • “Browser-only with SSO”
   • “Managed app only”
   • “VPN required”
   • “Privileged access prohibited from mobile”
4. Write it down in one standard so assessors do not have to infer your intent. ¹

Step 2: Establish configuration requirements (your baseline)

Your baseline should read like testable requirements. Common items you can express as rules (phrase as “must” statements):

• Device must be enrolled in MDM and report compliant state.
• Device must require screen lock and encryption.
• Device must support remote wipe.
• Device must be on a supported OS version and receive updates per your patch standard.
• Prohibit risky local controls (developer mode, sideloading, unknown sources) where feasible.
• Restrict local data sharing for managed apps (copy/paste, backups) where feasible for your risk model.

AC-19 does not prescribe the exact settings; it requires you to establish and apply configuration requirements and guidance. ¹

Step 3: Establish connection requirements (the “gate”)

Define conditions that must be true before a device can connect:

• Identity requirements: SSO, MFA, device-bound credentials, device certificates.
• Network requirements: VPN or zero trust access method for internal systems; disallow direct access paths you cannot monitor.
• Device posture requirements: only “compliant” devices can authenticate; block jailbroken/rooted if your tooling detects it.
• Session requirements: re-authentication rules for sensitive actions; block legacy protocols if applicable.

Then implement those requirements using your chosen stack (MDM + IdP conditional access + VPN/ZTNA controls). The point is simple: a mobile device should not be able to connect just because a user knows a password. ¹

Step 4: Create an authorization workflow for mobile connections

This is the part many teams miss. You need an auditable method that answers: who approved this device to connect, when, and under what conditions. ¹

A workable approach:

1. Define approval criteria (eligible roles, business need, training prerequisites for privileged users, minimum device posture).
2. Provisioning steps (enroll in MDM, assign compliance policy, issue cert/profile, add to allowed group).
3. Approver roles (manager + system owner for sensitive systems; Security for exceptions).
4. Revalidation cadence (set a policy-driven review cycle and record evidence of completion).
5. Revocation triggers (termination, role change, noncompliance, loss/theft, device inactive, repeated failed compliance). ¹

Daydream (or your GRC system) fits here as the system of record: intake request, route approvals, capture exceptions with expiry, and produce an evidence packet for assessors without chasing screenshots across tools. Keep the operational enforcement in your IT stack; keep the decision trail in GRC.

Step 5: Write “outside controlled areas” guidance that people can follow

You need explicit do/don’t guidance for offsite use, such as:

• What to do on public Wi‑Fi (approved VPN/ZTNA path, prohibit hotspot tethering if needed).
• What to do if the device is lost or stolen (reporting steps, remote wipe, credential reset).
• Where sensitive data may be stored (managed container only; no local downloads if that’s your rule).
• Travel guidance (border searches, high-risk locations, temporary devices if your policy requires it).

AC-19 explicitly calls out offsite conditions; don’t bury this in a general security policy. Put it in the mobile standard and user guidance. ¹

Step 6: Operate the control (monitor, review, and correct drift)

Operational minimums that make AC-19 defensible:

• Maintain a current inventory of organization-controlled mobile devices with owner, status, and enrollment state.
• Monitor compliance status and investigate noncompliance.
• Perform periodic access reviews for mobile-enabled groups and privileged mobile access.
• Track and close exceptions (each with compensating controls and an expiry).

This is where teams get burned in assessments: policy exists, tooling exists, but there is no repeatable review evidence. ¹

Required evidence and artifacts to retain

Keep these artifacts in an assessor-ready structure (system boundary focused). ²

Policy/standards

• Mobile Device Access Control Standard (configuration + connection rules + offsite guidance). ¹
• Mobile enrollment/provisioning SOP and deprovisioning SOP. ¹

Authorization records

• Access requests and approvals for mobile connection authorization (tickets/workflow exports). ¹
• Exceptions register with approval, compensating controls, and expiry. ¹

Technical evidence

• MDM compliance policy screenshots/exports (baseline settings).
• Conditional access / IdP policy configuration showing device posture gating (where used).
• VPN/ZTNA policy summaries showing required connection path (where used).
• Mobile device inventory export (from MDM) mapped to authorized users/groups. ¹

Ongoing operations

• Access review records (who reviewed, what changed, when).
• Deprovision samples (terminated user device access revoked; lost device wiped). ¹

Common exam/audit questions and hangups

Assessors commonly press on these points for AC-19 (prepare your answers and evidence):

• “Show me which mobile devices are authorized to connect.” If you cannot produce a list tied to approvals, you will struggle. ¹
• “What happens when a device is offsite?” They want explicit rules and enforcement, not verbal assurances. ¹
• “How do you prevent unmanaged devices from accessing email/admin tools?” Expect posture-gating and group-based controls. ¹
• “How do you review and revoke access?” They will ask for completed review records and examples of revocation triggers. ¹
• “Where is this documented in your FedRAMP package?” Map your standard and procedures into your system security documentation approach aligned to FedRAMP templates. ²

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails AC-19	Fix
“MDM exists” but no written connection authorization	AC-19 requires you to authorize device connections, not just manage devices. 1	Add an approval workflow tied to device/user groups and keep approval evidence.
Offsite use is handled in an HR policy	AC-19 expects implementation guidance connected to the technical control. 1	Put offsite rules in the mobile standard and reference the enforced controls (VPN/ZTNA, conditional access).
Exceptions never expire	Exceptions become permanent shadow policy with no revalidation trail. 1	Require expiry, compensating controls, and review evidence for every exception.
Inventory is not reconcilable to access	You cannot prove authorization if you can’t map device → user → allowed systems. 1	Reconcile MDM inventory to IdP groups and access requests; store the mapping output.
Privileged access allowed from any mobile context	Risk spikes if admin actions can occur from weakly controlled devices/networks.	Explicitly restrict privileged actions from mobile, or require stronger device posture and connection paths. 1

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not cite specific actions or penalties.

Operationally, weak mobile access control increases the chance of unauthorized access through lost devices, unmanaged apps, insecure networks, or lingering access after role change. AC-19 also has a practical compliance risk: if you cannot show authorization and revalidation evidence, assessors may treat mobile access as uncontrolled and expand testing or require remediation before authorization. ¹

Practical 30/60/90-day execution plan

Exact timelines vary by environment and tooling; use these phases as execution checkpoints, not calendar promises.

First 30 days (Immediate)

• Confirm scope: which systems are accessible from mobile and which roles need it. ¹
• Publish a mobile standard draft: configuration baseline, connection requirements, offsite guidance, and authorization workflow. ¹
• Identify current-state gaps: unmanaged devices, legacy protocols, shadow VPN profiles, undocumented exceptions.

Days 31–60 (Near-term)

• Implement or tighten MDM compliance policies to match the written baseline; align naming so evidence is easy to match to the standard.
• Turn on conditional access/posture gates for the highest-risk systems first (admin portals, support tooling, cloud consoles). ¹
• Stand up the authorization workflow in your ticketing/GRC system (Daydream or equivalent): request, approve, record, expire exceptions. ¹

Days 61–90 (Stabilize and evidence)

• Run the first formal access review for mobile-enabled access groups; capture actions taken and approver sign-off. ¹
• Reconcile inventory to authorization records; close gaps (remove access, enroll devices, document exceptions). ¹
• Build an assessor packet aligned to FedRAMP documentation patterns (standard, SOPs, sample approvals, inventory export, conditional access configs). ²

Ongoing (Continuous monitoring posture)

• Repeat access reviews on your defined cadence and retain evidence.
• Track mobile exceptions to closure; renew only with fresh approval and updated risk acceptance. ¹

Frequently Asked Questions

Do we have to allow BYOD to comply with AC-19?

No. AC-19 requires controls for organization-controlled mobile devices and authorization of mobile device connections you do permit. If you prohibit BYOD, document the prohibition and enforce it through conditional access and network controls. ¹

What does “authorize the connection” mean in practice?

You need a documented decision and an enforceable mechanism that only approved devices (or approved users on approved devices) can use to connect. Keep request/approval records and show how approval maps to access groups/policies. ¹

If we use MDM, is that enough for the requirement?

MDM helps with configuration requirements, but AC-19 also expects connection requirements, offsite guidance, and a clear authorization process. Auditors typically want proof that unmanaged or noncompliant devices cannot connect. ¹

How do we handle contractors or other third parties who need mobile access?

Treat third-party users the same as employees for authorization: documented business need, named approver, and enforced device requirements. If you cannot make the device organization-controlled, restrict access paths (for example, no admin actions from mobile) and document the decision. ¹

What evidence is most persuasive to a FedRAMP assessor?

A tight chain: mobile standard → enforced MDM/conditional access policies → inventory export → a sample set of access requests/approvals → completed access review results. Present it in a package consistent with FedRAMP documentation expectations. ²

How should exceptions work for executives or high-friction cases?

Create a formal exception record with compensating controls and an expiry, approved by the right risk owner. Then track it like any other control obligation so the exception does not become permanent. ¹

Footnotes

1. NIST Special Publication 800-53 Revision 5

2. FedRAMP documents and templates