A Declaration Is Not a Warranty

By Fredrik Lindstrom · ~24 minute read · September 2026

What the EU Cyber Resilience Act Changes for Boards

On 11 September 2026 Article 14 of the EU Cyber Resilience Act began to apply, the first of the Regulation’s obligations on manufacturers, and the question for a buyer is what a supplier now owes you and your supply chain. In July 2026 I wrote about two security products that became the breach: Ivanti’s quiet fix in February 2025, shipped as a low-risk bug with no CVE and no advisory for that flaw, and the roughly 74,000 internet-facing FortiGate devices whose administrator and VPN credentials turned up in an exposed dataset in June 2026. Run both against the Regulation and it reaches less than the board packs are about to claim. The gap is where the governance work sits.

The Regulation states its own purpose. Recital 2 wants hardware and software placed on the market with fewer vulnerabilities and manufacturers taking security seriously throughout a product’s lifecycle. It also wants users able to take cybersecurity into account when they choose and use a product, and its own example is transparency about the support period. Article 1 turns that into rules for making products available on the market, essential cybersecurity requirements for how they are built and for how their vulnerabilities are handled for as long as they are expected to be in use, and rules on market surveillance and enforcement. This article explores if the EU Cyber Resilience Act actually achieves its purpose for users.

Today the EU Cyber Resilience Act reaches a vulnerability once somebody is exploiting it, and from December 2027 it reaches a quiet fix, on products placed on the market from that date. The FortiGate credential store never produced a CVE, so today it produces a filing only if Fortinet calls it an exploited vulnerability, which Fortinet declined to do; from December 2027 the Regulation reaches that design on new placements, and no earlier. A board that reads a CE mark as a security guarantee has already agreed to be shown that case again, on time and in full compliance.

What a vendor disclosure means from 11 September 2026

Article 14 of the EU Cyber Resilience Act is the only obligation on manufacturers that applies as this is published, and it is narrower than most board packs will assume.

The trigger is an actively exploited vulnerability, or a severe incident affecting the security of a product with digital elements. Not every CVE. Not every advisory. Once a manufacturer becomes aware, it has 24 hours for an early warning and 72 hours for a notification describing the corrective or mitigating measures taken and the ones users can take, as far as any exist. A final report follows within 14 days of a measure becoming available, or for a severe incident within a month of the 72-hour notification. The manufacturer files once, through ENISA’s Single Reporting Platform, to the computer security incident response team designated as coordinator in the Member State of its main establishment in the Union, or down the cascade Article 14(7) sets for a manufacturer without one. The filing is simultaneously accessible to ENISA, subject to the particularly exceptional circumstances Article 16(2) allows for the 72-hour notification. No fine sits behind any of those clocks until 11 December 2027, when Article 64 applies.

The duty runs to a CSIRT and to ENISA first. You are downstream of a filing you never see. Article 14(8) then obliges the manufacturer to inform impacted users, and where appropriate all users, of the vulnerability or incident and of any mitigations they can deploy. That duty carries no clock. The CSIRT may step in if the manufacturer fails to inform users in a timely manner, and the recitals give publishing on the manufacturer’s website as one way to do it. So the one duty aimed at you arrives on the manufacturer’s judgement of who counts as impacted and on no fixed timetable. The Regulation does not define “timely”. The Commission’s guidance C(2026) 5252 repeats the word without defining it, then says the manufacturer may limit what it tells whom. That is a flaw in the text, and it is written in the manufacturer’s favour. The clock you want is the one you draft into the contract.

This notification lands on an organisation whose vendor-risk process runs on a quarterly review cycle. Somebody must own what happens between that notification arriving and the change window opening. In my experience, most organisations do not have an owner for this.

