AC-19 Access control for mobile devices: evidence guide

What AC-19 access control for mobile devices asks an organization to prove

When an audit, contract or customer questionnaire requires AC-19, the organization must show that its organization-controlled mobile devices are configured, connected and authorized in a way that protects organizational systems and data. The control covers those devices wherever they go, including when they leave controlled areas such as offices and data centers. In practice, the assessor will expect a documented set of configuration requirements, connection requirements and implementation guidance for mobile devices, plus a record that each connection to an organizational system was authorized. The control text itself is only the starting point, so read it alongside the NIST catalog entry for AC-19 and confirm the wording your auditor will use.

The risk is straightforward: a lost, stolen or compromised phone or tablet that already holds a session, a token or cached organizational data can reach systems the owner should never have exposed. Two things make this hard to prove. The first is inventory. If the organization cannot list which mobile devices are enrolled, which are personal, and which connect to email, file shares or internal applications, it cannot show that any configuration requirement applies to them. The second is authorization. Assessors look for evidence that each type of connection was approved before it was used, so a policy that says devices must be managed is not enough without records of who approved what and when.

Before scoping work or asking for a quote, decide which device types and connection paths are in scope, who authorizes each one, and where the configuration requirements are written down. Then confirm with your assessor which records they will examine, such as the configuration management plan, the authorizations for mobile device connections and the system audit records. Self-hosted tools such as osquery, which can run device queries across a fleet through Fleet's policy pages, can help produce some of that evidence, but whether a given device or platform reports the attributes you need is something to confirm in your own environment before you rely on it.

Which mobile devices, teams and systems AC-19 reaches

AC-19 applies to organization-controlled mobile devices, and the boundary of that population decides most of the work. The cards below cover the scoping choices that determine which devices, apps and teams fall under the control, and which controls take over when ownership or location changes.

Organization-controlled versus personal devices

AC-19 covers mobile devices the organization controls. Company-issued phones and tablets are in scope, while personal devices that employees bring to work usually fall under AC-20 Use of external systems, which asks for terms and conditions or asserted controls instead. Confirm ownership in writing for each device class, and record how enrollment or management profiles prove that a device is organization-controlled. Ownership that cannot be shown from records will be hard to defend at assessment.

Devices that leave controlled areas

The control names devices used outside controlled areas as a specific concern. Laptops and phones that travel, work from home or sit in vehicles carry the organization's access without the physical protections of an office. Decide which device classes may leave the facility, which connections they may make from outside, and how a lost or stolen device is reported and cut off. Ask the team to show how these rules differ from the rules for devices that stay on site.

Mobile apps and mail clients reaching systems

A mobile device is in scope when an app or mail client connects it to an organizational system. Email, file sync, chat and internal web apps each open a path that the authorization must cover. Inventory which apps and clients are approved, which accounts they use, and whether they store data on the device. Test one connection path end to end, since the assessor will look at what the device can actually reach rather than the policy that describes it.

Authorization of each device connection

AC-19 requires that connections from mobile devices to organizational systems be authorized. This is a per-connection decision, not only a device purchase record. Define who approves a connection, which systems it may reach, and how revocation works when a person leaves or a device is retired. Keep the authorization records, since assessors examine them directly and interview the personnel who use devices to access systems.

Baseline selection and the privacy baseline

SP 800-53B selects AC-19 for the low, moderate and high baselines, so any system categorized at those impact levels needs it. The privacy baseline does not select AC-19, although that does not remove access control duties for personal information elsewhere in the catalog. Confirm the impact categorization of each system before deciding that AC-19 applies, and document any tailoring decision in the system security plan.

Enhancement scope for full device encryption

The enhancement for full device or container-based encryption, AC-19(5), is selected in the moderate and high baselines. Only the current enhancements count, since AC-19(1) through AC-19(3) are withdrawn in Release 5.2.0. Decide whether the encryption requirement covers the whole device or only a managed container holding organizational data, and confirm that the chosen method is what the system security plan describes. Ask the team which devices cannot meet the requirement and how those exceptions are approved.

