AC-19: Access Control for Mobile Devices

AC-19 requires you to define and enforce baseline configurations, allowed connections, and operator-ready guidance for organization-controlled mobile devices, including when those devices leave controlled areas. To operationalize it, standardize mobile builds in MDM/UEM, restrict how devices connect to enterprise services, and retain evidence that the policy is enforced in production ¹.

Key takeaways:

• Treat AC-19 as an enforceable mobile control standard: configuration + connection rules + runbooks ¹.
• Scope is “organization-controlled mobile devices,” including offsite and travel use ¹.
• Audits hinge on proof: MDM policies, device inventory, compliance reports, and exception handling.

AC-19: access control for mobile devices requirement shows up in real audits as a simple question with sharp edges: “How do you know your corporate phones and tablets stay securely configured and only connect in approved ways when they leave the building?” NIST’s intent is operational, not theoretical. You must (1) establish configuration requirements, (2) establish connection requirements, and (3) publish implementation guidance for organization-controlled mobile devices, explicitly covering use outside controlled areas ¹.

For a Compliance Officer, CCO, or GRC lead, the fastest path is to turn AC-19 into a control card with a named owner, a single baseline per device class, and hard technical enforcement through MDM/UEM. Then make it auditable: show device inventory, show your enforced configuration profiles, show conditional access rules, and show what happens when a device drifts or a user asks for an exception. This page gives you requirement-level implementation guidance you can hand to IT and Security with minimal translation, plus an evidence bundle that stands up to external assessors.

Regulatory text

Requirement excerpt: “Establish configuration requirements, connection requirements, and implementation guidance for organization-controlled mobile devices, to include when such devices are outside of controlled areas; and” ¹.

What the operator must do (interpretation of the text):

1. Configuration requirements: Define the minimum security configuration for corporate mobile devices (phones, tablets, rugged devices). Your standard must be specific enough to enforce (MDM settings), not just a policy statement ¹.
2. Connection requirements: Define and enforce how those devices may connect to enterprise resources (email, SaaS, VPN, Wi‑Fi, Bluetooth peripherals, cellular tethering, USB). Focus on preventing untrusted networks, insecure protocols, and unmanaged endpoints from accessing sensitive systems ¹.
3. Implementation guidance: Provide practical instructions for users, IT, and Security that still apply when devices are offsite (travel, home, client sites). This includes what to do if a device is lost, how to use VPN/secure Wi‑Fi, and how to request support ¹.

Plain-English requirement interpretation (what AC-19 is really asking)

AC-19 expects you to control mobile devices the same way you control laptops: standard build, enforced settings, restricted access paths, and documentation that explains how it works day-to-day. The “outside controlled areas” clause is a signal: your controls must hold when the device is on public Wi‑Fi, in a hotel, or crossing borders, not only on corporate networks ¹.

Who it applies to

Entity context

• Federal information systems and contractor systems that handle federal data commonly inherit or adopt NIST SP 800-53 controls, including AC-19 ².
• Any organization using NIST 800-53 as a security baseline (directly, or mapped via customer requirements) will be expected to show a working AC-19 program ².

Operational scope

• In scope: Organization-controlled mobile devices (corporate-owned and managed), including devices used offsite ¹.
• Common adjacent scope decisions you must document: Whether employee-owned (BYOD) devices are allowed, and if allowed, what “organization-controlled” means in your environment (for example, enrollment in MDM with enforceable profiles). AC-19’s excerpt is explicit about organization-controlled devices, so if BYOD is not controlled, you need a clear prohibition or a separate model with enforceable controls ¹.

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

1) Create a control card (the operational contract)

Write a one-page control card that includes:

• Objective: Enforced baseline security and approved connection paths for org-controlled mobile devices, including offsite use ¹.
• Owner: Endpoint Engineering / IT Security (primary), with Compliance accountable for evidence readiness.
• Trigger events: New device enrollment, OS updates, policy changes, new SaaS onboarding, major incidents (lost device).
• Operating cadence: Continuous enforcement with periodic control health checks (recommended practice aligned to the provided guidance) ¹.

