# EU Cyber Resilience Act: What Changes > The EU Cyber Resilience Act starts to bite on 11 September 2026. What it changes about the smart devices you buy, and what to check before you buy one. By Rose · August 16, 2026 · 13 min read · Privacy Source: https://bluwarden.com/blog/cyber-resilience-act-what-changes --- Most of the EU tech law that reaches the general public arrives as something to worry about. Chat Control, data retention, age verification - the pattern is usually a new power for someone else and a new exposure for you. The Cyber Resilience Act is the rare one that runs the other way. It is a product safety law, and the product it makes safer is the router in your hallway, the camera watching your front door, and the app on the phone in your pocket. For the first time, a device sold in the EU has to tell you how long it will receive security updates - before you pay for it - and has to ship in a secure state rather than a convenient one. The first hard deadline lands on **11 September 2026**, a few weeks from now. The bulk of it lands on **11 December 2027**. This post covers what the law actually requires, what genuinely changes for you as a buyer, the significant thing it does *not* fix, and what a business selling anything connected needs to have started already. --- ## What the Cyber Resilience Act actually is [Regulation (EU) 2024/2847](https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng) entered into force on 10 December 2024. In the plainest terms: **if a product can connect to something, it now has to be secure to be legal in the EU.** The Commission keeps a [plain-language summary of the legislative text](https://digital-strategy.ec.europa.eu/en/policies/cra-summary) if you want the official version of everything below. It works like the CE mark on a kettle. A kettle cannot be sold in the EU unless it meets electrical safety rules, and the manufacturer signs off on that. The CRA extends the same machinery to "products with digital elements" - hardware with software in it, and software sold on its own. From December 2027, the CE mark on a smart doorbell will mean something about its security, not just its electrical behaviour. Scope is broad on purpose. Smart home devices, routers, baby monitors, wearables, industrial controllers, desktop software, mobile apps, operating systems. The Commission's guidance, published on 27 July 2026, confirmed that websites and pure cloud services generally sit outside the CRA - they are covered by NIS2 instead - unless they are the remote component that makes an in-scope product work. Free and open-source software only picks up obligations when it is supplied commercially, with a lighter regime for open-source stewards. The thing worth understanding is the philosophy. The CRA does not tell manufacturers to be careful. It makes an insecure connected product a **defective product**, in the same legal sense a kettle that electrocutes people is defective - with market surveillance authorities who can order a recall and fines up to €15 million or 2.5% of worldwide annual turnover for breaching the essential requirements. That is GDPR-scale money aimed at engineering decisions. --- ## The dates that matter | Date | What happens | |---|---| | **10 December 2024** | Regulation entered into force. Clock starts, nothing required yet. | | **11 June 2026** | Conformity assessment bodies can be notified - the certification plumbing goes live. | | **11 September 2026** | **Reporting obligations apply.** Manufacturers must report actively exploited vulnerabilities and severe incidents. | | **11 December 2027** | **Full application.** Essential requirements, CE marking, support periods, documentation. | The September date is the one most people underestimate, because it applies more widely than the rest of the law. From 11 September 2026, a manufacturer that learns of a vulnerability in its product being actively exploited has **24 hours** to file an early warning with ENISA and the relevant national CSIRT, followed by a fuller notification within **72 hours**. Crucially, that reporting duty covers products already on the market - not just products released after December 2027. So this is the first piece of the CRA that touches the devices sitting in your house right now. Reports go through a single channel - the CRA Single Reporting Platform - addressed to the CSIRT of the country where the manufacturer has its main establishment, with ENISA receiving the information at the same time. The Commission's [reporting obligations page](https://digital-strategy.ec.europa.eu/en/policies/cra-reporting) sets out the full sequence, including the final report due within 14 days of a fix being available. What it does not do is tell *you*. The reports go to regulators, not to customers. The public benefit is indirect: coordinated response, faster patches, and a growing body of evidence about which vendors keep having the same problem. --- ## What changes for you as a buyer This is the part worth actually knowing, because several of these are new consumer rights rather than vague aspirations. All of the following come from the CRA's Annex I (essential requirements) and Annex II (information to the user), and apply in full from December 2027. | What you get | What it means in practice | |---|---| | **A published end-of-support date** | The manufacturer must tell you, at the time of purchase, the date after which security updates stop. Month and year, minimum. | | **A minimum five-year support period** | Support must run at least five years unless the product is genuinely expected to be used for less, justified and documented *before* it goes on sale. | | **Free security updates** | Security updates must be provided free of charge, and separately from feature upgrades. No paying to unlock a patch. | | **Automatic updates, on by default** | Automatic security updates must be enabled by default where applicable, with a clear and easy opt-out. | | **A secure default configuration** | Products must ship secure rather than convenient, with the ability to reset to that original state. | | **A working way to report a flaw** | A single named point of contact where anyone can report a vulnerability. | | **A way to wipe the device** | Users must be able to securely and permanently remove all their data and settings. | | **Data minimisation, in the product itself** | The device may only process data adequate, relevant and limited to what its function needs. | Two of these are quietly significant. **The end-of-support date changes shopping.** Today, "how long will this get updates?" is usually unanswerable - you find out when the updates stop, which is to say you never explicitly find out at all. Turning it into a printed figure makes it comparable, and things that become comparable become competitive. Expect it on spec sheets next to battery life. **The support clock starts at market placement, not at your purchase.** The five years run from when the product was first made available in the EU, not from the day you unboxed it. A heavily discounted device that has been sitting in a distributor's warehouse for two years is a device with three years of support left. That is not a loophole - it is how the law defines the term - but it does mean end-of-life stock is worth less than the sticker suggests. One honest caveat on the secure-default requirement: the CRA mandates a secure configuration and proper access control, but it is written in outcome language rather than a specific ban on shipping every unit with the same factory password. In practice that combination is what it is aimed at. Until enforcement produces actual cases, treat it as strong pressure rather than a guarantee, and keep changing default credentials yourself. --- ## The catch: it does not fix what you already own This is the part most coverage skips, and it matters more than any of the above. The CRA's substantive requirements apply to products **placed on the market after 11 December 2027**. Devices already sold are only pulled into scope if they undergo a substantial modification after that date. The only obligation reaching backwards is the reporting duty starting this September. So the practical picture is: - Your current router, camera, TV and smart plugs get **no new support commitment**, no guaranteed update period, and no end-of-life disclosure. - A device you buy in 2026 or early 2027 is very likely still a pre-CRA device. - The improvement arrives with your *next* purchase cycle, and reaches your whole home only as old hardware is replaced - which for things like routers and cameras can be five to ten years. That gap is the reason network-level defence still matters. Regulation raises the floor for new products; it does nothing for the ten-year-old IP camera with a hardcoded password that will never see another firmware release. Segmenting IoT devices onto a separate network or guest VLAN, and keeping them off the same segment as laptops and phones, remains the highest-value thing you can do about equipment that will never be compliant with anything. --- ## How to buy a connected device in the meantime Nothing here requires waiting for December 2027. These are the questions the CRA will eventually force manufacturers to answer, asked early - and a vendor who can answer them now is telling you something useful about the vendor. ### 1) Find the end-of-support date before you pay Look for a stated date or duration, in months or years, on the product page or in the manual. "Regular updates" is not a date. If a manufacturer cannot state one in 2026, they are going to struggle to state one in 2027, and that is worth knowing while you can still buy something else. ### 2) Check that updates install themselves The default should be automatic. If applying a security patch requires downloading a file from a support page and running a desktop utility, assume in practice it will never happen - because for most owners it does not. ### 3) Treat the vulnerability contact as a maturity signal Look for a `/security` page, a security.txt file, a disclosure policy, or a named contact. A vendor with a real intake process has thought about receiving bad news. A vendor with only a general sales enquiry form has not. ### 4) Change the default credentials, and use unique ones Until secure-by-default is enforced reality rather than a 2027 requirement, this is on you. Router admin panels, camera portals and NAS boxes are the usual offenders. A password manager makes unique-per-device credentials practical - see our [guide to passkeys and password practice](/blog/password-best-practices-2026) for the current approach, and prefer passkeys wherever a vendor offers them. ### 5) Put IoT devices on their own network Most consumer routers can run a guest network. A compromised smart bulb on an isolated segment is a nuisance; the same bulb on the same network as your laptop is a foothold. ### 6) Wipe devices properly before selling or discarding them The CRA will require a secure-deletion function. Today it is inconsistent. Factory reset, then verify the device no longer appears in the vendor's app and the account link is removed - a "reset" that leaves your cloud account attached has not reset the part that matters. ### 7) Apply the same discipline to the phone in your hand Your phone is the control surface for everything else in the house, and it is already covered by mature update mechanisms that the CRA is essentially trying to make universal. Our [Android](/blog/android-standard-security-hardening) and [iOS hardening guides](/blog/ios-standard-security-hardening) cover the settings that matter. --- ## What it means if you sell anything connected If your company makes hardware with software in it, sells software into the EU, or integrates third-party components into a product that ships to EU customers, the CRA is a product compliance programme, not a security project. Six things it is worth being blunt about. 1. **September 2026 is a process deadline, not a paperwork deadline.** A 24-hour early warning obligation means someone must be reachable, empowered, and rehearsed on a weekend. If you cannot name that person today, that is the gap. 2. **The support period is a commercial decision disguised as a technical one.** Five years of patching for every SKU has a cost, and it has to be committed to before the product goes on sale - and disclosed to buyers. This belongs in product planning, not in a compliance review three months out. 3. **You inherit your dependencies' problems.** Manufacturers must exercise due diligence on the components they integrate, including open-source ones, and report vulnerabilities upstream. An SBOM in machine-readable form is required in your technical documentation - which means knowing what is actually in your build. Our post on [securing AI-generated applications](/blog/secure-vibe-coded-apps-2026) covers the dependency-provenance problem that makes this harder than it sounds. 4. **Your conformity route depends on your product class.** Default products self-assess. Important Class I and II and critical products face progressively stricter routes, up to mandatory third-party certification. Find out which bucket you are in before you plan the timeline, because third-party assessment has a queue. 5. **Substantial modification restarts the analysis.** A security patch that introduces no new risk is not a substantial modification - the Commission's July 2026 guidance was helpful on this. A significant functional change is, and it can drag a pre-2027 product into full scope. 6. **The penalties are tiered and large.** Up to €15 million or 2.5% of worldwide turnover for the essential requirements, €10 million or 2% for other obligations, €5 million or 1% for supplying incorrect information to authorities - whichever is higher, in each case. Worth noticing the direction of travel here. The CRA, the platform-level identity requirements behind [Android's developer verification rules](/blog/android-developer-verification-sideloading), and the scanning obligations in [Chat Control](/blog/chat-control-is-back) are all the same instinct applied to different layers: someone accountable must stand behind the code. The CRA is the version of that instinct most clearly aimed at protecting the person who bought the thing. --- ## Summary The highest-impact points, in order: 1. **11 September 2026** brings vulnerability reporting obligations, and they apply to products **already on the market** - the only part of the CRA that reaches backwards. 2. **11 December 2027** is when the consumer-visible parts land: published end-of-support dates, a five-year minimum support period, free security updates, automatic updates on by default. 3. **It does not fix the devices you already own.** Anything bought before December 2027 is outside the substantive requirements unless it is substantially modified. 4. **Ask for the end-of-support date now.** A vendor who can answer in 2026 is a vendor who will still be patching in 2029. 5. **Segment your IoT devices**, because the equipment the CRA will never cover is exactly the equipment most likely to be compromised. 6. **If you sell connected products**, the September reporting process and the support-period commitment are the two decisions that cannot wait for 2027. The interesting thing about the CRA is not the compliance burden - it is that "how long will this be supported?" is about to become a number on a box. Security has been an invisible attribute of consumer electronics for thirty years, which is precisely why so little of it exists. Making it visible is the mechanism. Whether it works depends on how many people read the number before they buy. --- *Not sure where your product sits under the CRA, or whether your September reporting process would survive contact with a real incident? [Get in touch](/#contact) - the bluwarden team can map your obligations and pressure-test the process.* *This guide is general advice, not legal counsel or a substitute for a compliance assessment tailored to your organisation. For a review of your specific product scope and regulatory exposure, consult a qualified product compliance or security professional.*