SC-7(8): Route Traffic to Authenticated Proxy Servers

SC-7(8) requires you to force defined classes of network traffic (typically web and other egress/ingress traffic) through authenticated proxy servers at your managed network interfaces, so users, devices, and services cannot bypass inspection and policy enforcement. Operationalize it by defining in-scope traffic, placing proxies at boundary choke points, enforcing authentication, and retaining configuration and log evidence. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Key takeaways:

• Define exactly which traffic must be proxied, then make bypass technically impossible at managed interfaces. (NIST SP 800-53 Rev. 5 OSCAL JSON)
• “Authenticated proxy” means identity-backed access to the proxy service (user, device, or service identity), not just an IP allowlist. (NIST SP 800-53 Rev. 5 OSCAL JSON)
• Audit success depends on evidence: routing/ACLs, proxy auth configuration, and logs proving traffic traverses the proxy. (NIST SP 800-53 Rev. 5 OSCAL JSON)
• Assign a control owner and a recurring evidence cadence so the control stays “true” after network changes. (NIST SP 800-53 Rev. 5 OSCAL JSON)

The sc-7(8): route traffic to authenticated proxy servers requirement is a boundary protection enhancement under NIST SP 800-53 that targets a common failure mode: “shadow paths” where users, workloads, or third-party connections reach external destinations without going through your security stack. Proxies are a practical choke point because they centralize policy decisions (allow/deny), identity (who/what is making the request), and telemetry (what was accessed, from where, and when).

For a CCO or GRC lead, the fastest path is to treat SC-7(8) as a routing and enforcement requirement, not a paperwork exercise. You need three things: (1) a scoped definition of the traffic types and directions that must be proxied, (2) technical controls at managed interfaces that force that traffic through authenticated proxies, and (3) durable evidence that the design works and stays working after changes. (NIST SP 800-53 Rev. 5 OSCAL JSON)

This page gives requirement-level implementation guidance you can hand to network/security engineering, plus the artifacts you should collect for an assessor.

Regulatory text

“Route {{ insert: param, sc-07.08_odp.01 }} to {{ insert: param, sc-07.08_odp.02 }} through authenticated proxy servers at managed interfaces.” (NIST SP 800-53 Rev. 5 OSCAL JSON)

Operator interpretation: you must identify the relevant traffic flows (the “{{…odp…}}” organization-defined parameters) and then enforce routing so those flows traverse proxy servers that require authentication, placed at interfaces you manage (for example, internet egress points, partner interconnects, or controlled network segments). The key operational test is simple: if a user/device/workload tries to send in-scope traffic directly, does the network block it unless it goes through the authenticated proxy? (NIST SP 800-53 Rev. 5 OSCAL JSON)

Plain-English interpretation of the requirement

SC-7(8) expects you to:

• Centralize access for specific network traffic through proxies.
• Tie traffic to an identity by requiring authentication to use the proxy.
• Enforce at managed interfaces so routing and policy cannot be bypassed by local configuration, alternate DNS, direct IP access, or ad hoc tunnels. (NIST SP 800-53 Rev. 5 OSCAL JSON)

A proxy can be “forward” (client-to-internet egress), “reverse” (internet-to-app ingress), or service-specific (for example, secure web gateway for HTTP/S). The requirement does not force a particular product. It forces an outcome: authenticated proxy traversal at controlled boundary points. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Who it applies to

Entity types

• Federal information systems.
• Contractor systems handling federal data (including many regulated contractor environments aligning to NIST baselines). (NIST SP 800-53 Rev. 5 OSCAL JSON)

Operational context (where assessors look)

• Enterprise internet egress from corporate networks and cloud VPC/VNETs.
• Administrative access paths (jump hosts, management networks, privileged sessions).
• Third-party connectivity (partners, MSPs, SaaS admin consoles, vendor support tunnels) where traffic could bypass standard inspection.
• Hybrid networks with split-tunnel VPN, remote access, and multiple egress points. (NIST SP 800-53 Rev. 5 OSCAL JSON)

If your environment has multiple “ways out,” SC-7(8) is about making the proxy the only way out for the traffic you scope in.

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

1) Assign ownership and set scope (your “ODP” decisions)

1. Name a control owner (network security or security engineering is typical) and a GRC contact accountable for evidence quality.
2. Define sc-07.08_odp.01 and sc-07.08_odp.02 in plain language:
   • Traffic class: HTTP/S egress, all web traffic, outbound admin traffic, API calls from workloads, ingress to public apps, etc.
   • Source and destination boundaries: user subnets, data center segments, cloud workloads, external networks, and high-risk segments.
3. Write a scope statement that an engineer can implement without interpretation. Avoid “all traffic” unless you can enforce it across all protocols and networks. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Deliverable: a one-page SC-7(8) implementation standard with a traffic matrix.

