Access Control for Mobile Devices AC-19

Source: NIST SP 800-53 Rev.5, Access Control family NIST SP 800-53 Rev.5. The baseline shows the lowest SP 800-53B baseline (Low / Moderate / High) this control appears in NIST SP 800-53B.

Control guide — plain-English, per NIST SP 800-53

AC-19 (Access Control for Mobile Devices) is about setting the rules for the mobile devices — mainly phones and tablets, plus any laptop your program chooses to manage the same way — that connect to your systems, including when those devices are outside your controlled areas (home, a coffee shop, a hotel). You decide how a device must be configured before it may connect, how it is allowed to connect, and you authorize each connection on purpose instead of letting any device attach. It sits in the Low baseline.

What good looks like

• Write down configuration requirements — for example, a device must have full-disk encryption and an automatic screen lock before it may connect.
• Write down connection requirements — how a device is allowed to reach the server, such as over a VPN (Virtual Private Network) or with an SSH (Secure Shell) key rather than an open password login.
• Authorize each connection on purpose — keep a short list of approved devices so an unknown device cannot quietly attach.
• Cover the ‘outside controlled areas’ case — the same rules apply when the device leaves the building.
• At Low, the base control is enough — you do not need remote wipe or managed work containers yet. Those come later, and they map to CIS (Center for Internet Security) Safeguards 4.11 and 4.12.

Framework mapping

• NIST CSF 2.0 — PR.AA-05 — Access permissions, entitlements, and authorizations are defined in a policy, managed, enforced, and reviewed, and incorporate the principles of least privilege and separation of duties
• CIS Controls v8 — Control 4 — Secure Configuration of Enterprise Assets and Software

How to move it toward Implemented

• Write a one-page mobile device rule: what a device must have (encryption, screen lock), how it may connect (SSH key or VPN, not a password), and who approves a new device.
• On the server, require key-based login and turn off password login so only a device holding an approved key can connect — set PasswordAuthentication no in /etc/ssh/sshd_config and give each approved device its own entry in ~/.ssh/authorized_keys.
• Limit which networks can even reach the server with the firewall. With UFW (Uncomplicated Firewall), allow SSH only from your VPN range: ufw allow from <vpn-subnet> to any port 22 — that enforces the connection requirement.
• Cut off idle mobile sessions by setting ClientAliveInterval and ClientAliveCountMax in /etc/ssh/sshd_config, then run systemctl restart ssh — this ties AC-19 to session termination (AC-12).
• Attach the rule, the sshd_config, and the authorized-key list as hardening evidence on the asset, naming AC-19 in the Requirement field — that moves it from ‘To assess’ toward ‘Completed’.