CP-13 Alternative security mechanisms: requirements and evidence

What CP-13 alternative security mechanisms asks for and why it is hard

When an assessor or a contract asks about CP-13, the answer the organization must be able to give is specific: it has defined which security functions must keep working when their primary mechanism is unavailable or compromised, it has defined the alternative mechanisms that will take over, and it can show that those alternatives actually run. The organization makes both choices itself. Nothing in the control names the functions or the mechanisms, so an assessor will not accept a generic statement that backup controls exist.

CP-13 sits in the contingency planning family, alongside the contingency plan, training and testing controls, and it is not a copy of the telecommunications or alternate site controls. It carries two organization-defined parameters that the organization must set, and it has no control enhancements. It is not selected in any SP 800-53B baseline, so a low, moderate or high system does not inherit it unless the organization tailors its baseline or applies an overlay. Its related controls in the catalog are CP-2, CP-11 and SI-13, which is useful when deciding where its evidence should live.

The risk behind the control is a fail-open condition. If the primary authentication service, audit logging or access enforcement point goes down or is compromised, a system that has no defined fallback may either stop all access or quietly allow access without checks or records. Both outcomes are failures, and the second is the one that surfaces in incident reviews. The hard part is therefore not writing the control statement but deciding, function by function, what the fallback is, who approves it and how the team would know it had engaged. Confirm these decisions with the system owner, and treat the parameters as the output of a documented risk decision rather than a configuration setting.

Which systems and functions CP-13 applies to when you tailor a baseline

CP-13 is not selected in any SP 800-53B baseline, so it enters a system's control set only when the organization tailors a baseline or an overlay adds it. The decisions below determine whether CP-13 is needed, what it must cover and how much evidence an assessor will expect.

Confirm CP-13 is added on purpose

CP-13 is absent from the low, moderate, high and privacy baselines, so a system only carries it when someone deliberately adds it through tailoring or an overlay. Record who made that decision and why in the system security plan. An assessor will ask whether the addition traces to a documented risk, and a control added without a stated reason is hard to defend in review.

Define the security functions in scope

CP-13 requires the organization to define which security functions need an alternative mechanism and to set the two organization-defined parameters that govern it. Start with functions whose failure would leave the system unprotected, such as authentication, logging, encryption or access enforcement. A vague list makes testing impossible, because an assessor cannot confirm a mechanism for a function nobody named.

Map systems that depend on a primary control

Identify each system whose defined security function relies on one primary mechanism, such as a single identity provider, a single hardware security module or one central log collector. Those single points of dependency are where an alternative mechanism matters. Systems that already run redundant controls may need little more than documentation. Check dependencies against the architecture diagrams, not against what teams remember.

Check managed services holding primary controls

When a third-party managed service holds a primary security control, such as key management, identity federation or log retention, the alternative mechanism may depend on the same provider. Ask whether the provider has its own fallback, what happens during a provider outage, and whether the organization can operate the function independently. Put those answers in the service agreement and the plan, and test them.

Align with the contingency plan

CP-2 covers essential functions, recovery priorities and roles, so the functions chosen for CP-13 should appear there too. If the contingency plan omits a function that CP-13 protects, the two controls contradict each other and the test results will not reconcile. Use the same function list in both documents, and record which CP-2 procedures invoke the alternative mechanism.

How an assessor tests CP-13 under SP 800-53A

This table breaks down how an SP 800-53A assessment of CP-13 is structured, showing the single determination statement, the examine, interview and test methods, and the objects each one draws on. Read it as a checklist of what an assessor will ask to see, who they will ask, and what they will run.

Assessment element	What the assessor does	Evidence or object to prepare
Determination statement	Decides whether the organization has defined and employed alternative or supplemental mechanisms for the defined security functions	Written statement of which functions have alternates and which parameters the organization set
Examine method	Reviews documents against the determination statement	Contingency plan and continuity of operations plan sections covering alternative mechanisms
Examine objects: test records and results	Checks that alternative mechanisms were exercised and results were recorded	Contingency plan test records and test results with dates, scope and corrective actions
Interview method	Asks personnel how the alternate mechanism is used during a disruption	Personnel with system operation responsibilities who can explain activation steps
Test method	Observes the alternative mechanism performing the defined security function	System capability implementing alternative security mechanisms, demonstrated in a controlled exercise
Undefined parameters	Flags plans that describe alternates but leave the CP-13 values unset	Completed organization-defined parameter values, traceable to the system security plan
Mechanisms never exercised	Finds alternates that exist on paper but have never been run	Dated exercise evidence showing the mechanism performed its function
Plans that do not match tests	Notes differences between documented steps and what staff actually did	Test results that reference the same mechanisms and steps named in the plan

