SA-20: Customized Development of Critical Components

SA-20 requires you to identify which “critical system components” you cannot adequately trust from external sources and then reimplement or custom develop those components under your control, with traceable engineering and assurance evidence. To operationalize it fast, define your “critical components” list, set decision criteria for “custom vs. buy,” and run a documented secure development and verification workflow for each in-scope component. ¹

Key takeaways:

• You need a named list of critical components and a clear rationale for why each is “critical” in your environment.
• Compliance depends on proving controlled development: requirements, design, code provenance, testing, approvals, and release gating.
• Auditors look for ownership, repeatable triggers (new component, major change), and a minimum evidence bundle per component.

The sa-20: customized development of critical components requirement is a supply chain risk control that forces a hard choice: for specific components that are truly “critical,” you either reimplement them or build them yourself so you can verify integrity and reduce exposure to hidden functionality, insecure dependencies, or unbounded third-party update risk. The control text is short, but implementation is not; teams fail SA-20 most often because they treat it like a policy statement instead of an engineering decision backed by evidence.

For a Compliance Officer, CCO, or GRC lead, the fastest path is to translate SA-20 into a small set of operational mechanisms: (1) an explicit definition of “critical component” for your system, (2) a governed inventory of those components, (3) a documented decision record for why each is custom-developed or reimplemented, and (4) a repeatable SDLC workflow that produces audit-ready artifacts.

This page gives requirement-level guidance you can hand to engineering and security leaders, then track through control ownership, evidence collection, and control health checks aligned to NIST SP 800-53 Rev. 5. ²

Regulatory text

SA-20 (Customized Development of Critical Components): “Reimplement or custom develop the following critical system components: {{ insert: param, sa-20_odp }}.” ¹

What the operator must do

• Decide which components are “critical” in your system context (the control expects you to fill in the organization-defined parameter).
• For those components, do not rely solely on externally provided implementations. Instead, reimplement (build your own version of an externally available component) or custom develop (build it in-house or under your direct contractual and technical control).
• Prove control and integrity. “Custom develop” in practice means you can show provenance, secure development practices, review/testing, and release governance for the component.

Plain-English interpretation (what SA-20 is really testing)

SA-20 tests whether you can reduce supply chain risk for the parts of your system that would cause the most damage if compromised. “Critical” usually means components that:

• enforce trust boundaries (identity, authn/authz, cryptographic services),
• control privileged access or policy decisions,
• handle sensitive data at scale,
• are embedded in the platform such that compromise is hard to detect or recover from.

An auditor is looking for disciplined scoping and proof you can stand behind the component’s integrity. If you cannot explain why a component is critical, or you cannot show how you control its development and updates, SA-20 will read as “not implemented.”

Who it applies to (entity and operational context)

SA-20 commonly applies where NIST SP 800-53 is the governing framework, including:

• Federal information systems and programs inheriting NIST SP 800-53 controls. ²
• Contractor systems handling federal data where NIST controls are flowed down via contract requirements or assessment regimes aligned to NIST SP 800-53. ²

Operationally, SA-20 matters most in environments that:

• ship production software,
• integrate open-source dependencies,
• consume third-party services with deep system privileges,
• deploy firmware/agents/drivers, or
• operate regulated/mission systems where a single compromised component can defeat other controls.

What you actually need to do (step-by-step)

Use this as the runbook you can assign to an engineering owner and track in GRC.

Step 1: Define “critical component” criteria (and get formal sign-off)

Create written criteria that a reasonable reviewer would accept. Keep it short and decision-oriented. Example criteria:

• Component performs authentication/authorization, key management, cryptographic operations, or policy evaluation.
• Component runs with system/root/admin privileges or can change system configuration.
• Component sits on the boundary between untrusted and trusted networks.
• Component failure or compromise would cause major confidentiality/integrity/availability impact.

Evidence tip: require approval by Security Architecture plus the system owner.