Ivanti’s fix went out on 11 February 2025 in a point release, assessed as a low-risk bug; Google’s threat intelligence team dates the first observed exploitation to mid-March, and Ivanti disclosed on 3 April 2025 with a CVE attached. Article 14 keys the duty to awareness of exploitation, so under the Regulation a filing would have been due 24 hours after Ivanti knew of the March exploitation, whenever that was, and the February silence stays silent. The provision that reaches a silent fix is Annex I, Part II, point (4), which requires public disclosure of a fixed vulnerability once the security update is available, with a delay the manufacturer may justify until users can patch. It applies from 11 December 2027, to products placed on the market from that date or substantially modified after it. Connect Secure as sold in 2025 was placed on the market well before that date, and sits outside the provision unless it is substantially modified after it.

The platform opened on the day the duty did

ENISA launched the Single Reporting Platform for EU Cyber Resilience Act reporting on 11 September 2026, the day Article 14 began to apply, and describes what went live as the initial operating capability: mandatory Article 14 reporting only, in English only. Its Executive Director, Juhan Lepassaar, said the streamlined reporting “helps to build a more resilient Digital Single Market.”

There is no API. ENISA’s own platform FAQ says that no application programming interface will be provided at the initial release, and that one may be considered in a future phase. A named person, registered through EU Login as the manufacturer’s Assigned Representative, logs into a web form and types. That is the mechanism behind a 24-hour clock that runs on weekends and through public holidays, during live exploitation, in English whatever language the manufacturer works in. Manual work in a real-time exploit window, by choice.

Article 69(3) reaches backwards. The reporting duty in the EU Cyber Resilience Act covers in-scope products already on the EU market, and only that duty does; under Article 69(2) the rest of the Regulation reaches a product placed on the market before 11 December 2027 only if it is substantially modified after that date. A router shipped in 2022 is inside Article 14 and outside everything else.

And there is an amnesty nobody will send you a notice about. The European Commission’s guidance on the Regulation, C(2026) 5252 of 27 July 2026, says at paragraph 217 that a manufacturer need not report a vulnerability whose active exploitation it had already established before 11 September 2026. Know the flaw but learn of the exploitation after that date, and the duty applies. So, a flaw whose exploitation a supplier had already confirmed on 10 September generates no filing on the 11th.

For a buyer that cuts one way. The EU Cyber Resilience Act neither compels that disclosure nor forbids it, and whether the user-information duty in Article 14(8) reaches those flaws is a question the guidance leaves open. Whether you hear about it depends on the supplier, which was exactly the position on 10 September, now written down.

Running FortiBleed against the EU Cyber Resilience Act

The second case from the July article, FortiBleed, shows what kind of instrument the EU Cyber Resilience Act is. It surfaced on the weekend of 13 June 2026, when Volodymyr Diachenko posted that a dataset on attacker-controlled infrastructure held administrator and SSL VPN credentials for tens of thousands of FortiGate devices; Hudson Rock counted 73,932 across 194 countries. Kevin Beaumont, working with Hudson Rock, confirmed on 17 June that the data was real and that almost all the devices were still online. CISA issued an alert on 18 June, and the Canadian Centre for Cyber Security issued Alert AL26-014 the same day. Fortinet’s position, on 19 June, was that the activity reused credentials from two earlier incidents, FG-IR-25-647 in December 2025 and FG-IR-26-060 in January 2026, combined with brute-force techniques, and that it was “not a new Fortinet vulnerability.”

That position was technically defensible, and Beaumont disputed it in print the same day: in the organisations he was helping, configurations had been exported over the previous month and cracked offline to yield new passwords. SpyCloud, which examined the attacker’s own servers, dated the earliest FortiGate capture cycle to 19 May 2026. The governance question starts there, because part of what made the dataset crackable at scale was a design decision. Fortinet moved administrator credentials to PBKDF2 hashing in FortiOS 7.6.1, released in November 2024, and the upgrade rehashed nothing already stored: a password stayed in the older salted SHA-256 format until that administrator next logged in, and by default the old hash was kept even after conversion. A device could run current, fully patched firmware and still hold an administrator credential that can be cracked offline once its configuration leaks. Beaumont’s estimate was “many devices.

