RA-9: Criticality Analysis

Quick-reference card

What this control requires

RA-09 requires organizations to identify their most critical system components and functions by performing a structured criticality analysis at defined points in the system development life cycle. Most organizations treat all components equally, applying the same baseline protections to authentication servers and low-consequence workstations alike. This control exists to break that pattern and force a deliberate ranking of what matters most.

The core activity is functional decomposition. Organizations break down each system into the specific missions it supports, trace those missions to the functions that execute them, and map those functions to the hardware, software, and firmware components that make them work. The result is a documented hierarchy showing which components are mission-critical and which aren’t, including dependencies on external services, cyber-physical systems, and outsourced IT.

Criticality analysis isn’t a one-time exercise. It should happen whenever an architecture is designed, modified, or upgraded, and it should account for the operational environment in which components actually run. Components that provide unmediated access to critical functions inherit critical status by default, regardless of their own standalone importance. The analysis also feeds directly into security categorization under RA-02, connecting component-level criticality to the broader risk assessment techniques that drive protection decisions.

Why it matters

Organizations that skip criticality analysis don’t just miss a compliance checkbox. They lose the ability to make principled decisions about where to focus limited security resources. When every component receives the same baseline protections, the components handling private keys, processing authentication, managing software deployment, or controlling physical safety systems get the same scrutiny as commodity hardware that could be replaced in hours.

In practice, this gap creates a direct opening for targeted attackers. An adversary conducting pre-intrusion reconnaissance will identify which components handle the most sensitive functions and prioritize those for exploitation. The organization, having never documented which components are critical, has no basis for applying differential controls, enhanced monitoring, or greater supply chain scrutiny to those assets.

The connection to supply chain attacks is especially direct. Attackers investing in hardware supply chain compromise (T1195.003) selectively place implants and firmware backdoors in components destined for high-value network positions. They target routers handling sensitive traffic, servers running authentication services, and storage appliances holding encryption keys. Organizations that have performed criticality analysis know which procurement channels and component categories warrant enhanced due diligence. Those that haven’t apply it nowhere.

Firmware corruption (T1495), system firmware persistence (T1542.001), and bootkit persistence (T1542.003) represent the downstream consequences. A compromised critical component deployed without the additional scrutiny that criticality status would have triggered becomes a persistent foothold. Attackers can also modify network device operating systems (T1601) on components that were never flagged as critical, maintaining access through infrastructure the organization never thought to monitor closely.

What attackers exploit

• Uniform security baselines that leave mission-critical components unprotected relative to their actual value
• Absence of supply chain due diligence on high-value hardware procurement channels (T1195.003)
• Firmware and boot process integrity gaps on components never classified as critical (T1495, T1542.001, T1542.003)
• Unmonitored network device operating systems on infrastructure components lacking criticality designations (T1601)
• Lack of documented component dependencies, allowing attackers to compromise one critical node and pivot through connected systems

Conducting a thorough cyber risk analysis before and during system design helps organizations identify these exposure points before attackers do.

How to implement

For your organization

The most common failure mode is treating criticality analysis as a documentation exercise rather than an operational input. Teams produce a spreadsheet of component classifications during initial system authorization, file it with the system security plan, and never revisit it when architectures change, new dependencies emerge, or threat landscapes shift.

Step 1: Inventory mission-to-component traceability. Start by listing the organizational missions each system supports. For each mission, identify the specific functions required to perform that mission. Then trace each function to the hardware, software, and firmware components that implement it. This functional decomposition should capture shared components, meaning a single authentication server that supports multiple mission-critical functions inherits the highest criticality level among them.

Step 2: Assess component and function criticality. Evaluate each component and function in terms of the impact of its failure on the missions the system supports. Account for the operational environment, including connections to cyber-physical systems, dependencies on outsourced IT services, and components that provide unmediated access to critical functions. Components enabling direct access to critical functions are classified as critical by default.

Step 3: Integrate criticality into the development life cycle. Perform criticality analysis at defined decision points, not just during initial design. Architecture modifications, system upgrades, and changes to the operational environment should all trigger a review. Early analysis during design can reduce the critical nature of components through redundancy, alternate paths, or architectural changes that eliminate single points of failure.

