If you manufacture IoT sensors or connected devices and sell them in Europe, there is a regulation you cannot ignore. The EU Cyber Resilience Act (CRA) was signed into law in late 2024 and the compliance clock is ticking. Most obligations take effect by September 2026, with full enforcement by December 2027.
This is not a recommendation or a best practice guideline. It is law. Non-compliant products cannot carry the CE mark. Without the CE mark, your product cannot be sold anywhere in the European Union. Fines for non-compliance go up to 15 million euros or 2.5 percent of global annual turnover, whichever is higher.
This checklist breaks down what you need to do, in plain language, so your engineering and compliance teams can start working today.
What the Cyber Resilience Act covers
The CRA applies to all "products with digital elements" sold in the EU. That includes any hardware or software that connects to a network or another device. IoT sensors, gateways, edge devices, embedded controllers, and the firmware running on them all fall under this regulation.
There are two product categories. Default category covers most IoT sensors and devices. These require self-assessment by the manufacturer. Important category covers devices used in critical infrastructure like industrial control systems, smart meters, and medical devices. These require third-party conformity assessment by a notified body.
If you make vibration sensors for factory floors or temperature sensors for industrial monitoring, you are likely in the default category. If your sensors go into energy grid infrastructure, water treatment plants, or healthcare equipment, expect to need third-party assessment.
Checklist: Security by design requirements
The CRA requires that cybersecurity is built into the product from the design phase, not bolted on later. Here is what your product must have.
Secure default configuration. Your device must ship with unique credentials, not factory defaults like "admin/admin." Each device needs a unique password or certificate provisioned during manufacturing. The Akran IQ platform uses mutual TLS certificates for device authentication, which satisfies this requirement out of the box.
No known exploitable vulnerabilities. Before you ship, you must scan your firmware for known CVEs in all third-party libraries, open source components, and operating system packages. This is not a one-time check. You need a process that runs with every firmware release.
Encrypted communication. All data transmitted by the device must be encrypted. TLS 1.2 or higher for TCP connections. DTLS for UDP. If your sensor uses MQTT, it must connect via MQTTS (MQTT over TLS). Unencrypted protocols like plain HTTP or unencrypted MQTT are not compliant.
Data minimization. Your device should only collect and transmit data that is necessary for its function. A vibration sensor does not need to collect location data unless location is part of its purpose. Document what data your device collects and why.
Access control. Your device must support role-based or at minimum credential-based access control. Unauthorized users should not be able to read sensor data, change configuration, or update firmware.
Checklist: Vulnerability handling requirements
The CRA puts significant emphasis on how you handle vulnerabilities after the product ships. This is where many sensor manufacturers will struggle because it requires ongoing processes, not just good initial engineering.
Vulnerability disclosure policy. You must publish a clear policy explaining how security researchers and customers can report vulnerabilities in your product. This needs to be publicly accessible, not buried in a PDF manual.
Coordinated vulnerability disclosure. When someone reports a vulnerability, you need a documented process to triage it, develop a fix, and release a patch. The CRA specifies timelines. You must acknowledge reports promptly and provide fixes within a reasonable period.
ENISA notification. For actively exploited vulnerabilities, you must notify the EU Agency for Cybersecurity (ENISA) within 24 hours of becoming aware. A detailed report must follow within 72 hours. This is similar to the GDPR breach notification requirement and requires an internal incident response process.
Security advisories. When you release a security patch, you must publish an advisory describing the vulnerability, its severity, and instructions for applying the fix. These advisories must be freely accessible to all users of the product.
Checklist: Software update requirements
The ability to update your device firmware securely is not optional under the CRA. Here is what you need.
Secure update mechanism. Your device must support over-the-air (OTA) firmware updates with integrity verification. The update package must be signed and the device must verify the signature before applying it. This prevents tampered firmware from being installed.
Free security updates. You must provide security updates free of charge for the entire support period of the product. The minimum support period is 5 years from the date the product is placed on the market, unless the expected product lifetime is shorter.
Automatic or easy updates. Users must be able to apply updates easily. The CRA encourages automatic updates with the ability for users to opt out. If updates are manual, the process must be simple and well documented.
Update availability notification. Your device or your cloud platform must notify users when a security update is available. Users should not have to check manually.
Checklist: Documentation and transparency
The CRA requires specific documentation that must accompany your product.
Software Bill of Materials (SBOM). You must maintain and provide an SBOM listing all third-party components, open source libraries, and their versions used in your firmware. This is critical because it allows downstream users to assess their own risk when a new vulnerability is discovered in a common library.
Technical documentation. You need detailed technical documentation covering the security architecture, the threat model, the risk assessment, and the conformity assessment results. This is not your user manual. It is an engineering document that demonstrates how your product meets each CRA requirement.
Declaration of conformity. A formal EU Declaration of Conformity must accompany each product. This declares that the product meets all applicable CRA requirements and allows it to carry the CE mark.
User instructions. Your product documentation must include clear instructions on how to set up the device securely, how to apply updates, how to report vulnerabilities, and what data the device collects.
Timeline: What happens when
The CRA has a phased enforcement timeline. Vulnerability reporting obligations take effect in September 2026. This means your vulnerability handling processes must be in place by then. Full compliance with all requirements is mandatory by December 2027. After that date, non-compliant products cannot be sold in the EU.
If you are designing a new product today, build CRA compliance into the requirements from the start. If you have existing products in the EU market, start a gap analysis now. You need 12 to 18 months to implement changes, test them, and complete the conformity assessment.
How Akran IQ helps with CRA compliance
If you are building IoT sensors or connected devices for the European market, the Akran IQ platform handles several CRA requirements at the infrastructure level.
Device authentication and encrypted communication are built into our cloud platform. Every device connects via mutual TLS with unique certificates. All data in transit and at rest is encrypted.
OTA firmware updates with signature verification are part of the platform core. You push an update, sign it, and the platform distributes it to your device fleet with integrity checks at every step.
Vulnerability monitoring for common IoT stacks is part of our managed services. We track CVEs in the libraries and protocols your devices use and alert you when action is needed.
The platform does not replace your own compliance process. You still need the SBOM, the documentation, and the conformity assessment. But it eliminates the hardest engineering challenges: secure device identity, encrypted communication, and secure update delivery.
What to do this week
Do not wait for 2027. Start now. Appoint a compliance lead. Download the CRA full text from EUR-Lex. Run a gap analysis against the checklist above. Prioritize the vulnerability handling requirements since those kick in first. And talk to us if you need help with the technical implementation. We have helped sensor manufacturers in India build CRA-compliant device infrastructure from the ground up.