Assume the EU Cyber Resilience Act had applied to every device in that dataset from the day it was placed on the market, both clocks running from before December 2025. That is a thought experiment; Article 69(2), stated above, is the rule that actually applies, and the declaration section returns to it.

What would have fired

Two vulnerabilities, on a 24-hour clock. The December 2025 FortiCloud single sign-on bypass in FortiOS, CVE-2025-59718, and the January 2026 bypass, CVE-2026-24858, are the two earlier compromises Fortinet itself named as the credential sources, and both are on CISA’s Known Exploited Vulnerabilities catalogue, the second from 27 January 2026. Active exploitation is exactly the trigger in Article 14 of the EU Cyber Resilience Act, and Article 14(8) then puts a notification, with no clock, in front of impacted users for each of them. On the January one, Arctic Wolf published on 21 January and Fortinet’s advisory followed on 27 January, the day of the KEV listing, so a CSIRT would have heard within 24 hours of Fortinet’s awareness and a CSIRT’s knowledge moves by days while public disclosure stays where it was. The December one Fortinet disclosed before anyone exploited it, so the filing adds nothing on timing.

A notified body in the room. This is the largest change, and almost no buyer has priced it. A firewall is an important product in Annex III, Class II, of the EU Cyber Resilience Act, and Commission Implementing Regulation (EU) 2025/2392 of 28 November 2025 names firewalls. Article 32(3) leaves a Class II manufacturer three routes and none of them is self-assessment: EU-type examination by a notified body, full quality assurance audited by one, or a European cybersecurity certificate that no one can yet issue for this purpose. For a proprietary FortiGate a third party is in the room. It examines the design file and specimens of the critical parts, with tests as it judges appropriate, and every later change to the type that may affect conformity goes back to it; under full quality assurance it examines the quality system and audits it periodically. A credential store that keeps the weaker hash by default is a question under Annex I, Part I, points (2)(b) and (2)(e), and the file that describes it is the file the assessor reads: in the type file for units placed after November 2024, and as a change to the type for the rest. It is the kind of decision that survives internal review comfortably. In my experience, a documented weaker-by-default choice reads very differently to an assessor whose accreditation is on the line than it does to the team that made it.

One sentence made mandatory user information. Annex II of the EU Cyber Resilience Act lists what must accompany a product: point 8(a) is the measures needed to use it securely, and point 8(b) is “how changes to the product with digital elements can affect the security of data.” Fortinet’s 7.6.1 documentation did say that the old hash is kept until the next login, and by default afterwards, and it documented the setting that removes it, as a downgrade-compatibility toggle. It named no risk and recommended nothing; the recommendation to remove the legacy setting arrived on 19 June 2026, in the post about FortiBleed. Under Annex II point 8(b) the effect of that change on the security of data is a topic the user information must cover or point to, and point 8(a), the measures needed for secure use, is where the recommendation belongs. The same user information carries the support-period end date under Annex II point 7 and Article 13(19), and Annex VII folds all of it into the file the assessor examines. Smaller than it sounds. Larger than most buyers have today.

What is contested, and who decides

The EU Cyber Resilience Act defines a vulnerability as any weakness that can be exploited, with no mention of a CVE, and its recitals give weaknesses in a product’s authentication functions as the example of what gets exploited. Whether a crackable hash retained by default on current firmware is an actively exploited vulnerability is therefore a live question. Fortinet’s June position, given to the activity as a whole, put it on the customer’s side: “not a new Fortinet vulnerability.”

The recitals key active exploitation to what a manufacturer establishes about a breach in its own product, so under the Regulation the manufacturer makes that judgement first, with market surveillance behind it from December 2027. The party with the strongest incentive to log an event as customer-side is the party whose 24-hour clock starts if it is not. The contract you negotiated is what surfaces a classification decision a supplier made and chose not to report; the EU Cyber Resilience Act leaves that to you.

What would not have changed

Nothing in the EU Cyber Resilience Act rotates a credential or cleans up a device that was already compromised. Article 14(8) has the manufacturer describe what users can do, and the rotation is the operator’s job.

