This article is a general overview and does not constitute legal or regulatory advice. Requirements evolve - confirm current obligations with qualified counsel and the relevant regulator before making compliance decisions.
Quick Answer: Which Framework Applies to You?
- Selling any connected product in the EU? → CRA applies, full stop.
- Building a medical device with software or connectivity, sold in the US? → FDA cybersecurity requirements apply.
- Need a general information security management system for your organisation? → ISO 27001.
- Building or operating industrial automation, OT, or critical infrastructure equipment? → IEC 62443.
- Selling consumer IoT in the US? → Watch NIST IR 8425 / the U.S. Cyber Trust Mark.
- Selling consumer IoT in the UK? → PSTI Act baseline requirements are legally binding.
Most product companies with any international footprint end up needing two or three of these simultaneously. Here's what each one actually requires.
1. EU Cyber Resilience Act (CRA)
What it is: Regulation (EU) 2024/2847 - mandatory, horizontal cybersecurity law covering essentially any hardware or software product with a network or device connection, sold into the EU market.
Who it applies to: Manufacturers, importers, and distributors of "products with digital elements." This is intentionally broad - medical devices and a handful of other categories are carved out and covered by their own regimes instead.
Key dates: Entered into force December 10, 2024. Reporting obligations apply from September 11, 2026. Full compliance (CE marking, conformity assessment, technical documentation) from December 11, 2027.
Core requirements: Security-by-design and secure-by-default development, an SBOM covering all top-level components, a 24-hour/72-hour/14-day reporting cascade for actively exploited vulnerabilities, a minimum 5-year security support period, and a Coordinated Vulnerability Disclosure policy.
Penalties: Up to €15 million or 2.5% of global annual turnover for serious infringements - a scale deliberately modeled on GDPR.
2. FDA Cybersecurity Requirements for Medical Devices
What it is: Statutory requirements under Section 524B of the Food, Drug & Cosmetic Act, in effect since March 2023, supported by FDA's premarket submission guidance.
Who it applies to: Manufacturers of "cyber devices" - devices that include software validated by the sponsor, can connect to the internet (even unintentionally), and have characteristics that could be vulnerable to cybersecurity threats.
Key requirements for premarket submissions: A Security Risk Management Report, a machine-readable SBOM, evidence of a Secure Product Development Framework (SPDF) applied across the total product lifecycle, a Requirements Traceability Matrix, and a Cybersecurity Management Plan.
Enforcement: The FDA can reject 510(k) and PMA submissions outright for insufficient cybersecurity documentation - this makes cybersecurity a market access issue, not a best-practice recommendation.
If your connected medical device also ships into the EU, don't assume FDA clearance automatically satisfies EU obligations - the CRA's medical device exemption has specific conditions worth checking against your product.
3. ISO 27001
What it is: The international standard for an Information Security Management System (ISMS) - organisational, not product-specific. It doesn't tell you how to secure a specific IoT device; it tells you how to run a security program.
Who it applies to: Any organisation that wants a certifiable, internationally recognised security governance structure. It shows up constantly in IoT compliance conversations because it's frequently required contractually by enterprise customers, and its Annex A control set maps cleanly onto requirements that show up in CRA, FDA, and IEC 62443 alike.
Practical takeaway: ISO 27001 doesn't replace CRA, FDA, or IEC 62443 compliance - think of it as the governance foundation everything else sits on top of.
4. IEC 62443 (ISA/IEC 62443)
What it is: The globally recognised standard series for securing Industrial Automation and Control Systems - covering everything from PLCs and SCADA software to the increasingly cloud-connected sensors and gateways that make up modern Industrial IoT.
Core structure:
- Zones and conduits - assets grouped by shared protection requirements ("zones"), connected through controlled communication paths ("conduits")
- Security Levels (SL-0 through SL-4) - a risk-based scale describing the sophistication of adversary a zone must resist, from casual misuse up to nation-state-level attacks. SL-2 is the typical baseline for most industrial environments.
- Seven Foundational Requirements spanning identification and authentication, use control, system integrity, data confidentiality, restricted data flow, timely incident response, and resource availability
Certification pathways: SDLA for development processes, CSA and ICSA for individual products, SSA for full deployed architectures. A recent update to Part 4-2 added mandatory firmware digital signature validation and secure OTA update requirements for IIoT gateways - a direct response to the firmware-update weaknesses attackers exploit at scale across IoT broadly.
Worth Knowing: Consumer IoT Labeling Schemes
If your product is consumer-facing rather than industrial or medical, these are increasingly relevant alongside CRA:
- NIST IR 8425 (US) - the technical baseline behind the U.S. Cyber Trust Mark, a voluntary FCC labeling program. Covers asset identification, secure configuration, data protection, interface access control, and software updates.
- ETSI EN 303 645 (EU/UK) - the most widely referenced consumer IoT baseline globally, built around 13 recommendations, the top three being: no default passwords, a vulnerability disclosure policy, and ongoing software updates.
- UK PSTI Act - unlike the FCC's voluntary Cyber Trust Mark, this makes the "no default passwords, disclose your update support period, publish a vulnerability disclosure policy" baseline legally mandatory for products sold in the UK.
Side-by-Side Comparison
| Framework | Mandatory? | Product Type | Key Deadline |
|---|---|---|---|
| EU CRA | Yes | Hardware & software, broad | Reporting: Sep 2026; Full: Dec 2027 |
| FDA (524B) | Yes | Medical devices | In effect since Mar 2023 |
| ISO 27001 | Voluntary (often contractual) | Any organisation | Ongoing certification cycle |
| IEC 62443 | Voluntary / contractually driven | OT, IIoT, critical infrastructure | Continuously updated |
| NIST IR 8425 / Cyber Trust Mark | Voluntary | Consumer devices | Program finalising launch |
| UK PSTI Act | Yes | Consumer & connected products | In force since 2024 |
A Practical Cross-Framework Checklist
Regardless of which combination applies to you, these show up in nearly every framework above:
- Build and maintain an SBOM for every product.
- Establish a Coordinated Vulnerability Disclosure policy with a public contact point.
- Eliminate default credentials and enforce secure default configuration.
- Define and publish your security support period.
- Document your development lifecycle - an SPDF for FDA, secure-by-design documentation for CRA, SDLA alignment for IEC 62443.
- Run independent security testing before launch - none of these frameworks are satisfied by paperwork alone.
Where Independent Testing Fits
Every framework here asks you to demonstrate that your product resists real-world attack techniques - not just describe your intentions in a policy document. An SBOM tells you what's inside a product. A risk management report tells you what you've assessed. Neither tells you whether an attacker with physical access can extract firmware over UART, or whether your "secure" OTA update mechanism actually validates signatures the way your documentation claims.
That's the gap independent penetration testing closes - and it's directly relevant to compliance evidence across all four frameworks above, whether that's supporting an FDA premarket submission, validating CRA security-by-design claims, or generating the test evidence IEC 62443 certification pathways expect.
If you're mapping your product portfolio against one or more of these frameworks and want a clear picture of where the real gaps are, get in touch.