Security starts before the first release
Suppose a serious vulnerability is discovered in a software library. The development team wants to respond. First, however, it must establish which product versions contain that library, where those versions are used and whether the component can be replaced without extensive rebuilding.
The real difficulty does not begin with writing a fix. It lies in decisions and omissions that may date back a long way.
That is why security belongs in application planning for me. A final test before release cannot fully compensate for confusing structure, missing update paths and unclear responsibilities.
The European Cyber Resilience Act (CRA) gives this additional legal significance. Certain reporting obligations have applied to manufacturers in scope since 11 September 2026. The main remaining obligations apply from 11 December 2027. These stages must be kept distinct. [1] [2]
What already applies, and what follows
The CRA is Regulation (EU) 2024/2847. It sets cybersecurity requirements for products with digital elements in scope. The European Commission explicitly connects design, development and subsequent maintenance. [1]
These dates are especially important for this article:
10 December 2024: the Regulation entered into force.
11 September 2026: Article 14 reporting obligations began to apply to manufacturers in scope.
11 December 2027: the main remaining obligations begin to apply.
This overview covers the central stages discussed here, not every transitional provision. [1]
It means neither that all requirements already apply today nor that nothing needs doing before December 2027.
An application being developed now may already be running for customers then. I would therefore establish early which obligations concern the specific product and which technical foundations they require.
Which software may be covered
The CRA generally covers hardware and software products made available on the EU market whose intended or reasonably foreseeable use involves a direct or indirect data connection to a device or network. Certain products are excluded. The Commission explains this scope in its legislative summary, updated on 3 December 2025. [3]
The price tag alone does not decide this. Free distribution may form part of a commercial activity. Free and open-source software supplied outside commercial activity has exemptions, while separate rules apply to open-source software stewards. [4]
Cloud and SaaS services cannot all be classified in the same way either. Remote processing necessary for an in-scope product may be included; independent cloud services are not automatically covered. [5]
For a specific offering, I would have the product, distribution model and our own role assessed together. “We only write software” does not answer these questions any more than “Our application is free”.
Security needs verifiable requirements
I would not stop at the broad instruction “The application must be secure”.
For customer management, first establish which users may see which data, how customer organisations are separated, which information may be exported and which functions need elevated permissions.
Specific requirements follow: an ordinary user role must not create administrators. An export must not include another organisation’s data. A technical background service should receive only the access its task requires.
These are planning examples, not a complete CRA implementation checklist.
The Commission explains that manufacturers must base measures on a cybersecurity risk assessment and consider them throughout development and maintenance. The assessment and selected measures form part of technical documentation. [3]
My aim would be to connect each important security requirement with a responsible party and a suitable check. A general aspiration then becomes an obligation whose completion can be traced.
A software bill of materials provides visibility, not security by itself
SBOM stands for Software Bill of Materials: a structured inventory of software components.
For vulnerability handling, the CRA requires a commonly used, machine-readable SBOM covering at least top-level dependencies. This does not create a general duty to publish it on the internet; provision to users is addressed separately. [5]
In everyday work, I would bind the inventory to the version actually shipped. A list created at some earlier stage is of little use when different components are later delivered.
I would also record indirect dependencies where possible. If a library brings in other packages, I do not want to reconstruct them laboriously after a security notification.
An inventory is not yet an assessment. It first establishes what is included. Whether a particular vulnerability affects our product, and under which conditions it could be exploited, must then be investigated.
An SBOM is a starting point for decisions, not a certificate of safety.
Replaceable components make a response easier
For the library in our opening example, I would want to know how deeply it is connected to our application.
Is it used through a clearly defined interface? Or do numerous parts of the program directly rely on its particular behaviour?
In a new application, I would therefore integrate external components where their purpose is clearly bounded. Replacement can then be planned and checked specifically.
This is not an argument for hiding every library behind several additional layers. Unnecessary abstraction also makes understanding harder. Separation should help where a real dependency needs managing.
NIST’s Secure Software Development Framework, published in February 2022, integrates secure practices across development, including responding to discovered vulnerabilities rather than relying on a single final check. [6]
For me, that includes planning ongoing maintenance of components rather than merely selecting them at project start.
An update path belongs in the product
A security fix only reaches users when it can actually be distributed and applied.
I would establish early how new versions are delivered. How is an update’s origin verified? What happens if installation is interrupted? Which data must be migrated? How can a faulty release be handled?
Functions allowed to update software themselves deserve particular attention. Their necessary rights and keys should not casually end up in an arbitrary background service.
Support duration also needs realistic planning. Under the support requirements generally applying from December 2027, the CRA sets a minimum of five years, unless expected use is shorter. Longer expected use must also inform the support period. [5]
This does not mean every product needs exactly five years of support and all responsibility then ends.
For costing, development is not complete at first shipment. I would allow time for security fixes, tests, supported versions and communication with users.
Reporting obligations need a prepared process
The Commission’s guidance, updated on 11 September 2026, requires manufacturers in scope to report actively exploited vulnerabilities and severe security incidents. An early warning is due without undue delay and within 24 hours of awareness; a further notification is due within 72 hours. [2]
Final-report deadlines differ: exploited vulnerabilities require a report within 14 days after a corrective or mitigating measure becomes available; severe incidents generally require one within a month of the 72-hour notification. Notifications use ENISA’s central CRA reporting platform. [2]
Not every error message or failed sign-in automatically meets the legal criteria. Classification must depend on the specific facts.
Reporting obligations can also cover in-scope products placed on the market before 11 December 2027. [5]
I would prepare a clear organisational route. Who receives reports? Who assesses the technical situation? Who decides on required notifications, and who covers absence?
A message arriving in a rarely checked mailbox is not functioning vulnerability management to me.
Documentation must match the software shipped
Extensive documentation helps little if it describes an obsolete product.
I would connect important evidence with versions: which components were included, which checks were performed, which limitations were known and what changed from the previous version?
A reported problem should also be traceable through receipt, assessment, necessary actions and the state of the fix.
Small teams do not need an unnecessarily elaborate procedure. Ordered version control, traceable issues and agreed responsibilities can provide a useful start.
On 27 July 2026, the Commission published additional non-binding CRA guidance covering scope, substantial modifications, support periods and reporting. These aids help interpretation; the Regulation remains authoritative. [7]
CE marking does not mean nothing can go wrong
The CRA includes conformity assessment. Available or required procedures depend on product category. Many products allow manufacturer assessment; certain important or critical categories face stricter requirements, including independent assessment where applicable. The Commission explains this in its overview updated on 31 July 2026. [8]
I would not market CE marking as a promise of being “unhackable”. Compliance does not replace careful operation or continued monitoring of vulnerabilities.
Nor would a single automated security scan demonstrate complete CRA conformity to me.
What I would address first
For an existing software product, I would begin with a manageable review: establish scope, record supported versions, identify components and check current reporting and update routes.
Then I would prioritise the largest practical gaps. A missing reliable inventory must be created. Unhandled security reports need an owner. If fixes cannot be shipped in a controlled way, the update process needs improvement.
For a new application, I would include these points directly in architecture and project planning. That seems more sensible than reconstructing every process and piece of evidence immediately before a deadline.
My conclusion: Security is also a matter of maintainability
The Cyber Resilience Act makes clear that responsibility for software does not end with its first release.
For me, it also carries a technical lesson: an understandable application is easier to check, correct precisely and develop reliably. That helps with legal requirements and when a real problem must be fixed under time pressure.
I would therefore neither reduce the CRA to more paperwork nor use it to justify blanket security promises.
Secure software needs an understandable structure, known components and a functioning route from a reported problem to a verified correction.
Scope and research
Research date: 9 October 2026. Legal and research position: 9 October 2026. General information, not a legal assessment of a particular product, business model or case. Examples do not form a complete conformity or security programme. Reporting duties since September 2026 are distinct from the main remaining duties applying from December 2027.
Sources and further reading
Sources checked on 9 October 2026. Access dates are not publication dates. Manufacturer, research and authority sources were checked directly.
[1] European Commission: Cyber Resilience Act (updated 7 September 2026)
Read source ↗
[2] European Commission: CRA reporting obligations (updated 11 September 2026)
Read source ↗
[3] European Commission: Summary of the legislative text (updated 3 December 2025)
Read source ↗
[4] European Commission: CRA and open source
Read source ↗
[5] Regulation (EU) 2024/2847 of 23 October 2024, EUR-Lex
Read source ↗
[6] NIST: Secure Software Development Framework version 1.1 (February 2022)
Read source ↗
[7] European Commission: Non-binding CRA guidance (27 July 2026)
Read source ↗
[8] European Commission: CRA conformity assessment (updated 31 July 2026)
Read source ↗