Fault tolerance is the ability of a system to keep running when one or more of its components fails. That is the definition NIST uses, adapted from its own publications and CNSSI 4009. Redundancy is a common technique for achieving it, but having spare parts does not by itself prove a system tolerates faults.
How do standards define it?
The NIST glossary gives two wordings. One, sourced from CNSSI 4009-2022 and adapted from NIST SP 1500-1r2, says it is the ability of a system to continue to run when one or more components fail. The other, from NISTIR 8202, says it is a property of a system that allows proper operation even if components fail.
Both say "proper operation" or "continue to run," not "never go down." A fault-tolerant system may run slower or with fewer features during a failure. The design question is what it must keep doing, and what it may give up.
How is it different from backup or disaster recovery?
Backups restore data after loss. Disaster recovery restores service after a major event, typically with some downtime. Fault tolerance is about not noticing the failure at all, or noticing it only as reduced capacity. The three work together: a fault-tolerant database pair does not protect you from an operator deleting a table, which is a job for backups.
What are the common techniques?
- Redundancy: two or more copies of a component, so one can take over.
- Failure detection: health checks and timeouts that notice a component is gone.
- Failover: moving work to a healthy copy, automatically or by a person.
- Isolation: limiting how far one failure spreads, so a bad node does not take its neighbors down.
- Graceful degradation: shutting off non-essential features to protect essential ones.
Each one has a failure mode of its own. A health check that is too sensitive removes healthy nodes. A failover that takes ninety seconds is invisible to a batch job and painful for a payment page.
Where do designs fail in practice?
Here is a constructed example. A team runs two application servers behind a load balancer and a primary database with a replica. On paper, any single server can fail.
During a test, they stop one app server. Traffic moves to the other and everything looks fine. Then they stop the primary database. The replica is promoted, but the application holds connections to the old address and needs a restart, so users see errors for twelve minutes. The design had redundancy, but fault tolerance for the database was never tested end to end.
Other typical gaps: both servers share one power feed or one availability zone; the load balancer itself is a single point of failure; the replica has been quietly falling behind for weeks; the same bad configuration is pushed to both copies at once. Redundancy protects against independent failures. It does not protect against a shared cause.
How should security teams care?
Fault tolerance is part of availability, one of the three security goals alongside confidentiality and integrity. An attack that overwhelms or corrupts a component is a fault from the system's point of view. Tolerance also has a security edge: failover paths often skip normal controls, such as logging or authentication to a secondary service, so test that the backup path is protected the same way as the primary.
How to check or apply this
- List the components whose failure would stop a key service, and mark which have no spare.
- For each component, write down the expected behavior on failure, including how long switchover may take.
- Look for shared dependencies: power, network, zone, credentials, configuration pipeline.
- Test failures one at a time in a safe environment and record what users would see.
- Monitor replica lag and spare health, since a spare that is not working is not a spare.
- Check that logging, authentication and access controls work on the failover path.
- Repeat the tests after significant changes, and after staff turnover.
Quick check
Is a system with redundancy automatically fault tolerant?
No. Redundancy only helps if failures are detected, work moves to the spare, and the spare is healthy and independent of the failed part. Test each of those.
Does fault tolerance mean zero downtime?
Not necessarily. NIST's wording is that the system continues to run or operates properly despite failed components. Define in advance what level of service counts as acceptable during a fault.
Sources
Last reviewed: 18 October 2026.