How to implement CP-13 step by step

This sequence turns CP-13 from a tailoring decision into a documented, tested alternative for each security function that would otherwise fail when its primary mechanism is unavailable or compromised. Each step ends with an artifact an assessor can examine.

Confirm the tailoring decision for CP-13
Start by confirming that CP-13 is in scope. SP 800-53B Release 5.2.0 does not select CP-13 for the low, moderate or high baselines or the privacy baseline, so it appears only because the organization tailored its baseline or an overlay requires it. The system owner, the authorizing official and the compliance lead should record the decision and its rationale in the system security and privacy plan. Done means the tailoring entry names CP-13 and explains why the primary security functions need an alternative.
Define the two organization-defined parameters
CP-13 has two organization-defined parameters, which SP 800-53A labels CP-13_ODP[01] and CP-13_ODP[02]. The organization sets the values: the security mechanisms that serve as alternatives and the security functions they must perform. Read the exact wording of both parameters in the OSCAL catalog or the NIST CPRT entry before drafting. Done means both values are written down, approved by the control owner and traceable to the system's risk assessment.
Identify the primary security functions needing an alternative
Map each security function the system relies on, such as authentication, logging, access enforcement, malicious code detection and encryption key handling, to the primary mechanism that performs it. Mark the functions whose loss would leave the system unprotected or unmonitored if that mechanism became unavailable or compromised. Engineers and the risk owner should review the list together. Done means a function inventory exists in which each row names a primary mechanism, its dependencies and a yes or no decision on whether an alternative is required.
Select and configure each alternative mechanism
For every function that needs an alternative, select a mechanism that can operate independently of the primary one, such as a separate logging path, a secondary authentication source or an out-of-band administrative channel. Document its configuration, its owner and the conditions that trigger its use. Confirm it does not share the same single point of failure as the primary. Done means each alternative has a configuration record, a named owner and a documented activation condition that a reviewer can verify against the system design.
Document the alternatives in the contingency plan
Add the alternative mechanisms to the system contingency plan that CP-2 requires, including the activation steps, the roles that switch to them and how control is returned to the primary mechanism after recovery. Coordinate the entries with incident handling so responders know when a compromise calls for an alternative. Done means the contingency plan lists each alternative, its trigger, its activation procedure and its restoration steps, and the plan has been reviewed by the people who would use it.
Test failover of each security function
Test each alternative mechanism by disabling or simulating the failure of its primary and confirming that the defined security function still operates. Record what was tested, the observed behavior, the time the function took to resume and any gaps. Assessors using SP 800-53A examine the contingency plan test records and test results and test the system capability implementing the alternative, so the test should be reproducible. Done means a dated test record exists for each function with the test steps, the outcome and the people who ran it.
Record results and track corrective actions
Review each test result against the defined function and the organization's tolerance for a gap. Open a corrective action for every failure, assign an owner and a target date set by the organization, and track it in the plan of action and milestones where the program uses one. Update the contingency plan and the configuration records when the fix changes the alternative. Done means every finding has a closed or accepted corrective action, and the updated test results and plan revisions are retained as evidence for the next assessment.

Evidence that passes a CP-13 assessment

CP-13 is assessed through examination, interviews and testing, so an assessor will look for a paper trail and for proof that the alternative mechanism works when the primary one is gone. The cards below cover the artifacts that connect the defined parameters, the plan, the test cycle, the deployed configuration and the people who run the alternative, along with how to keep each one current between assessments.

Defined parameter values

CP-13 has two organization-defined parameters that you set when you implement the control. They name the security functions that need an alternative and the alternative mechanisms that satisfy them. Record the chosen values in the system security plan and in a short register that states which primary mechanism each alternative replaces. An assessor will compare these values against the plan and the test results, so any mismatch becomes a finding. Review the values after every significant system change, because a new authentication or logging path can make an old alternative obsolete.

Contingency and continuity plan sections

The contingency plan and the continuity of operations plan should name each alternative mechanism, the security function it covers, the trigger that activates it and the person who authorizes its use. Write the trigger in observable terms, such as a failed directory service or a compromised signing key, so responders do not have to guess. Cross-reference the CP-2 plan sections so the alternative appears where responders will look during an incident. Confirm the plan lists the rollback steps that return the system to the primary mechanism.

