AC-4(4): Flow Control of Encrypted Information

AC-4(4) requires you to stop encrypted traffic from “slipping past” your required flow-control points (for example, boundary devices, inspection chokepoints, or routing policy enforcement) by enforcing a defined method that still applies controls to encrypted content and sessions. Operationalize it by inventorying encrypted flows, defining mandatory enforcement points, and implementing technical controls that prevent bypass. ¹

Key takeaways:

• AC-4(4) is about bypass prevention: encryption must not become a tunnel around your flow-control architecture. ¹
• You need named enforcement points plus technical guardrails that force encrypted traffic through them, not around them. ¹
• Assessors will ask for network evidence (diagrams, configs, logs) proving encrypted flows cannot route around controls. ¹

The ac-4(4): flow control of encrypted information requirement exists because encryption can unintentionally defeat your network and system flow controls. If your organization relies on firewalls, secure web gateways, data loss prevention (DLP), intrusion detection, segmentation, or boundary protections, encrypted channels can become “blind spots” or, worse, convenient tunnels that bypass those controls entirely.

AC-4(4) sits under Access Control’s Information Flow Enforcement (AC-4). Practically, it forces you to answer a simple operator question: “If a user, workload, third party, or system encrypts traffic, can it route around our required enforcement points?” If the answer is “maybe,” you do not have AC-4(4) nailed.

This page is written for a Compliance Officer, CCO, or GRC lead who needs to drive execution with network, cloud, and security engineering. You will find requirement-level interpretation, a step-by-step implementation procedure, the evidence you should retain for audits, and a practical phased execution plan. Control language is taken from NIST SP 800-53 Rev. 5. ²

Regulatory text

Control enhancement statement: “Prevent encrypted information from bypassing {{ insert: param, ac-04.04_odp.01 }} by {{ insert: param, ac-04.04_odp.02 }}.” ¹

How to read the placeholders (operator interpretation):

• The first placeholder is your defined flow-control mechanism(s) that encrypted information must not bypass. In real programs, this is typically a set of mandated enforcement points and policy checks (for example: boundary firewall clusters, segmentation gateways, zero trust policy enforcement points, egress controls, or inspection stacks).
• The second placeholder is the method you choose to prevent bypass. NIST does not force one technique in the excerpt you were given; it requires that you define a method and make it effective. ¹

What the operator must do: document the flow-control mechanisms that matter, identify encrypted flows that could evade them, and implement routing, policy, and technical controls that make bypass infeasible or detectable with a defined response.

Plain-English interpretation of the requirement

Encrypted traffic is not automatically “safe.” AC-4(4) treats encryption as a potential way to evade controls. Your job is to ensure that encrypted sessions still traverse the places where your organization enforces information flow rules (allow/deny, segmentation, egress restrictions, proxy requirements, inspection requirements, and monitoring requirements).

This is not a “decrypt everything” mandate. It is a “no hidden tunnels around policy” mandate. If you decide to decrypt some flows for inspection, that can be part of your method. If you decide to enforce strict path controls (forced proxy, service chaining, private connectivity, explicit routing constraints) without decryption, that can also be part of your method. The requirement is satisfied by preventing bypass of your defined mechanisms. ¹

Who it applies to (entity and operational context)

Entity scope (typical):

• Federal information systems.
• Contractor systems handling federal data. ¹

Operational contexts where AC-4(4) becomes “real” fast:

• Hybrid networks: on-prem to cloud, cloud-to-cloud, and SaaS access where TLS is default.
• Remote access and site connectivity: VPNs, SD-WAN, private links, and partner connections.
• Kubernetes and service-to-service encryption: mTLS service meshes that can route around centralized controls.
• Third party connectivity: managed service providers, integration partners, outsourced SOC tools, and data feeds that use encrypted channels.
• Developer and automation channels: CI/CD runners, infrastructure APIs, and secrets retrieval over encrypted protocols.

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

1) Name your “must-pass” flow-control points

Create a short list of enforcement points that define compliant flow control in your environment. Examples (choose what matches your architecture):

