Is Firmware in SOC 2 Scope? OTA Updates, Signing Keys and Device Fleets

SOC 2 firmware scope comes down to one test: if your cloud service builds, signs and delivers firmware over the air, each release is a change to your system under CC8.1, the signing key falls under the CC6.1 point of focus on protecting cryptographic keys, and signature checks on the device are a CC6.8 control against unauthorized software. The devices themselves are in scope when you operate them; customer-owned devices come into the report through complementary user entity controls (CUECs).

Is Firmware in SOC 2 Scope When Your Cloud Service Delivers It?

Firmware is in SOC 2 scope when the system described in your SOC 2 report builds it, signs it or pushes it to devices. CC8.1 covers changes to infrastructure, data, software, and procedures, and the OTA service that delivers firmware is software your customers depend on.

A typical connected-device company has this release path:

1. Engineers merge firmware changes after review.
2. A CI pipeline builds the image and runs unit and hardware-in-the-loop tests.
3. A signing service signs the image with a production key in an HSM or cloud KMS.
4. The OTA service releases the signed image to a test group, then to the fleet in stages.
5. Devices verify the signature, install the image and report their new version.

Every step on that list is a control an auditor can test. Buyers of device-plus-cloud products tend to ask about firmware updates in security reviews, because one compromised update reaches every device at once. When the report covers the firmware path, the sales team answers those questions with audited evidence.

Which SOC 2 Criteria Apply to Firmware and OTA Updates?

SOC 2 firmware controls map to four criteria through specific points of focus in the AICPA text.

The CC6.8 point of focus Restricts Installation and Modification of Application and Software translates to a short, reviewed list of people who can start or widen an OTA rollout. The SOC 2 CC8.1 change management guide covers the full set of CC8.1 points of focus.

How to Protect Firmware Signing Keys for SOC 2: HSM, KMS and Key Ceremonies

Firmware signing key management for SOC 2 means the private key lives inside a protected cryptographic module, a documented ceremony records its creation, and no one person can both approve and sign a release. NIST SP 800-193 explains the stakes: an attacker who steals the signing key could sign invalid firmware that might damage platform devices or inject malware into the platform.

Four elements make up a defensible setup:

• Custody. Keep the production signing key in an HSM, ideally one validated under FIPS 140-3, or in a cloud KMS key configured so the private key stays inside the service. Production devices trust only the production key.
• Separation of duties. The signing service signs only images that came from the release pipeline after an approved change. HSM administration uses quorum approval where the HSM supports it.
• Key ceremony. Generate the production key in a scripted ceremony with named participants and a witness. Record the date, steps, public key fingerprint and participant signatures.
• Compromise plan. NIST SP 800-193 notes that proper use of signatures thus necessitates provisions to recover from a key compromise. Document how devices receive a new trusted key, through an authenticated update, if the old one is lost or stolen.

Evidence for CC6.1 comes from the ceremony record, the HSM or KMS access policy, periodic reviews of signing permissions and the signing log. NIST SP 800-57 Part 1 covers key lifetimes and key types. The SOC 2 access control guide for on-prem covers the access reviews that apply to signing and HSM administration accounts.

SOC 2 Controls for the OTA Update Pipeline: Provenance, Staged Rollouts, Rollback and Monitoring

OTA update security for SOC 2 rests on four pipeline controls: build provenance, staged rollouts, rollback and fleet monitoring. Each leaves records an auditor can sample.

Build Provenance for OTA Firmware Releases

Build provenance ties each signed firmware image to the source and pipeline that produced it. SLSA defines provenance as the verifiable information about software artifacts describing where, when, and how something was produced. Record the commit, pipeline run and image hash for every build, and have the signing service refuse images without matching provenance. The SOC 2 secure development guide for self-hosted GitLab covers the merge request approvals behind that record.

Staged Rollouts for OTA Firmware Releases

A staged OTA rollout releases firmware to internal test devices first, then to a small share of the fleet, then wider. Write the halt criteria into the release procedure, such as an update failure rate or a crash rate above a set threshold, and record who approved each stage.

Rollback Rules for OTA Firmware Releases

Firmware rollback needs two rules: authorized rollback for recovery and a block on attacker downgrades. NIST IR 8259A lists the ability for authorized entities to roll back updated software to a previous version as part of its Software Update capability. NIST SP 800-193 adds the other side: the update mechanism should prevent unauthorized rollback to an earlier authentic version that has a security weakness. In practice: rollback through the signed OTA path, with downgrades blocked below a minimum security version.

Fleet Monitoring After OTA Firmware Releases

Fleet monitoring for OTA updates means every device reports its firmware version, update result and boot status to the cloud. A fleet dashboard showing devices on unexpected versions supports the CC7.1 point of focus Detects Unknown or Unauthorized Components.

Device Fleet Scope in SOC 2: Company-Operated Devices and Customer-Owned Devices

IoT device fleet scope in SOC 2 depends on who owns and operates the devices. Company-operated devices, such as gateways managed as part of a hosted service, are infrastructure inside the system boundary and need an inventory, configuration standards, credentials and patching like any server.

