Quick-reference card
| Field | Value |
|---|---|
| Control ID | SA-20 |
| Control Name | Customized Development of Critical Components |
| Framework | NIST SP 800-53, Revision 5 |
| Control Family | System and Services Acquisition |
| Baselines | None |
| Relevance | Organization (First Party) |
| Risk Severity | Medium |
What this control requires
SA-20 requires organizations to reimplement or custom-develop critical system components when standard commercial products can’t be trusted to resist targeted attacks. This control exists because some hardware, software, or firmware components carry specific vulnerabilities that available security controls can’t adequately mitigate, forcing organizations to build trusted alternatives from the ground up.
The core obligation centers on identifying components where known threats and vulnerabilities create unacceptable risk, then making a deliberate build-or-buy decision. When organizations determine that off-the-shelf components are fundamentally compromised or compromisable, they must initiate changes through reimplementation or custom development so that standard adversary techniques are less likely to succeed.
In situations where custom development isn’t feasible, the control doesn’t leave organizations without options. Compensating measures include enhanced auditing of the untrusted component, restricting access to source code and system utilities, and protecting system and application files from unauthorized deletion. These alternative controls acknowledge the reality that not every organization can rebuild critical components, while still requiring meaningful risk reduction.
Why it matters
Organizations that skip SA-20 expose their most sensitive systems to the exact threats this control was designed to counter. Adversaries exploit known weaknesses in standard components that no available patch or configuration can fix. Auditors reviewing NIST SP 800-53 compliance will flag the absence of a documented decision process for critical components as a gap in supply chain risk management.
Without a structured approach to evaluating component trustworthiness, security teams can’t demonstrate due diligence during audits or regulatory reviews. This gap becomes particularly problematic for organizations in defense, intelligence, critical infrastructure, and other sectors where adversaries actively target supply chain dependencies. Organizations pursuing ISO 27001 certification face similar scrutiny around supplier risk management and component assurance.
Failure to address this control also weakens your overall System and Services Acquisition posture. Assessors look for evidence that you’ve evaluated which components warrant custom development and documented compensating controls for those you chose to accept as-is. A missing supply chain risk management plan or absent criticality analysis signals systemic risk governance failures.
What attackers exploit
- Compromised firmware and hardware components: Adversaries embed persistent backdoors in firmware that survive reboots, re-imaging, and standard endpoint detection, giving them long-term access below the operating system layer.
- Trojanized software libraries and dependencies: Attackers insert malicious code into widely-used open-source or commercial libraries, knowing that organizations trust these components without independent verification.
- Supply chain insertion points: Nation-state actors and advanced persistent threats target manufacturing and distribution channels to modify components before they reach the customer, bypassing all downstream security controls.
- Unpatched vulnerabilities in legacy components: When vendors abandon support for critical components or no viable patch exists, attackers exploit known vulnerabilities with commodity tooling.
- Insufficient source code review processes: Organizations that deploy critical components without reviewing source code or verifying build integrity create blind spots that adversaries use to maintain covert access.
How to implement
For your organization
The central challenge with SA-20 is that most organizations have never formally evaluated which system components qualify as “critical” or determined whether those components can be trusted against targeted attacks. Without that foundation, the control’s requirements remain abstract.
Step 1: Conduct a criticality analysis. Start by identifying which system components are critical to your mission or business operations. Map each component to the threats it faces and the vulnerabilities it carries. Use your system security plan and the output from RA-09 (Criticality Analysis) to prioritize components where standard attacks could succeed despite existing controls. Document which components fall into the “cannot be adequately protected with available controls” category.
Step 2: Evaluate trust and sourcing options. For each critical component, assess whether the vendor’s supply chain, development practices, and security track record provide sufficient assurance. Look at factors like the vendor’s vulnerability disclosure history, whether source code is available for review, and whether the component has been independently tested. Record your findings in your supply chain risk management plan.
Step 3: Make and document the build-or-buy decision. For components that fail the trust evaluation, determine whether reimplementation or custom development is feasible given your resources and timeline. If you choose to build, define the development approach using your system development life cycle (SDLC) documentation, ensuring you apply security and privacy engineering principles aligned with SA-08. If custom development isn’t practical, document which compensating controls you’ll apply instead.
Step 4: Implement compensating controls where custom development isn’t feasible. When you can’t reimplement a component, layer additional protections. Enable enhanced auditing on the component to detect anomalous behavior. Restrict access to source code repositories and system utilities that could modify the component. Implement file integrity monitoring to protect system and application files from unauthorized changes. Each compensating control should tie to the specific risk you identified in your criticality analysis.
Step 5: Integrate into configuration management and ongoing monitoring. Track all critical components, their trust status, and applied controls in your configuration management records. Establish a review cadence to reassess component trustworthiness as threat landscapes evolve, new vulnerabilities emerge, or vendor circumstances change. Common tooling categories include software composition analysis platforms, firmware verification tools, and supply chain risk management solutions.
Common mistakes to avoid:
- Treating SA-20 as a one-time assessment rather than an ongoing process
- Failing to document the rationale for accepting commercial components without modification
- Applying compensating controls without linking them to specific identified risks
- Overlooking firmware and hardware components in favor of software-only analysis
Evidence examples
| Evidence Type | Example Artifact |
|---|---|
| Risk management plan | Supply chain risk management plan identifying critical components, their threat profiles, and trust evaluation criteria |
| Policy documentation | System and services acquisition policy defining when custom development or reimplementation is required versus when compensating controls are acceptable |
| Development procedures | Procedures for customized development of critical system components, including SDLC phases, security testing requirements, and approval gates |
| Design documentation | System design records showing architecture decisions for reimplemented or custom-developed components, including threat models and security requirements |
| Configuration records | Configuration management records tracking critical component versions, trust status, applied compensating controls, and change history |
| Audit evidence | System audit records demonstrating enhanced monitoring of components where compensating controls replaced custom development |
| Security planning | System security plan sections addressing critical component identification, trust evaluation outcomes, and selected risk treatment approaches |
Cross-framework mapping
No applicable cross-framework mappings for this control.
Related controls
- CP-02 — Contingency Plan: Contingency planning must account for the failure or compromise of critical components that SA-20 identifies, ensuring recovery strategies address custom-developed or reimplemented elements.
- RA-09 — Criticality Analysis: RA-09 feeds directly into SA-20 by identifying which system components are critical enough to warrant trust evaluation and potential reimplementation.
- SA-08 — Security and Privacy Engineering Principles: Custom-developed components under SA-20 must follow the engineering principles defined in SA-08 to ensure security is built into reimplemented components from the start.
Frequently asked questions
What is NIST SP 800-53 SA-20
SA-20 requires organizations to reimplement or custom-develop critical system components that can’t be adequately protected by available security controls against targeted attacks. The control applies when specific threats and vulnerabilities in hardware, software, or firmware make standard commercial products untrustworthy for your environment. Your supply chain risk management plan should document which components meet this threshold and what action you’ve taken. When custom development isn’t feasible, SA-20 also accepts compensating controls like enhanced auditing and restricted source code access.
What happens if SA-20 is not implemented
Without SA-20, your organization lacks a formal process for identifying and addressing critical components vulnerable to targeted supply chain attacks. Auditors reviewing your system security plan will flag the missing criticality analysis and absent documentation of build-or-buy decisions. This gap can result in audit findings, delayed authorizations to operate, and unmanaged exposure to adversaries who specifically target trusted components in your technology stack.
How do you audit SA-20
Auditors verify SA-20 by reviewing your supply chain risk management plan, criticality analysis outputs, and any procedures addressing customized development of critical system components. They’ll examine whether reimplemented components follow your documented SDLC process and whether compensating controls are applied where custom development wasn’t pursued. Evidence like configuration management records, system audit logs showing enhanced monitoring, and design documentation for rebuilt components all demonstrate compliance.
What are compensating controls if custom development is not feasible
When reimplementation isn’t practical, organizations can apply enhanced auditing to detect anomalous behavior in untrusted components, restrict access to source code and system utilities, and implement protections against unauthorized deletion of system and application files. These compensating controls must be documented in your system security plan and tied to the specific risks identified during your criticality analysis. Effective compensating controls address the same threat vectors that custom development would have eliminated, even if they operate at a different layer in your security architecture.