For the part of the affected population running weak passwords with no multi-factor authentication, the Regulation has nothing to say to the operator. That failure was measurable by any competent programme before the Regulation existed and stays measurable after. From December 2027 Annex I, Part I puts secure-by-default configuration and access control on the manufacturer, for products placed from that date, so the part of that failure the shipped default controls moves over time from the operator’s column to the vendor’s.

Which gives you the honest total, counted as the floor, with Fortinet’s own classification left standing: two filings to a CSIRT and ENISA that you never see, a notification to impacted users for each of them with no clock on it, one outside assessor examining the design file, and one sentence with an end date made mandatory user information. Against 74,000 exposed devices, that is real and nowhere close to sufficient. It is also the point. What reaches you from that list is information on terms the Regulation sets as minimums and a notification on the manufacturer’s timetable, and the remedy for any of it belongs to a regulator. That is what the Regulation is made of, and it is why a declaration is not a warranty.

What the declaration says, and who holds the remedy

From 11 December 2027 the second clock starts, for products placed on the market from that date; the estate a board already runs will never be conformity-assessed unless it is substantially modified. This is the part boards will misread, and the Regulation provides for the case they will miss.

Article 13(12) of the EU Cyber Resilience Act requires a manufacturer to demonstrate that the product complies with Annex I, Part I, and that its processes comply with Part II, then draw up an EU declaration of conformity under Article 28 and affix CE marking under Article 30. Article 28(4) says that by drawing up the declaration the manufacturer assumes responsibility for the compliance of the product, and Annex V records that it does so on its sole responsibility. Sole responsibility, for compliance of the product and of the processes.

Who checked depends on the tier, and the tier fixes the minimum route. Default-tier products may use internal control, which is self-assessment. Class I products keep that route only on full application of harmonised standards, common specifications or a European cybersecurity certification scheme, and as at 12 September 2026 none of the three exists: no harmonised-standard reference in the Official Journal under Article 27(1), no common specification, and no certification scheme designated under Article 27(9), though the Commission has scheduled that last act for late 2026. If that holds when assessment begins, Class I is a notified-body route. The full declaration names the notified body and the procedure where one was involved, so a full declaration naming none was self-assessed; the simplified form Article 13(20) allows to travel with the product names nothing and links to the full one. The mark itself carries a notified body’s number only under full quality assurance.

Here is the trap for a board. The CE mark is already on most of the hardware you own, and from 11 December 2027 the same mark on a newly placed product also says the manufacturer declared it conformant with the EU Cyber Resilience Act. The Regulation says what that is worth. Recital 89 makes the mark the only marking that guarantees compliance with the Regulation’s requirements, and Article 57 is an entire procedure for products that comply and present a significant cybersecurity risk anyway, with a risk to health, safety, fundamental rights or essential services alongside it. The drafters wrote the limit into the text. In July 2026 I wrote that “a passed audit is a lagging indicator of a security posture.” A CE mark under this Regulation is the same instrument with better typography, and for a default-tier product with no outside assessor in the room, a weaker one.

The distinction that matters is who holds the remedy. A declaration is a claim of conformity, and the remedies for a false one belong to the market surveillance authority: from 11 December 2027, corrective action, withdrawal, recall and prohibition under Articles 54 to 58, and fines under Article 64. A warranty is a promise addressed to you, with your remedy attached. The Regulation gives you no claim and no remedy; the Product Liability Directive (EU) 2024/2853 gives one to natural persons and excludes property used exclusively for professional purposes, which is your estate. A declaration is handed to you. A warranty is negotiated. The EU Cyber Resilience Act leaves the three asks from July standing: the security super-cap, the committed remediation window and the evidence-of-security warranty. This piece adds a fourth, the notification term you draft yourself, because Article 14(8) carries none. A declaration satisfies none of the four. What the Regulation adds is a set of hooks procurement can price, and the one with the clearest statutory footing is the support period.

