AC-19: Access Control for Mobile Devices

Control ID AC-19 · Control Name Access Control for Mobile Devices · Framework NIST SP 800-53, Revision 5 · Control Family Access Control · Baselines LOW · MODERATE · HIGH · Relevance Organization (First Party and Third Party) · Risk Severity High

What this control requires

AC-19 requires organizations to define configuration standards, connection rules, and usage guidance for every mobile device they control, including when those devices leave the building.

But the scope extends further than most teams expect. Smartphones, tablets, and any computing device small enough to carry, self-powered, and designed to operate wirelessly all fall under AC-19. The control has two explicit obligations: first, establish the rules that govern how these devices are configured, connected, and used; second, formally authorize each mobile device before it touches an organizational system. Without both halves, you have a policy gap that auditors will flag and attackers will exploit.

In practice, this requirement means your organization needs documented configuration baselines for each class of mobile device, a formal connection-authorization process, and implementation guidance that travels with the device, not just a policy that sits in a SharePoint folder. Because mobile devices routinely operate outside controlled physical areas, the control explicitly requires that your rules account for off-premises use, where physical and procedural safeguards are weakest.

Why it matters

Most organizations allow mobile devices to connect to the same systems that hold their most sensitive data, yet govern those connections with policies written for desktops that never leave the building.

In practice, the gap between policy and enforcement is where risk concentrates. Organizations that allow mobile connections without formal authorization create unmonitored pathways into systems that store sensitive data. A device that syncs email, caches documents locally, and connects to both corporate Wi-Fi and public hotspots carries a fundamentally different risk profile than a desktop that never leaves the server room. AC-19 exists because those differences demand deliberate controls, not inherited assumptions from your desktop security program.

Where this control breaks down is bring your own device (BYOD). When personal devices access organizational systems, configuration requirements compete with employee expectations around privacy and usability. Organizations that skip the authorization step (or reduce it to a checkbox on an onboarding form) lose visibility into which devices are connecting, what software they’re running, and whether they meet baseline security standards.

The downstream consequence is audit exposure. Failure to maintain AC-19 controls may result in findings during Federal Information Security Management Act (FISMA) assessments, FedRAMP authorization reviews, or any audit that references NIST SP 800-53. For organizations handling controlled unclassified information, the downstream effect reaches NIST SP 800-171 compliance as well.

What attackers exploit

• Unmanaged devices connecting to corporate networks without authentication or compliance checks
• Outdated operating systems and unpatched firmware on mobile devices
• Absence of mandatory protective software (antivirus, endpoint detection) on personal devices
• Unsecured wireless synchronization between mobile devices and organizational data stores
• Lack of remote wipe capability when devices are lost or stolen

How to implement

The most common failure mode is treating mobile device access control as a single policy document rather than an operational program with technical enforcement. A written policy without mobile device management (MDM) enrollment, without device compliance checks, and without connection-authorization workflows is a finding waiting to happen.

For your organization

Step 1: Classify mobile device types

Inventory every class of mobile device that touches organizational systems: organization-issued smartphones, tablets, laptops below a size threshold, and any BYOD devices with authorized access. Different device classes may require different configuration baselines.

Step 2: Establish configuration baselines

Define mandatory settings for each device class: OS version minimums, encryption requirements (full-device or container-based), screen lock timeouts, disabling of unnecessary hardware features (infrared, near-field communication where not required), and mandatory protective software. Align baselines with your CM-02 and CM-06 configuration management requirements.

Step 3: Build a connection-authorization process

No mobile device should connect to organizational systems without a documented authorization decision. This process requires a formal request, a compliance check against your configuration baseline, and an approval record. Automate where possible through MDM or unified endpoint management (UEM) platforms.

Step 4: Implement ongoing compliance monitoring

Authorization isn’t one-and-done. Devices drift out of compliance: OS updates get deferred, protective software gets disabled, jailbreaking occurs. Use MDM/UEM tools to continuously verify device posture and automatically quarantine non-compliant devices.

Step 5: Address off-premises use explicitly

Your implementation guidance must cover scenarios where devices operate outside controlled areas: VPN requirements for remote access, restrictions on connecting to public Wi-Fi, rules for local data storage, and procedures for reporting lost or stolen devices.

Common mistakes

• Relying on user self-attestation instead of automated compliance checks
• Allowing BYOD connections with no technical enforcement of configuration requirements
• Treating mobile device authorization as a one-time onboarding event rather than a continuous process
• Failing to update configuration baselines when new device types or OS versions enter the environment
• Not documenting exceptions or waivers for devices that cannot meet baseline requirements

For your vendors