How an assessor tests AC-19 and what they ask to see

This table compares the examine, interview and test methods SP 800-53A Rev. 5 uses for AC-19, the assessment object each one draws on, and the evidence that closes common findings. Read each row as a question the assessor will ask and the artifact that answers it.

Assessment method	Assessment objects	Evidence an assessor expects	Common finding and the evidence that closes it
Examine	Configuration management plan	A written plan that sets configuration requirements and connection requirements for organization-controlled mobile devices, including devices used outside controlled areas	The plan covers managed devices but not the devices actually in use. Close it with the plan revised to match current mobile device management settings and a dated approval record
Examine	Authorizations for mobile device connections to organizational systems	A list of authorized devices and users, with the approval for each connection and the systems it may reach	Authorizations do not match the devices actually connected. Close it with a reconciliation of the authorization list against connection records from the period under review
Examine	System audit records	Logs showing when mobile devices connected, which systems they reached and any denied attempts	Connection events exist but are not tied to an authorization. Close it with logs that show the authorization reference or device identifier for each connection
Interview	Organizational personnel using mobile devices to access organizational systems	Consistent answers about which devices they use, what settings apply and how they report a lost or changed device	Users describe personal devices as approved, or report workarounds. Close it with the acceptable use rule, user acknowledgments and records of follow-up on reported devices
Interview	System and network administrators	Explanations of how connections are authorized, enforced and monitored, and who can change the settings	Administrators cannot explain how a device is blocked or removed. Close it with documented procedures and a walkthrough record showing the enforcement steps
Test	Access control capability for mobile device connections to organizational systems	A demonstration that an unauthorized or noncompliant device is refused and an authorized device is admitted under the stated requirements	The capability exists on paper but a test device connects. Close it with a dated test record showing the refusal, the admission and the retest after any fix

How to implement AC-19 in the order an assessor expects

This sequence moves from deciding which devices and systems are in scope to proving that each connection is authorized, encrypted where required and monitored. Each step produces a record an assessor can examine, interview against and test.

Define mobile device types and in-scope systems
Start by listing the kinds of organization-controlled mobile devices in use, such as company phones, tablets and laptops that behave like mobile devices, and the organizational systems they may reach. Name the device owner, the operating system families and whether each device leaves controlled areas. Ask the system owner to confirm the impact level, because it decides whether the moderate and high encryption enhancement applies. The output is a scoped device inventory that the system security plan references. The step is done when every device type has a named owner and a stated system boundary.
Write configuration and connection requirements
Write the configuration requirements that every in-scope device must meet before it connects, and the connection requirements that govern how it reaches organizational systems. Cover items such as screen lock, OS patch level, jailbreak or root detection, approved apps and remote wipe capability, and state which requirements apply to personal devices if any are allowed. Route the draft through your configuration management process so it is versioned with the baseline. The output is a signed mobile device requirements document, approved by the system owner and security leadership. Assessors will ask for this document first.
Implement enforcement on devices and at the access point
Deploy a mobile device management or equivalent enrollment tool that pushes the configuration settings and blocks non-compliant devices. Confirm the enforcement at the access point too, so that email, VPN or application gateways refuse connections from devices that fail the checks. Test a compliant device and a deliberately non-compliant test device to show that the gateway behaves as the requirements say. The output is a test record with device identifiers, timestamps and the observed result for each case. Confirm the exact capabilities of your chosen tool with its vendor before you rely on them.
Set up the authorization workflow for each connection
Define who may approve a mobile device connection to each organizational system, what evidence the approver needs and how the decision is recorded. Use your identity and access management process so approvals link to a named user and a named device. Keep the approval and any revocation in a ticketing or access record that carries dates and approver identity. The output is an authorization record for every connection, along with the approval procedure. Interview the people who approve connections to confirm they follow the procedure as written.
Decide and implement the encryption approach
For moderate and high systems, decide how mobile devices or their containers will be encrypted, which is the AC-19(5) enhancement that SP 800-53B selects at those baselines. Choose between full device encryption and container-based encryption according to the data the device holds, and confirm the encryption is enabled and enforced by the enrollment tool. Record the cryptographic modules and any FIPS validation status that your authorizing official requires, and verify those claims against the module vendor's own documentation. The output is an encryption decision record and a compliance report from the device fleet. Low baseline systems do not select this enhancement, so record that decision explicitly.
Monitor device state and connection compliance
Set up recurring checks that confirm each enrolled device still meets the requirements after it is connected. Open-source tools such as osquery, Fleet and Wazuh can run configuration queries across a device fleet and report pass or fail results per policy, depending on the platform and device types you use. Define how often checks run, who reviews failures and what happens to a device that falls out of compliance, such as revoking its connection. Confirm which device platforms each tool supports before you commit to it. The output is a dated compliance log and a record of each remediation or revocation.
Document the results for assessment
Assemble the evidence into the package an assessor will examine: the system security plan entries for AC-19, the requirements document, enforcement test records, authorization records, the encryption decision, monitoring logs and the list of related controls such as AC-17, AC-18 and AC-20 that cover overlapping connection paths. Cross-check the package against the four determination statements in SP 800-53A so that each one has a matching artifact. Ask an independent assessor to confirm scope and evidence expectations before the formal assessment begins. The output is a complete assessment evidence package that the organization owns and maintains.

