CP-13: Alternative Security Mechanisms

Quick-reference card

What this control requires

CP-13 requires organizations to maintain alternative security mechanisms that preserve critical security functions when primary controls fail or are compromised. The control targets the gap between a primary mechanism going down and normal operations resuming, ensuring that essential protections don’t disappear entirely during that window.

In practice, this means identifying which security functions are critical enough to warrant a backup and then selecting, documenting, and maintaining fallback mechanisms for each one. The alternative mechanism doesn’t need to match the full capability of the primary control. What matters is that it preserves the security function at an acceptable level until normal operations resume. For example, if hardware-based multi-factor authentication (MFA) tokens become unavailable, an organization might pre-position one-time pads or certificate-based authentication as a temporary substitute.

But the scope of CP-13 is deliberately narrow. Because standing up and maintaining alternative mechanisms carries real cost, the control applies only to critical security capabilities provided by systems, system components, or system services. CP-13 also sits outside all three NIST 800-53 impact-level baselines, meaning organizations adopt it when their own risk assessment identifies security functions where a temporary loss of capability is unacceptable. That scoping decision is itself part of the compliance story, because you need a documented rationale for which functions you’ve included and which you’ve excluded.

Why it matters

Most contingency planning controls focus on restoring systems and data. CP-13 addresses a different problem, asking what happens to your security posture while those systems are being restored. Without predefined alternatives, organizations face a forced choice between operating without a critical control and shutting down operations until the primary mechanism is fixed.

In practice, this gap translates directly into audit risk. Assessors specifically look for documented fallback mechanisms tied to critical security functions, and the absence of those mechanisms signals a gap in contingency planning maturity. For organizations pursuing federal authorization or operating under regulatory oversight, that gap can trigger findings that delay or block certification.

The practical consequence extends beyond audit results. When a primary security mechanism fails and no alternative exists, teams improvise. Improvised workarounds bypass change management, skip logging, and often introduce new vulnerabilities. A documented alternative mechanism prevents that spiral by giving responders a pre-approved path that preserves security controls, maintains audit trails, and avoids the ad hoc decisions that compound risk during incidents.

Where this exercise pays unexpected dividends is in resilience planning. Defining alternative mechanisms forces teams to identify single points of failure in their security architecture before an incident reveals them.

Take the dependency-mapping benefit as an example. The exercise of selecting alternatives exposes hidden dependencies. A security function that appears well-protected may rely on a single vendor’s API, a shared certificate authority, or a network path that also carries the primary mechanism. Mapping alternatives surfaces those dependencies in a way that architecture reviews alone often miss.

What auditors flag

• No documented mapping between critical security functions and their designated alternative mechanisms
• Alternative mechanisms that exist on paper but have never been tested during contingency plan exercises
• Contingency plans that address system recovery but omit security function continuity
• Lack of criteria for determining which security capabilities qualify as “critical” under CP-13
• Alternative mechanisms that haven’t been reviewed or updated after changes to primary controls

How to implement

The most common failure with CP-13 isn’t a missing plan. It’s an organization that has never inventoried which security functions actually need an alternative, so the contingency plan covers system recovery but leaves security controls unprotected during the transition.

For your organization

Step one: identify critical security functions. Work with your security architecture and operations teams to catalog the security functions your environment depends on. Focus on authentication, access control, encryption, logging, and integrity verification. For each function, ask: if this mechanism failed today, could we continue operating securely? If the answer is no, it qualifies for CP-13 coverage.

Step two: select alternative mechanisms. For each critical security function, choose an alternative that can be activated quickly and doesn’t depend on the same infrastructure as the primary. The alternative can be less capable, but it must preserve the core security outcome. Document the alternative in your contingency plan and continuity of operations plan (COOP).

Step three: integrate with contingency plan testing. Your alternative mechanisms should be tested as part of regular contingency plan exercises. Testing validates that the alternative actually works, that staff know how to activate it, and that transition procedures are documented. Record test results alongside your other contingency plan test records.

Step four: maintain and review. When you update or replace a primary security mechanism, review whether its designated alternative still applies. Changes to system architecture, vendor products, or threat landscape can render a previously valid alternative ineffective. Build this review into your change management process.