What to ask in a security questionnaire

• Does the vendor maintain a documented mobile device policy that covers configuration, connection authorization, and off-premises use?
• What MDM or UEM platform does the vendor use to enforce mobile device compliance?
• How does the vendor handle BYOD devices that access systems containing your data?
• What is the vendor’s process for revoking mobile device access when an employee departs?

What evidence to request

• Mobile device access control policy document
• MDM/UEM enrollment and compliance reports
• Connection authorization records or approval workflows
• Evidence of periodic mobile device compliance reviews

Red flags

• No MDM/UEM platform in use despite allowing mobile device connections
• Policy exists but no evidence of technical enforcement
• BYOD devices have unrestricted access to production systems
• No documented process for lost or stolen device response
• Vendor cannot produce connection authorization records

How to verify beyond self-attestation

Request a screenshot or export from the vendor’s MDM/UEM console showing enrolled device counts, compliance rates, and enforcement actions. Cross-reference the vendor’s mobile device policy against the configuration requirements they claim to enforce. Ask for evidence of a recent mobile device compliance audit or review cycle. A zero trust posture that verifies device identity and health on every access request is the strongest signal that a vendor takes mobile device controls seriously.

Evidence examples

Cross-framework mapping

Related controls

• AC-03, Access Enforcement: Provides the mechanism-level enforcement that AC-19 configuration requirements depend on for mobile device connections.
• AC-04, Information Flow Enforcement: Controls data movement between mobile devices and organizational systems, particularly relevant for containerized environments.
• AC-07, Unsuccessful Logon Attempts: Defines lockout behavior for mobile devices after repeated failed authentication attempts.
• AC-11, Device Lock: Specifies automatic screen-lock requirements that form part of the AC-19 configuration baseline.
• AC-17, Remote Access: Governs the remote connection methods that mobile devices use to reach organizational systems from outside controlled areas.
• AC-18, Wireless Access: Addresses the wireless protocols and network-level controls that mobile devices rely on for connectivity.
• AC-20, Use of External Systems: Covers mobile devices that are not organization-controlled, the complement to AC-19’s scope.
• CA-09, Internal System Connections: Addresses authorization of connections between internal systems, including mobile device integration points.
• CM-02, Baseline Configuration: Provides the foundational configuration standards that AC-19 mobile device baselines should reference and extend.
• CM-06, Configuration Settings: Defines the specific parameter values enforced on mobile devices through MDM/UEM profiles.

Frequently asked questions

What is NIST SP 800-53 AC-19

AC-19 is the NIST SP 800-53 control that requires organizations to establish configuration standards, connection rules, and usage guidance for mobile devices and to formally authorize each device before it connects to organizational systems. The control applies to any computing device small enough to carry, self-powered, and designed to operate wirelessly, including smartphones and tablets. It spans all three baselines (LOW, MODERATE, HIGH), making it a universal requirement for organizations following the NIST SP 800-53 framework. AC-19 specifically addresses organization-controlled devices; AC-20 covers devices the organization does not control.

What happens if AC-19 is not implemented

Organizations without AC-19 controls face unmonitored mobile device connections to sensitive systems, creating pathways for data exfiltration, malware introduction, and unauthorized access. Auditors assessing against NIST SP 800-53 will flag the absence of mobile device configuration requirements, connection authorization records, and implementation guidance as findings. For federal agencies, this creates FISMA compliance gaps; for cloud service providers, this gap risks FedRAMP authorization delays or revocations. The operational risk compounds in BYOD environments, where unmanaged personal devices may sync corporate data without encryption, endpoint protection, or remote wipe capability.

How do you audit AC-19

Auditors assess AC-19 by examining the mobile device access control policy for documented configuration requirements, connection authorization procedures, and off-premises usage guidance. They review MDM or UEM enrollment records to verify that authorized devices match the connection authorization log, and they test whether configuration baselines (OS version minimums, encryption enforcement, mandatory protective software) are technically enforced rather than self-attested. Interviews with system administrators and mobile device users confirm that the authorization process operates as documented. Audit records from network access control systems or MDM platforms provide evidence that non-compliant devices are detected and quarantined.

What mobile devices are covered by AC-19

AC-19 applies to any organization-controlled computing device that is small enough for one person to carry, operates without a physical connection, has local data storage, and includes its own power source. This definition includes smartphones, tablets, and e-readers — but the scope extends to any device meeting those four criteria, regardless of brand or operating system. Laptops may fall under AC-19 depending on organizational definitions of “mobile device.” The control doesn’t cover personally-owned devices used without organizational authorization; those devices fall under AC-20, which addresses use of external systems.