What the full device or container encryption enhancement requires

AC-19(5) is the enhancement that asks an organization to encrypt the contents of its organization-controlled mobile devices, using either full device encryption or container-based encryption of the organizational data stored on them. SP 800-53B Release 5.2.0 selects it in the moderate and high baselines only. The AC-19 catalog entry lists five numbered enhancements, but AC-19(1), AC-19(2) and AC-19(3) are withdrawn, which leaves AC-19(5) and AC-19(4) as the two current enhancements. Confirm the enhancement numbering against the CPRT entry or the OSCAL catalog before citing it in a system security plan, because withdrawn enhancements still appear in older documents and tooling.

The choice between the two approaches is a design decision, and it should be made before the mobile device management policy is written. Full device encryption protects everything on the handset, including the operating system, applications and personal data, and it usually fits organization-owned devices used for mixed purposes. Container-based encryption protects only a managed workspace that holds organizational data, which can suit bring-your-own or mixed-ownership fleets, but it leaves the rest of the device to the user. Document which approach you chose, the device platforms it covers and how a device that fails the requirement is handled, because an assessor will test the decision against your stated boundary.

Evidence should show that encryption is both enabled and enforced. Keep the configuration profile or policy that requires encryption, a current compliance report showing which devices pass or fail, and the list of exceptions with the approver, the reason and the expiry date. A fleet query for encryption state can be run with osquery or Fleet against endpoints that report to them, but mobile devices often need the mobile device management platform's own reporting, so confirm with the vendor which encryption fields and compliance states it exposes and whether they can be exported with timestamps. Also confirm how the platform treats devices that are not enrolled, because an enrolled device that is compliant says nothing about a device that has never reported in.

Which evidence passes an AC-19 assessment

An assessor testing AC-19 looks for documented requirements, authorizations that match real connections, and proof that the requirements are enforced over time. The cards below cover the artifacts that connect those three points, and how each one stays current between assessments so the organization is not rebuilding it the week before a review.

Mobile device configuration requirements

This is the written standard that sets what an organization-controlled mobile device must look like before it may connect: operating system minimums, screen lock, encryption state, management enrollment and approved app rules. It also carries the implementation guidance for devices used outside controlled areas, which assessors read against the configuration management plan they examine. Keep it under change control, record the approver and effective date on each revision, and review it on a fixed cadence so the requirements match the current device fleet.

Device connection authorizations