Step 4: Feed results into downstream controls. Criticality designations should directly inform protection measures, monitoring intensity, supply chain due diligence requirements, and vendor tiering decisions. Development contractors should receive criticality-informed requirements. Procurement channels for critical components should receive enhanced scrutiny.

Step 5: Maintain and update. Establish a review cadence tied to system change management processes. When components are added, removed, or repositioned in the architecture, update the criticality analysis accordingly.

Common tooling categories include asset management platforms, configuration management databases, system architecture modeling tools, and risk management frameworks that support functional decomposition and dependency mapping.

Common mistakes to avoid:

• Classifying components by cost or visibility instead of mission impact
• Failing to account for shared components that support multiple critical functions
• Treating the analysis as a point-in-time artifact rather than a living document
• Ignoring dependencies on external services and outsourced IT when assessing vendor criticality
• Not flowing criticality designations into supply chain and procurement decisions

Evidence examples

Cross-framework mapping

Related controls

• CP-02 — Contingency Plan: contingency planning depends on criticality analysis to prioritize recovery of mission-critical components and functions first.
• PL-02 — System Security and Privacy Plans: the system security plan documents how criticality designations inform protection measures and monitoring requirements.
• PL-08 — Security and Privacy Architectures: security architecture decisions should reflect criticality analysis results, placing stronger controls around high-criticality components.
• PL-11 — Baseline Tailoring: criticality analysis results directly inform how organizations tailor security baselines to apply stronger protections where impact is greatest.
• PM-01 — Information Security Program Plan: the information security program plan should reference criticality analysis as a key input to resource allocation and prioritization.
• PM-11 — Mission and Business Process Definition: mission and business process definitions feed directly into the functional decomposition that criticality analysis requires.
• RA-02 — Security Categorization: security categorization uses criticality analysis results to determine the appropriate impact levels for systems and information.
• SA-08 — Security and Privacy Engineering Principles: engineering principles guide how organizations reduce the critical nature of components through redundancy and alternate paths.
• SA-15 — Development Process, Standards, and Tools: development standards and tools should incorporate criticality-informed requirements from the analysis.
• SA-20 — Customized Development of Critical Components: components identified as critical through RA-09 analysis may require customized development to reduce supply chain risk.

Frequently asked questions

What is NIST SP 800-53 RA-09?

RA-09 requires organizations to perform a criticality analysis that identifies which system components and functions are mission-critical, based on the consequences of their failure. The analysis involves functional decomposition, tracing organizational missions to the specific functions and hardware, software, and firmware components that implement them. Organizations must perform this analysis at defined decision points in the system development life cycle, not as a one-time activity. RA-09 applies to systems operating at MODERATE and HIGH baselines.

What happens if RA-09 is not implemented?

Without criticality analysis, organizations apply uniform security baselines across all components, leaving mission-critical assets no better protected than low-consequence ones. Attackers conducting pre-intrusion reconnaissance can identify high-value targets like authentication servers and key management systems while the organization has no documented basis for differential protection. Supply chain due diligence becomes unfocused because there is no principled method for determining which procurement channels and component categories warrant enhanced scrutiny. The result is that the components most valuable to an attacker receive the least proportionate protection.

How do you audit RA-09?

Auditors verify that a documented criticality analysis exists for each in-scope system and that it includes a functional decomposition tracing missions to functions to implementing components. They confirm that criticality designations are assigned based on the impact of component or function failure on organizational missions, not on subjective criteria like cost or visibility. Auditors also check that the analysis was performed at the decision points specified in the organization’s policy and that results flow into downstream controls, including protection measures, monitoring intensity, and supply chain requirements.

When should criticality analysis be performed?

Criticality analysis should be performed whenever a system architecture is designed, modified, or upgraded. Early analysis during the system development life cycle allows organizations to reduce the critical nature of components through design changes such as adding redundancy or alternate paths. The analysis should also be revisited when the operational environment changes, including new dependencies on cyber-physical systems, outsourced IT services, or external system-of-systems integrations.