The EU Cyber Resilience Act (CRA) Kicks in from December 11, 2027

The EU Cyber Resilience Act (CRA) sets mandatory cybersecurity baselines, vulnerability reporting, and lifecycle security rules for hardware and software products sold in the European Union. EU Cyber Resilience Act (CRA) compliance is not restricted to hardware and embedded software; it also applies broadly to standalone (non-embedded) software and remote data processing solutions.

The CRA applies to manufacturers, importers, and distributors of almost any product with digital elements sold in the EU, including companies based outside the EU whose products reach the EU market.

If your hardware or software connects to a device or network, you're likely in scope. That covers the obvious connected gear and the components inside it: firmware, embedded software, operating systems, and the open-source libraries you depend on. The manufacturer carries the heaviest load, since they're the one declaring conformity. Importers and distributors have their own duties to verify that what they're selling carries the right marking and documentation.

Location doesn't get you out of it. If you ship into the EU from the United States, Asia, or anywhere else, the CRA applies the moment your product hits the EU market. For most global manufacturers, that makes CRA conformity a condition of doing business in Europe, not a regional edge case.

Key requirements

• Security by design
  Manufacturers must integrate security measures during the planning, development, and production stages.
• Vulnerability handling
  Companies must track components via a Software Bill of Materials (SBOM) and patch security flaws throughout the product support period. SBOM is a formal, machine-readable inventory list that details all components, open-source libraries, third-party modules, and hierarchical dependencies present in a software product.
• Automatic updates
  Security updates must be pushed automatically by default where feasible, separated from feature upgrades.

EU mandates that full enforcement of all essential cybersecurity and conformity assessment requirements must be implemented by December 11, 2027.

As an IoT software developer, the EU Cyber Resilience Act (CRA) directly fundamentally shifts the daily workflow. Security is no longer a post-development addition or a premium feature; it is a strict legal prerequisite for deployment on the EU market. If the IoT software connects to a network — whether it is embedded firmware, a companion mobile app, or middleware — we must legally prove its "secure-by-design" status before launch and maintain its lifecycle security for up to 10 years.

The impact on daily engineering workflow

• Automated evidence collection
  Every build pipeline must continuously generate security artifacts (like scan records and threat models). If a regulator requests audit data, we must provide documented proof linking design requirements to final testing results.
• Shift-left coding
  Code security checks move straight into our IDE and CI/CD pipelines. Build gates must block compilation or release if code contains hard-coded secrets or known, unpatched vulnerabilities.
• Mandatory transparency
  We cannot ship a black box. We are legally required to maintain a machine-readable bill of materials for code dependencies and clearly document the expected product security lifecycle for the end user.

Phase-by-phase developer compliance checklist

Follow these engineering phases to ensure that IoT software aligns with the CRA guidelines before the upcoming deadlines.

1. Architecture and design phase
   • Classify your IoT product. Determine if your device falls under the Default tier (e.g., smart home toys, connected appliances) or Important Class I/II (e.g., smart door locks, routers, microcontrollers with hardware roots-of-trust). High-risk tiers require third-party conformity audits instead of self-assessments. Refer to the product category list at the end of this article.
   • Perform formal threat modeling. Document a structural risk assessment (e.g., using frameworks like STRIDE) prior to writing code. Identify edge-case physical and digital attack surfaces.
   • Enforce secure-by-default controls. Disable unencrypted communication protocols (e.g., Telnet, HTTP). Force users to set a unique, strong password during initial onboarding, outlawing universal factory-default passwords entirely.
2. Build and CI/CD pipeline phase
   • Automate SBOM generation. Configure tools (e.g., CycloneDX or SPDX plugins) into your build script to export a machine-readable Software Bill of Materials (SBOM) with every release.
   • Embed Static Application Security Testing (SAST). Use automated SAST scanners in the CI/CD pipeline to flag common memory-safety bugs, injection vectors, and hard-coded cryptographic keys before code merging.
   • Implement Software Composition Analysis (SCA). Run SCA scans continuously against your SBOM. Set the pipeline to break the build if open-source or commercial third-party libraries carry high-severity, exploitable CVEs (Common Vulnerabilities and Exposures).
