SC-7(18): Fail Secure

SC-7(18) requires you to design and configure boundary protection devices (firewalls, gateways, WAFs, proxies, VPN concentrators, cloud security controls) so that if they fail, they fail closed or otherwise prevent traffic from bypassing enforcement. Operationalize it by defining “secure fail states,” enforcing default-deny behavior, and testing failure modes with retained evidence. ¹

Key takeaways:

• Define and document secure failure behavior for each boundary control (fail closed, bypass disabled, default deny). ¹
• Engineer redundancy and routing so a device outage does not create an unfiltered path to protected networks. ¹
• Test failure scenarios (power loss, crash, link failure, HA split-brain) and keep results as assessment-ready evidence. ¹

The sc-7(18): fail secure requirement is about a specific bad day scenario: your boundary protection device fails, and your environment silently becomes more permissive than your policy. NIST’s intent is straightforward: a failure of a boundary control must not create an unsecure state where traffic can flow without the intended inspection, filtering, segmentation, or authentication. ¹

For a Compliance Officer, CCO, or GRC lead, the fastest way to operationalize SC-7(18) is to treat “failure modes” as part of boundary control design, not an engineering afterthought. That means you (1) enumerate the boundary devices and the trust boundaries they enforce, (2) specify what “secure” means when each device is degraded, rebooting, or offline, (3) implement configurations and architectures that default to deny, and (4) prove it with repeatable tests and change-controlled evidence.

This page is written for operators who need to pass an assessment and reduce real exposure. You’ll find step-by-step implementation guidance, evidence to retain, common audit hangups, and a practical execution plan you can hand to network, security engineering, and cloud platform teams.

Regulatory text

Requirement (verbatim excerpt): “Prevent systems from entering unsecure states in the event of an operational failure of a boundary protection device.” ¹

What the operator must do: Ensure your network and cloud boundaries do not “open up” if a boundary control fails. In practice, you need documented secure fail states (typically default-deny), architectures that avoid unfiltered bypass paths, and testing that demonstrates real failure conditions do not permit prohibited traffic. ¹

Plain-English interpretation (what SC-7(18) means on the ground)

A boundary protection device is any control that enforces a trust boundary: internet edge firewalls, internal segmentation firewalls, secure web gateways, email security gateways, IDS/IPS inline devices, WAFs, reverse proxies, VPN concentrators, ZTNA gateways, and cloud equivalents (for example, security groups, NACLs, gateway firewalls, managed WAF). SC-7(18) expects that if one of those devices crashes, loses power, loses links, or experiences an HA fault, your environment does not default to “allow” or “bypass.” ¹

A good mental model for audits: your “most restrictive intended policy” must still hold during failure, even if availability degrades.

Who it applies to (entity and operational context)

SC-7(18) is relevant anywhere you claim conformance to NIST SP 800-53 Rev. 5, including:

• Federal information systems with defined authorization boundaries. ²
• Contractor systems handling federal data where 800-53 controls are flowed down through contracts, ATO requirements, or system security plans. ²

Operationally, it applies to:

• Internet ingress/egress chokepoints
• Inter-VPC/VNet and inter-segment boundaries
• Third-party connectivity boundaries (MPLS, SD-WAN, partner links)
• Remote access boundaries (VPN, ZTNA)
• High-risk management plane boundaries (admin networks, bastions)

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

Use this as your implementation runbook.

1) Define scope: list boundary protection devices and enforced boundaries

Create an inventory that maps:

• Device/control name and type (firewall, WAF, proxy, cloud firewall policy)
• Location in the data flow (internet edge, DC core, cloud perimeter, east-west)
• The trust boundary it enforces (public-to-private, user-to-prod, partner-to-internal)
• Owner team and on-call group

Deliverable: “Boundary Protection Inventory & Trust Boundary Map” (diagram plus table).

2) Define “secure fail state” per boundary (write it down)

For each boundary, specify the required behavior during failure modes. Common secure definitions:

• Fail closed / default deny: If the device cannot enforce policy, traffic is blocked.
• Bypass disabled: Hardware bypass (if present) is off unless explicitly approved for safety reasons.
• Known-safe degradation: Only explicitly approved emergency flows remain allowed, with documented rationale and compensating monitoring.

Also define failure modes you care about:

• Power loss
• Process crash/reboot
• Interface/link down
• HA failover event
• HA split-brain / asymmetric routing
• Cloud control-plane errors that detach policies