Article 13(8) requires a manufacturer to set a support period that reflects how long the product is expected to be in use, of at least five years unless the expected use is shorter. The Commission’s guidance C(2026) 5252 says the minimum operates only as a safeguard and is not a default, and the Regulation’s recitals name routers, modems and switches as products that should carry longer periods. Article 13(19) requires the end date, at least the month and the year, to be stated at the time of purchase, and Annex VII puts the information the manufacturer took into account into the technical documentation a market surveillance authority can demand. That is a procurement input a buyer can hold.

What propagates, and where it stops

Under the EU Cyber Resilience Act the obligation moves down the supply chain, and the duty lands on the manufacturer that integrates, which is what your supplier is holding.

Article 13(5) puts the due-diligence duty on the manufacturer integrating third-party components, and it reaches open-source software that was never placed on the market commercially. A manufacturer that puts a third-party chip or a public cryptography library in its product owns their vulnerabilities for the whole support period. Article 13(6) then requires it to report a vulnerability it finds in a component back to whoever maintains it, and to share the fix where it built one.

What is missing is a warranty from upstream. A commercial component vendor carries its own Article 13 and Article 14 duties for a component it sells separately. A library that is not monetised has no manufacturer behind it; where it has a steward, Article 24 gives the steward reporting duties from December 2027 for what it helped develop, and Article 64(10) no fines. Where it has no steward, the chain stops there. The integrator’s due diligence under Article 13(5) stays with the integrator in every case.

Article 13(8) is where a common reading of that chain gets the law backwards. The manufacturer answers for the vulnerabilities of the product, including its components, for the whole declared support period; the support periods of third-party components that provide core functions are among the things it may take into account when setting its own. A component vendor’s end-of-support decision leaves your supplier holding the duty for its whole declared period over a part with nobody behind it, and the declared period stays where it was.

Article 64’s ceiling of 15 million euros or 2.5 percent of worldwide annual turnover, whichever is higher, for breaches of Annex I or of Articles 13 and 14 from 11 December 2027, will get the attention in most board packs. What to lead on is what a supplier cannot evidence because it never instrumented it: nobody can reconstruct component provenance and update commitments after the fact, and by the time the gap surfaces the component is load-bearing and the supplier has to rebuild around it.

One more duty propagates, and it catches organisations that never thought of themselves as manufacturers. Under Article 22, substantially modify a product and make the modified product available on the market, and you are its manufacturer for the part you changed, or for the whole product where the change affects its cybersecurity as a whole. A rebuild for your own internal use never gets there. A rebuild you supply to customers does, from December 2027, whether or not you knew the classification existed.

What changes on your side

Each head carries the date the Regulation backs it from. None of them waits.

Whether you are a manufacturer is a question with a written answer, and Article 14 already applies to the answer. A managed service provider that has a firewall appliance built to its specification and ships it under its own brand is a manufacturer under Article 3(13) of the EU Cyber Resilience Act, and Article 14 has run against it since 11 September 2026; a distributor that only rebrands somebody else’s appliance becomes one under Article 21 from 11 December 2027. A bank whose customer app goes to market under the bank’s name is the manufacturer of that app under Article 3(13), whether or not it touched the VPN component inside; the component is a due-diligence question under Article 13(5). Any product with digital elements you develop, or have developed, and place on the EU market under your name puts you in scope, subject to the sector exclusions in Article 2. Get the answer in writing before a market surveillance authority provides it.

Name the owner of the absorb path, today. Here is a test with a real date in it. Ask your team how many hours passed between the 18 June 2026 alerts landing and somebody terminating sessions and rotating administrator credentials on every internet-facing device you own. If nobody can produce the number, that is the finding. Article 14 of the EU Cyber Resilience Act gives you one thing here, a notification under Article 14(8), and the clock on it is yours.

