AC-19(4): Restrictions for Classified Information

AC-19(4) requires you to ban unclassified mobile devices (personal phones, smartwatches, tablets, non-cleared laptops) inside any facility area that contains systems processing, storing, or transmitting classified information, unless an Authorizing Official (AO) explicitly permits an exception. To operationalize it quickly, define restricted zones, enforce device prohibition at entry, document AO-approved exceptions, and keep recurring evidence of compliance. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Key takeaways:

• Default stance is prohibition: unclassified mobile devices do not enter classified-processing areas without an AO-approved exception. (NIST SP 800-53 Rev. 5 OSCAL JSON)
• “Facilities containing systems…” means you must treat physical space as part of the control boundary and enforce rules at doors, not just on networks. (NIST SP 800-53 Rev. 5 OSCAL JSON)
• Audit success depends on evidence: posted rules, access procedures, exception memos, logs, and periodic checks mapped to an owner and cadence. (NIST SP 800-53 Rev. 5 OSCAL JSON)

AC-19(4): restrictions for classified information requirement is a physical-and-operational control disguised as a mobile device control. The requirement is not asking you to harden phones with MDM. It is asking you to prevent unclassified mobile devices from being present in spaces that host classified processing, storage, or transmission, unless your Authorizing Official grants an explicit permission. (NIST SP 800-53 Rev. 5 OSCAL JSON)

For a CCO, Compliance Officer, or GRC lead, the fastest path is to treat this like a “controlled area” problem: define where the rule applies, define what devices are covered, implement an entry workflow that makes violations difficult, and run an exception process that is narrow, documented, and reviewable. Most assessment issues come from ambiguity (“What counts as the facility?”), informal exceptions (“The program manager said it was fine”), and missing proof (“We do it, but we didn’t retain logs”). (NIST SP 800-53 Rev. 5 OSCAL JSON)

This page gives you requirement-level implementation guidance you can hand to security operations, facilities, and program leadership, with artifacts to retain and common audit questions to prepare for.

Regulatory text

Requirement (excerpt): “Prohibit the use of unclassified mobile devices in facilities containing systems processing, storing, or transmitting classified information unless specifically permitted by the authorizing official; and” (NIST SP 800-53 Rev. 5 OSCAL JSON)

Operator meaning: Your default operating rule is a ban on unclassified mobile devices inside the relevant facility space. The only acceptable way to allow a device is a specific, documented permission by the AO, scoped to conditions you can enforce and later prove to an assessor. (NIST SP 800-53 Rev. 5 OSCAL JSON)

What you must do, in plain terms:

• Identify the physical areas where classified systems exist or where classified processing could occur.
• Prevent unclassified mobile devices from entering or being used in those areas.
• Run a formal AO exception process and enforce the approved constraints. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Plain-English interpretation

AC-19(4) treats unclassified mobile devices as a high-risk presence in classified spaces because they can capture, store, or transmit information outside approved channels (camera, microphone, Bluetooth, Wi‑Fi, cellular, removable storage). So the control is primarily about physical presence and use: if the device is unclassified, it is not allowed in the space unless the AO says yes. (NIST SP 800-53 Rev. 5 OSCAL JSON)

A practical interpretation that holds up in audits:

• “Unclassified mobile device”: any mobile device that is not authorized/approved for classified use. In practice, assume personal phones and wearables are unclassified unless your classified program explicitly designates them otherwise.
• “Facilities containing systems…”: the rule applies to rooms, suites, labs, or enclosed spaces where classified systems are located or operated, not just the rack or workstation itself.
• “Specifically permitted by the authorizing official”: permission must be explicit, documented, and attributable to the AO; informal approvals do not count. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Who it applies to

Entities

• Federal information systems implementing NIST SP 800-53 controls.
• Contractors operating environments that handle federal data where NIST SP 800-53 is contractually required (common in regulated federal programs). (NIST SP 800-53 Rev. 5 OSCAL JSON)

Operational contexts

• Secure facilities, SCIF-like spaces, closed processing areas, labs, integration rooms, or operations floors that include systems that process, store, or transmit classified information.
• Any co-located office footprint where a subset of rooms contain classified systems and you must draw clear boundaries between “classified spaces” and “non-classified spaces.” (NIST SP 800-53 Rev. 5 OSCAL JSON)

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

1) Define the scope: spaces and systems

1. Inventory which systems process/store/transmit classified information.
2. Map those systems to physical locations (building, floor, room, cage).
3. Declare those locations as mobile-device restricted areas (or the equivalent term used by your facilities/security team). (NIST SP 800-53 Rev. 5 OSCAL JSON)