Test plans and test records

SP 800-53A treats the test method as the way to show that the alternative mechanism can perform the function. Keep a written test plan that states the scenario, the primary mechanism taken offline, the expected outcome and the success criteria. Retain dated test records showing who ran the test, which environment was used and what was observed. Tie each test to the version of the system and the alternative configuration that existed at that time, so the record remains meaningful after later changes.

Test results and tracked findings

A passing test is only half the evidence. Assessors also ask what failed, what was corrected and how the correction was verified. Document each test result with its gaps, assign an owner and a due date for every finding, and record the retest. Track unresolved items in the plan of action and milestones so they remain visible until closed. An alternative that worked once but has an open finding about latency or coverage will still draw attention during assessment.

Configuration evidence of the deployed alternative

Assessors test whether the alternative mechanism is actually present and wired into the system, not only described in a document. Keep configuration exports, deployment manifests and change tickets that show the alternative in place, such as a second authentication service, a standby logging destination or an offline signing path. Compare these artifacts with the baseline configuration on a schedule, and capture the evidence again after each change that touches the function the alternative covers.

Personnel role records

Each person who activates or operates an alternative mechanism needs a documented role in the contingency plan and evidence of contingency training. Keep current role assignments, training completion records and access grants for the alternative, including break-glass or offline credentials. Review the list when staff change roles or leave, and remove access that no longer matches a documented responsibility. Interviews under CP-13 often start with these records, so confirm that the people named in the plan can describe the activation steps without reading them aloud.

Why alternative mechanisms fail in testing

The most common reason an alternative security mechanism fails under test is that it depends on the same thing the primary mechanism depends on. CP-13 only has value when the alternative keeps working after the primary is unavailable or compromised. If the backup authentication path relies on the same identity provider, the same directory domain, or the same network segment as the primary, a single outage or intrusion removes both at once. Assessors tend to ask where each alternative gets its trust anchor, which DNS and network path it uses, and whether the team has ever brought up the alternative while the primary was deliberately taken offline. Before a test, confirm in writing which identity source, network path and administrative tooling the alternative uses, and document any shared dependency as a known gap with an owner and a remediation date.

The second failure mode is unmanaged credentials. Many alternative mechanisms exist as break-glass accounts, emergency VPN profiles, offline recovery keys, or secondary administrator tools that were configured once and then left alone. When the test calls for them, the credentials have expired, the sealed copies no longer match the current system, or nobody on the rota knows where the secret is stored. Treat each alternative mechanism as a managed component with an inventory entry, a named custodian, a rotation schedule, and a documented procedure for retrieving and using its credentials. Evidence that the credentials were checked on a schedule, and that the check result was recorded, is usually easier to defend than a statement that the accounts exist.

The third and fourth failure modes are less visible in documents. An alternative that has never been exercised under realistic failure conditions often fails on first use because of a missing license, a firewall rule that only permits traffic from the primary site, or a manual step that assumes an engineer who has since left. Plans also drift: after a platform upgrade, a change of cloud account structure, or a change of tooling vendor, the plan may still describe a mechanism that no longer exists. Ask for test records that show the alternative being invoked, the time taken, the functions it actually performed, and the gaps found. Where the plan and the live environment disagree, the test record should show the correction. Confirm the plan is reviewed after each significant change, since CP-2 and CP-4 are the controls that normally carry that evidence.

What meeting CP-13 costs in money and effort

This table breaks down the cost components of meeting CP-13 Alternative security mechanisms, marking each as one-time or recurring and naming what drives it up or down. Use it to see who is paid for what, then ask each bidder to price every row separately in the written scope. No dollar figures or durations are given because none are supported by NIST or DeployOpen sources.

Cost component	One-time or recurring	What drives it and what to ask for
Engineering to define alternatives	One-time, revisited on change	Number of defined security functions and systems. Ask for the list of functions each alternative covers and the hours assumed per function.
Configuration of alternative mechanisms	One-time per mechanism	Complexity of the primary control being backed up. Ask whether configuration is in the client's environment and who maintains it afterward.
Licenses and tooling	Recurring if commercial, none for self-hosted open source	Choice of commercial versus open-source tooling. Open-source platforms can remove license spend, but engineering and support cost remain. Ask for every license line.
Test effort for alternative mechanisms	Recurring at the frequency the organization defines	Number of tests per year and whether tests include failover of the primary mechanism. Ask what test records and results will be produced.
Evidence upkeep	Recurring	Frequency of test records, changes to the contingency plan and mechanism configuration. Ask who keeps the records and in what system.
External testing or review	Recurring or per engagement	Scope of independent testing and whether it covers the alternative mechanism. Ask for a fixed-scope quote naming the systems in scope.
Auditor sampling and assessment	Recurring per assessment cycle	Assessor testing of the defined functions and the test results. Ask the assessor for its evidence request list before work starts, since the assessor issues the findings.
Change impact when systems change	Recurring, triggered by change	Frequency of system changes that affect the primary or alternative mechanism. Ask how change control will update the mechanism's documentation.

