SA-10(1): Software and Firmware Integrity Verification

SA-10(1) requires you to contractually and operationally require the developer of your system, component, or service to provide a way to verify the integrity of software and firmware. To operationalize it fast, you need explicit supplier requirements (signing/hash support), acceptance testing that proves verification works, and repeatable evidence that integrity checks are available and used. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Key takeaways:

• Put “integrity verification enabled” into procurement language, SOWs, and technical acceptance criteria, not just security policy. (NIST SP 800-53 Rev. 5)
• Prove the mechanism works: validate signatures/hashes on delivered builds, firmware images, updates, and boot components. (NIST SP 800-53 Rev. 5 OSCAL JSON)
• Keep audit-ready artifacts: requirements, supplier attestations, test results, and operational runbooks that show checks occur in real change flows. (NIST SP 800-53 Rev. 5)

The sa-10(1): software and firmware integrity verification requirement is a supply chain control disguised as a software assurance requirement. It does not ask you to “scan for malware” in the abstract. It asks you to ensure the developer (internal engineering, a third party software publisher, an OEM, a managed service provider delivering images, or a firmware supplier) has enabled integrity verification for the software and firmware you run. (NIST SP 800-53 Rev. 5 OSCAL JSON)

For a Compliance Officer, CCO, or GRC lead, the fastest path is to translate SA-10(1) into three things you can inspect and evidence: (1) contractual/requirements language that obligates integrity verification features, (2) technical verification during intake and change management, and (3) operational procedures that keep verification “on” across patching, upgrades, and emergency fixes. (NIST SP 800-53 Rev. 5)

This page gives requirement-level implementation guidance you can hand to procurement, engineering, platform teams, and vendor management. It also frames what assessors typically look for: clear applicability, unambiguous supplier obligations, repeatable testing, and artifacts that prove integrity verification is feasible for the components in scope. (NIST SP 800-53 Rev. 5)

Regulatory text

Excerpt (control enhancement SA-10(1)): “Require the developer of the system, system component, or system service to enable integrity verification of software and firmware components.” (NIST SP 800-53 Rev. 5 OSCAL JSON)

Operator meaning (what you must do):

• You must require the developer to provide a workable integrity verification capability for delivered software and firmware. “Require” is satisfied through binding internal SDLC requirements for in-house development and binding third party terms (contract/SOW/acceptance criteria) for external developers. (NIST SP 800-53 Rev. 5)
• “Enable integrity verification” means the delivered component must support a mechanism you can actually run to confirm it was not modified (for example, vendor-provided signing, checksums/hashes, secure boot measurements, or another verifiable integrity mechanism appropriate to the component). SA-10(1) is not satisfied by a statement of intent without a testable method. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Plain-English interpretation

You are accountable for proving that software and firmware you deploy can be checked for tampering, and that the party who builds it has made that check possible. This is mainly a supplier requirement plus verification step: if you cannot verify integrity, you cannot confidently accept the component into production or safely apply updates.

Think of SA-10(1) as an “ingress control” for code and firmware:

• Before you install or update, you must be able to confirm you got what the developer intended to ship.
• If the developer cannot provide a verification method, you treat that as a risk exception with compensating controls, not as “close enough.”

Who it applies to

Entity scope

• Federal information systems and contractor systems handling federal data commonly inherit SA-family expectations in their security control baselines and assessments. (NIST SP 800-53 Rev. 5)

Operational scope (where this shows up)

• In-house development: your SDLC and release engineering must publish integrity artifacts (signatures/hashes) and verification instructions for each release. (NIST SP 800-53 Rev. 5 OSCAL JSON)
• Third party software (COTS/SaaS agents, endpoint tools, database binaries): procurement and security engineering must ensure the publisher provides integrity verification for installers, packages, and updates. (NIST SP 800-53 Rev. 5)
• Firmware and embedded components: OEM/ODM firmware, BIOS/UEFI, network gear firmware, storage controllers, IoT. Integrity verification must exist for images and update channels. (NIST SP 800-53 Rev. 5 OSCAL JSON)
• System services: managed service providers delivering images/containers/appliances. You need a verification mechanism for delivered artifacts and update pipelines. (NIST SP 800-53 Rev. 5)

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

1) Assign ownership and define “in scope”

1. Name a control owner in GRC (often AppSec, Platform Security, or Secure Engineering) and a business owner for supplier enforcement (often Procurement/Vendor Management). (NIST SP 800-53 Rev. 5)
2. Define scope categories:
   • Software you build
   • Software you buy
   • Firmware you deploy
   • Service-delivered artifacts (images, containers, agents) (NIST SP 800-53 Rev. 5 OSCAL JSON)
