AC-4(22): Access Only

AC-4(22): access only requirement shows up when your workforce (or admins) need to interact with systems in different security domains from a single device, but you cannot allow data to cross from one domain to another. This is common in regulated environments that segment domains by sensitivity, mission, customer, or contractual boundary, and still want operational efficiency for users and administrators.

The practical challenge is that “single device access” naturally creates temptation for shortcuts: copy/paste across sessions, shared clipboards, shared file systems, shared browsers, or dual-homing a workstation to multiple networks. Those shortcuts are exactly the information-flow paths AC-4(22) is meant to shut down. Your job as a Compliance Officer, CCO, or GRC lead is to translate the requirement into a design pattern your technical teams can implement consistently, then collect evidence that it actually blocks cross-domain flows.

This page gives requirement-level implementation guidance you can hand to control owners: who should own it, what to deploy, how to validate separation, what artifacts to retain, and what auditors typically challenge.

Regulatory text

Requirement (excerpt): “Provide access from a single device to computing platforms, applications, or data residing in multiple different security domains, while preventing information flow between the different security domains.” ¹

Operator meaning: You must support a user workflow where one endpoint can reach more than one security domain, and you must design that workflow so the endpoint cannot become a bridge that moves information between domains. The “preventing information flow” clause is the real bar: you need technical controls that block cross-domain transfer paths and evidence that those controls work as designed. ²

Plain-English interpretation (what AC-4(22) is really asking)

Think of AC-4(22) as “multi-domain access with enforced isolation.”

• Single device: one workstation/laptop/thin client used by a person.
• Multiple security domains: separate environments with different trust levels or sensitivity (for example: corporate IT vs. production; unclassified vs. controlled; customer A vs. customer B enclaves).
• Prevent information flow: stop the endpoint from transferring data between domains through any channel you can reasonably control (clipboard, file transfer, network routing, shared browser profiles, shared credentials, shared management tools).

A compliant implementation usually looks like one of these patterns:

• VDI / remote session per domain from a controlled endpoint, with clipboard/drive redirection disabled and strong session boundaries.
• Hardened jump host / bastion per domain, reachable only through a controlled access path, with logging and restrictions.
• Dedicated “multi-domain workstation” build that enforces separation (often with virtualization) and forbids cross-domain sharing features.

Who it applies to (entity and operational context)

AC-4(22) is most relevant when:

• You operate federal information systems or contractor systems handling federal data and have segmented environments that represent distinct security domains. ¹
• You have admins supporting multiple environments (for example: IT admins managing corporate and production; SOC analysts viewing multiple client environments; engineers working across regulated enclaves).
• You have third parties that require access to multiple domains from their endpoints, and you need a controlled access pattern as part of third-party risk management (TPRM) and contract requirements.

Typical operational triggers:

• “We need one laptop to access both networks.”
• “Our analysts must pivot between client enclaves.”
• “Admins need access to production but shouldn’t copy data back to corporate.”

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

1) Define your domains and the “no-flow” rules

Create (or confirm) a simple domain register:

• Domain name, business owner, data sensitivity, and boundary (network, identity, tenant, or enclave).
• Explicit prohibited flows (example: “No transfer from Domain High to Domain Low.”)
• Approved workflows (example: “User may view tickets in Low and administer servers in High via separate sessions.”)

Deliverable: “Security Domains & Allowed/Prohibited Flows” standard operating procedure (SOP) mapped to AC-4(22). ¹

2) Pick an implementation pattern and standardize it

Choose one pattern per use case; avoid one-off exceptions.

• VDI pattern: one VDI pool per domain, separated identity, restricted device redirection.
• Jump host pattern: bastion per domain, enforced through firewall rules and conditional access.
• Virtualization pattern: separate VM per domain, no shared clipboard, no shared folders, no bridging.

Decision filter (use this in design reviews):

• Can the endpoint route between domains (dual-homing)? If yes, redesign.
• Can a user copy text/files between domains (clipboard, local downloads)? If yes, harden.
• Is authentication shared across domains (same browser profile, same tokens)? If yes, separate.

3) Engineer the “prevention of information flow” controls

This is where audits usually focus. Implement controls that block transfer paths:

• Disable clipboard and drive redirection for remote sessions used to access higher domains.
• Block direct network paths between domains at the network layer; do not rely on “people won’t do it.”
• Separate identity contexts (distinct accounts/roles per domain; avoid standing access when feasible).
• Harden the endpoint: restrict local admin, restrict local storage where needed, enforce endpoint DLP settings if applicable to your environment.
• Log session activity: at least connection metadata; ideally session recordings for high-risk admin access if your governance model supports it.

Your technical control owners should document exactly which settings enforce flow prevention and where they are configured (VDI broker policy, jump host baseline, firewall ruleset, endpoint configuration management).

4) Implement approvals and access provisioning that match the domains

Access governance needs to reflect domain boundaries:

• Domain-specific access request and approval (domain owner or delegate).
• Time-bounded elevated access for administrative operations when practical.
• Third-party access via the same controlled pattern, with contract language that forbids bypass routes and requires use of the authorized access method.

5) Validate with tests that mirror real user behavior

Auditors will not accept “we think it’s blocked” if you have not tested. Minimum validation tests to run and record:

• Attempt clipboard copy/paste from Domain A session to Domain B session.
• Attempt file transfer via mapped drives, local downloads, browser uploads.
• Attempt to access Domain B network resources from within Domain A session.
• Attempt to authenticate to Domain B using Domain A credentials/tokens where applicable.