Step 2: Build the “SA-20 Critical Components List” (inventory + rationale)

Create a living list that includes:

• component name,
• where it runs (service/host/container),
• function,
• why it is critical (mapped to your criteria),
• current source (third party, open source, internal),
• decision: reimplement, custom develop, or out-of-scope (with justification),
• owner and review date.

This list is your auditor’s starting point. Treat it like a controlled artifact.

Step 3: Define acceptable implementation patterns (custom vs. reimplement)

Create a decision matrix. Example:

Decision	Use when	Minimum expectations
Custom develop	You need full control over roadmap, security posture, and update process	Documented requirements, secure coding, testing, review gates, controlled releases
Reimplement	A reference exists, but you do not trust its supply chain or need tighter assurance	Clear spec, test parity against requirements, independent codebase and build pipeline
Not SA-20 scoped	Component is not “critical” by your criteria	Written rationale and periodic re-evaluation

Step 4: Put the development under a controlled SDLC with traceable provenance

For each SA-20 component, require:

• documented security requirements and threat considerations,
• design review (security and engineering),
• code review standards,
• dependency controls (pinning, approval for new deps),
• build integrity controls (reproducible builds where feasible; signed artifacts where applicable),
• test coverage expectations that map to the component’s risk (unit, integration, negative testing, security tests),
• release gating and rollback plan.

You are not being asked to invent a perfect SDLC. You are being asked to show disciplined control over these components.

Step 5: Create an “SA-20 evidence bundle” per component and per release

Define what “done” means and where evidence lives. Keep it consistent to reduce audit friction. ¹

Minimum bundle (practical baseline):

• criticality decision record (why in-scope),
• requirements + security requirements,
• design artifacts (diagram + key decisions),
• code provenance (repo, commit history, PR reviews),
• test results (CI logs, security test outputs),
• approval record for release,
• deployment record (what version shipped, where),
• exceptions (any waived steps, who approved, compensating controls).

Step 6: Operationalize triggers and cadence

SA-20 is not a “once” control. Define triggers:

• new critical component added,
• major version rewrite,
• major change to trust boundary behavior,
• change in cryptographic approach,
• significant incident implicating the component.

Then run periodic control health checks to confirm the list is current and evidence bundles exist for recent changes. ¹

Step 7: Make it auditable: assign ownership and establish oversight

Put a single owner on the control (often Security Architecture or Product Security) and component-level owners (service owners). Use a simple control card:

• objective,
• scope,
• triggers,
• steps,
• evidence,
• exception process,
• review/attestation workflow. ¹

Daydream (as a workflow) fits naturally here by turning your SA-20 control card, evidence bundle definition, and health checks into assigned tasks with due dates and a single audit-ready evidence location.

Required evidence and artifacts to retain

Auditors typically want to see evidence that is both design-time and run-time.

Core artifacts

• SA-20 control card (owner, scope, triggers, steps, exceptions)
• Critical components list (with rationale and approvals)
• Per-component decision record (custom vs. reimplement)
• Secure development workflow definition (SDLC gates for SA-20 components)
• Per-release evidence bundles (requirements → code → tests → approvals → deployment)
• Exceptions and compensating controls register
• Control health check records and remediation tracking to closure ¹

Retention approach

• Store in a system with access control and immutable history where possible (ticketing + repo + CI logs).
• Ensure you can produce artifacts per component quickly, not by hunting across Slack threads.

Common exam/audit questions and hangups

Expect questions like:

• “Show me your list of critical components and who approved it.”
• “How do you define criticality, and how often do you reassess?”
• “For this component, why is it custom developed rather than procured?”
• “Prove integrity: show code review, test evidence, and release approval for the last significant change.”
• “How do you handle emergency fixes without breaking the required gates?”
• “Where is the evidence stored, and who can alter it?”

Hangups that drive findings:

• “Critical” is undefined or defined so broadly that the organization cannot realistically meet SA-20.
• The list exists, but it is stale and not tied to engineering reality.
• Evidence exists but is not traceable per component/per release.

Frequent implementation mistakes (and how to avoid them)

1. Treating “custom develop” as “we configured a third-party product.”
   Fix: “Custom develop” should mean you control the code and build/release process for the component.

2. Scoping everything as critical.
   Fix: Use tight criteria and defendable rationale. Over-scoping guarantees evidence gaps.

3. No decision records.
   Fix: Require a lightweight template that captures criticality, choice (reimplement/custom), and approvals.

4. Evidence lives in too many places.
   Fix: Define the minimum evidence bundle and a single pointer per component (folder, ticket, or GRC record).

5. Exceptions are informal.
   Fix: Add an exception workflow with time bounds and compensating controls documented.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement. Practically, SA-20 failures increase exposure to:

• software supply chain compromise risk,
• inability to prove integrity to customers/assessors,
• control inheritance misunderstandings (assuming a third party’s assurance equals yours for critical functions).

Even without enforcement citations, auditors and customer diligence teams commonly treat supply chain controls as high-scrutiny because they determine whether downstream controls can be trusted.

A practical 30/60/90-day execution plan

Use this phased approach; adjust based on engineering release cycles and system complexity.

First 30 days (Immediate)

• Assign SA-20 control owner and component owners.
• Draft criticality criteria and get Security Architecture sign-off.
• Create the first critical components list with top-priority components.
• Define the SA-20 evidence bundle template and storage location.
• Pick one pilot component and build the evidence bundle end-to-end. ¹

Days 31–60 (Near-term buildout)

• Expand inventory coverage across major systems/products in scope.
• For each in-scope component, complete the decision record (custom vs. reimplement).
• Integrate SDLC gates into engineering workflow (PR requirements, CI checks, release approval).
• Stand up an exception process (who can approve, required compensating controls). ¹

Days 61–90 (Operationalize and prove repeatability)

• Run the first control health check: verify the list is current and evidence bundles exist for recent releases.
• Remediate gaps to closure with tracked actions and due dates.
• Prepare an “audit packet” view: control card + inventory + 2–3 component evidence bundles.
• Automate reminders and evidence collection where possible; Daydream can act as the system of record for control operation and evidence pointers. ¹

Frequently Asked Questions

What counts as a “critical system component” for SA-20?

SA-20 expects you to define this based on your system and risk. Commonly critical components enforce trust boundaries (identity, authorization, crypto) or run with high privilege and broad access. Document the criteria and apply it consistently. ¹

Does SA-20 ban open source or third-party components?

No. SA-20 targets the subset you designate as “critical.” For those, you must reimplement or custom develop, which usually means you cannot depend solely on an externally produced implementation for that critical function. ¹

If we outsource development to a third party, does that meet “custom develop”?

It can, if you maintain direct control through contracts and technical governance: you own requirements, review code, control the build/release pipeline, and retain evidence. If the third party ships opaque binaries with minimal transparency, it will be hard to defend as “custom develop.”

What evidence is the fastest way to satisfy auditors?

Start with a signed-off critical components list and one complete evidence bundle for a pilot component (requirements, design review, code review, test results, release approval). Auditors respond well to traceability from decision to release.

How do we handle emergency fixes without violating SA-20 gates?

Define an emergency change path that still captures minimum evidence: rationale, approver, code review, test evidence (even if reduced), and post-release review. Track it as an exception with compensating controls.

How does SA-20 relate to broader supply chain controls?

SA-20 is a targeted control inside the NIST SP 800-53 System and Services Acquisition family. It complements broader third-party and supply chain risk work by forcing higher assurance for the few components that can negate other controls if compromised. ²

Footnotes

1. NIST SP 800-53 Rev. 5 OSCAL JSON

2. NIST SP 800-53 Rev. 5