3. Set an applicability rule: integrity verification is required for production deployments and for any update path that can change executable code or firmware.

2) Convert SA-10(1) into developer requirements (contract + engineering)

Create a short, enforceable requirement set that engineering and procurement can use.

Minimum requirement statements (examples you can adapt):

• Developer must provide integrity verification instructions and artifacts for each release (hashes and/or digital signatures) covering installers/packages/firmware images and updates. (NIST SP 800-53 Rev. 5 OSCAL JSON)
• Developer must publish a secure distribution method for verification artifacts (for example, a signed release manifest) and document key management expectations for signature verification where applicable. (NIST SP 800-53 Rev. 5)
• Developer must support customer-side verification as part of operational change workflows (patching, upgrades, rollback). (NIST SP 800-53 Rev. 5 OSCAL JSON)

Where to place them

• For third parties: master agreement security addendum, SOW, and acceptance criteria for go-live.
• For internal dev: SDLC policy, CI/CD release checklist, and definition-of-done for release packaging.

3) Build an intake and acceptance test that proves verification works

Define a standard “integrity verification test” executed whenever you onboard a new component or new major version.

Acceptance test checklist

• Obtain the supplier’s official verification method (signed manifest, checksum file, signature chain, firmware verification procedure). (NIST SP 800-53 Rev. 5 OSCAL JSON)
• Verify one release end-to-end in a non-production environment:
  • Download artifact from official channel
  • Validate signature or compare hash against supplier-provided values
  • Record tool output/logs as evidence (screenshots are acceptable if logs are not available)
  • Confirm procedure is repeatable by someone outside the dev team (reduce key-person risk) (NIST SP 800-53 Rev. 5)
• For firmware: confirm how integrity is validated during update and, if applicable, during boot (document what the platform supports and what you check). (NIST SP 800-53 Rev. 5 OSCAL JSON)

4) Operationalize in change management (make it routine)

You need integrity verification embedded in the workflows that change code.

Operational controls to implement

• Add a required change ticket field: “Integrity verification performed? Evidence attached?” for software/firmware changes.
• Update runbooks for patching and emergency changes to include integrity verification steps before deployment.
• For CI/CD: publish release artifacts with signing/hashes and require pipeline gates that verify artifact integrity before promotion to production. (NIST SP 800-53 Rev. 5)

5) Handle exceptions explicitly

Some legacy components will not support meaningful integrity verification.

Exception handling expectations

• Document why integrity verification is not possible (supplier limitation, technical constraints).
• Require compensating controls (tighter source restrictions, isolation, monitoring, restricted admin paths) and a remediation plan (replacement, upgrade path, contract renegotiation). (NIST SP 800-53 Rev. 5)

6) Keep the control “alive” with recurring checks

SA-10(1) fails in audits when it’s treated as a one-time onboarding step.

Recurring activities you can defend:

• Periodic sampling of recent changes to confirm integrity checks were performed and evidenced.
• Supplier reassessment triggers: new firmware line, new updater mechanism, acquisition/major distribution change, or a switch in hosting channel. (NIST SP 800-53 Rev. 5)

Required evidence and artifacts to retain

Keep evidence that matches the requirement’s verbs: require and enable.

Artifact	What it proves	Owner
Contract/SOW security requirements or internal SDLC requirement stating integrity verification must be enabled	You “required the developer”	Procurement + GRC / Engineering Governance
Supplier documentation describing integrity verification method (release signing, checksums, verification procedure)	Verification is “enabled” and defined	AppSec / Platform Security
Acceptance test record (ticket, test plan, logs/screenshots showing verification succeeded)	You validated the method works	Engineering / IT Ops
Change tickets with attached verification outputs for updates	Integrity verification is operational, not shelfware	Change Mgmt / Ops
Exception register entries with approvals and compensating controls	Managed risk where verification isn’t feasible	GRC

Daydream fits here as a control operations layer: map SA-10(1) to an owner, a repeatable procedure, and a recurring evidence set so audits don’t depend on tribal knowledge. (NIST SP 800-53 Rev. 5)

Common exam/audit questions and hangups

Assessors and internal audit teams usually push on these points:

1. “Show me where you require this of developers.” They will ask for contract clauses or SDLC requirements, not a policy statement. (NIST SP 800-53 Rev. 5 OSCAL JSON)
2. “Demonstrate integrity verification for a real component.” Expect to walk through one software package and one firmware update example with evidence. (NIST SP 800-53 Rev. 5)
3. “Is this enforced in the release/change process?” They will inspect tickets and pipelines for gating/steps. (NIST SP 800-53 Rev. 5)
4. “What happens when a supplier can’t support it?” They will look for an exception process with sign-off and compensating controls. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Frequent implementation mistakes and how to avoid them