Capture results as evidence. Re-run tests after major changes to VDI/jump host policies, firewall segmentation, or endpoint baselines.

6) Make it assessable: assign ownership and recurring evidence

AC-4(22) fails most often as an “evidence gap,” not a pure technical gap. Track:

• Control owner (usually IAM, network security, or EUC/endpoint engineering, with GRC oversight).
• Evidence cadence ¹.
• Exceptions and compensating controls.

Daydream (or any GRC system you already run) becomes useful here: map AC-4(22) to a named owner, attach the SOP, link configuration snapshots and test results, and schedule recurring evidence tasks so assessment prep is routine instead of reactive. ¹

Required evidence and artifacts to retain

Keep evidence that proves both access and no-flow.

Governance artifacts

• AC-4(22) control narrative: scope, domains, pattern used, ownership.
• Domain register and allowed/prohibited flow matrix.
• Exceptions register with approvals and compensating controls.

Technical artifacts

• Architecture diagram showing domains, access path, and enforced boundaries.
• Configuration exports or screenshots:
  • VDI/session policies (clipboard/drive/device redirection settings)
  • Jump host baseline config and access rules
  • Firewall/segmentation rules preventing cross-domain routing
  • Conditional access / MFA policies where used for domain access
• Logging proof: sample logs showing session establishment and user identity.

Validation artifacts

• Test plan and test results for attempted cross-domain transfers.
• Change records tying control-impacting changes to re-validation.

Common exam/audit questions and hangups

Expect these questions and prepare short, evidence-backed answers:

1. “Define your security domains.” Provide the domain register and boundaries.
2. “Show me how information flow is prevented.” Walk through configs, not just policy.
3. “Can a workstation connect to both domains directly?” If yes, be ready to justify and show compensating controls.
4. “How do you prevent copy/paste and file transfer?” Demonstrate settings and test attempts.
5. “How do you know it stays enforced over time?” Provide recurring evidence and change-driven re-tests.

Frequent implementation mistakes (and how to avoid them)

• Mistake: Treating segmentation as a network-only problem. Users move data through remote session features and browsers. Fix: lock down redirection, downloads, and identity separation.
• Mistake: Dual-homing endpoints “temporarily.” Temporary becomes permanent. Fix: prohibit by standard and detect via endpoint/network controls.
• Mistake: Documenting intent instead of enforcement. A policy that says “no copying” does not meet “prevent information flow.” Fix: retain config evidence and test results.
• Mistake: One-off jump boxes with local tweaks. Drift kills you. Fix: baseline-as-code, standard images, and controlled change.
• Mistake: No clear control owner. Evidence will be missing at audit time. Fix: assign ownership and recurring evidence tasks. ¹

Enforcement context and risk implications

No public enforcement sources are provided for this specific enhancement in the supplied source catalog. Practically, AC-4(22) gaps increase the likelihood of cross-domain data spillage, unauthorized disclosure, and breach scope expansion after endpoint compromise. In assessments, the most common adverse outcome is a finding for insufficient technical enforcement or inability to produce evidence that flow prevention is real and repeatable. ²

A practical 30/60/90-day execution plan

Days 0–30: Stabilize scope and pick the pattern

• Name the AC-4(22) owner and backup.
• Inventory security domains and document prohibited flows.
• Select the standard access pattern per use case (VDI, jump host, virtualization).
• Identify and stop obvious bypass routes (dual-homing, shared admin accounts) via quick configuration changes or interim guardrails.

Days 31–60: Implement enforcement and logging

• Roll out hardened configurations (disable clipboard/drive redirection where required; enforce segmentation rules).
• Standardize builds (gold images, configuration management baselines).
• Implement or tune logging so you can answer “who accessed what domain, when, and how.”

Days 61–90: Validate and make it audit-ready

• Execute test cases that simulate real transfer attempts; capture results.
• Write the AC-4(22) procedure and evidence checklist; store artifacts centrally.
• Build recurring evidence tasks in your GRC workflow (Daydream or your existing platform) so the control stays “always ready,” not “ready when someone remembers.”

Frequently Asked Questions

Do I need a separate physical device for each security domain to meet AC-4(22)?

No. AC-4(22) explicitly allows a single device to access multiple domains, but you must prevent information flow between them. If your only practical way to prevent flow is separate devices for a specific high-risk scenario, document that as a design choice.

Does “prevent information flow” mean I must block all copy/paste and all file transfers?

You need to prevent flows between the different security domains in scope. In practice, that usually means blocking clipboard, drive mapping, and other redirection paths between domain sessions, then proving it with configuration evidence and tests.

Can I meet AC-4(22) with policies and user training alone?

No for most assessments. The requirement language calls for preventing information flow, which implies technical enforcement. Use policy and training as supporting controls, not your primary mechanism. ¹

How do third parties fit into AC-4(22)?

If a third party needs access to multiple domains, require them to use the same controlled access pattern (VDI/jump hosts) and prohibit unmanaged direct connectivity. Treat bypass routes as a contractual and technical control issue.

What evidence is most persuasive to auditors?

Configuration exports/screenshots that show flow-blocking settings, network rules that prevent cross-domain routing, and recorded test results where you attempted cross-domain transfer and it failed. Pair that with a domain register and a clear control narrative.

How should we handle exceptions when business teams demand “just this one time” cross-domain transfer?

Route exceptions through a formal process: define the data, direction of transfer, approval, method (for example, mediated transfer through an approved service), and expiration. Track it in an exceptions register and re-assess after the expiration.

Footnotes

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

2. NIST SP 800-53 Rev. 5