3. Release and delivery phase
   • Compile technical documentation. Save your risk assessments, automated test reports, and verification records. Retain this data for 10 years post-sale for compliance reporting.
   • Provide explicit security instructions. Draft an end-user guide outlining how to securely configure the device or software, how to toggle features, and how to verify that updates are installing correctly.
   • Coordinate the CE mark. Work with your compliance officer to confirm your software satisfies Annex I requirements, sign the EU Declaration of Conformity, and apply the physical or digital CE Mark. The CE mark does not apply only to hardware; it also applies to certain types of standalone software, such as Software as a Medical Device (SaMD).
4. Post-market operations phase
   • Deploy a Coordinated Vulnerability Disclosure (CVD) system. Host a public security file (such as a security.txt path) or a dedicated web portal where white-hat researchers can securely report bugs.
   • Establish a rapid-incident clock. Configure automated alerts for your security operations center. If an actively exploited exploit hits your device ecosystem, you must notify EU authorities (ENISA) and your local CSIRT within 24 hours of discovery.
   • Separate security patches from feature builds. Configure your OTA (Over-The-Air) updater to push security hotfixes automatically by default. Keep security patches detached from feature releases so users can fix bugs without forcing unwanted functional modifications.

What makes the CRA particularly consequential beyond Europe is that it doesn't offer a convenient workaround for companies considering other markets. IoT regulatory compliance has gone global, with Japan, India, Brazil, and the US all developing their own frameworks, and the EU standard often functions as the floor.

Companies that treat the CRA as a European concern are likely underestimating the regulatory direction of travel. Industry analysts now rank compliance ahead of cost and connectivity as the top challenge in IoT deployment, which reflects how seriously practitioners are taking this shift. For manufacturers that export globally or operate at scale, building CRA-compliant processes is increasingly table stakes for market access.

The practical question at this point is where to start if you haven't already. For teams in the middle of product development, the most valuable move is treating the CRA's secure-by-default requirement as a design constraint — which means OTA update infrastructure, code signing, and vulnerability management need to be in the architecture before the product ships.

EU CRA product category list

The EU Cyber Resilience Act (CRA) categorizes products with digital elements into four main risk-based tiers: Default, Important Class I, Important Class II, and Critical. Each tier defines distinct conformity assessment and third-party testing mandates before a product can receive a CE mark for the European market.

• Default products
  Accounts for roughly 90% of all connected hardware and software not explicitly named in higher risk lists. Examples include smart home consumer goods, printers, Bluetooth speakers, and media players. Assessment is by internal control / self-assessment (Module A).
• Important products — Class I
  Products with significant connectivity or central system/security functions. Examples include operating systems, web browsers, password managers, antivirus software, VPN products, routers, modems, switches, smart door locks, and connected toys. Self-assessment is only allowed if harmonized European standards are fully applied; otherwise, third-party assessment is mandatory.
• Important products — Class II
  Higher-risk infrastructure and virtualization or boundary-defense components. Examples include firewalls, intrusion detection/prevention systems, hypervisors, container runtime systems, and tamper-resistant microprocessors/microcontrollers. Third-party assessment is mandatory via EU-type examination (Module B+C) or full quality assurance (Module H).
• Critical products
  Highest-risk products with critical cybersecurity footprints. Examples include smart meter gateways, secure elements, hardware security modules, and smart cards. A mandatory European cybersecurity certification scheme (EUCC) at a "substantial" or higher assurance level applies.

The CRA's assessment procedures come from Annex VIII and map to standard EU "modules." In plain terms: self-assessment means you do the work and declare conformity on your own responsibility. Third-party assessment means an independent notified body examines your product, your technical documentation, and your vulnerability handling processes before signing off. Here's how the categories line up.