The support period belongs in procurement, from December 2027 on new purchases and in your contracts now. An edge appliance on a ten-year deployment carrying a five-year declared support period gives you five years of unsupported perimeter, and the depreciation schedule will never tell you so. Ask two things of every security product at renewal: the declared end date, which Article 13(19) puts at the point of purchase, and how the supplier keeps its Article 13(8) promise when a component underneath it reaches end of support. Put the security super-cap, the remediation window, the evidence-of-security warranty and your own notification term beside them; the declaration answers none of the four.

Update the vendor-introduced exposure metric, today. In July 2026 I set that line to draw from matches in CISA’s Known Exploited Vulnerabilities catalogue, vendor advisories, disclosed design and migration gaps, and credential-store audits. FortiBleed is why: it produced no CVE for the migration gap, so a KEV-sourced metric read green while many of the roughly 74,000 devices in the dataset held administrator credentials in a format that can be cracked offline, and the advisories did better, since CISA’s 18 June alert and Fortinet’s 19 June guidance both named the legacy-hash removal step. The EU Cyber Resilience Act adds one source to that line, manufacturer notifications to impacted users, and removes nothing. Keep the credential-store audit, and add one question with a factual answer to the quarterly pack: the hash format every administrator credential on every internet-facing device is stored in today, and when each was last rotated. A number, a date, and a direction of travel.

The annex your security products sit in, and the route that follows, from December 2027. Your CRM, if it is browser-only software in a vendor’s cloud, is outside the EU Cyber Resilience Act and will carry no CE mark for you to misread; a cloud back end without which the software the vendor ships to you cannot perform one of its functions is inside it, as remote data processing. Build the one-page version of the table above for every security product you run, and read the route off the full declaration of conformity, because the mark will tell you only whether full quality assurance was used. A notified body reading a firewall vendor’s vulnerability-handling processes, on the periodic audits Annex VIII requires, is new to security reporting, and it will cover a far smaller share of your stack than the marks are going to suggest.

From 11 December 2027 the CE mark on a newly placed product also says that the manufacturer declared the product and its processes conformant, on its sole responsibility, and that a market surveillance authority can hold it to that. Nobody in that sentence promised you an outcome.

What the EU Cyber Resilience Act achieves for users

Recital 2 of the EU Cyber Resilience Act sets two tests for users: can they take cybersecurity into account when they choose a product, and when they use it. Ivanti’s users had no way to pass the first, because nothing told them that the February 2025 fix, inside a release that carried an advisory for other flaws, was a security fix. Had Article 14 been in force, a filing would have been due 24 hours after Ivanti knew of the March exploitation, and users would have been told something, on no clock; the silent fix itself comes inside Annex I, Part II, point (4) only from December 2027, for products placed on the market from that date or substantially modified after it. FortiBleed’s users could not weigh a hashing decision whose documentation stated the mechanism and named no risk, and which Fortinet, judging the activity as a whole, called no vulnerability. Had both clocks been running, they would have had two filings they never see and a notification for each on the manufacturer’s timetable; from December 2027 they get an end date at purchase and, with the product, a declaration that shows whether anyone outside the manufacturer checked. The roughly 74,000 devices already in the field stay where Article 69 leaves them: inside Article 14 and outside the rest, unless substantially modified after December 2027.

For choosing a product, then, the Regulation delivers part of its purpose, on new placements from December 2027. For using one, it delivered nothing to either set of users, because both cases fall before 11 September 2026 and inside the amnesty, and on the next case it delivers a notification on the manufacturer’s judgement of who is impacted, with no clock and no remedy behind it.

The Regulation reviews itself: a report on the reporting platform by 11 September 2028 and a review of the whole text by 11 December 2030, under Article 70. What I would put in front of that review is the four things a buyer has to negotiate today, made statutory, and one thing no single contract buys.

