SOC 2 for Hardware Startups: What's in Scope When You Sell Devices, Chips or Appliances

SOC 2 for hardware companies reports on the service the company operates around its product: the cloud platform, the device management backend, the data pipeline and the support process. The device, chip or appliance itself is usually outside the SOC 2 system; customers who want assurance about the product ask for product standards such as IEC 62443 or ETSI EN 303 645.

A typical case: a company sells connected gateways to industrial operators, with a cloud dashboard, over-the-air (OTA) firmware updates and a contract manufacturer that builds the boards. An enterprise customer's security review asks for a SOC 2 Type 2 report before the purchase order, and the CTO's first question is whether the gateways, the firmware and the factory all have to be audited. The auditor tests the controls around the service the customer relies on, and the scope decisions below decide how big that is.

What Does a SOC 2 Report Cover for a Hardware Company?

A SOC 2 report for a hardware company covers the system the company uses to deliver a service to its customers. The AICPA defines a system as the infrastructure, software, procedures, and data that are designed, implemented, and operated by people to achieve one or more of the entity's specific business objectives (for example, delivery of services or production of goods) in accordance with management-specified requirements.

For a hardware company, the service the customer buys alongside the device is the cloud dashboard, the fleet management console, the API, the data storage and the support desk. Those hold customer data, and the description criteria (DC 200) require the company to describe them, the system boundaries, the subservice organizations it relies on and the controls it expects customers to operate.

The AICPA offers a separate examination for production of goods: SOC for Supply Chain reports on a production, manufacturing, or distribution system. Buyers of connected products typically ask for SOC 2, because their concern is the cloud service and its data.

SOC 2 Scope for Hardware Companies: Component-by-Component Table

SOC 2 scope for a hardware company follows the data and the control points: anything that stores customer data, changes what runs on customer devices, or supports those two things belongs in the system. The auditor confirms each decision against the system description.

The SOC 2 scoping guide for hybrid and on-prem infrastructure covers how to draw the boundary as a data flow and write it into the system description.

How SOC 2 Treats the Cloud Platform and the Device Fleet Management Backend

The cloud platform and the device fleet management backend are the center of SOC 2 scope for a hardware company, because they hold customer data and control every device in the field. The cloud side is tested like any SaaS system.

The fleet backend adds one thing a pure SaaS company lacks: an OTA update changes software at a customer's site. CC8.1 requires that the entity authorizes, designs, develops or acquires, configures, documents, tests, approves, and implements changes to infrastructure, data, software, and procedures to meet its objectives. Auditors ask for the release ticket, test results on a staging cohort, the approval, the rollout record by device group and the rollback procedure.

Device provisioning belongs here too. The CC6.1 point of focus Manages Credentials for Infrastructure and Software asks that new infrastructure be registered, authorized, and documented prior to being granted access credentials, which maps to how a device gets its identity and joins the fleet.

Firmware Signing Keys and the Build System in SOC 2 Scope

Firmware signing keys and the build system are in SOC 2 scope because whoever controls them controls what runs on every customer device. The CC6.1 point of focus Protects Cryptographic Keys reads: The entity protects cryptographic keys during generation, storage, use, and destruction. Auditors and customer security teams look for four things:

• Where the key is held. A hardware security module or cloud key management service, with access limited to named people or a build service identity.
• Who can trigger a signed release. Signing tied to a release pipeline with required approvals, never from a developer laptop.
• What the build system records. Each signed image traced to a commit, a build job and an approver.
• What happens if a key is compromised. A documented rotation and revocation procedure that devices in the field can follow.

The CC6.8 point of focus Restricts Installation and Modification of Application and Software covers who can change what reaches production, which for a hardware company includes the firmware pipeline. The guide to SOC 2 secure development with self-hosted GitLab covers branch protection, approvals and pipeline evidence for self-run build systems.

Device Data in SOC 2 Scope: Where the System Boundary Starts

