CA-3(4): Connections to Public Networks

CA-3(4): Connections to Public Networks requires you to explicitly authorize, document, and technically control any system connection that crosses into public networks (for example, internet-based links), so the connection is known, risk-assessed, and governed. Operationalize it by inventorying all public network pathways, approving them through a formal connection process, and retaining evidence that controls and approvals match reality. ¹

Key takeaways:

• Maintain an authoritative inventory of all system connections that traverse public networks, including third-party pathways.
• Require formal approval, defined security conditions, and technical enforcement (segmentation, boundary protections, monitoring) for each connection.
• Keep assessment-ready evidence: diagrams, approvals, configurations, and recurring review records tied to each connection.

The ca-3(4): connections to public networks requirement is a governance control with a technical backbone: you must know which systems connect through public networks, who approved those connections, what security conditions apply, and how those conditions are enforced in production. In practice, this control fails when “the internet” is treated as a default transport rather than a regulated boundary, or when network diagrams and approvals do not match the actual paths traffic takes (especially through cloud services, SaaS, CDNs, managed security providers, and other third parties).

For a Compliance Officer, CCO, or GRC lead, the fastest path to operationalizing CA-3(4) is to treat every public-network connection as an auditable object with an owner, purpose, authorization record, security requirements, and an evidence set that can be refreshed on a recurring cadence. You are not trying to prove that connections exist; you are trying to prove that connections are controlled, approved, and continuously aligned with your architecture and risk posture. This page gives you requirement-level implementation guidance you can execute quickly, with the artifacts auditors ask for and the failure modes that create repeat findings. ¹

Regulatory text

Control reference: CA-3(4) “Connections to Public Networks.” ²

Provided excerpt: “NIST SP 800-53 control CA-3.4.” ²

Operator interpretation of the excerpt (what you must do):

• Treat connections that traverse public networks as explicitly governed system interconnections that require authorization and defined security conditions, not ad hoc engineering choices. ¹
• Be able to show, on demand, (1) what public-network connections exist, (2) who authorized them, (3) which security requirements apply, and (4) evidence that controls are implemented and operating for those connections. ¹

Practical compliance framing: CA-3(4) is where “architecture reality” meets “authorization reality.” If you cannot reconcile diagrams, configs, and approvals for internet-traversing connections, expect findings.

Plain-English interpretation (what CA-3(4) expects)

You must identify, approve, and control every connection where your system communicates over a public network. “Public network” usually means the internet, but it also includes any network you do not control end-to-end. The control expectation is that public-network connectivity is:

1. Known (complete inventory),
2. Authorized (documented decision),
3. Constrained (security conditions are specified), and
4. Enforced (technical controls match the stated conditions).
   ¹

Who it applies to

Entity scope

• Federal information systems. ¹
• Contractor systems handling federal data, including cloud-hosted environments and managed services that support federal workloads. ¹

Operational context (where it shows up)

• Cloud environments with internet-facing endpoints, public load balancers, API gateways, and remote administration paths.
• Site-to-site VPNs and remote access that use the internet as transport.
• Third-party connectivity: managed SOC tools, MSSPs, payment processors, SaaS platforms, and data exchanges where traffic traverses public networks.
• Hybrid architectures where “internal” traffic hairpins through the internet (common with SaaS, SD-WAN, and misconfigured routing).

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

Use this as a build sheet for your CA-3(4) operating procedure.

Step 1: Define what counts as a “public network connection” in your environment

Create a one-page definition and boundary statement that covers:

• Internet ingress/egress (including NAT egress paths).
• Public endpoints (DNS names, public IPs, CDN front doors).
• Remote admin paths (SSH/RDP/bastions, management planes).
• Third-party connections that traverse public networks (even if “encrypted”). Document where you will record these connections (your CMDB, architecture repo, GRC tool, or a controlled spreadsheet). ¹

Step 2: Build (or correct) the authoritative connection inventory

For each system in scope, inventory every public-network pathway and record:

• Connection name and unique ID
• Source system/component and owner
• Destination (service, third party, endpoint)
• Directionality (inbound, outbound, bidirectional)
• Data types involved (high-level categories)
• Authentication method (human, service-to-service)
• Transport/security mechanism (for example, TLS, VPN, private link fallback if any)
• Where enforcement happens (firewall, security group, proxy, API gateway)
• Logging/monitoring source (SIEM, flow logs, WAF logs)
• Approval record reference (ticket/change/request ID) This is the core artifact auditors will map everything else to. ¹

Step 3: Implement a formal authorization workflow for public-network connections

Stand up a lightweight but enforceable workflow:

• Requester (system owner) submits purpose, endpoints, data category, and proposed controls.
• Security/architecture review validates boundary protections, authentication, and monitoring.
• GRC/risk review confirms the connection aligns with risk acceptance and system authorization conditions.
• Approval is recorded with explicit conditions (allowed ports/protocols, allowed sources, required logging, required encryption, required change control).
• Implementation occurs through standard change management with a configuration reference (IaC commit, firewall rule ID, cloud security group ID). Tie the workflow to your change process so no one can “just open a port” without an auditable decision. ¹

Step 4: Enforce technical controls at the boundary

Translate approval conditions into concrete enforcement:

• Restrict ingress/egress to required endpoints and ports only.
• Require strong authentication for remote access and admin paths.
• Use segmentation so internet-facing components do not provide direct lateral movement into sensitive segments.
• Centralize logging for boundary devices and cloud controls that govern internet exposure. Your evidence should show the control intent (approval conditions) and the technical reality (configs) are consistent. ¹

Step 5: Monitor and re-validate connections on a recurring basis

Build recurring checks that catch drift:

• Detect new internet-facing assets and compare them to the authorized inventory.
• Alert on firewall/security group rule changes that broaden exposure.
• Review third-party connectivity and confirm endpoints, certificates/keys, and logging remain intact.
• Reconfirm owners and business purpose for each connection; retire connections with no current need. From an audit standpoint, this is how you show the control operates continuously, not as a one-time documentation exercise. ¹

Step 6: Operationalize ownership and evidence refresh (make it sustainable)

Assign a control owner (usually security architecture or network security) and define RACI:

• System owners own justification and data flows.
• Network/cloud security owns enforcement.
• GRC owns evidence quality and assessment readiness. Tools like Daydream fit well here when you need a single requirement-to-evidence map across many systems and third parties, plus a repeatable evidence request and refresh workflow that does not rely on heroics.

Required evidence and artifacts to retain

Keep evidence in a way that a reviewer can trace “connection → approval → enforcement → monitoring.”

Minimum evidence set (practical):

• Public network connection inventory (authoritative list) ¹
• System/network diagrams that show internet boundaries and trust zones ¹
• Approved connection requests (tickets/changes) with stated security conditions ¹
• Firewall/security group/WAF/proxy configuration extracts or rule IDs mapped to each approved connection ¹
• Logging/monitoring proof: sample events, log source onboarding confirmation, or SIEM data source list for boundary telemetry ¹
• Recurring review records: connection recertification notes, exception/risk acceptance where needed, and decommission evidence for retired connections ¹

Common exam/audit questions and hangups

Auditors and assessors tend to press on completeness and traceability.

Questions you should be ready for

• “Show me every internet-facing endpoint for System X and the approval for each.” ¹
• “How do you prevent engineers from creating new public exposure outside the process?” ¹
• “Prove that your inventory matches production. What detects drift?” ¹
• “Which third parties connect over public networks, and how are those connections governed?” ¹

Typical hangups

• Cloud accounts and subscriptions without centralized visibility.
• Shadow IT SaaS integrations that bypass network controls.
• “Temporary” firewall rules that become permanent.

Frequent implementation mistakes (and how to avoid them)