Who owns CP-13 and what a partner can take on

Your organization owns CP-13. That starts with choosing which security functions need an alternative mechanism, since SP 800-53 leaves those choices to the organization through the two organization-defined parameters (CP-13_ODP[01] and CP-13_ODP[02] in SP 800-53A). You also decide the primary means each alternative covers, record the risk you accept when an alternative is weaker than the primary, and approve whether any test runs against production.

Defined parameters: Name the security functions and the conditions under which the alternative activates. These values belong in your system security plan and contingency plan.
Risk acceptance: A named owner signs off on any gap between the alternative and the primary mechanism, with a review date.
Production testing decisions: Your change authority approves whether a failover test touches live identity, logging or access paths.
Contingency plan integration: Your staff keep the procedures for switching to the alternative aligned with CP-2 and the test schedule under CP-4.
Evidence ownership: Your records of test results and plan updates are the artifacts an assessor will request.

Before engaging anyone, confirm which of these decisions your governance process already assigns to a named role.

Common gaps that fail CP-13 and how to close them

CP-13 asks whether an organization has chosen alternative mechanisms for defined security functions and can show they work when the primary means is gone. Most failures are not missing tools but gaps in definition, documentation, testing and access. The cards below cover the gaps assessors most often find and the action that closes each one.

Undefined organization-defined parameters

CP-13 has two organization-defined parameters that the organization must set: the security functions covered and the alternative mechanisms that perform them. Where these are left blank or described only as "appropriate controls," the assessor has nothing to test against. Close the gap by writing each function and its named alternative mechanism into the control statement, with an owner and the condition that triggers use. Check that the values match what the system actually does.

Alternatives missing from the contingency plan

An alternative mechanism that exists only in an engineer's head or a runbook outside the system's documentation will not be found in an examination of the contingency plan. Assessors look for the alternative mechanisms in the plan itself, alongside the essential functions they support. Add each mechanism to the contingency plan, record the activation steps, and confirm the plan version matches the one tested.

Testing availability but not the security function

Many tests confirm that a backup system starts and serves traffic, yet never check that it still enforces authentication, logging, or encryption. CP-13 concerns the security function itself, so a failover that restores service while dropping MFA or audit records fails the requirement. Build a test case for each defined security function that verifies its behavior on the alternative path, and record the results as contingency plan test results.

Shared dependencies between primary and alternative

An alternative mechanism that depends on the same identity provider, logging pipeline, certificate authority or network segment as the primary can fail in the same disruption it is meant to cover. Map each alternative's dependencies and compare them with the primary's. Where they overlap, document the shared component and either separate it or record the accepted risk with an owner and a review date.

Unmanaged break-glass credentials

Alternative paths often rely on emergency accounts, local administrator passwords or offline keys that are rarely rotated and seldom reviewed. These credentials can become the weakest point of the whole design. Store them in a controlled vault with access logging, assign a named custodian, rotate them after each use and test that they work on the alternative path. Record each test in the contingency plan test records.

No link to CP-2 or CP-11

CP-13 is listed as related to CP-2, the contingency plan, and CP-11, alternate communications protocols. A CP-13 mechanism that is not referenced in the plan's recovery objectives, or a communications fallback that does not carry the alternative security mechanisms, leaves a gap between controls. Trace each alternative mechanism to the CP-2 essential function it supports and to any CP-11 protocol it depends on. Confirm the traceability during the annual plan review.

CP-13 questions buyers ask before bringing in help

Is CP-13 required by default under NIST SP 800-53?

No. CP-13 is not selected in any SP 800-53B baseline, including the low, moderate and high baselines and the privacy baseline. It applies only when your organization adds it by tailoring a baseline or through an overlay that selects it. Before you assume it is in scope, check your system's selected baseline, any agency or contract overlay, and your own tailoring decisions. If an assessor or contract clause asks for CP-13, the requirement usually comes from that tailoring or overlay, so ask the requester which document names it.