• The committed remediation window becomes a defined timeline, where Annex I currently asks for a fix without delay and names no date.
• The evidence-of-security warranty becomes a file the buyer can read, where the technical documentation as written is kept for a market surveillance authority.
• The security super-cap becomes a remedy for the business buyer, where the Product Liability Directive (EU) 2024/2853 stops at property used exclusively for professional purposes.
• The notification term becomes a clock on Article 14(8), with “timely” defined.
• An audited quality-assurance process for every line of code a manufacturer ships, once its sales of products with digital elements in the Union pass 100 million euros, with the result published as a tiered risk label on the vendor and any use of AI in that process declared. The Regulation as written requires an outside assessor only for Annex III and IV products, audits a quality system only where the manufacturer chooses full quality assurance, publishes neither, and asks nothing of a vendor on account of its size.

The 100 million euro threshold is a proxy for how much of the Union’s estate runs on a vendor’s code, and so of the exposure that vendor carries; 74,000 devices is what that exposure looks like for one product line. The figure is twice the turnover at which the Regulation stops treating a manufacturer as a medium-sized enterprise, and the trigger borrows the Digital Markets Act’s Union-turnover test. The label borrows the shape of the EU AI Act’s risk classes and moves the tier from the system to the vendor; and neither the EU Cyber Resilience Act nor the EU AI Act, Regulation (EU) 2024/1689, asks a manufacturer to say where AI wrote or tested its code.

Until then the warranty is still yours to negotiate, and the boards that find that out from the next dataset will be holding a declaration that was in full compliance the whole time.

Questions directors ask

Does the EU Cyber Resilience Act apply to us if we do not sell hardware?

Software made available on the EU market whose intended purpose or reasonably foreseeable use includes a direct or indirect logical or physical data connection to a device or network is in scope of the EU Cyber Resilience Act as a product with digital elements (Article 2(1)). Software-as-a-service designed and developed outside a product manufacturer's responsibility falls outside that definition and, for cloud providers above the size threshold, under the NIS2 Directive (EU) 2022/2555. A buyer stays a buyer. Under Article 22, an organisation that substantially modifies a product and makes the modified product available on the market becomes its manufacturer, from 11 December 2027.

If a supplier notifies us under the EU Cyber Resilience Act, what is our obligation?

As an end user, none under the EU Cyber Resilience Act; the reporting and user-information obligations are the manufacturer's, and the user notification under Article 14(8) carries no clock. If you integrate that product into one you place on the market under your name, you are a manufacturer under Article 3(13) and Article 14 has run against you since 11 September 2026: the supplier's notice starts your own assessment, and awareness of exploitation starts your 24-hour clock. If you import, distribute or rebrand it, Articles 19 to 21 apply from 11 December 2027. Your exposure as an end user is operational: whether you can act on the notification inside the window the attacker is working in.

Is a CE mark under the EU Cyber Resilience Act evidence that a product is secure?

No. It is evidence that the manufacturer declared the product conformant with the Annex I product requirements and its processes conformant with the Annex I process requirements, and assumed responsibility for that compliance, which only a market surveillance authority can enforce. For default-tier products the manufacturer may reach that declaration by internal control, with no outside assessor. The EU Cyber Resilience Act itself provides, in Article 57, for products that comply and still present a significant cybersecurity risk together with a risk to health, safety, fundamental rights or essential services.

What is the difference between the September 2026 and December 2027 dates?

Article 14 reporting obligations under the EU Cyber Resilience Act apply from 11 September 2026, to in-scope products already on the market as well as new ones. The Annex I product and vulnerability-handling requirements, conformity assessment, the EU declaration of conformity, CE marking and the support period apply from 11 December 2027, to products placed on the market from that date or substantially modified after it.

Our vendor says the exposure came from customer configuration, not a product flaw. Does the EU Cyber Resilience Act help?

Not directly. Article 14 of the EU Cyber Resilience Act is triggered by an actively exploited vulnerability or a severe incident, and the manufacturer makes the first call on both. A design or migration gap the manufacturer classifies as neither generates no Article 14 report and no Article 14(8) notification, which is why a vendor-exposure metric cannot rely on regulatory reporting as its only source. From 11 December 2027 the secure-by-default and access-control requirements in Annex I, Part I give a market surveillance authority a second route to the same gap, on products placed on the market from that date.