Control statement
Employ [Organization-defined: alternative or supplemental security mechanisms] for satisfying [Organization-defined: security functions] when the primary means of implementing the security function is unavailable or compromised.
Discussion
Use of alternative security mechanisms supports system resiliency, contingency planning, and continuity of operations. To ensure mission and business continuity, organizations can implement alternative or supplemental security mechanisms. The mechanisms may be less effective than the primary mechanisms. However, having the capability to readily employ alternative or supplemental mechanisms enhances mission and business continuity that might otherwise be adversely impacted if operations had to be curtailed until the primary means of implementing the functions was restored. Given the cost and level of effort required to provide such alternative capabilities, the alternative or supplemental mechanisms are only applied to critical security capabilities provided by systems, system components, or system services. For example, an organization may issue one-time pads to senior executives, officials, and system administrators if multi-factor tokens—the standard means for achieving secure authentication— are compromised.
Organization-defined parameters
These values must be resolved through the organization’s tailoring and governance process. Bracketed parameter references in the control text identify where a decision is required.
From control text to operational evidence
Use Alternative Security Mechanisms as a testable risk decision. Translate the official statement into accountable people, repeatable processes, configured technology, and evidence that demonstrates the outcome over time. In this family, pay particular attention to resilient operations, recovery priorities, alternate capabilities, and tested restoration.
Implementation workflow
- Define the control boundary, responsible owner, inherited portions, and systems or processes in scope.
- Resolve each organization-defined parameter before declaring the control implemented.
- Document how the implementation satisfies every clause of the official control statement.
- Collect evidence as a normal byproduct of operation rather than only before an assessment.
- Review exceptions, changes, and monitoring results on a risk-based cadence.
Evidence examples
- contingency and recovery plans
- backup success and restoration-test records
- exercise after-action reports
- alternate processing or communications agreements
Common failure patterns
- backups never restored in testing
- recovery priorities not tied to mission impact
- plans dependent on unavailable people or facilities
- exercise findings not tracked to closure
Questions practitioners should ask
- What risk decision is this control intended to support in this system?
- Which parts are implemented locally, inherited, shared, or not applicable—and what evidence supports that decision?
- Do the documented narrative, deployed configuration, operating process, and collected evidence agree?
- What event or threshold requires the implementation to be reviewed or changed?
Assessment objectives and methods
Show the assessment objective
[Organization-defined: alternative or supplemental security mechanisms] are employed for satisfying [Organization-defined: security functions] when the primary means of implementing the security function is unavailable or compromised.
Examine
- Contingency planning policy
- procedures addressing alternate security mechanisms
- contingency plan
- continuity of operations plan
- system design documentation
- system configuration settings and associated documentation
- contingency plan test records
- contingency plan test results
- system security plan
- other relevant documents or records
Interview
- Organizational personnel with system operation responsibilities
- organizational personnel with information security responsibilities
Test
- system capability implementing alternative security mechanisms
Related controls
These relationships come from the official OSCAL catalog. They indicate useful dependencies or context, not automatic inheritance or equivalence.
Authoritative sources
Bare Metal Cyber is an independent educational publisher and is not affiliated with or endorsed by NIST. Official control requirements and interpretations remain with NIST and the responsible authorizing organization.