Step five: document the scoping rationale. Because CP-13 isn’t part of any baseline, your system security plan (SSP) should explain why specific security functions were selected for alternative mechanism coverage and why others were excluded. Assessors will look for this rationale to confirm that the scoping decision was risk-informed rather than arbitrary.

Common mistakes:

• Treating CP-13 as a documentation exercise without testing alternatives
• Selecting alternatives that depend on the same infrastructure as the primary mechanism
• Defining alternatives only for technology controls while ignoring procedural security functions
• Failing to update alternative mechanism documentation when primary controls change

For your vendors

What to ask in security questionnaires:

• Does the vendor maintain documented alternative security mechanisms for critical security functions?
• Are alternative mechanisms included in the vendor’s contingency plan testing program?
• Can the vendor provide test records showing that alternative mechanisms have been activated and validated?
• How does the vendor determine which security capabilities qualify as critical?

What evidence to request:

• Contingency plan sections addressing alternative security mechanisms
• Test records from exercises that activated alternative mechanisms
• System design documentation showing primary and alternative mechanism pairings
• Configuration documentation for alternative mechanisms

Red flags:

• Vendor contingency plans mention alternative mechanisms in general terms but don’t name specific alternatives for specific functions
• No test records exist for alternative mechanism activation
• The vendor’s redundancy approach covers infrastructure failover but doesn’t address security control continuity
• Alternative mechanisms rely on the same vendor, platform, or infrastructure as primary controls

Verification beyond self-attestation: Request evidence of contingency plan test results that specifically exercised alternative security mechanisms. Ask whether the vendor’s most recent test included a scenario where a primary security control was deliberately disabled to validate the alternative. Cross-reference the vendor’s system security plan with their contingency plan to confirm that the same critical security functions appear in both documents with consistent alternative mechanism assignments.

Evidence examples

Cross-framework mapping

Related controls

• CP-02 — Contingency Plan: Establishes the broader contingency planning framework within which alternative security mechanisms are documented and maintained.
• CP-04 — Contingency Plan Testing: Validates that contingency measures, including alternative security mechanisms defined under CP-13, function as expected when activated during exercises.
• CP-10 — System Recovery and Reconstitution: Covers restoring systems to operational status after disruption, while CP-13 ensures security controls remain active during the recovery window.
• CP-11 — Alternate Communications Protocols: Addresses backup communication channels, a specific category of alternative mechanism that CP-13 covers at a broader security function level.
• SI-13 — Predictable Failure Prevention: Focuses on proactively identifying components likely to fail, complementing CP-13’s focus on having alternatives ready when failure occurs.

Frequently asked questions

What is NIST SP 800-53 CP-13?

CP-13 is a contingency planning control that requires organizations to maintain alternative or supplemental security mechanisms for critical security functions. It ensures that when a primary security mechanism becomes unavailable or compromised, a pre-selected fallback can preserve the security function until normal operations resume. The control applies to both organization-level and system-level implementations.

What happens if CP-13 is not implemented?

Without CP-13, organizations lack pre-approved fallback mechanisms for critical security functions, leaving security gaps during outages or compromise events. Assessors reviewing contingency plans and continuity of operations plans will flag the absence of documented alternative security mechanisms as a finding. The gap also increases operational risk, because teams without pre-defined alternatives tend to improvise workarounds that bypass logging, change management, and access controls.

How do you audit CP-13?

Auditors assess CP-13 by examining the contingency planning policy and contingency plan for documented mappings between critical security functions and their designated alternative mechanisms. They review procedures addressing alternate security mechanisms to confirm that activation steps, roles, and rollback criteria are specified. Auditors also examine contingency plan test records and test results to verify that alternative mechanisms have been exercised, and they interview personnel to confirm awareness of when and how to activate alternatives.

What are examples of alternative security mechanisms?

Alternative security mechanisms vary based on the security function they protect. For authentication, an organization might pre-position one-time pads or backup certificate authorities when hardware MFA tokens are compromised. For encrypted communications, a fallback to a secondary encryption protocol or out-of-band channel can maintain confidentiality, and for logging, a manual log collection procedure can preserve accountability when automated systems are offline. Each alternative must be documented in the contingency plan, tested during exercises, and ready to activate without depending on the same infrastructure as the primary mechanism.