SC-24: Fail in Known State

Quick-reference card

What this control requires

SC-24 requires systems to fail into a predetermined secure state rather than an unpredictable one. You need to identify the types of failures that could affect each system component, define the known state each component should enter during those failures, and preserve enough system state information to support recovery.

In practice, this control means you can’t leave failure behavior to chance. Every system component that handles sensitive data or supports critical operations needs an explicit failure mode that protects confidentiality, integrity, and availability. You define what “known state” means for each component, whether that’s a locked-down configuration, a read-only mode, or a graceful shutdown that preserves transaction logs and session data. This requirement sits within the broader System and Communications Protection family, which addresses how systems maintain security boundaries under stress.

The underlying principle is straightforward. Uncontrolled failures create windows where security controls stop enforcing policy, data flows bypass protections, and attackers gain access they wouldn’t have during normal operations. SC-24 closes those windows by forcing you to decide in advance what happens when something breaks.

Why it matters

Most organizations invest heavily in preventing failures but spend far less time defining what should happen when failures inevitably occur. That gap between prevention and failure response is where compliance risk concentrates for SC-24. Auditors evaluating HIGH-baseline systems expect documented evidence that you’ve identified failure scenarios, defined secure states for each one, and tested that those states hold under real conditions.

Without this control in place, your systems may fail into permissive states that grant unintended access or expose data. The compliance consequence is direct. Federal Information Security Modernization Act (FISMA) audits treat missing fail-state documentation as a control deficiency, and a deficiency in a HIGH-baseline control escalates the risk rating for your entire authorization package.

Organizations that rely on default vendor configurations often discover during assessments that their systems fail into open or degraded states that don’t preserve security properties. Remediation during an active audit cycle is significantly more disruptive than building fail-state requirements into your system design from the start.

What attackers exploit

• Undefined failure modes that leave services running in degraded states with authentication or access controls disabled
• Missing state preservation that destroys audit trails and forensic evidence during crashes, preventing incident reconstruction
• Network boundary failures where firewalls or access control devices default to allow-all rules when they lose connectivity to policy servers
• Application-level crashes that bypass input validation, session management, or encryption requirements during error handling
• Recovery processes that restore systems to baseline configurations missing recent security patches or hardened settings, as addressed by baseline configuration management

How to implement

The most common failure mode in SC-24 implementation is assuming that default vendor configurations handle failure securely. They rarely do. Most commercial systems prioritize availability over security during failure, which means your fail-state behavior needs to be explicitly designed, configured, and tested.

For your organization

Start by inventorying every system component in scope for your HIGH-baseline authorization boundary. For each component, document the types of failures it could experience, including hardware faults, software crashes, network partitions, resource exhaustion, and dependency failures.

Define the known state for each failure type on each component. A known state should preserve confidentiality, integrity, and availability to the extent possible. For a web application, this state might mean returning a static error page while refusing to process new requests. For a database, it might mean completing or rolling back in-flight transactions before shutting down. For a firewall, it means defaulting to deny-all rather than allow-all when policy enforcement fails.

Preserve system state information during failures. This preservation includes active session data, transaction logs, configuration state at time of failure, and audit records. Without this information, you can’t determine what happened before the failure, what data may have been affected, or whether the failure was triggered deliberately. Your system backup procedures should account for state preservation requirements.

Test your fail-state behavior regularly. Tabletop exercises don’t satisfy this requirement on their own. You need to simulate actual failure conditions in a controlled environment and verify that each component enters its defined known state and preserves the required state information. Document test results as evidence for your assessors.

Common mistakes to avoid:

• Documenting fail-state requirements in design documents but never testing them in production-equivalent environments
• Defining known states that preserve security but destroy the state information needed for recovery and forensics
• Treating fail-state testing as a one-time activity rather than incorporating it into your regular contingency plan testing cycle
• Overlooking application-layer failures while focusing exclusively on infrastructure components

For your vendors

When assessing vendors against SC-24, you need to verify that they’ve defined and tested fail-state behavior for the systems that process your data. Start by requesting their system design documentation with specific attention to failure mode definitions.