Each authorization records which device, owner, connection type and organizational system it covers, with an approval date and the approving official. Assessors compare this register with the connections they see in logs and asset inventories, so any device that connects without a matching entry is an immediate finding. Export the register on a recurring schedule, reconcile it against the mobile device management inventory, and retire entries when owners leave or devices are wiped.

Device compliance reports over time

A single compliance snapshot shows little. Assessors want a trend showing how many enrolled devices met the configuration requirements across the period under review, along with what happened to the ones that failed. Osquery or Fleet policy results can be exported on a schedule and retained as dated files, which shows that the checks ran continuously rather than only when preparing for an audit. Confirm retention periods with your assessor before you set them.

Blocked and revoked connection records

Evidence that the organization acts on non-compliant devices is as important as evidence that it detects them. Keep records of connections denied at access control, authorizations revoked after a failed check, and devices quarantined or wiped, with the ticket or event that started each action. Review these records in the same meeting as the compliance trend so that repeated failures for one device or owner are escalated rather than closed one at a time.

Encryption status exports and exceptions

Where the organization selects the full device or container encryption enhancement, assessors expect an export showing encryption status for each in-scope device and a documented exception process for any device that cannot meet it. Each exception should name the device, the reason, a compensating measure, an owner and an expiry date. Export the status on the same cadence as the compliance reports and confirm the baseline that applies to your system, since the encryption enhancement is selected in the moderate and high baselines.

Audit records of mobile connections

Logs from the mobile device management platform, the identity provider and the target systems show when a device connected, which account it used and what it reached. Assessors use these records to test whether connections happened only under an authorization. Forward these logs to a central store with a documented retention period, and run a recurring check that matches each connection event to an active authorization. Mismatches should open a review rather than sit in an archive.

What meeting AC-19 costs in money and effort

This table breaks AC-19 spending into its components rather than totals, because NIST does not estimate compliance costs and no supplied figure gives a price. Read each row for who is paid, whether the cost is one-time or recurring, and what moves it up or down. The main takeaway is that device count, personal device policy and the number of connection types drive most of the effort, and these are the inputs to fix before requesting a quote.

Cost component	One-time or recurring, and who is paid	What drives it up or down, and how to keep it down
Mobile device management or endpoint tooling licenses	Recurring. Paid to the tool vendor per device or per seat, unless the tool is self-hosted open source with no license fee	Device count and platform mix drive license spend. Self-hosted open-source tools such as osquery-based fleet management can remove license spend, but hosting and staff time remain
Engineering time for configuration and connection rules	One-time for initial rules, then recurring for changes. Paid to internal staff or an implementation partner under a written scope	Number of mobile platforms and configuration baselines drives effort. Fewer, well-defined baselines reduce rework
Authorization workflow setup	One-time build, then recurring approvals. Paid to internal IT or service staff, with partner time if scoped	Number of connection types and the approval path drive effort. A single documented approval flow for each connection type keeps it down
Encryption rollout for full device or container encryption (AC-19(5))	One-time rollout, then recurring checks. Paid to internal staff for device enrollment, help desk and user support	Relevant only in moderate and high baselines. Device age, OS versions and the number of unmanaged devices drive effort. Confirm the baseline before scoping
Personal device policy design	One-time policy work, then recurring exceptions handling. Paid to legal, HR and IT staff	Use of personal devices under AC-20 increases scope. Restricting personal devices to a container or limited set of apps reduces it
Evidence upkeep	Recurring. Paid to internal compliance or security staff for collecting configuration exports, approval records and audit records	Frequency of collection and the number of devices sampled drive effort. Automated, self-hosted query exports reduce manual collection
External testing or configuration review	Recurring or periodic. Paid to an independent tester or assessor under a written scope, separate from any auditor report	Scope size and the number of device types drive cost. Ask the provider to state what is tested and what is excluded in the quote
Auditor sampling	Recurring at each assessment. Paid to the independent assessor, who issues any report	Number of devices, connection types and baselines in scope drive sampling. A current, complete device inventory shortens the sampling effort