Deliverable: “SC-7(18) Fail Secure Standard” (one page plus an appendix per boundary type).

3) Engineer architecture to eliminate “unfiltered bypass paths”

This is where many programs fail: engineers configure devices correctly, but routing and HA create a bypass.

Patterns that typically meet intent:

• Redundant enforcement points with stateful failover or active/active plus consistent policy.
• Default-deny at multiple layers (for example, subnet ACLs plus firewall policy), so one control failure does not remove all enforcement.
• Deterministic routing so return paths do not skip inspection.

Patterns that commonly violate intent:

• A “temporary” route that sends traffic around the firewall during outages.
• L2/L3 designs where a failed inline device falls back to bridging/forwarding.
• Cloud environments where security groups are permissive because “the appliance does inspection.”

Deliverable: Approved reference architectures for edge and segmentation.

4) Configure devices to fail securely (config-level controls)

Examples of concrete configuration expectations you can verify:

• Default deny rules exist and are last in order.
• HA pair behavior is defined: which node is active, how failover occurs, and how policy sync is validated.
• Bypass ports (if present) are governed: disabled by default, break-glass only with approval and time limit.
• Management interfaces are separated and do not become transit paths.

Deliverable: Configuration baselines (golden configs) and standards.

5) Test failure modes and document results (this is your proof)

Design test cases tied to your “secure fail state” definition:

• Induce a controlled failure (device reboot, interface shutdown, simulate HA failover).
• Attempt prohibited flows during the event (internet-to-private, user-to-prod, partner-to-internal).
• Record results: blocked vs allowed, logs generated, alerts triggered, and time to recover.

Keep the tests repeatable. If production testing is risky, test in a staging environment that mirrors routing and HA behavior, then justify any gaps in your SSP.

Deliverable: “SC-7(18) Fail Secure Test Report” per boundary class, with raw evidence attached.

6) Operationalize through change management and monitoring

Add control hooks so failure doesn’t become a silent exception:

• Changes to boundary routing, HA, bypass settings, and default rules require security review.
• Monitoring detects reduced enforcement (device down, policy not attached, route drift).
• Incident response runbooks define what to do if you must temporarily accept reduced enforcement.

Deliverable: Change control checklist items and monitoring/alert definitions.

7) Map the requirement to an owner and recurring evidence cadence

Assessors look for ownership and repeatability. Assign:

• Control owner: Network/security engineering lead (primary), GRC (oversight)
• Evidence owner: The team that can produce configs, diagrams, and test logs
• Recurrence: Re-test after major changes and on a defined operational cycle

Daydream (as a GRC system) fits naturally here because it helps you map SC-7(18) to an owner, procedure, and recurring artifacts so evidence is consistently collected and ready for assessment. ¹

Required evidence and artifacts to retain

Auditors rarely accept “we designed it right” without artifacts. Retain:

Evidence	What “good” looks like	Where it comes from
Boundary inventory + data flow diagrams	Shows every trust boundary and enforcement point	Network architecture, cloud platform diagrams
Fail Secure Standard	Defines secure fail state and failure modes	Security architecture / GRC
HA and routing design docs	Demonstrates no bypass paths during failure	Network/cloud engineering
Config baselines / exports	Default deny, HA settings, bypass governance	Firewall/WAF/VPN admin
Failover and failure-mode test reports	Tests show prohibited flows blocked	SecEng, NetEng, QA
Change records	Security review for boundary-impacting changes	ITSM / change management
Monitoring/alert evidence	Alerts fire when enforcement degrades	SIEM/NMS screenshots, alert logs
Exceptions register	Any approved fail-open scenario is time-bound and justified	GRC risk acceptance workflow

Common exam/audit questions and hangups

Expect these questions and prep answers with evidence:

1. “Show me what happens if the firewall dies.”
   Have a test report with timestamps, traffic attempts, and outcomes.

2. “How do you know traffic can’t route around the boundary?”
   Provide routing/SD-WAN intent, segmentation diagrams, and proof that alternative paths still hit enforcement.

3. “Do you have any fail-open behavior?”
   If yes, auditors will ask for risk acceptance, compensating controls, and an expiration date.

4. “How do cloud-native controls fit?”
   Be ready to explain layered enforcement (security groups/NACLs plus managed inspection) and the secure state if the managed appliance is unavailable.

