EU Cyber Resilience Act: What It Means for Asset Tracking

Cybersecurity in connected hardware used to be a slide near the back of the deck: a feature to mention if a prospect asked, rarely the reason a deal was won. The EU Cyber Resilience Act (CRA) changes that. It’s the first horizontal EU law to mandate cybersecurity requirements across the entire lifecycle of “products with digital elements,” and it applies to essentially anything with a chip, a connection, and a customer in Europe, from industrial sensors and smart meters to asset trackers riding on returnable containers. 

As Talking IoT put it, the CRA marks a new era for device manufacturers: security stops being optional and becomes something you have to prove. At Sensolus, we build trackers that sit in the field for years and stay connected to the cloud the whole time, so that shift is one we recognize well. Our VP Engineering, Steven Van Hoof, laid out our approach in his whitepaper “Sleep Like a Baby Thanks to IoT: Security at Every Level,” and line by line, the regulation asks for things we already treat as standard practice at Sensolus. 

Strip away the legal language and the CRA rests on a simple idea: manufacturers must keep a connected product secure for its entire time in service, from the day it ships until it’s decommissioned. Concretely, that means: 

1. Security built in from the start, shipping with no known exploitable vulnerabilities and no more attack surface than the product actually needs. 

1. A vulnerability-handling process for the product’s expected lifetime, including a software bill of materials and free security updates. 

1. Fast reporting of actively exploited vulnerabilities and severe incidents: an early warning within 24 hours, full notification within 72 hours, and a final report within 14 days (or one month for incidents). 

1. The paperwork to back it up: technical documentation, user instructions, a CE mark, and an EU declaration of conformity. 

The regulation entered into force on 10 December 2024, and the rest phases in over three years: 

1. 11 June 2026: rules for designating the notified bodies that carry out third-party conformity assessments start applying. 

1. 11 September 2026: vulnerability and incident reporting obligations become binding. 

1. 11 December 2027: the rest of the CRA’s main provisions, including manufacturers’ own conformity-assessment obligations, become binding. 

Non-compliance carries fines of up to €15 million or 2.5% of global annual turnover, whichever is higher, just under GDPR’s own top-tier cap of €20 million or 4%. 

Products in the CRA’s “important” category face tighter scrutiny: Class I (password managers, VPNs, general-purpose operating systems) allows self-assessment if harmonised standards are applied, Class II (firewalls, intrusion detection systems) always requires third-party assessment, and “critical” products (smart meter gateways, secure elements) need certification outright. Most connected devices, trackers included, sit outside these categories under the default self-assessment route, but the core obligations around secure design, vulnerability management, and incident reporting apply no matter which bucket a product lands in. There is no tier where “we’ll patch it eventually” is an acceptable answer.

Asset trackers are a clear example of what the CRA is worried about: built to sit unattended in the field for years, easy to forget once installed, and permanently connected to a cloud platform holding real operational data. That combination of long deployment, low visibility, and constant connectivity is exactly the profile the CRA is trying to cover. 

It reaches two audiences at once. Device manufacturers, whose trackers and firmware are exactly the “products with digital elements” the regulation describes, and the operators who buy and deploy those trackers (logistics, industrial, aerospace), who will increasingly be asked by their own auditors to prove their connected hardware meets the standard. Procurement teams that once asked “does it work?” are starting to ask “can you show me your vulnerability-handling process?” A vendor who can’t answer that becomes a liability the moment it’s plugged in. 

This is where Steven’s whitepaper is worth reading end to end: its three guidelines map closely onto what the CRA is trying to standardize. 

1. Secure by design.Not an add-on module, but the default state of every tracker from the moment it leaves production: data encrypted in transit and at rest, each device with its own unique identity and key management rather than a shared credential.Sensolus hosts its platform in the EU on AWS, with separate environments per customer and dedicated tenants where needed (aerospace, for instance), and produces its hardware in the EU too, at partners like Alps Alpine in Ireland. As Steven puts it, that combination gives customers “clear contractual safeguards, faster due diligence and easier adoption by compliance teams,” which is nearly word for word what a CRA-conscious procurement team is now looking for. 
2. Platform governance.Single sign-on, multi-factor authentication, and role-based access control keep the login simple for users while staying strict underneath. Every action is logged, so questions like “who pushed the latest firmware update?” or “who changed thisgeozone?” always have an answer, the firmware one especially, since an update is exactly the kind of change that could introduce a vulnerability. That matters once you’re operating under a regulation that gives you 24 hours to report an incident once you become aware of it. The same audit trail also helps during the response itself: knowing what changed, when, and by whom is what lets a team contain and reverse the damage, not just file the report on time. 
3. Security that keeps working.Firmware is encrypted and authenticated from first installation, updates are checked beforethey’re trusted, and unique device IDs let Sensolus detect a device that doesn’t belong before it gets in. One good illustration: a US car dealership once raised a privacy concern about a tracker left in a sold vehicle by mistake. Sensolus’s fix became a standard feature, with geozones now able to force a tracker to stop or limit its logging outside an agreed area. That’s the difference between security as a checkbox and security as a routine: independent penetration tests every year, run by a different partner each time, with findings shared with customers and folded back into the product. 

The CRA requires manufacturers to keep a product secure for as long as it’s reasonably expected to stay in use, so new capabilities added years later have to meet the same standard as what shipped on day one. That’s the test AI features are starting to pose across IoT. Sensolus already uses AI to flag anomalies, such as an asset stationary far longer than normal or one that’s drifted outside its zone, and to sharpen location accuracy, always within a user’s existing access rights: every action is logged and enforceable through the same SSO, MFA, and RBAC controls that govern a human user. As Steven puts it, “first data quality and privacy, then AI. Otherwise, you only make mistakes faster,” a fair summary of what the CRA is trying to legislate into every connected product by default.

It’s tempting to treat the CRA as a compliance tax: one more audit, one more document before a deal closes. The more useful read, and the one Steven lands on in the whitepaper’s conclusion, is that security done properly is invisible day to day and obvious in the result: peace of mind, predictability, and due diligence that goes faster because the answers were already true before anyone asked. 

That’s the real opportunity for operators managing connected assets across Europe. Vendors who’ve already built end-to-end encryption, EU hosting, strict access governance, and a genuine vulnerability-handling routine won’t need to scramble once reporting obligations begin; they’ll simply hand over documentation their customers’ auditors are already asking for. For everyone else in the supply chain, that’s exactly the kind of vendor question worth asking now, well before the reporting clock starts running. 

Steven titled his whitepaper “Sleep Like a Baby Thanks to IoT” for a reason: when secure design, EU hosting, and a real incident-response routine are already in place, the CRA stops being something to lose sleep over.