How self-hosted open-source tools support AC-19 evidence

AC-19 asks for connection requirements on organization-controlled mobile devices and authorized connections to organizational systems. The tools below can gather device state and show whether devices meet your requirements, so assessors have records to review. Each tool produces evidence only. The organization still decides which devices are authorized to connect.

Fleet policies for device compliance

Fleet (MIT) policies are yes or no questions written as osquery queries, such as whether disk encryption is enabled or a screen lock is set. The policies page shows which devices on each fleet pass or fail each policy, which gives you a per-device record of the connection requirements you have defined. Treat a failing device as a finding to review, not an automatic block. Confirm that Fleet's policy checks cover the mobile platforms you use, since coverage differs by operating system.

osquery device state queries

osquery (Apache-2.0 OR GPL-2.0-only) exposes device state such as running processes, open network connections and hardware events as SQL tables. Its osqueryd daemon can schedule the same query across an entire fleet, which produces repeatable snapshots for AC-19 testing. Check which tables are available on each mobile platform you manage, because mobile coverage is narrower than desktop coverage. Under the dual license, you may choose either Apache-2.0 or GPL-2.0-only, so have counsel confirm which terms fit your distribution model.

Wazuh configuration assessment

Wazuh (GPL-2.0-only) Security Configuration Assessment scans monitored endpoints for misconfigurations using YAML policies. Its policies are mostly based on CIS benchmarks and can be extended with custom checks on files, registry keys and running processes, and each failed check comes with recommended remediation. Use it to evidence the configuration requirements you set for managed devices. Confirm that a policy exists for each device platform in your environment, and plan for custom policies where none is shipped. GPL-2.0 obligations apply if you modify and distribute the software.

Velociraptor hunts for offline devices

Velociraptor (AGPL-3.0-only) collects forensic artifacts defined in VQL from endpoints. Hunts run one or more artifacts across a group of systems, schedule offline machines to collect when they reconnect, and create a notebook per hunt for analyzing combined results. This helps when a device was off the network during a check and you need its record before deciding on a connection. The AGPL network clause can apply if you modify Velociraptor and make it available to users over a network, so review that obligation before deployment.

Who owns AC-19 work, what a partner can take on, and where the auditor stops

Your organization owns AC-19 because it owns the mobile devices, the policy and the decisions about who may connect them to organizational systems. No partner or tool can make those decisions for you, and an assessor will ask who made them and when. Your team keeps the accountable record for each decision, even when someone else prepares the supporting data.

Policy and requirements: Define the configuration and connection requirements for organization-controlled mobile devices, including what applies when a device leaves a controlled area.
Authorization decisions: Approve each mobile device connection to organizational systems and record who approved it, on what basis and for which systems.
Device ownership and inventory: Decide which devices are organization-controlled, who holds them and how they are retired.
Exceptions and risk acceptance: Document any device that cannot meet a requirement and have an accountable owner accept the residual risk in writing.
Encryption decisions: If you select the full device or container encryption enhancement, decide which devices and data containers it covers.

Before an assessment, confirm that each of these decisions has a named owner and a dated record.

Questions buyers ask about AC-19 cost, effort and outside help

How much effort does AC-19 take and what drives it?

The effort depends mainly on how many mobile devices the organization controls, how many of them reach organizational systems, and how many connection paths already have written rules. NIST does not publish a cost or duration for AC-19, and no figure is given here. The work splits into one-time items (writing the mobile device configuration requirements, defining which devices may connect and under what conditions, and setting up authorization records) and recurring items (reviewing authorizations, checking device configurations, and reporting on them). Ask any partner for a written scope that lists the device types, the number of devices, the systems in scope and the evidence deliverables before agreeing to a quote.

Can a team meet AC-19 with open-source tools alone?