How much effort does CP-13 take, and what drives it?

Effort depends mainly on how many security functions you have defined for alternative mechanisms and how many parameters your organization sets for CP-13. The control has two organization-defined parameters, so you must decide which alternative mechanisms apply and what they must cover. Other drivers include how many primary mechanisms exist (for example, authentication, logging or monitoring services), how dependent the system is on each one, whether alternatives are already deployed, and how much testing evidence the team must produce. Systems with a small set of well-understood dependencies generally need less work than systems with many chained services.

How long does it take to implement CP-13?

No duration is supplied for this control, so no timeline can be stated here. Ask any implementation partner to tie its schedule to a written scope that lists the defined functions, the systems involved, the alternative mechanisms to build or configure, and the test cycle. Timelines also depend on change approval windows, procurement lead times for any additional tools, and how quickly your staff can review the contingency plan and test results. Confirm these factors with the scope before you commit to dates.

Can our own team implement CP-13 without outside help?

Yes, if your team has the engineering skills and the authority to configure alternative mechanisms and test them. The organization owns its controls, so the decision of which functions need alternatives and what those alternatives must do stays with you. Outside help is typically used to design and build the alternatives, prepare the test records and documentation, and organize evidence for an assessor. An independent assessor or certification body, not a consultant, is the party that issues assessment results or reports. Decide early which parts you will keep in-house and which you will contract out.

What does CP-13 require from our staff?

Staff need to define the security functions that the alternative mechanisms must cover, and they need to know the primary mechanisms those functions depend on. Operators and system owners must be able to explain how the alternatives activate, who decides when to switch, and how security is kept while the alternative is in use. Testing requires people who can run the alternative mechanism, record results and correct gaps. Assessors will interview personnel with system operation responsibilities, so those people must understand the design and be able to describe it accurately.

How does CP-13 relate to CP-2 and CP-11?

The SP 800-53 catalog lists CP-2 and CP-11 as related controls for CP-13, so the three are usually reviewed together. CP-2 covers the system contingency plan, which is where the alternative mechanisms and the conditions for using them should be described. CP-11 covers alternative communications protocols, a closely related resilience control that is also outside the SP 800-53B baselines. Practically, the contingency plan is the document that ties these together, and the test records for CP-13 should be consistent with the CP-2 plan. Check the parameter values in each control so the three do not contradict one another.

Which evidence should we collect to show CP-13 works?

Assessors commonly look for the contingency plan and any continuity of operations plan that describe the alternatives, contingency plan test records, and contingency plan test results showing that the alternative mechanisms performed the defined functions. They may also test the system capability itself. Keep configuration records for each alternative, dated test logs, and records of corrective actions taken after failures. Confirm the exact evidence list with your assessor before testing, because the assessment procedure for CP-13 names these objects and your auditor will expect them.

How DeployOpen prepares CP-13 systems and evidence

DeployOpen plans, implements and documents self-hosted open-source platforms inside the client's own infrastructure, and for CP-13 that work centers on the alternative security mechanisms the organization has defined for its own system. Before any build starts, the scope should name each security function the alternative mechanism must perform, the primary mechanism it stands in for, and the conditions that trigger the switch. Those decisions belong to the organization. DeployOpen's role is to make the alternative mechanism deployable, configurable and documented in the client's cloud accounts, data centers or air-gapped networks, and to prepare the records an assessor will ask for. The organization owns the control. DeployOpen does not issue audit reports, attestations or certifications; independent assessors do.

Testing is where CP-13 becomes provable. DeployOpen runs security testing that includes failover tests of security functions, so the team can show that the alternative mechanism performs its defined function when the primary means is made unavailable in a controlled exercise. The results feed the contingency plan test records and test results that SP 800-53A lists as examine objects, along with the findings and corrective actions that follow. The organization should confirm which test scenarios its assessor will accept and decide who signs off on each result before testing begins.

Engagements are fixed-scope. Scope, deliverables and timelines are agreed in writing before work starts, and the quote follows from that written scope. Work that recurs, such as re-running failover tests after configuration changes or keeping evidence current, can be covered by a retainer for ongoing testing and support. Ask for a written list of deliverables that names the configuration documentation, test plans, test records and the handover format for evidence, so the organization knows what it holds at the end of the engagement and what it must still maintain itself.

CP-13 Alternative security mechanisms