SOC 2 vs the Cyber Resilience Act: Are They the Same Thing?
SOC 2 and the CRA get asked about together, but one is a voluntary attestation report and the other is EU product law. Here is what actually separates them.
SOC 2 and the Cyber Resilience Act are not the same kind of thing, and they are not competing for the same job. SOC 2 is a voluntary attestation report from the AICPA, requested by a customer, investor, or procurement process, mostly relevant to US enterprise sales. The CRA (Regulation (EU) 2024/2847) is EU law regulating products with digital elements placed on the EU market, binding manufacturers regardless of company size, with statutory penalties up to 15 million EUR or 2.5% of global turnover. A device maker selling into the EU is very likely CRA in-scope no matter what any buyer asks for, and may separately need SOC 2 because a US customer or investor asked for it. Neither substitutes for the other.
The two show up in the same search results because both get called "compliance" and both get raised in the same conversations about getting a deal or a market unblocked. But they attach to different things: SOC 2 attaches to whether a buyer trusts your organisation enough to sign, and the CRA attaches to whether your product is legally allowed on the EU market. Our SOC 2 framework page and Cyber Resilience Act framework page each cover their own scope in full; this post is about the line between them.
What is the actual difference between SOC 2 and the CRA?
SOC 2 is an attestation report. An independent auditor examines your controls against the AICPA's Trust Services Criteria and writes up what they found. Nobody is legally required to have one, it becomes necessary when a customer's security review, a procurement checklist, or an investor's diligence list asks for it. Security is the one mandatory criterion; Availability, Confidentiality, Processing Integrity, and Privacy are added when relevant.
The CRA is a regulation. It applies to products with digital elements placed on the EU market and puts obligations directly on their manufacturers: secure-by-design development, a Software Bill of Materials, coordinated vulnerability handling, security updates through the support period, and a conformity assessment, self-assessment for the default class or a notified body for higher-risk classes. There is no opt-out and no buyer has to ask for it first.
A useful test: SOC 2 exists because someone requested it. The CRA exists because you shipped a product into the EU. Remove the request and SOC 2 obligations go away. Remove the EU market and the CRA obligations go away, but the CRA itself never asked your permission to apply.
SOC 2 vs the CRA at a glance
| SOC 2 | CRA | |
|---|---|---|
| Legal form | AICPA attestation standard, not a law | Regulation (EU) 2024/2847, applies directly in every member state |
| Regulates | An organisation's controls (security, and optionally availability, confidentiality, processing integrity, privacy) | Products with digital elements placed on the EU market |
| Who is bound | Nobody by statute; effectively any company a customer, investor, or procurement process is asking | Manufacturers, importers, distributors, regardless of company size or location |
| Trigger | A customer, investor, or procurement ask | Placing a product with digital elements on the EU market |
| Key penalty / stakes | None from government; a stalled deal, a security review that never clears | Up to 15 million EUR or 2.5% of global annual turnover for essential-requirement violations, plus market surveillance action |
| Primary buyer / regulator | Enterprise customers and investors, mostly US-centric sales motion | EU market surveillance authorities, ENISA, national CSIRTs |
For what the CRA's fine tiers mean in practice, see CRA penalties and fines.
Does the CRA apply to me if I already have SOC 2?
Yes, and this is the mistake worth naming directly. SOC 2 examines organisational controls: access management, change management, vendor oversight, incident response process. None of that produces a Software Bill of Materials, a coordinated vulnerability-disclosure process, or a 24-hour actively-exploited-vulnerability reporting pipeline, which are the CRA's actual asks about the product itself. A company can hold a clean SOC 2 report and still ship a device with no SBOM and no patching process, and the CRA does not care that the SOC 2 report exists. Who counts as a manufacturer under the CRA, and what that role actually requires, is covered in who does the CRA apply to.
Does SOC 2 apply to hardware and connected-device companies?
Often, yes, just not for CRA reasons. Any connected product with a cloud dashboard, companion app, or customer account system runs through a US enterprise sales motion sooner or later, and that motion routinely asks for SOC 2 before signing. So a device maker can be CRA in-scope because of what it ships into the EU, and separately be asked for SOC 2 because of who it is selling to in the US. Same company, two different asks, two different reasons.
Do SOC 2 and CRA work overlap, or is it duplicated effort?
There is real practical overlap, even though the obligations themselves don't merge. Vulnerability handling, incident response, and access control done well for one meaningfully speeds up the other: a working vulnerability-management process is graded by a SOC 2 auditor and is also the operational backbone the CRA's 24-hour reporting clock depends on. Access reviews and change management show up in both. What doesn't transfer is the artifact itself, a SOC 2 report is not an SBOM and a conformity assessment is not a Trust Services Criteria examination, so the paperwork stays separate even when the underlying discipline is shared.
Which one should a device maker prioritise?
Start from what is actually blocking something right now, not from which framework sounds more serious. If you place a product with digital elements on the EU market, CRA scoping should happen regardless of what any customer has asked for, because the obligation exists whether or not a deal depends on it. If a specific enterprise buyer or investor is holding a deal open behind a SOC 2 report today, that becomes the more urgent track in parallel. Most connected-product companies selling on both sides of the Atlantic eventually run both tracks at once. Run the free two minute CRA readiness check to see where your product actually stands, and if you're weighing the CRA against other EU regimes, CRA vs NIS2 and GDPR vs the Cyber Resilience Act cover the rest of that picture.
Frequently asked questions
Is SOC 2 the same thing as the Cyber Resilience Act? No. SOC 2 is a voluntary attestation report from the AICPA, examined by an independent auditor and requested by a customer, investor, or procurement process. The CRA, Regulation (EU) 2024/2847, is EU law regulating products with digital elements placed on the EU market, binding manufacturers regardless of company size or whether anyone asked for it.
Does having SOC 2 mean I am CRA compliant? No. SOC 2 examines organisational controls like access management, change management, and vendor oversight. The CRA asks for product-specific things a SOC 2 report does not cover: a Software Bill of Materials, secure-by-design development, and a 24-hour actively-exploited-vulnerability reporting pipeline. Passing one audit says nothing about the other.
Does the CRA apply if I already have SOC 2? Yes, if you place a product with digital elements on the EU market, the CRA applies regardless of what attestation reports you already hold. The CRA has no size threshold and does not accept SOC 2 as a substitute for its own conformity assessment.
Do I need SOC 2 and the CRA at the same time? Often, but usually for different reasons and on different timelines. A device maker selling into the EU is likely CRA in-scope regardless of customer asks. The same company may separately need SOC 2 because a US enterprise buyer or investor is asking for it. The two obligations run in parallel, not in sequence.
What happens if I skip SOC 2 versus if I skip the CRA? Skipping SOC 2 has no government penalty, the cost is a stalled sales cycle or a security review that never clears. Skipping the CRA can mean market surveillance action against your product and fines up to 15 million EUR or 2.5% of global annual turnover, because it is statutory law, not a report someone requested.
Which one should a connected-device company do first? Start from what is actually blocking something. If you place products on the EU market, CRA scoping comes first because it applies regardless of what any customer asks for. If a specific enterprise deal or investor is waiting on a SOC 2 report today, that becomes the more urgent track. Many device makers end up running both.
Last reviewed: July 12, 2026.
Where Scadable fits
Scadable covers both sides of this, and for a device maker doing both, the underlying capability, knowing what you've shipped, monitoring for exposure, and being able to prove your controls actually operate, is genuinely shared work, not duplicated effort. On the CRA side, Scadable maps every device and component to the vulnerabilities that affect them, flags active exploitation, and files the 24-hour report when the clock starts. On the SOC 2 side, it implements the missing controls and builds the evidence trail as the controls run, not reconstructed the week before an audit. If you're trying to figure out which of these actually applies to you right now, run the free CRA readiness check or book a call.