Customer-owned devices are outside the system boundary, but your controls still cover what you deliver to them: signed firmware, the OTA service and device authentication to your cloud. What the customer must do goes into the system description as complementary user entity controls, which the AICPA description criteria require the description to list. Typical CUECs for a device product:

• The customer keeps devices connected so they receive security updates within a stated period.
• The customer restricts physical access to installed devices.
• The customer reports lost, stolen or tampered devices so their credentials can be revoked.
• The customer decommissions devices through the documented process, which revokes the device certificate.

A clear CUEC list tells customer reviewers what they own. The SOC 2 complementary user entity controls guide covers how to write and evidence CUECs in both directions.

Firmware Vulnerability Management for SOC 2: SBOMs and Component Monitoring

Firmware vulnerability management for SOC 2 starts with a software bill of materials (SBOM) for every release, because firmware images bundle third-party components a network scan cannot see. NTIA's minimum elements list seven data fields, including supplier, component name and version, and state that a new build or release needs a new SBOM.

With an SBOM per release, the CC7.1 requirement to identify susceptibilities to newly discovered vulnerabilities becomes a repeatable process:

1. Generate the SBOM in the build pipeline and store it with the signed image.
2. Match SBOM components against vulnerability feeds on a schedule.
3. Rate each finding against how the component is used on the device.
4. Fix through a firmware release under the CC8.1 point of focus Manages Patch Changes, or record a risk acceptance with an owner and a review date.

The cloud side still needs regular scanning; the SOC 2 vulnerability scanning guide for on-prem covers scan cadence and remediation SLAs for servers and network devices.

What SOC 2 Auditors Sample for Firmware and OTA Releases

SOC 2 auditors test firmware controls by picking releases from the observation period and tracing each one from change to fleet. Expect requests like these:

Emergency firmware fixes get sampled too; the SOC 2 change management tickets guide covers emergency changes and retrospective approval.

SOC 2 Firmware Controls Answer the Questions Device Buyers Ask

SOC 2 firmware controls give device buyers audited answers to the questions their security reviews tend to ask: how updates are signed, who holds the key and how field devices get fixed when a vulnerability appears. A report covering the release pipeline, signing keys and OTA service answers them with tested evidence.

The SOC 2 for bare metal and on-prem infrastructure page lists the other controls that change when you run your own hardware. Teams scoping a first report can book a scoping call to map their firmware path to the criteria.

Related Guides

• SOC 2 for Hardware Startups: What's in Scope When You Sell Devices, Chips or Appliances
• SOC 2 Vulnerability Risk Acceptance: What to Do When There Is No Vendor Fix
• EU Cyber Resilience Act (CRA): What It Is, Timeline and Requirements for Hardware and Software Makers
• IEC 62443 Explained: 4-1, 4-2, 3-3, Security Levels and Certification for Product Companies

Frequently Asked Questions

Is firmware in scope for SOC 2?

Firmware is in SOC 2 scope when the system in the report builds, signs or delivers it. Each firmware release is then a change under CC8.1. Devices the company operates are in-scope infrastructure; customer-owned devices are covered through CUECs.

Which SOC 2 criteria cover OTA firmware updates?

OTA firmware updates map to CC8.1 for approval, testing and deployment, including the point of focus Manages Patch Changes. CC6.1 covers the signing key and device credentials, CC6.8 covers blocking unauthorized software, and CC7.1 covers new vulnerabilities in firmware components.

Does SOC 2 require an HSM for firmware signing keys?

SOC 2 names no specific technology. The CC6.1 point of focus asks the entity to protect cryptographic keys during generation, storage, use and destruction. An HSM or non-exportable cloud KMS key, with a ceremony record and access reviews, is the simplest way to show it.

How are customer-owned devices handled in a SOC 2 report?

Customer-owned devices are outside the system boundary. The report covers what the company delivers to them, such as signed firmware and the OTA service, and lists complementary user entity controls for the customer, such as keeping devices online for updates and reporting lost or tampered devices.

Does SOC 2 cover the device hardware itself?

SOC 2 covers the service system, including firmware delivery and fleet management. For manufacturing controls, the AICPA criteria text describes a SOC for Supply Chain examination for a system used to produce, manufacture, or distribute products.

Sources

• AICPA, 2017 Trust Services Criteria (With Revised Points of Focus, 2022)
• AICPA, Description Criteria for a SOC 2 Report
• NIST, SP 800-193 Platform Firmware Resiliency Guidelines
• NIST, IR 8259 Foundational Cybersecurity Activities for IoT Device Manufacturers
• NIST, IR 8259A IoT Device Cybersecurity Capability Core Baseline
• NIST, SP 800-57 Part 1 Rev. 5 Recommendation for Key Management
• NIST, FIPS 140-3 Security Requirements for Cryptographic Modules
• SLSA, Provenance specification v1.2
• NTIA, The Minimum Elements for a Software Bill of Materials