Customer data that comes off devices is in SOC 2 scope from the moment it enters a system the hardware company controls, such as the ingestion endpoint, message broker or time-series store. Data that stays on the device at the customer's site is under the customer's control.

That split creates complementary user entity controls (CUECs): the customer secures the network the device connects to, controls physical access to it and manages local accounts. The guide to complementary user entity controls in SOC 2 covers how to write and evidence them.

The data path in between is the company's responsibility. CC6.7 requires that the entity restricts the transmission, movement, and removal of information to authorized internal and external users and processes, and protects it during transmission, movement, or removal. For a device fleet, that means device authentication, encrypted transport and a record of which device sent what. The SOC 2 data protection guide for on-prem datastores covers the storage side.

For custom silicon companies, the sensitive data is often design data, such as customer specifications and tape-out files sent to a foundry, which brings the design environment into scope.

Contract Manufacturers in SOC 2: Subservice Organization or Vendor?

A contract manufacturer is a vendor under CC9.2 in most hardware SOC 2 reports, and becomes a subservice organization only when it performs controls the system depends on. CC9.2 reads: The entity assesses and manages risks associated with vendors and business partners. The AICPA glossary even uses a hardware example of a business partner: a computer manufacturer who works with another company that supplies it with parts.

The line moves when the factory takes part in the security of the service. A manufacturer that injects device keys or certificates, flashes the production firmware image or holds the device identity database performs a control the fleet relies on. The auditor may then expect the system description to name it as a subservice organization, usually with the carve-out method.

Either way, the evidence is similar: security requirements in the manufacturing agreement, a review of the manufacturer's reports or questionnaire responses, and a record of how key material moves to and from the line. The SOC 2 vendor management guide for data centers as subservice organizations covers the carve-out mechanics, which apply the same way to a manufacturer.

Lab Hardware, RMA Returns and Corporate IT in a Hardware Company's SOC 2

Lab and test hardware stays outside SOC 2 scope when it is isolated from production and holds no customer data, and corporate IT is inside scope because it supports everything else. Lab benches, prototype boards and test rigs need their own network segment, no production credentials and no copies of customer data.

Returned devices need a control of their own, because an RMA unit can hold logs, cached data or credentials. CC6.5 requires that the entity discontinues logical and physical protections over physical assets only after the ability to read or recover data and software from those assets has been diminished. A wipe procedure for returned units, with a record per serial number, covers it.

Corporate IT covers identity, laptops, email and the tools engineers use to reach production, and a lab or office with a server rack falls under CC6.4 physical access. Evidence for these pieces often comes from outside a GRC platform integration; the guide to SOC 2 evidence collection without APIs covers how to collect it.

When Hardware Customers Want SOC 2 and When They Want Product Security Evidence

Enterprise customers ask for SOC 2 when their concern is the vendor's service and data, and for product security evidence when their concern is the device on their network or the product on a store shelf.

ETSI EN 303 645 (V3.1.3, 2024) sets 13 security provisions for consumer IoT devices and their associated services, including no universal default passwords, keeping software updated and ensuring software integrity. The EU Cyber Resilience Act is law, unlike the voluntary standards and labels: its reporting obligations apply from 11 September 2026 and its main obligations from 11 December 2027. The FCC's U.S. Cyber Trust Mark is a voluntary label for consumer wireless IoT products.

SOC 2 and these standards overlap in secure development, vulnerability handling and updates, so the controls can be built once and mapped to several. Sibling posts in this cluster cover firmware, OTA and fleet scope, SOC 2 compared with product security standards, and SOC 2 for semiconductor startups.

The First 90 Days of SOC 2 for a Hardware Startup

The first 90 days of SOC 2 for a hardware startup go to scoping, building controls around the cloud and the firmware pipeline, and getting evidence flowing before the audit starts. A practical sequence:

1. Days 1 to 15: draw the boundary. Map the data flow from device to cloud, list every system that stores customer data or can change device software, and note whether the contract manufacturer touches keys, firmware or device identity.
2. Days 15 to 30: run a capability assessment. Score the security capabilities (access control, change management, vulnerability management, incident response and the rest) against that scope and name the gaps.
3. Days 30 to 60: build the biggest gaps first. For hardware companies these are usually signing key protection, the firmware release approval path, OTA rollout records and the RMA wipe procedure. Write policies and the system description to match.
4. Days 60 to 75: connect the evidence. Set up the GRC platform for the cloud side and a collection routine for the build system, key management and the lab boundary.
5. Days 75 to 90: pick an auditor and a date. Choose a Type 1 for speed or start the Type 2 observation period, and give customers a security summary with the expected report date.

The SOC 2 readiness guide for bare metal SaaS covers timelines for companies that run their own hardware, and the SOC 2 for bare metal and on-prem infrastructure page lists the controls that change when infrastructure is self-managed.

SOC 2 for Hardware Companies Comes Down to Scoping the Service Around the Device

SOC 2 for hardware companies is a report on the service behind the product. Scoped that way, the audit is close to a SaaS audit with four hardware additions: signing keys, OTA changes, manufacturer controls and returned devices. A clear scope gets enterprise buyers the report they asked for and leaves the device to product security standards.

Related Guides

• Contract Manufacturers and SOC 2: Subservice Organization, Vendor, or Out of Scope?
• Is Firmware in SOC 2 Scope? OTA Updates, Signing Keys and Device Fleets
• SOC 2 for Chip Startups: Design IP, EDA Environments, Foundries and Compute Services
• SOC 2 vs IEC 62443 vs ETSI EN 303 645: Which Does Your Hardware Customer Want?
• EU Cyber Resilience Act (CRA): What It Is, Timeline and Requirements for Hardware and Software Makers

Frequently Asked Questions

Do hardware companies need SOC 2?

Hardware companies need SOC 2 when enterprise customers ask for it, typically because the product comes with a cloud service, fleet management or data storage. SOC 2 is a voluntary attestation covering the company's service and data handling. Product security standards such as IEC 62443 or ETSI EN 303 645 cover the device.

Is the physical device in scope for a SOC 2 audit?

The physical device is usually outside the SOC 2 system, because SOC 2 reports on the service the company operates. In scope is everything that controls the device from the company's side: fleet management, OTA updates, firmware signing, provisioning and the cloud that receives device data. Controls customers run on site become CUECs.

Is a contract manufacturer a subservice organization in SOC 2?

A contract manufacturer is usually a vendor managed under CC9.2, with security terms in the agreement and periodic review. It becomes a subservice organization when it performs controls the system relies on, such as injecting device keys, flashing signed firmware or holding device identity records.

Does SOC 2 cover firmware security?

SOC 2 covers the processes around firmware: change management under CC8.1 for builds and OTA releases, signing key protection under CC6.1, and restrictions on who can modify software under CC6.8. It does not test firmware code for vulnerabilities; IEC 62443-4-1 addresses secure product development directly.

Do semiconductor startups need SOC 2?

Semiconductor startups need SOC 2 when customers share confidential design data with them or rely on a cloud service, tool or platform they operate. The scope then covers the design environment, file transfers to foundries and the corporate IT behind them, often with the confidentiality criteria included.

Sources

• AICPA, 2017 Trust Services Criteria (With Revised Points of Focus, 2022)
• AICPA, Description Criteria for a SOC 2 report (DC 200)
• AICPA, SOC for Supply Chain guide
• ISA, ISA/IEC 62443 series of standards
• IEC, IEC 62443-4-1:2018
• ETSI, EN 303 645 V3.1.3 Cyber Security for Consumer Internet of Things
• European Commission, Cyber Resilience Act
• FCC, New Lead Administrator for U.S. Cyber Trust Mark Program (April 13, 2026)
• UL Solutions, IoT Security Rating levels guide