Ask vendors to provide their list of identified failure types for each system component that handles your data. This list should include both infrastructure failures and application-level fault scenarios. If a vendor can’t produce this list, they likely haven’t addressed SC-24 in a meaningful way.

Request evidence that the vendor has defined known states for each identified failure type. The documentation should specify what security properties each known state preserves and what system state information is retained during failure. Compare the vendor’s failure definitions against your own data protection requirements to confirm alignment.

Verify that the vendor tests fail-state behavior on a regular cadence. Ask for test results, including the failure conditions simulated, the observed system behavior, and any deviations from the expected known state. Vendors managing HIGH-baseline systems should demonstrate that their system recovery and reconstitution processes restore systems to a known secure configuration.

Red flags to watch for:

• Vendors who describe their fail-state approach only in terms of availability and uptime, without addressing security state preservation
• Missing or outdated failure mode documentation that doesn’t reflect the current system architecture
• No evidence of fail-state testing within the past 12 months
• Recovery procedures that focus on restoring service without verifying security configuration integrity
• Inability to describe what system state information is preserved during failures

Evidence examples

Cross-framework mapping

No cross-framework mappings are currently configured for SC-24.

Related controls

• CP-02 — Contingency Plan: defines the broader organizational response framework that SC-24 fail-state behavior feeds into, ensuring system failures trigger pre-planned recovery actions
• CP-04 — Contingency Plan Testing: validates that fail-state transitions and recovery procedures work as designed through regular exercises and simulations
• CP-10 — System Recovery and Reconstitution: governs how systems return to operational status after entering a known failure state, ensuring recovery restores both functionality and security properties
• CP-12 — Safe Mode: provides an alternative operating mode that preserves essential functions when a system can’t maintain full capability, complementing SC-24 fail-state definitions
• SA-08 — Security and Privacy Engineering Principles: establishes the design-level engineering practices that inform how fail-state behavior is architected into systems from the start
• SC-07 — Boundary Protection: addresses how network boundaries maintain security enforcement during failures, directly affected by whether boundary devices fail open or fail closed
• SC-22 — Architecture and Provisioning for Name/Address Resolution Service: covers DNS and name resolution availability during failures, where undefined fail-states can redirect traffic or expose internal addressing
• SI-13 — Predictable Failure Prevention: focuses on proactively identifying components likely to fail and replacing them before failure occurs, reducing the scenarios where SC-24 fail-state behavior activates

Frequently asked questions

What is NIST SP 800-53 SC-24?

SC-24 is the NIST SP 800-53 control that requires systems to fail into a defined, secure state while preserving system state information needed for recovery and forensic analysis. It applies to HIGH-baseline systems and addresses the risk that uncontrolled failures disable security protections or destroy evidence. The control requires you to identify system failures on system components, define the known system state each component enters during failure, and ensure critical data like transaction logs and session records survives the failure event.

What happens if SC-24 is not implemented?

Without SC-24 implementation, system components may fail into permissive or undefined states that bypass access controls, disable encryption, or expose protected data. Auditors reviewing HIGH-baseline systems will flag the absence of documented failure modes and state preservation procedures as a control deficiency, which can delay or block your authority to operate. The lack of preserved system state information also means you lose the forensic trail needed to determine whether a failure was accidental or the result of a deliberate attack.

How do you audit SC-24?

Auditing SC-24 starts with reviewing the documented list of failures requiring systems to fail in a known state, then verifying that each identified failure type has a corresponding known system state definition that preserves security properties. Assessors examine system design documentation and configuration settings to confirm that fail-state behavior is technically enforced, not just documented as policy. They also review test results from simulated failure scenarios to verify that components entered the correct state and that state information, including audit logging data, was preserved as specified.

What is the difference between fail-safe and fail-secure?

Fail-safe systems prioritize preventing physical harm or property damage when failures occur, while fail-secure systems prioritize maintaining security controls like access restrictions and data protection during failure. SC-24 encompasses both concepts by requiring systems to fail to a known system state that addresses safety and security concerns in accordance with organizational mission needs. In practice, the distinction matters because a fire door that fails open is fail-safe but not fail-secure, while a server that locks all access during a crash is fail-secure but may not be fail-safe if it disrupts safety-critical operations.