5. “Who owns this control and how often do you validate it?”
   Show the control owner assignment and the recurring evidence plan. ¹

Frequent implementation mistakes (and how to avoid them)

• Mistake: Assuming HA equals fail secure.
  Fix: Test HA edge cases (split-brain, asymmetric routing). Validate policy sync and routing convergence.

• Mistake: One control layer protects everything.
  Fix: Add layered default-deny controls so a single device failure cannot remove all enforcement.

• Mistake: “Temporary” bypass becomes permanent.
  Fix: Treat bypass as an exception with approvals, monitoring, and forced expiry.

• Mistake: Cloud perimeter appliances without guardrails.
  Fix: Enforce cloud-native deny-by-default at subnet/security group layers, and alert if inspection policies detach.

• Mistake: No evidence.
  Fix: Predefine the artifact set and collect it continuously (not during audit week). Daydream can track owners, procedures, and evidence requests so you don’t rebuild this each cycle. ¹

Enforcement context and risk implications

No public enforcement cases were provided in the source material for this requirement, so treat SC-7(18) primarily as an assessment and risk control driver rather than a “case law” control.

Risk-wise, fail-open boundary behavior turns operational incidents into security incidents. The typical blast radius includes unauthorized inbound access, data exfiltration over uncontrolled egress, and lateral movement across segments that are usually filtered. SC-7(18) is also a dependency control: many other controls assume boundaries remain enforced, even during outages. ¹

Practical 30/60/90-day execution plan

Use this plan as an operator’s checklist. Adjust scope based on your authorization boundary and highest-risk segments.

First 30 days (baseline and decisions)

• Build the boundary inventory and trust boundary map.
• Identify the top critical boundaries (internet edge, prod segmentation, third-party links, remote access).
• Define the Fail Secure Standard: secure fail state per boundary type and which failure modes must be tested.
• Assign control ownership, evidence owners, and evidence repository locations. ¹

By 60 days (implementation and hardening)

• Remediate obvious fail-open configurations (default allow, bypass enabled, permissive cloud SGs relying on appliances).
• Validate HA and routing designs; remove or govern bypass paths through change management.
• Create configuration baselines and standard operating procedures for boundary changes.
• Implement monitoring for “enforcement degraded” events (device down, policy detach, route changes).

By 90 days (prove it and operationalize)

• Execute failure-mode tests for each critical boundary and retain test reports with raw evidence.
• Run a tabletop for an outage scenario where enforcement might degrade; validate escalation and decision rights.
• Establish recurring validation triggers (after major changes, after upgrades, periodic control checks).
• In Daydream, map SC-7(18) to the control owner, link procedures, and schedule recurring evidence pulls so future audits become routine. ¹

Frequently Asked Questions

Does SC-7(18) mean every boundary device must “fail closed” no matter what?

The requirement is to prevent an unsecure state if the boundary device fails. “Fail closed” is the common implementation, but you can document an alternate secure fail state if it still prevents prohibited traffic and you can prove it in tests. ¹

How do we handle environments where availability requirements push teams toward fail-open?

Treat fail-open as an exception with explicit risk acceptance, compensating controls, and monitoring. Auditors will expect clear documentation that you intentionally chose the behavior and bounded the risk. ¹

What counts as a “boundary protection device” in cloud-native architectures?

Cloud firewalls, security groups/NACLs, managed WAFs, API gateways, and ZTNA gateways can all be boundary controls if they enforce a trust boundary. Scope based on your data flows and the enforcement points your SSP claims. ¹

What evidence is most persuasive to an assessor for SC-7(18)?

A failure-mode test report that shows prohibited traffic was blocked during an induced device failure, plus supporting configs and diagrams that show there is no alternate routing path. Pair that with change records that show you control drift. ¹

Do we need to test every possible failure mode on every device?

Focus on failure modes that could create an unfiltered path across a trust boundary. Document your rationale, test the high-risk scenarios, and re-test when architecture or routing changes. ¹

How do we operationalize ownership so this doesn’t become a once-a-year audit scramble?

Assign a single accountable owner for SC-7(18), define recurring evidence artifacts, and tie validation to change management. Tools like Daydream help by keeping the owner, procedure, and evidence schedule attached to the requirement. ¹

Footnotes

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

2. NIST SP 800-53 Rev. 5