1. Inventory is a diagram, not a control. A Visio that is never reconciled to config will fail. Fix: make the inventory a living register tied to rule IDs, IaC commits, and change records. ¹

2. Treating encryption as authorization. TLS/VPN reduces exposure but does not replace approval, scoping, and monitoring. Fix: require a formal connection authorization even for encrypted tunnels. ¹

3. Forgetting outbound exposure. Many teams only track inbound internet-facing services. Fix: include outbound internet egress, third-party APIs, and data exports in the inventory. ¹

4. No owner, no lifecycle. Orphaned connections persist after system changes. Fix: require an owner field and periodic recertification; close connections with no current business purpose. ¹

5. Exceptions without boundaries. “Approved exception” becomes a blanket permission. Fix: document time bounds, compensating controls, and explicit scoping in the approval record. ¹

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for CA-3(4), so you should treat enforcement expectations as assessment-driven rather than case-driven here. ¹

Risk-wise, uncontrolled public network connections increase the likelihood of unauthorized access paths, data exfiltration routes, and incident scope expansion. CA-3(4) reduces that risk by making connectivity explicit, reviewable, and technically constrained. ¹

A practical execution plan (30/60/90-day)

You asked for speed. Use phased delivery without promising fixed outcomes.

First 30 days (stabilize and inventory)

• Name a CA-3(4) control owner and publish the “public network connection” definition for your environment. ¹
• Build the initial connection inventory for your highest-impact systems and critical third-party pathways. ¹
• Require that new public network connections go through a single request path (ticket template). ¹

By 60 days (authorize and enforce consistently)

• Backfill approvals for existing connections, prioritizing internet-exposed services and admin access paths. ¹
• Map each approved connection to an enforcement point (firewall/WAF/security groups/proxy) and collect configuration evidence. ¹
• Centralize boundary logging sources and confirm you can retrieve logs for a sampled connection end-to-end. ¹

By 90 days (operate and prove control effectiveness)

• Implement drift detection: identify new exposures and reconcile to the authorized inventory. ¹
• Establish recurring recertification for connections, including third-party connections, and document outcomes (renew, restrict, retire, accept risk). ¹
• In Daydream, map CA-3(4) to the control owner, procedure, and recurring evidence artifacts so assessments do not require rebuilding context each time. ¹

Frequently Asked Questions

Does CA-3(4) apply if we only have outbound internet access and no inbound services?

Yes. Outbound connections still traverse public networks and can create data exfiltration and command-and-control paths. Track, approve, and constrain outbound egress the same way you do inbound exposure. ¹

Are SaaS integrations “connections to public networks” even if they use HTTPS?

Usually, yes, because the traffic still traverses a public network. Record the integration endpoints, data categories, authentication method, and monitoring approach, then authorize it with explicit conditions. ¹

What evidence is strongest for auditors: screenshots, exports, or IaC?

Prefer immutable or reproducible evidence such as IaC commits, policy/rule exports, and change tickets that map to specific rule identifiers. Screenshots help for point-in-time support but are harder to validate at scale. ¹

How do we handle third-party connections managed by the third party (for example, a managed SOC tool)?

Treat the connection as a governed interconnection: document endpoints, auth, logging, and the approval conditions you require. Where you cannot directly configure controls, retain third-party attestations and contractual/security addendum terms that define boundary and monitoring expectations. ¹

We discover an unauthorized internet-facing endpoint. What’s the compliant response?

Contain exposure through change control (restrict or remove access), document the incident as a control failure, then either retroactively authorize with risk acceptance and remediation tasks or decommission the endpoint. Update the inventory so the “known connections” set becomes accurate again. ¹

Can we meet CA-3(4) without a formal “interconnection agreement” document?

You can meet the intent if your authorization workflow captures the same elements: purpose, parties, endpoints, security conditions, and approvals, plus evidence of enforcement and monitoring. If your program already uses interconnection agreements, you can attach them to the same record. ¹

Footnotes

1. NIST SP 800-53 Rev. 5

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