Crafting Excellence in Software
Let’s build something extraordinary together.
Rely on Lasting Dynamics for unparalleled software quality.
Michele Cimmino
Sep 16, 2026 • 13 min read
The Cyber Resilience Act stopped being a 2027 planning item on 11 September 2026. ENISA deployed the initial operating capability of its Single Reporting Platform that day, and from that date manufacturers have had to report actively exploited vulnerabilities and severe incidents affecting the security of their products. The Commission's reporting page was last updated the same day. ENISA's platform FAQ carries the line "Updated: 12 September 2026". The regulator was still writing guidance after the duty commenced.
Article 71(2) sets three dates, not two. The Regulation applies in full from 11 December 2027, Article 14 has applied since 11 September 2026, and Chapter IV, Articles 35 to 51, since 11 June 2026. The Commission's own policy page and the text on EUR-Lex both lead with the first two. Most planning documents contain only the first.
Article 3(42) defines an actively exploited vulnerability as one for which there is reliable evidence that a malicious actor has exploited it in a system without permission of the system owner, and Article 14(2)(a) runs the 24 hours from the manufacturer becoming aware of it, which is neither the moment the bug is found nor the moment it is disclosed publicly, but the moment somebody inside the organization learns that it is being used against them.
That is the whole engineering problem in one sentence, and it is why the Cyber Resilience Act reads as a compliance obligation and lands as an operational one.
The unit of regulation is the product with digital elements, and that phrase is doing more work than it appears to Article 3(1) of Regulation (EU) 2024/2847 defines it as "a software or hardware product and its remote data processing solutions, including software or hardware components being placed on the market separately". Components shipped on their own are products in their own right.
The software-as-a-service question is the most misstated point on this subject, and the Cyber Resilience Act answers it by definition rather than by carve-out. Article 3(2) covers "data processing at a distance for which the software is designed and developed by the manufacturer, or under the responsibility of the manufacturer, and the absence of which would prevent the product with digital elements from performing one of its functions".
Recital 12 is the decisive gloss: cloud functionality that lets a user control a smart home device remotely is in scope, while "cloud services designed and developed outside the responsibility of a manufacturer of a product with digital elements do not fall within the scope". Standalone SaaS, PaaS and IaaS go to Directive (EU) 2022/2555 instead.
So the test is functional dependency, not deployment model, and recital 11 bounds it further: these requirements "do not extend to securing a manufacturer's network as a whole". The Cyber Resilience Act reaches the remote component your product needs in order to work, and stops there.
Who carries the duty is the second thing teams get wrong. Article 3(13) defines a manufacturer as a person who develops or manufactures products with digital elements, or has them designed, developed or manufactured, and markets them under its name or trademark. The definition is conjunctive, so writing the code is not sufficient. Article 21 makes an importer or distributor a manufacturer where it places the product under its own name or substantially modifies it.
Which gives an answer most pages never give: if you write software another company places on the EU market under its own brand, the Cyber Resilience Act duties are theirs. Contracts allocate the work and cannot move the obligation. A separate, lighter regime covers the open-source software steward of Article 3(14), and Article 24(3) brings stewards into Article 14(1) reporting only from 11 December 2027.
Let’s build something extraordinary together.
Rely on Lasting Dynamics for unparalleled software quality.
Two cascades run under Article 14, and they do not end the same way. For an actively exploited vulnerability, the manufacturer owes an early warning within 24 hours of becoming aware of it, a fuller vulnerability notification within 72 hours, and then a final report no later than 14 days after a corrective or mitigating measure becomes available. For a severe incident affecting the security of the product, the first two steps are identical, 24 hours and then 72, but the final report falls due within one month of that 72-hour notification rather than being tied to a fix.
The difference is not pedantry, because in the first cascade the last deadline is keyed to your own fix, so a patch shipped on day three makes the final report due on day seventeen, while a fix that takes three months moves the deadline with it. In the second it is keyed to a notification you already sent. Cyber Resilience Act summaries that give 14 days for both, or one month for both, describe a regulation that does not exist.
Articles 14(1) and 14(3) require notification simultaneously to the CSIRT designated as coordinator and to ENISA, which in practice means the Single Reporting Platform established under Article 16, and access to it is not instant. A manufacturer files through registered Assigned Representatives, one primary and up to twenty secondary, and ENISA states that each needs an EU Login account with multi-factor authentication enabled.
Which produces the least glamorous and most useful action available this week: create the EU Login accounts and register the representatives now. Twenty-four hours is not enough time to discover that the only person who can file is on leave and the account does not exist. ENISA allows up to twenty notifications before manufacturer verification becomes mandatory, which is a grace period rather than a plan.
Then there is the judgment nobody has staffed. Telling a CVE in a dependency scan apart from reliable evidence of active exploitation is a decision, and the Cyber Resilience Act deadline runs from awareness rather than from confirmation. The escalation path from an on-call engineer to whoever is authorized to sign a regulatory filing is usually missing rather than slow, and a path that does not exist cannot be walked quickly.
An honest treatment has to name the second-order effect too: a duty that starts on awareness creates an incentive not to look too hard. That is not an argument against the obligation. It is the reason triage criteria and the escalation path belong in writing before the first incident rather than after one.
One caveat is worth carrying into any plan that depends on the platform, which is that what shipped on 11 September is an initial operating capability, and the Cyber Resilience Act does not care that the tooling is young. No API in the first release, English only, and voluntary reporting under Article 15 not implemented. The FAQ even documents a counter showing the 72-hour due date 48 hours after the early warning. Plan for a person submitting a form.
The Cyber Resilience Act says less about the software bill of materials than the commentary around it would suggest. Annex I, Part II, point 1 requires manufacturers to identify and document vulnerabilities and components, including by drawing up a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies of the products.
Two things follow, and both cut against the received wisdom. The phrase "at the very least the top-level dependencies" sets a floor rather than a target: anyone telling you the Cyber Resilience Act mandates full transitive depth is reading something that is not in the text, and anyone stopping at the top level has met that floor and nothing more. And "commonly used and machine-readable" names no format: Article 13(24) leaves format and elements to a Commission implementing act, which has not arrived.
From idea to launch, we craft scalable software tailored to your business needs.
Partner with us to accelerate your growth.
CycloneDX is stewarded by the OWASP Foundation with Ecma International and published as ECMA-424, currently version 1.7. SPDX is a Linux Foundation project and an international standard, ISO/IEC 5962:2021, with 3.0 as the current specification version. Both qualify under the Cyber Resilience Act. Neither is required, and what your build tooling emits natively is a better reason to choose than which name sounds more official.
The argument worth making is about provenance rather than format. An inventory assembled for an auditor answers a different question from an inventory emitted by the build. Under a 24-hour clock, the question is which shipped versions contain the affected component, and only an artifact generated at build time and versioned with the release answers it without starting a research project. Article 13(25) also lets market surveillance authorities request bills of materials, so they have to exist for versions still in support rather than only for the current one.
Five years is a floor, not a default, and the distinction has money attached. Article 13(8) requires manufacturers to set the support period so that it reflects the length of time during which the product is expected to be in use. Then two constraints: "the support period shall be at least five years", and "where the product with digital elements is expected to be in use for less than five years, the support period shall correspond to the expected use time". A product expected to live fifteen years does not get a five-year answer under the Cyber Resilience Act.
The obligation nobody prices sits in the next paragraph. Article 13(9) requires every security update made available during the support period to remain available afterwards for a minimum of 10 years or for the remainder of the support period, whichever is longer. Ten years of retrievable artifacts for something you shipped once.
Article 13(19) removes the ambiguity that made all of this survivable in practice: under the Cyber Resilience Act the end date of the support period, including at least the month and the year, has to be given at the time of purchase. An open-ended maintenance intention becomes a declared commitment printed on the transaction, and it is enforceable.
For a fixed-scope engagement, this means rethinking the price. Years of security maintenance now have to be priced into a contract signed for a one-off delivery, and committing to support a release means committing to patch a dependency tree, including the parts nobody explicitly chose. This cost follows the same pattern as work that requires independent verification: it does not shrink as tooling improves, because it demands qualified attention over time.
Annex I, Part II, point 5 is one line: "put in place and enforce a policy on coordinated vulnerability disclosure" Point 6 adds a contact address for vulnerabilities found in the product and in its third-party components, and Article 13(17) requires a single point of contact that lets users choose how to reach you and does not limit them to automated tools.
It is the cheapest obligation in the Cyber Resilience Act and an afternoon of work: a published policy, a monitored address, a stated triage commitment, and a security.txt file at /.well-known/security.txt so a researcher finds the address without guessing.
The failure mode is not an absent policy. It is an address nobody reads on a Saturday. The verb in the Annex is "enforce", not "publish", and the same address a researcher uses to report an exploited vulnerability is the one that starts the Cyber Resilience Act clock. Route that address to a shared inbox triaged on Mondays and the clock has been running for two days before anybody opens it.
We design and build high-quality digital products that stand out.
Reliability, performance, and innovation at every step.
Annex I, Part II describes a set of practices rather than a set of product features. Manufacturers have to document their components, remediate without delay and, where technically feasible, ship security updates separately from functionality updates, apply effective and regular tests and reviews, disclose fixed vulnerabilities once an update exists, enforce a disclosure policy, provide a contact address for reports, and distribute the updates securely.
The concession is worth making properly, because the argument is not that tooling is useless against the Cyber Resilience Act. Dependency scanning genuinely discharges part of point 1 and part of point 2. Bill of materials generation is a build step a machine does better than a person. Parts of the testing obligation in point 3 automate cleanly, and a scanner on every merge beats a quarterly review by a human.
What does not automate is the judgment, and the record of having exercised it: the decision to ship or hold when a fix carries its own risk, the call that a vulnerability is actively exploited rather than merely published, and the assessment of what "technically feasible" meant. The Cyber Resilience Act requires somebody to have made those calls and to be able to defend them later.
Producing evidence continuously is a different activity from passing a scan, and the Cyber Resilience Act is written against the first. Anyone who has been through a payment-industry assessment will recognize the distinction immediately.
Technical documentation is retrospective, which is what makes the final date the wrong one to aim at. Nobody can write in 2027 the evidence trail they failed to keep in 2026, and the conformity route depends on that trail existing rather than on it being assembled.
Article 7 classifies a product as an "important product with digital elements" where its core functionality matches a category in Annex III, and it splits those into two classes. Class I is long and familiar: operating systems, browsers, password managers, VPNs, routers and switches, SIEM, smart home products with security functions, identity and access management.
Class II is short and specific: hypervisors and container runtime systems, firewalls and intrusion detection and prevention systems, tamper-resistant microprocessors and microcontrollers. Annex IV lists critical products separately, and under the Cyber Resilience Act the class decides the route.
Article 32 sets the routes, and outside those lists you can self-assess through internal control. The route ends in the same two artifacts either way: an EU declaration of conformity under Article 28, and CE marking on the product under Article 30. CE marking on software is the part that surprises people - it is a legal claim about a process, affixed to something that has no surface to affix it to. For class I that survives only where harmonised standards, common specifications or a qualifying certification scheme are applied in full, and otherwise it is EU-type examination plus conformity to type, or full quality assurance. For class II there is no self-assessment route at all.
Here the honest position costs nothing, and nobody selling a compliance product will state it: the harmonised standards are not all in place. A plan that depends on applying a standard in full is a plan against a document that may not exist yet, and anyone projecting certainty about the Cyber Resilience Act route for a class I product today is selling something.
Penalties belong in two sentences rather than a section. Article 64 provides administrative fines of up to EUR 15,000,000 or 2.5% of total worldwide annual turnover, whichever is higher, for breaches of the Annex I essential requirements and of Articles 13 and 14, with lower tiers at EUR 10,000,000 or 2% and EUR 5,000,000 or 1%. Recital 120 records two carve-outs that summaries drop: no administrative fines at all for open-source software stewards, and none for micro and small enterprises for missing the 24-hour early warning specifically.
The structure is the same move as the other EU regulation that attaches to the process rather than the output: duties that bind how the work is done and recorded rather than what the finished thing looks like.
Three cost centers carry almost all of it. The support commitment comes first, because it prices years of maintenance into a product that is sold once, and the out-of-hours capability comes second, because a Cyber Resilience Act clock that can start on a Saturday needs people rather than a process document. The third is the documentation history, which is the awkward one, because it accumulates over time and cannot be produced on demand.
For some products the compliant path costs more than the European revenue justifies, and an honest treatment of the Cyber Resilience Act has to say so. A low-margin connected device with a fifteen-year life and a European share in the low single digits can be cheaper to withdraw than to carry ten years of update availability. Narrowing a product's EU footprint is a legitimate response, and nobody selling compliance software will suggest it.
The counter-case is the stronger one for most readers. A component inventory, a disclosure address, a declared support window and a working escalation path are not regulatory inventions. They are things a serious engineering organization wanted anyway and kept deferring because nothing forced the date. The Cyber Resilience Act mostly removes the excuse.
Which points at who will struggle. The manufacturers that fail in December 2027 will not be the ones with weak engineering. They will be the ones that read September 2026 as paperwork.
Four checks separate an organization that has read the Cyber Resilience Act from one that has read an article about it. The first is whether you can produce the software bill of materials for the version currently in production, right now, without asking anyone and without running a build. The second is what support period you could state in writing today, and and what you have committed to doing on the day it ends.
The third is who can file with ENISA at two in the morning on a Sunday, and whether anybody has ever logged into that account to confirm it. The fourth is the sharpest, because it has no comfortable answer: what are you not compliant with yet? An organization with nothing on that list has not looked.
Shipping software into the EU and unsure which of these obligations already applies to you? Tell us what you ship.
This article was written by Michele Cimmino at Lasting Dynamics, an EU-based custom software development company.
Regulation (EU) 2024/2847 sets cybersecurity requirements for products with digital elements placed on the EU market. What most definitions leave out is that it regulates a development process and a support commitment rather than a product at the moment of sale: vulnerability handling, a declared support period and an evidence trail all continue after shipping. Reporting duties have applied since 11 September 2026.
Article 71(2) sets three dates. Chapter IV, Articles 35 to 51, has applied since 11 June 2026. Article 14 reporting has applied since 11 September 2026. The regulation applies in full from 11 December 2027. That last date is not a preparation deadline, because the technical documentation and evidence history it requires are retrospective.
Yes, and the requirement is short: Annex I, Part II, point 1 asks for a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies. No format is mandated, so CycloneDX and SPDX both qualify, and Article 13(24) leaves format and elements to a future Commission implementing act. Generating it at build time and versioning it with the release is what makes it usable under a 24-hour clock.
The manufacturer, simultaneously to the CSIRT designated as coordinator and to ENISA, through the Single Reporting Platform established under Article 16. For an actively exploited vulnerability: an early warning within 24 hours, a notification within 72 hours, and a final report within 14 days of a corrective measure becoming available. The clock runs from awareness of active exploitation, not from discovery.
Not on its own, because a remote service is in scope only where it is designed and developed by or under the responsibility of the manufacturer and its absence would stop a product with digital elements performing one of its functions, per Article 3(2). Recital 12 routes standalone SaaS, PaaS and IaaS to Directive (EU) 2022/2555 instead. The test is functional dependency, not deployment model.
Transform bold ideas into powerful applications.
Let’s create software that makes an impact together.
Michele Cimmino
I believe in hard work and daily commitment as the only way to get results. I feel an inexplicable attraction for the quality and when it comes to the software this is the motivation that makes me and my team have a strong grip on Agile practices and continuous process evaluations. I have a strong competitive attitude to whatever I approach - in the way that I don't stop working, until I reach the TOP of it, and once I'm there, I start to work to keep the position.