Practical note: AC-19 fails in audits when it exists only as a “Mobile Device Policy” PDF with no mapping to enforced MDM profiles.

2) Define your mobile device configuration baseline (enforceable)

For each device class (iOS/iPadOS, Android, rugged/other), define a baseline that includes, at minimum:

• Screen lock and authentication settings
• Device encryption expectations
• OS version and patch level expectations (enforced via compliance checks)
• Application controls (approved app store model, block unknown sources where applicable)
• Device integrity controls (root/jailbreak detection where supported)
• Logging/telemetry expectations where supported
• Remote wipe and lock capability and conditions for use

Then implement the baseline as MDM/UEM configuration profiles. The audit question is “Show me the profile, and show me it’s applied.”

3) Define connection requirements (how mobile devices may connect)

Write connection rules that your IAM/Network teams can enforce:

• Enterprise access path: Require managed devices for access to corporate email, SSO, or sensitive SaaS via conditional access rules.
• Network connectivity: Define when VPN is required, what Wi‑Fi networks are allowed, whether captive portals are permitted, and what to do on public networks.
• Peripheral and local connections: Set rules for Bluetooth pairing, USB data connections, and tethering/hotspot use based on your data exposure risk.
• Data paths: Decide whether local copy/paste, downloads, or offline storage is permitted for corporate data on mobile.

Then translate rules into technical controls: conditional access policies, VPN profiles, certificate-based authentication, and MDM restrictions. AC-19 is explicit that connection requirements must exist, so “user training” alone is not enough ¹.

4) Publish implementation guidance that works outside controlled areas

Produce short runbooks for:

• End users: secure travel and offsite usage, reporting lost devices, how to verify MDM enrollment status
• IT Helpdesk: enrollment, troubleshooting, remote wipe/lock procedure, exception intake
• Security Operations: what alerts matter (jailbreak/root, compliance failure), escalation steps

Keep guidance specific. “Do not use public Wi‑Fi” is rarely realistic; state the approved method (for example: “If you must use public Wi‑Fi, connect only after enabling VPN and do not access restricted apps unless the device is compliant”).

5) Build exception handling that doesn’t break the control

Define:

• What can be exempted (rare)
• Who approves (Security + Data Owner)
• Compensating controls (temporary access, reduced scope, VDI, separate device)
• Expiration and revalidation
• Evidence to retain

This is where Daydream fits naturally: track AC-19 exceptions like other risk items, with clear owners, due dates, and validated closure, so you can prove sustained operation during audits ¹.

6) Run control health checks and remediate

Perform recurring checks that answer:

• Are all in-scope devices enrolled and reporting?
• Are baseline profiles deployed and noncompliance handled?
• Are conditional access and connection rules effective?
• Are exceptions expired, reviewed, and closed?

The core risk factor to manage is evidence of ownership and operating cadence ¹.

Required evidence and artifacts to retain (minimum evidence bundle)

Create a single “AC-19 evidence folder” with:

• AC-19 control card (objective, owner, triggers, steps, exceptions)
• Mobile device policy/standard covering configuration + connection requirements + offsite use ¹
• MDM/UEM configuration profiles (exports or screenshots) for each device class
• Device inventory (in-scope list with ownership and enrollment status)
• Compliance reports (devices compliant vs noncompliant, jailbreak/root detections where available)
• Conditional access / access rules evidence (managed-device requirement, blocked conditions)
• User and IT runbooks (lost device, offsite access, enrollment steps)
• Exception register with approvals, compensating controls, and expiration
• Control health check records and remediation tickets through closure

Retention period should follow your governance and audit requirements. The key is consistency: an assessor should be able to trace from requirement → standard → enforcement → proof.

Common exam/audit questions and hangups

Expect these:

• “Show me the enforced configuration baseline for iOS and Android. Where is it documented and where is it configured?”
• “How do you prevent unmanaged devices from accessing email and corporate SaaS?”
• “How do you address mobile use outside controlled areas?”
• “What happens if a device becomes noncompliant?”
• “How do you handle exceptions, and who approves them?”
• “Prove this control is operating, not just written.”

Hangup patterns:

• Inventory mismatch (asset list vs MDM list vs IdP device list).
• “Offsite” is covered only in training slides, not in enforceable connection rules.

Frequent implementation mistakes (and how to avoid them)

1. Policy without enforcement. Fix: map every requirement to an MDM setting or conditional access rule; document the mapping.
2. No defined scope. Fix: define “organization-controlled” in your environment and document BYOD posture.
3. Over-broad exceptions. Fix: require expiration, compensating controls, and periodic review; block access by default for noncompliant devices.
4. Evidence scattered across teams. Fix: maintain a minimum evidence bundle with a single system of record; Daydream can manage control cards, evidence bundles, and recurring health checks as a workflow ¹.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page avoids case claims. Practically, AC-19 gaps show up as incident drivers (lost devices, unauthorized access via unmanaged endpoints) and as customer diligence failures because mobile controls are easy to test: assessors ask for conditional access rules and MDM compliance reports, then verify that noncompliant devices cannot connect ¹.

A practical 30/60/90-day execution plan

First 30 days (stabilize scope and baseline)

• Name an AC-19 control owner and publish the control card ¹.
• Define in-scope mobile device categories and data access patterns (email, SaaS, VPN).
• Document baseline requirements per platform; implement minimum MDM profiles.
• Implement a basic managed-device gate for core apps (at least email and SSO).

Days 31–60 (enforce connection requirements and close gaps)

• Expand conditional access rules to cover sensitive SaaS and administrative access.
• Add noncompliance handling (block, quarantine, or restricted access path).
• Publish user and helpdesk runbooks for offsite use and lost devices.
• Stand up an exception process with approvals, expiration, and tracking.

Days 61–90 (prove operation and make it audit-ready)

• Run a control health check; reconcile inventory vs MDM vs IdP.
• Collect the evidence bundle and store it in a consistent location.
• Test scenarios: noncompliant device, lost device, device offsite on public Wi‑Fi, exception request.
• Track remediation items to validated closure; keep artifacts tied to tickets ¹.

Frequently Asked Questions

Does AC-19 apply to employee-owned phones (BYOD)?

The excerpt applies to “organization-controlled mobile devices,” so BYOD is in scope only if you truly control it (for example, enrollment with enforceable policies) ¹. If you do not control BYOD, document a prohibition or alternate access method that avoids corporate data on unmanaged devices.

What counts as “outside of controlled areas” in practice?

Treat it as any location where you do not control physical access and network conditions: home networks, travel, client sites, hotels, and public Wi‑Fi ¹. Your guidance and connection rules must still apply there.

What evidence do auditors usually accept for AC-19?

Auditors typically want the written standard plus proof of technical enforcement: MDM profiles, compliance reports, and conditional access policies ¹. Add an exception register and health check records to show sustained operation.

Can we meet AC-19 with training and an acceptable use policy alone?

Training helps, but AC-19 explicitly calls for configuration and connection requirements for organization-controlled devices ¹. You should be able to demonstrate that devices are configured and access is restricted through technical controls.

How do we operationalize exceptions without creating shadow IT?

Define a narrow exception policy with approvals, compensating controls, and expiration, then track each exception to closure with evidence. A workflow system like Daydream helps keep exception decisions and artifacts tied to the control record ¹.

What’s the cleanest way to show “connection requirements” are enforced?

Show conditional access rules that require a compliant, managed device before access to corporate apps, and show test results or logs demonstrating that noncompliant devices are blocked. Pair that with your documented connection standard for offsite use ¹.

Footnotes

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

2. NIST SP 800-53 Rev. 5