SI-13: Predictable Failure Prevention

Quick-reference card

What this control requires

SI-13 requires organizations to calculate mean time to failure (MTTF) for critical system components and replace them before they fail. The control targets a gap that most security programs overlook, specifically the predictable degradation of hardware and software components that provide security capabilities. Rather than waiting for a firewall, intrusion detection sensor, or encryption module to fail during an incident, you proactively track how long each component is expected to function and swap it out on a defined schedule.

In practice, this control breaks into two requirements. First, you determine MTTF values for designated system components in your specific operating environment, not industry averages pulled from vendor spec sheets. Your data center’s temperature, workload patterns, and usage cycles all affect how quickly components wear out. Second, you maintain substitute components and a documented exchange process so you can swap active and standby parts without losing security posture, operational readiness, or system state.

The intent behind SI-13 goes beyond reliability engineering. When a component that enforces access controls, monitors network traffic, or encrypts data in transit fails unexpectedly, the resulting gap creates an unmonitored window that adversaries can exploit. Predictable failure prevention closes that window by ensuring replacements are staged and exchange procedures are tested before the failure occurs.

Why it matters

Organizations that ignore predictable failure prevention face a compliance gap that auditors can flag during any assessment tied to NIST SP 800-53. Because SI-13 isn’t part of any baseline, it often gets deprioritized, but its absence signals a reactive security posture that regulators and assessors notice when evaluating system and information integrity controls.

The deeper risk is operational. Security-critical components don’t fail on a schedule that aligns with your maintenance windows. A hardware security module that degrades past its MTTF threshold, a firewall appliance running beyond its expected lifecycle, or a storage controller nearing end-of-life can each create a silent gap in your defensive architecture. Without substitute components staged and ready, the time between failure and restoration becomes an unprotected window.

Audit findings related to SI-13 typically surface during continuous monitoring reviews or system authorization renewals. Assessors look for documented MTTF calculations, evidence that substitution criteria exist, and proof that exchange procedures preserve system state variables. Missing any of these artifacts can result in a plan of action and milestones (POA&M) entry that delays your authorization.

For organizations managing vendor ecosystems, the risk compounds. If a third party’s security infrastructure relies on aging components without a substitution plan, their failure becomes your exposure. Verifying that vendors maintain predictable failure prevention procedures alongside system recovery and reconstitution capabilities strengthens your overall risk posture.

What attackers exploit

• Unmonitored degradation of security appliances, creating gaps in logging, filtering, or encryption during the period between failure and replacement
• Absence of standby components, which extends mean time to recovery and leaves security functions offline longer than necessary
• Failure to preserve system state during component exchanges, which can reset security configurations or drop active sessions
• Aging infrastructure that vendors no longer patch or support, increasing the attack surface through known vulnerabilities
• Lack of environment-specific MTTF data, leading organizations to rely on optimistic vendor estimates that don’t reflect actual operating conditions

How to implement

Most organizations struggle with SI-13 not because the concept is complex, but because calculating environment-specific MTTF requires data that security teams rarely collect. The first step is identifying which components fall under this control, and the second is building the operational discipline to track, stage, and exchange them before they fail.

For your organization

Start by inventorying every system component that provides a security capability. This inventory includes firewalls, intrusion detection and prevention systems, hardware security modules, encryption appliances, authentication servers, log collectors, and any redundant storage or network devices that support security functions. Tag each component with its deployment date, vendor-specified MTTF, and operating environment conditions such as temperature ranges, utilization levels, and power cycling frequency.

Next, calculate environment-specific MTTF values. Vendor-published figures assume laboratory conditions and don’t account for your workload patterns. Pull failure history from your configuration management database (CMDB), maintenance logs, and incident records. If you don’t have enough historical data, begin tracking component health metrics now and refine your MTTF estimates over time using environmental monitoring tools and predictive analytics platforms.

Define substitution criteria that specify when a component must be replaced, aligned with your timely maintenance requirements. These criteria should reference a percentage of the calculated MTTF threshold, not a fixed calendar date. A component operating in a high-utilization environment may hit its substitution trigger years before the same model in a low-demand role.

Establish an exchange procedure that preserves system state variables during the swap between active and standby components. This procedure should document how session data, configuration state, security policies, and audit logs transfer without interruption. Test the exchange process during scheduled maintenance windows to confirm that security capabilities remain continuous throughout the transition.

Common mistakes to avoid:

• Relying on vendor-published MTTF without adjusting for your operating environment
• Treating SI-13 as a one-time inventory exercise instead of a recurring process
• Failing to test the active-to-standby exchange under realistic conditions
• Neglecting to update MTTF calculations when workload or environmental conditions change
• Storing standby components without periodic health checks to confirm they remain functional

For your vendors

When assessing third-party compliance with SI-13, your goal is to verify that vendors don’t rely on aging security infrastructure without a documented replacement plan. Include the following in your vendor assessment questionnaires:

Ask vendors to provide their inventory of security-critical components along with the MTTF values calculated for their specific operating environments. Request evidence that these values reflect actual deployment conditions rather than manufacturer defaults. Vendors should be able to show maintenance logs, environmental monitoring data, or failure trend analyses that feed into business continuity planning that support their calculations.

Request documentation of the vendor’s substitution criteria. You want to see defined thresholds that trigger component replacement, not vague commitments to “replace as needed.” The criteria should specify what percentage of MTTF triggers the procurement process, what percentage triggers the staging of standby components, and what percentage triggers the mandatory exchange.

Evaluate the vendor’s exchange procedures by asking for their active-to-standby transition documentation. Specifically, verify that the procedures address how system state variables are preserved during the swap. A vendor that can’t demonstrate state preservation during component exchanges may experience security gaps during transitions that affect your data.

Red flags during vendor assessment:

• No documented MTTF calculations for security-critical infrastructure
• Reliance on manufacturer-published MTTF without environment-specific adjustments
• No standby components staged for security appliances
• Exchange procedures that require security services to go offline during the swap
• Absence of testing records for the component exchange process

Verification approach: request the vendor’s most recent predictable failure prevention procedures, MTTF substitution criteria documentation, and maintenance records showing completed exchanges. Confirm they maintain alternative security mechanisms for critical components and cross-reference the component inventory against the vendor’s system security plan to confirm coverage.

Evidence examples

Cross-framework mapping

No cross-framework mappings are currently documented for SI-13.

Related controls

• CP-02 — Contingency Plan: defines the broader continuity framework that predictable failure prevention supports by ensuring security components remain available during disruptions
• CP-10 — System Recovery and Reconstitution: addresses restoring system capabilities after a failure, complementing SI-13’s goal of preventing the failure from occurring
• CP-13 — Alternative Security Mechanisms: provides fallback security capabilities when primary mechanisms become unavailable, which intersects with SI-13’s standby component requirements
• MA-02 — Controlled Maintenance: governs how maintenance activities are scheduled and documented, directly supporting the component exchange procedures required by SI-13
• MA-06 — Timely Maintenance: ensures that maintenance actions happen within defined timeframes, reinforcing the MTTF-based substitution schedule that SI-13 establishes
• SA-08 — Security and Privacy Engineering Principles: guides the design of systems with redundancy and failover capabilities that make predictable failure prevention feasible
• SC-06 — Resource Availability: ensures that sufficient resources are allocated to maintain security functions, including the standby components that SI-13 requires

Frequently asked questions

What is NIST SP 800-53 SI-13

SI-13 is a NIST SP 800-53 control that requires organizations to calculate mean time to failure (MTTF) for security-critical system components and replace them before they fail. The control applies to any hardware or software component that provides a security capability, from firewalls and encryption modules to authentication servers. By tracking environment-specific MTTF values and maintaining standby components with tested exchange procedures, you prevent gaps in your security posture caused by predictable component degradation.

What happens if SI-13 is not implemented

Without SI-13, security-critical components can fail without warning, leaving security functions offline until a replacement is sourced, configured, and deployed. This unplanned downtime creates windows where logging, access controls, or encryption may be absent. Auditors reviewing your system and information integrity controls will flag the lack of documented MTTF substitution criteria and predictable failure prevention procedures as a deficiency, potentially resulting in a plan of action and milestones entry.

How do you audit SI-13

Auditing SI-13 starts with verifying that the organization has documented MTTF calculations for each designated system component in its specific operating environment. Assessors then review the MTTF substitution criteria to confirm that defined thresholds trigger component replacement before failure occurs. The audit also examines exchange procedures and associated test records to verify that active-to-standby transitions preserve system state variables and maintain continuous security capabilities.

What is mean time to failure in NIST 800-53

Mean time to failure (MTTF) in the context of NIST SP 800-53 is the calculated average time a system component is expected to operate before it fails in a specific environment. Unlike vendor-published reliability figures, NIST requires organizations to determine MTTF based on their actual operating conditions, including workload, temperature, and usage patterns. This environment-specific calculation drives the substitution criteria that determine when standby components must be staged and exchanges must occur.