SC-24 Fail in Known State asks that, for chosen types of failure on chosen components, the system fails to a defined known state while preserving chosen state information. You decide the failures, the components, the known state and what to preserve.
NIST SP 800-53 binds US federal systems, and reaches contractors and cloud providers through contract terms such as FedRAMP. For everyone else it is a reference catalog you borrow from, so check which parts your customer or auditor actually expects.
The guidance says failure in a known state addresses security concerns according to your mission and business needs. It prevents loss of confidentiality, integrity or availability when systems or components fail. It also helps prevent systems from failing into states that could injure people or destroy property. Preserving state information makes restarts easier and returns you to operation with less disruption.
What it means in practice
Every system fails. The question is what it does when it does. Two familiar choices are fail closed and fail open. A door lock that fails closed keeps people out when power is lost. A fire exit that fails open lets people leave. The right answer depends on what you are protecting, and SC-24 asks you to decide on purpose and write it down.
Examples in software:
- An authorization service that cannot be reached. Do requests get denied, or allowed? For access to sensitive data, denied is usually right.
- A payment service that times out midway. Does the order land in a clear pending state with the details saved, or does it leave a half completed transaction?
- A security agent that crashes. Does the host keep running unprotected, or is it quarantined?
- A configuration service outage. Do applications continue with the last known good configuration, or with defaults?
- A database failover. Is the application read only until consistency is confirmed?
State preservation means that logs, queue contents, session data and transaction records survive the failure so you can recover and investigate.
Evidence to collect
- A table of components, failure types, the defined known state and the reason for each.
- Design or architecture documents that state fail closed or fail open decisions.
- Configuration showing timeouts, circuit breakers and default deny behavior.
- Failure injection or chaos test results, with date and outcome.
- Backup, journal or queue persistence settings for state information.
- Runbooks showing how to restart from the preserved state.
- Incident reviews where a failure behaved as designed, or where it did not and was fixed.
Common gaps
Nobody has decided what the known state is, so the behavior is whatever the code happens to do. Error handlers that swallow exceptions and continue. Authorization code that returns allow when a lookup fails. Security tooling that fails open silently with no alert. Services that lose in flight work on restart because it was held only in memory. A recovery process that has never been run.
Another gap is a mismatch between components. One service fails closed, another fails open, and together they create an exposure no one designed.
How to implement it
Start with a short list of components whose failure matters most: authentication, authorization, payment, data stores, security agents and logging. For each, write a single line: when X fails, we do Y, and we keep Z.
Review code paths for default behavior on error. Search for places where a failed check returns success. Change them to deny and log.
Add timeouts and circuit breakers so that slow dependencies do not hang the system. Make the fallback explicit and safe.
Persist what matters. Queue messages durably, write transaction state before acting, and ship logs off the machine.
Then test it on purpose. Take a dependency down in a staging environment and observe. Record what happened and whether it matched the design. Repeat after significant changes.
Finally, alert on failure. A system that fails safely and silently still needs someone to know about it.
Tie the failure table to your continuity plan. The same list that tells you what happens on failure tells you what to restore first.
A worked example helps. A company runs an API gateway that checks each request against an authorization service. In the first version, if the authorization service times out, the gateway logs a warning and lets the request through, because availability complaints once outweighed security concerns. A review under SC-24 turns that into a decision. For read access to public data, serving a cached allow is acceptable. For access to customer records, the gateway returns an error and raises an alert. Both behaviors are written in the failure table, and a test in staging takes the authorization service down and shows each outcome.
That table is also your evidence. One row per component, with the failure, the chosen state, the reason, the test date and the owner. It is short, easy to review and hard to fake, because the tests back it up.
Watch for the human side of failure too. A runbook that says restart the service is not a known state if the restart loses data. State the recovery steps, including where preserved state lives and who confirms integrity before service resumes.
Revisit the table whenever architecture changes. New dependencies introduce new failure modes, and the most dangerous ones are those nobody wrote down.
Quick check
Is fail closed always right?
No. The right known state depends on what is at risk. Choose deliberately and document the reason.
What does preserving state mean?
Keeping information such as logs, queue contents and transaction records so you can restart and investigate with less disruption.