• Internet egress firewall / secure web gateway stack
• Cloud egress controls (NAT gateways + firewall policies)
• Segmentation gateways between zones (prod vs. corp vs. third party)
• Email security boundary
• Data transfer gateways (SFTP gateways, API gateways)
• Remote access termination points

Deliverable: “AC-4(4) Enforcement Points Register” (one page is fine) listing each enforcement point, owner, and what policy it enforces.

2) Inventory encrypted flows that matter

Focus on flows that could carry sensitive data or privileged operations:

• User web traffic (TLS)
• Service-to-service mTLS
• VPN/SD-WAN tunnels
• Database connections with TLS
• File transfer over encrypted protocols
• API calls to SaaS or third parties

Tip for speed: start with your existing network flow logs, firewall logs, cloud flow logs, and proxy logs. Your goal is not perfection; it’s identifying bypass-capable paths.

Deliverable: encrypted flow inventory with source zone, destination zone, protocol, and whether it currently traverses the defined enforcement points.

3) Identify bypass paths (the actual AC-4(4) gap)

For each flow, ask:

• Can this encrypted traffic route directly from a workload subnet to the internet without passing the egress stack?
• Can a site-to-site tunnel connect into a sensitive zone without passing segmentation controls?
• Can a workload in cloud A send encrypted data to cloud B outside your monitored path?
• Can third party remote tools establish encrypted outbound sessions that bypass your proxy and logging?

Deliverable: “Bypass Paths & Risk Decisions” table: flow, bypass condition, impact, planned fix, target owner.

4) Choose your bypass-prevention method(s) and document them

The requirement text expects you to define the method that prevents bypass. Common method categories:

• Forced path / routing enforcement: default routes, VPC route tables, UDRs, transit gateways, and firewall/service-chaining that makes the approved path the only path.
• Control-plane enforcement: deny creation of unapproved tunnels, deny direct internet egress from restricted subnets, require approved endpoints.
• Proxy enforcement: explicit proxy for user traffic and controlled egress for workloads.
• Selective decryption/inspection (where permitted): decrypt at a controlled point to apply content-based controls; re-encrypt after.
• Detection with automatic blocking: if bypass cannot be fully prevented in a legacy edge case, implement monitoring that detects the bypass attempt and blocks or isolates quickly, with documented risk acceptance.

Deliverable: “AC-4(4) Method Statement” tied directly to your named enforcement points. ¹

5) Implement technical guardrails

This is where engineering work happens. Your GRC job is to make it measurable and testable:

• Update routing so sensitive zones cannot egress directly.
• Add firewall rules that block direct outbound TLS except via approved proxies or egress gateways.
• Restrict who can create VPNs/tunnels and require security review for any new encrypted tunnel.
• For third party connections, require termination in a controlled zone, then route through segmentation gateways.
• Add continuous validation tests (automated where possible): attempt outbound 443 from a restricted subnet and prove it fails unless it uses the approved path.

Deliverable: change tickets, configuration baselines, and test results.

6) Validate with a repeatable test procedure

Create an “AC-4(4) validation” checklist:

• Pick representative subnets/zones.
• Attempt to establish encrypted sessions to external endpoints.
• Confirm traffic is blocked or forced through the enforcement point.
• Confirm logs exist at the enforcement point for encrypted session metadata (at minimum).

Deliverable: quarterly (or change-driven) test record plus evidence snapshots.

Required evidence and artifacts to retain

Assessors will not accept “we encrypt everything” as evidence. Keep artifacts that prove no bypass:

• Network and cloud architecture diagrams with enforcement points clearly marked.
• Data flow diagrams for sensitive systems and third party connections.
• Routing tables / route policies showing forced path controls.
• Firewall / security group / NACL / policy excerpts showing denied bypass and allowed approved paths.
• Proxy policies and egress allowlists (where used).
• Configuration management records and change approvals for enforcement controls.
• Validation test procedure and the latest execution results.
• Exceptions register: any approved bypass with compensating controls and approval.

If you run Daydream for control operations, map AC-4(4) to a control owner, an implementation procedure, and recurring evidence artifacts so you can produce the above on demand. ¹

Common exam/audit questions and hangups

Common questions you should be ready to answer with evidence:

• “What are your defined flow-control mechanisms that encrypted traffic must not bypass?” ¹
• “Show me how you prevent direct-to-internet TLS from restricted workloads.”
• “How do you control and approve encrypted tunnels (VPN, SD-WAN, third party)?”
• “What happens if a team deploys a new encrypted service that creates a new egress path?”
• “How do you validate this control after network changes?”

Hangups that slow audits:

• Diagrams that do not match reality.
• Controls implemented in one environment (on-prem) but not mirrored in cloud.
• “Tribal knowledge” enforcement points not captured in policy or runbooks.

Frequent implementation mistakes and how to avoid them

1. Treating encryption as the control.
   Avoidance: AC-4(4) is about flow control. Require evidence of routing and policy enforcement, not just TLS config.

2. Allowing “temporary” bypasses that become permanent.
   Avoidance: enforce time-bound exceptions with compensating controls and review triggers tied to network changes.

3. Ignoring east-west encrypted traffic.
   Avoidance: include service-to-service mTLS flows in scope. If you rely on segmentation, prove mTLS does not create a route around segmentation gateways.

4. Over-scoping decryption.
   Avoidance: document where you decrypt (if you do), why, and what data types are excluded. AC-4(4) can be met without blanket decryption if bypass is prevented.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement. The practical risk is still clear: if encrypted channels bypass inspection and egress controls, you create unmonitored exfiltration paths and reduce your ability to enforce segmentation and data handling rules. That risk shows up during incident response as “we can’t tell what left” and during assessments as “controls are not consistently enforced for encrypted flows.”

Practical execution plan (30/60/90-day style, without hard duration claims)

First 30 days (Immediate)

• Assign an AC-4(4) control owner across network and cloud.
• Define and publish your enforcement points register.
• Pull an initial encrypted flow inventory from available logs.
• Identify obvious bypass paths (direct egress, unmanaged tunnels) and open remediation work items.

Days 31–60 (Near-term)

• Implement forced-path routing for the highest-risk zones.
• Add baseline firewall rules that prevent direct outbound encrypted traffic where it violates policy.
• Stand up an AC-4(4) validation test and run it once end-to-end.
• Establish an exceptions workflow for any required encrypted bypass with approvals and compensating controls.

Days 61–90 (Operationalize)

• Expand to remaining environments (other clouds, subsidiaries, labs).
• Convert the validation into a recurring control activity (change-driven plus periodic).
• Tighten third party connectivity patterns: terminate, segment, monitor, and log.
• Package evidence in a single place (for example, a control record in Daydream) so audits pull from live artifacts instead of email threads. ¹

Frequently Asked Questions

Do we have to decrypt TLS to meet ac-4(4): flow control of encrypted information requirement?

No. The requirement is to prevent encrypted information from bypassing your defined flow-control mechanisms, and your method can be routing and policy enforcement without decryption. If you do decrypt, document where and why. ¹

What counts as a “bypass” in practice?

Any encrypted path that allows data or commands to move around your mandated enforcement points, such as direct internet egress from restricted subnets or an unmanaged VPN into a sensitive zone. Prove the approved path is mandatory. ¹

How do we handle third party encrypted connections (MSPs, integrations, partners)?

Require termination in a controlled zone and enforce segmentation and egress policies from that termination point. Keep an inventory of third party tunnels and documented approvals tied to your enforcement points. ¹

What evidence is strongest for auditors?

Config and routing evidence that shows the only viable route passes through your enforcement points, plus a repeatable validation test record. Diagrams help, but assessors want configs and results. ¹

We use a service mesh with mTLS. How do we show compliance?

Map mesh traffic to zones and prove that mesh routing cannot cross prohibited boundaries without passing segmentation controls. Where the mesh can cross boundaries, enforce policy at the boundary and test it. ¹

Can we accept an exception if a legacy system needs a direct encrypted tunnel?

Yes, if your governance allows it. Record the exception, document compensating controls (extra monitoring, restricted endpoints, limited access), and set a review trigger based on architecture changes or reauthorization cycles. ¹

Footnotes

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

2. NIST SP 800-53 Rev. 5