• Mistake: Treating “integrity verification” as antivirus scanning. AV can be a compensating control, but SA-10(1) is about developer-enabled verification for shipped artifacts. Fix: require signatures/hashes and test the verification method. (NIST SP 800-53 Rev. 5 OSCAL JSON)
• Mistake: Contract language without a technical acceptance test. Audits fail when you cannot show the mechanism works. Fix: add a standardized onboarding test and attach evidence. (NIST SP 800-53 Rev. 5)
• Mistake: Verification exists, but nobody uses it during patching. Fix: embed a required verification step in change tickets and runbooks; sample changes for compliance. (NIST SP 800-53 Rev. 5)
• Mistake: Firmware ignored. Teams often focus on application code and skip BIOS/network device firmware. Fix: include firmware classes in your component inventory and onboarding criteria. (NIST SP 800-53 Rev. 5 OSCAL JSON)
• Mistake: No key management clarity for signature verification. Fix: document where verification keys/cert chains come from and how you validate authenticity. (NIST SP 800-53 Rev. 5)

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this specific control enhancement, so you should treat this as an assessment-driven requirement rather than a case-law-driven one. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Operationally, the risk is straightforward: without integrity verification, you can ingest tampered updates, compromised firmware images, or altered installers, and you may not detect it until after deployment. SA-10(1) reduces that exposure by making the developer responsible for providing verifiable integrity mechanisms and making you responsible for requiring and using them. (NIST SP 800-53 Rev. 5)

A practical 30/60/90-day execution plan

First 30 days (stabilize expectations)

• Assign control owner and procurement partner; publish a one-page SA-10(1) standard with required supplier deliverables (signatures/hashes + verification steps). (NIST SP 800-53 Rev. 5)
• Identify high-impact software and firmware in scope (production platforms, endpoint/security tooling, network/compute firmware). (NIST SP 800-53 Rev. 5 OSCAL JSON)
• Update templates: security addendum clause + internal SDLC release checklist language. (NIST SP 800-53 Rev. 5)

Days 31–60 (prove and embed)

• Run acceptance testing on a small set of representative components (one COTS app, one internally built release, one firmware update) and store evidence in your GRC repository. (NIST SP 800-53 Rev. 5 OSCAL JSON)
• Add a change management requirement: integrity verification evidence attached for relevant changes.
• Create an exception workflow for components that cannot support verification, with defined compensating controls. (NIST SP 800-53 Rev. 5)

Days 61–90 (scale and make audit-ready)

• Expand to remaining critical suppliers and firmware classes; require remediation plans for gaps discovered during onboarding.
• Start recurring sampling of changes to confirm evidence is consistently produced and retained.
• Implement a simple control mapping in Daydream: owner, procedure, evidence checklist, and review cadence so SA-10(1) stays current through staffing and tooling changes. (NIST SP 800-53 Rev. 5)

Frequently Asked Questions

Does SA-10(1) apply to SaaS, or only installed software?

It applies to any system, component, or service where the “developer” delivers software artifacts you run or update, including service-delivered agents, images, or appliances. If you accept executable artifacts from a third party, you need a verification method you can perform. (NIST SP 800-53 Rev. 5 OSCAL JSON)

What counts as “integrity verification” in practice?

A developer-enabled method that lets you confirm the artifact is authentic and unmodified, commonly through signatures or hashes plus a documented verification procedure. The key test is whether your team can repeat the verification and retain evidence. (NIST SP 800-53 Rev. 5)

Is a checksum on a download page enough?

It can be, if it is authoritative and you can show a controlled process that checks the checksum before install and retains evidence. If the checksum distribution channel is weak, document the risk and require a stronger supplier mechanism during renewal. (NIST SP 800-53 Rev. 5 OSCAL JSON)

We buy hardware with bundled firmware. How do we “require the developer” to enable verification?

Put the requirement into OEM/OEM reseller terms and into purchase acceptance criteria: firmware images and updates must have a verification method and documentation. If you cannot negotiate, log an exception and plan a lifecycle replacement path. (NIST SP 800-53 Rev. 5)

How do we evidence this without drowning in tickets and screenshots?

Standardize one evidence bundle per component onboarding and then sample operational changes. Daydream can track the required artifacts by component and prompt for the minimal evidence set during reviews. (NIST SP 800-53 Rev. 5)

What’s the quickest audit demo for SA-10(1)?

Show (1) the contractual or SDLC requirement, (2) a completed integrity verification test for a real software package or firmware update, and (3) a recent change record showing verification was performed before deployment. (NIST SP 800-53 Rev. 5 OSCAL JSON)