Deliverable: a controlled-area register that ties rooms to classified system presence.

2) Define “unclassified mobile device” for your environment

Create a short, enforceable definition that includes:

• Personal mobile phones and tablets
• Smartwatches and fitness wearables
• Personal hotspots
• Any laptop not explicitly approved for the classified environment
• Other portable electronics with storage or radio capabilities (as appropriate for your environment) (NIST SP 800-53 Rev. 5 OSCAL JSON)

Deliverable: a policy definition section that removes judgment calls at the door.

3) Implement entry controls (make the right action the easy action)

Pick controls that fit your facility design. Common, auditable options:

• Signage at entrances: “No unclassified mobile devices beyond this point without AO approval.”
• Lockers or secure storage outside the restricted area.
• Guard/checkpoint procedures, including a “pockets empty” check where appropriate.
• Badge-reader access control tied to the restricted area designation. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Deliverable: a written entry procedure plus physical measures (signage, lockers, checkpoints) that match it.

4) Establish the AO exception process (tight and reviewable)

You need an exception workflow that answers four questions:

• Who is requesting the exception (name, role, sponsor)?
• What device type and unique identifier (make/model/serial if available)?
• Where/when the device may be present (specific rooms, specific time window, specific purpose)?
• Under what constraints (features disabled, escort requirements, storage rules, inspections)? (NIST SP 800-53 Rev. 5 OSCAL JSON)

Operational rule: no device enters until the AO-approved exception is recorded and retrievable.

Deliverables:

• Exception request form/template
• AO approval memo (or ticket approval with AO attestation)
• Exception register (active/expired) (NIST SP 800-53 Rev. 5 OSCAL JSON)

5) Train the populations that will break this first

Targeted training beats broad awareness for this control. Train:

• Security/guards/reception staff who control entry
• Engineers and operators working in the space
• Executives and visitors (common source of “special” exceptions) (NIST SP 800-53 Rev. 5 OSCAL JSON)

Deliverables: training acknowledgement or attendance logs and the training content that states the prohibition and exception path.

6) Monitor and test compliance (prove operations, not intent)

Set up recurring checks aligned to your reality:

• Spot checks of restricted areas for prohibited devices
• Periodic review of access logs versus exception register (do the people with exceptions match entries?)
• Review signage placement and locker availability (are controls still in place?) (NIST SP 800-53 Rev. 5 OSCAL JSON)

Deliverables: inspection logs, findings, corrective actions, and closure evidence.

7) Map ownership and evidence cadence

Assign a control owner and define:

• Who updates the restricted-area list when systems move
• Who manages the exception register
• Who runs periodic checks and retains artifacts (NIST SP 800-53 Rev. 5 OSCAL JSON)

Practical note: This is where teams often use Daydream effectively, by mapping AC-19(4) to a named owner, a repeatable procedure, and a predictable evidence bundle so assessments stop being scavenger hunts. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Required evidence and artifacts to retain

Keep artifacts that show design, operation, and exception governance:

Design / governance

• Policy section prohibiting unclassified mobile devices in scoped facilities and naming the AO exception authority. (NIST SP 800-53 Rev. 5 OSCAL JSON)
• Restricted-area register (rooms/areas tied to classified systems). (NIST SP 800-53 Rev. 5 OSCAL JSON)
• Entry procedures (guards/reception, storage, visitor handling). (NIST SP 800-53 Rev. 5 OSCAL JSON)

Operational evidence

• Photos or floorplan excerpts showing signage locations (date-stamped where possible).
• Locker/storage provisioning record (location list; maintenance tickets if lockers are out of service).
• Inspection/spot-check logs and corrective actions. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Exceptions

• Exception requests and AO approvals with scope, timeframe, constraints.
• Active exception register and evidence of periodic review/expiration. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Training

• Targeted training materials and attendance/acknowledgements for staff assigned to restricted areas. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Common exam/audit questions and hangups

Assessors tend to ask questions that expose ambiguity and informal practice:

1. “Show me which rooms are covered by AC-19(4).” If you cannot produce a scoped list tied to classified systems, the control boundary looks undefined. (NIST SP 800-53 Rev. 5 OSCAL JSON)
2. “How do you prevent phones from entering?” A policy alone is weak; they will look for doors, signage, lockers, guard procedures, and evidence of checks. (NIST SP 800-53 Rev. 5 OSCAL JSON)
3. “Who is the Authorizing Official, and where are the approvals?” If approvals are verbal or delegated without documentation, you will struggle. (NIST SP 800-53 Rev. 5 OSCAL JSON)
4. “How do you handle visitors, executives, and third parties?” Visitor workflows are a frequent gap because they bypass routine staff discipline. (NIST SP 800-53 Rev. 5 OSCAL JSON)
5. “How do you keep exceptions from living forever?” Expect scrutiny on expiration, review, and revocation. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails	How to avoid it
Treating this as an MDM problem	The requirement is about prohibition in facilities, not configuring devices	Put controls at physical entry, then address any permitted devices via AO exceptions. (NIST SP 800-53 Rev. 5 OSCAL JSON)
Vague scope (“the lab area”)	Auditors need boundaries and rooms	Maintain a restricted-area register tied to system locations and keep it updated when systems move. (NIST SP 800-53 Rev. 5 OSCAL JSON)
Informal exceptions	“Permitted” must be AO-specific and provable	Use a standard request template and retain AO approval records and an exception register. (NIST SP 800-53 Rev. 5 OSCAL JSON)
No visitor controls	Visitors are the fastest path for policy bypass	Add visitor briefing, device storage, escort rules, and a sign-in log that references device restriction. (NIST SP 800-53 Rev. 5 OSCAL JSON)
Weak evidence retention	You can’t prove operations later	Define a recurring evidence bundle (inspections, photos, approvals, training logs) and store it centrally. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Enforcement context and risk implications

No public enforcement cases were provided in the supplied source catalog for this requirement, so this page does not list enforcement actions. The risk is still material: unclassified mobile devices in classified spaces increase the chance of unauthorized capture or transmission of classified information, and they create assessment findings that can delay authorization decisions or trigger remediation work. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Practical execution plan (30/60/90-day)

You asked for speed. Use a phased plan with concrete deliverables.

First 30 days (stabilize and stop the obvious violations)

• Name the control owner and AO exception authority for AC-19(4). (NIST SP 800-53 Rev. 5 OSCAL JSON)
• Publish an interim prohibition statement and post signage at all entrances to scoped areas.
• Stand up basic device storage (lockers/containers) outside restricted spaces.
• Create the exception template and start an exception register.
• Brief guards/reception and restricted-area staff on the new entry rule and exception path. (NIST SP 800-53 Rev. 5 OSCAL JSON)

By 60 days (make it repeatable and auditable)

• Finalize the restricted-area register tied to classified system locations.
• Document and test the visitor process (sign-in, briefing, device storage, escort).
• Run the first inspection cycle and retain logs and corrective actions.
• Review all exceptions for scope and expiration; revoke or tighten any that are broad. (NIST SP 800-53 Rev. 5 OSCAL JSON)

By 90 days (harden governance and evidence)

• Integrate AC-19(4) checks into facility change management (room moves, new systems, remodels).
• Establish recurring evidence collection and a centralized repository for artifacts.
• Conduct a tabletop exercise: “executive visit + third-party maintenance + urgent incident response,” and validate the exception process works under pressure.
• If you use Daydream, map AC-19(4) to the owner, procedures, and recurring artifacts so assessments pull from a single control record instead of email threads. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Frequently Asked Questions

Does AC-19(4) mean “no personal phones anywhere in the building”?

No. It applies to facilities or areas containing systems that process, store, or transmit classified information, based on your defined scope. You must clearly define those areas and enforce the prohibition at their entry points. (NIST SP 800-53 Rev. 5 OSCAL JSON)

What counts as an “unclassified mobile device” for this control?

Treat any mobile device that is not explicitly authorized for classified use as unclassified, including phones, wearables, tablets, and hotspots. Document the definition so staff and guards do not have to guess. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Who can approve an exception?

The requirement specifies “specifically permitted by the authorizing official.” Put the AO’s name/role in the procedure and retain approvals in a retrievable record. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Can we allow phones if cameras are covered or radios are disabled?

Only if the AO explicitly permits it and the approval states the constraints you will enforce and verify. Treat technical mitigations as conditions of an exception, not a substitute for the default prohibition. (NIST SP 800-53 Rev. 5 OSCAL JSON)

How do we handle third-party technicians who need to enter the restricted area?

Route them through the same entry control as employees: device storage outside the area by default, or a documented AO exception if there is a justified need. Keep visitor logs and any exception approvals with the engagement records. (NIST SP 800-53 Rev. 5 OSCAL JSON)

What evidence should we expect to show an auditor first?

Start with the scoped restricted-area list, the written prohibition and entry procedure, and the AO exception register with sample approvals. Then provide inspection logs, signage/photos, and training records to prove ongoing operation. (NIST SP 800-53 Rev. 5 OSCAL JSON)