2) Map current traffic flows and find bypass routes

1. Inventory managed interfaces: firewalls, gateways, cloud route tables, SD-WAN edges, VPN concentrators, direct connects.
2. Identify egress points (including “temporary” ones like test VPC NATs or developer VPN egress).
3. Validate whether clients/workloads can:
   • Reach the internet directly without proxy configuration.
   • Use alternate DNS resolvers or direct IPs to bypass URL controls.
   • Establish tunnels that avoid proxy inspection. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Deliverable: network egress/ingress diagram annotated with enforced choke points.

3) Implement authenticated proxy enforcement at the boundary

Use a pattern that matches your environment:

Pattern A: Explicit proxy with enforced egress controls

• Configure endpoints/workloads to use the proxy (PAC/WPAD, agent, MDM profile, or application config).
• On boundary firewalls and cloud egress controls, block direct outbound traffic for the scoped ports/protocols except from proxy IPs.
• Require authentication to the proxy (directory-backed users, device certificates, workload identity, or service accounts). (NIST SP 800-53 Rev. 5 OSCAL JSON)

Pattern B: Transparent/intercept proxy at a managed interface

• Redirect in-scope traffic to the proxy at the network boundary.
• Still require authentication (for example, device identity, user auth via integrated mechanisms, or mutually authenticated session models supported by your proxy architecture).
• Control exceptions tightly and document them. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Pattern C: Reverse proxy for inbound application access

• Place a reverse proxy/WAF in front of in-scope applications.
• Require authenticated access paths where appropriate (for example, admin portals, partner access, or sensitive apps).
• Ensure direct-to-origin access is blocked (security groups, firewall rules, private origins). (NIST SP 800-53 Rev. 5 OSCAL JSON)

4) Define and govern exceptions (because you will have them)

Common exceptions: OS update endpoints, certificate revocation, specific SaaS endpoints, non-HTTP protocols, legacy systems, and break-glass scenarios.

Your exception process should require:

• Business justification and scope (system, protocol, destination).
• Compensating controls (additional monitoring, restricted destinations, time-bound approvals).
• An expiry/review trigger tied to change management. (NIST SP 800-53 Rev. 5 OSCAL JSON)

5) Prove it works with tests that match the requirement

Run repeatable tests from representative segments:

• Attempt direct internet access from a standard endpoint with proxy disabled. Expect failure.
• Attempt access through the proxy without authentication. Expect failure.
• Attempt access through the proxy with valid identity. Expect success and logged identity context.
• Validate cloud workload egress cannot bypass proxy via alternate routes/NATs. (NIST SP 800-53 Rev. 5 OSCAL JSON)

6) Operationalize: monitoring, change control hooks, recurring evidence

• Alert on direct-to-internet flows from networks that should be proxy-only.
• Review proxy auth failures and unusual destinations.
• Tie network changes (new VPCs, new egress gateways, new VPNs) to a required SC-7(8) check. (NIST SP 800-53 Rev. 5 OSCAL JSON)

If you use Daydream for control operations, map SC-7(8) to a named owner, a written procedure, and recurring evidence artifacts so assessors see an auditable, repeatable control instead of one-time engineering work. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Required evidence and artifacts to retain

Keep artifacts that show design, enforcement, and operation:

Design evidence

• SC-7(8) scope statement with defined traffic classes and boundaries. (NIST SP 800-53 Rev. 5 OSCAL JSON)
• Network diagrams showing managed interfaces and proxy choke points.
• Proxy architecture decision record (explicit vs transparent vs reverse proxy, and why).

Enforcement evidence

• Firewall/ACL rule exports showing only proxy servers can egress for in-scope traffic.
• Cloud route table/NACL/security group evidence enforcing proxy egress paths.
• Proxy configuration screenshots/exports showing authentication is required (identity provider integration, certificate requirements, service account model). (NIST SP 800-53 Rev. 5 OSCAL JSON)

Operational evidence

• Proxy logs demonstrating authenticated sessions and traffic metadata.
• Monitoring/alert rules for bypass attempts.
• Exception register with approvals and expirations.
• Change management samples showing SC-7(8) checks for new networks/egress. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Common exam/audit questions and hangups

Assessors and auditors usually press on these points:

1. “What traffic is in scope?” If you cannot crisply define sc-07.08_odp.01 and sc-07.08_odp.02, the control becomes untestable. (NIST SP 800-53 Rev. 5 OSCAL JSON)
2. “Show me you can’t bypass it.” A proxy setting in a browser is not enforcement. They will look for boundary rules that prevent direct paths.
3. “How is the proxy authenticated?” IP allowlists and shared secrets rarely satisfy the intent because they do not bind activity to an identity.
4. “Are cloud workloads included?” Many programs fail by covering end-user egress while leaving workload egress unmanaged.
5. “How do you handle exceptions?” Undocumented exceptions are treated as control failures, not engineering realities. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails SC-7(8)	Fix
Relying on endpoint proxy settings only	Users/admins/workloads can disable or bypass	Enforce at managed interfaces with firewall/route controls. (NIST SP 800-53 Rev. 5 OSCAL JSON)
“Authenticated” proxy interpreted as source IP allowlist	No user/device/service identity	Integrate with an IdP, device certs, or workload identity; log the principal. (NIST SP 800-53 Rev. 5 OSCAL JSON)
Multiple uncontrolled egress points	Unavoidable bypass paths	Reduce egress, document choke points, block direct routes everywhere else.
Exceptions handled by email	No traceability, no expiry	Maintain an exception register with owner, scope, compensating controls, and review triggers.
No recurring evidence	Control drifts after network changes	Establish recurring exports/log pulls and change-control gates. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not cite enforcement actions.

From a risk standpoint, SC-7(8) reduces:

• Data exfiltration paths that bypass inspection.
• Malware command-and-control over standard web ports.
• Accountability gaps where you cannot tie outbound access to a user, device, or workload identity.
• Third-party access routes that sit outside your normal monitoring and policy stack. (NIST SP 800-53 Rev. 5 OSCAL JSON)

A practical 30/60/90-day execution plan

First 30 days (stabilize scope + stop easy bypass)

• Assign control owner and publish the SC-7(8) scope statement (traffic classes and boundaries). (NIST SP 800-53 Rev. 5 OSCAL JSON)
• Identify all managed interfaces and egress points, including cloud NATs and SD-WAN exits.
• Pick the enforcement pattern (explicit, transparent, reverse proxy) per network segment.
• Implement boundary blocks for the most common bypass path: direct web egress that does not originate from the proxy.

Next 60 days (expand enforcement + implement authentication cleanly)

• Roll out proxy authentication integrated with enterprise identity for users and device identity for managed endpoints. (NIST SP 800-53 Rev. 5 OSCAL JSON)
• Extend controls to cloud workload egress where applicable.
• Stand up an exception workflow and register; migrate existing “special cases” into it.
• Build standard test scripts and store test outputs as evidence.

By 90 days (operate the control like a program)

• Add monitoring for direct-to-internet flows from in-scope networks and alert triage runbooks.
• Add change-control gates for new networks, new VPNs, and new egress routes.
• Produce an assessor-ready evidence package: diagrams, rules, configs, logs, exceptions, and testing results. (NIST SP 800-53 Rev. 5 OSCAL JSON)
• In Daydream (or your GRC system), map SC-7(8) to owner, procedure, and recurring evidence tasks so the control remains audit-ready after reorganizations and network changes. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Frequently Asked Questions

Does SC-7(8) require a secure web gateway (SWG), or will any proxy work?

The requirement is outcome-based: route defined traffic through authenticated proxy servers at managed interfaces. An SWG is a common implementation, but the key is enforced routing plus authentication and logs. (NIST SP 800-53 Rev. 5 OSCAL JSON)

What does “authenticated proxy” mean for machine-to-machine traffic?

Use workload identity patterns supported by your proxy stack, such as mutual TLS with client certificates, service accounts, or identity-aware proxy mechanisms. Document the identity model and show logs that tie requests to that identity. (NIST SP 800-53 Rev. 5 OSCAL JSON)

We have remote users on VPN with split tunneling. Can we still meet SC-7(8)?

Yes, but you need to ensure in-scope traffic still traverses an authenticated proxy and cannot go direct. Split tunneling often creates bypass routes, so you must enforce proxy-only egress for scoped traffic or adjust the remote access design. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Is blocking direct outbound 80/443 enough evidence?

Blocking is necessary but rarely sufficient by itself. Pair it with proxy authentication configuration evidence and proxy logs proving that the routed traffic is actually traversing the proxy under an authenticated context. (NIST SP 800-53 Rev. 5 OSCAL JSON)

How should we handle exceptions like OS updates or certificate revocation endpoints?

Put them in a formal exception register with scoped destinations, compensating controls, and an expiry or review trigger. Keep firewall rules as narrow as possible and retain approvals and rule evidence. (NIST SP 800-53 Rev. 5 OSCAL JSON)

What’s the fastest way to get audit-ready if engineering says this will take time?

Start by scoping the traffic and enforcing a single choke point for the highest-risk segments, then expand. In parallel, build the evidence package: diagrams, current rules, and a documented plan mapped to an owner and recurring evidence tasks. (NIST SP 800-53 Rev. 5 OSCAL JSON)