Open-source tools can produce much of the technical evidence, but they do not write the requirements or make the authorization decisions. Fleet policies, which are yes or no questions asked of devices as osquery queries, can show which devices pass or fail a configuration check. osquery can schedule queries across a fleet, and Wazuh Security Configuration Assessment can check endpoints against YAML policies and recommend remediation. Velociraptor can collect artifacts from endpoints, including devices that were offline and reconnect later. Your team still needs to define the configuration requirements, decide which connections are authorized, and keep the records an assessor will examine. Confirm each tool's current mobile device coverage with its documentation before you rely on it.

What does AC-19 need from our own staff?

AC-19 needs decisions and records from your own people, because the organization owns its controls. Expect to involve the security owner who sets the mobile device requirements, the system and network administrators who enforce connection settings, the personnel who use mobile devices to reach organizational systems, and the approver who authorizes each connection. The SP 800-53A assessment procedure for AC-19 names interviews with these groups, so they must be able to explain the rules and how they are applied. Plan time for those people to review the configuration management plan and the connection authorizations before an assessment starts.

Can an implementation partner make the auditor's job easier, and where does that stop?

A partner can prepare the systems, device configurations, logs and documents an assessor will examine, so the evidence is organized and reproducible. A partner cannot issue an assessment result, decide whether a control is satisfied, or sign an authorization. Only the organization's authorizing official and independent assessors make those determinations. Under FISMA, Inspectors General independently assess agency system security, which is a separate line of oversight from any implementation work. Ask a partner to state in writing which evidence they will prepare and which decisions remain with your organization and the assessor.

Does AC-19(5) apply to every mobile device or only to moderate and high systems?

AC-19(5) is selected in the moderate and high security control baselines in SP 800-53B Release 5.2.0. It is not part of the low baseline, so a low-impact system does not need it unless your own risk assessment or a contract adds it. The enhancement asks for full device or container-based encryption, and it applies to the organization-controlled mobile devices in scope for the system. The base AC-19 control, which covers configuration and connection requirements, is selected in all three baselines (low, moderate and high) and is not selected for the privacy baseline. Confirm the baseline and any overlays with your authorizing official before you scope the encryption work.

What should we confirm before we scope AC-19 work?

Confirm the impact level and baseline of each system that mobile devices reach, because that decides whether AC-19(5) applies. Confirm which device types are organization-controlled and which are personal devices, since personal devices fall under AC-20 rather than AC-19. List the connection types you allow, the systems they reach, and where a device may leave a controlled area. Confirm which existing tools already report device state and whether they cover your mobile platforms. Finally, ask for a written scope, a deliverables list and a quote before work begins. A fixed-scope agreement is the usual way to record these decisions. DeployOpen does not publish a price list, so a quote will follow from that written scope.

How DeployOpen prepares AC-19 systems and evidence

DeployOpen works on AC-19 Access control for mobile devices as a fixed-scope implementation inside the client's own infrastructure. We prepare the mobile device configuration, connection controls and evidence that an independent assessor will examine and test, while the organization keeps ownership of its control decisions.

How we scope

Agree in writing which organization-controlled mobile device types and management points fall inside AC-19 scope.
Confirm which baseline applies, whether low, moderate or high, and whether AC-19(5) encryption is in scope.
Define the connection authorization workflow, the owners of each decision and the systems that mobile devices may reach.

How we build

Configure open-source endpoint telemetry such as osquery to report device state across the mobile and endpoint fleet.
Set up policy checks that flag devices failing encryption, configuration or connection requirements, with results tied to owners.
Test the connection restrictions and the enforcement path so the assessment test object for mobile connections can be demonstrated.

How we hand over

Deliver documented configuration requirements, authorization records and connection procedures mapped to the AC-19 determination statements.
Provide exported policy results, query definitions and audit records that show configuration and connection checks over time.
Walk the organization's staff through the evidence set so they can answer assessor interview questions about mobile access.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Review device policy results and update checks when device types, operating systems or access rules change.
Confirm with your assessor the evidence format and sampling they expect before the assessment window opens.