The last articles in our series covered the cyber risk assessment and the answer to the question: is my product cybersecure when placed on the market? But there is an even more uncomfortable follow-up question raised by Annex I Part II of the Cyber Resilience Act: does it stay that way in five years, or in ten? That is the fundamental difference between the two parts of Annex I. Part I describes a state the product has to reach. Part II describes the processes the manufacturer has to run permanently in order to maintain that state. Part I is a project goal. Part II is ongoing operations. It is exactly this manufacturer obligation that puts cybersecurity in live operation into focus. Two things are decisive for it: the software bill of materials (SBOM for short) and continuous vulnerability management. This article covers the associated obligations from the CRA in detail.
Manuel Sandler
The Cyber Resilience Act bundles this requirement for “cybersecurity in permanent operation” into eight specific obligations, set out in Annex I Part II. We go through these obligations in the following.
After that, we turn to an expanded understanding of the SBOM, which is to be seen here less as one obligation among many than as the backbone of the whole. Because cybersecurity-relevant vulnerabilities can only be found, assessed, fixed, and, when it counts, reported if one even knows what is inside one’s own product.
The eight obligations from CRA Annex I Part II, and their link to EN 40000-1-3
The emerging European standardization series EN 40000 has already been introduced in the previous articles. With a view to the CRA obligations mentioned, we take up EN 40000-1-3, which addresses vulnerability handling and thereby translates the requirements from Annex I Part II into concrete, verifiable process requirements. (Additional help is also offered by EN 40000-1-2, which contains a mapping between the standard and the CRA requirements in its Annex C.)
The gain for practice: the legal obligation “the manufacturer has to handle vulnerabilities” turns into a verifiable guide, “this is what a traceable process for it looks like.”
As already described: this standard is still in draft and therefore does not yet officially establish a presumption of conformity, but as a working basis it is already usable today.
Until it is referenced in the EU Official Journal, expected at the earliest at the end of 2026/2027, the BSI TR-03183 (Part 2), also mentioned before, counts as the most pragmatic interim solution. Whoever works with it today builds on a foundation that lies close enough in substance to EN 40000-1-3 to allow the later transition without reinvention.
Now, on to Annex I Part II of the CRA, the requirements for the handling of vulnerabilities.
Obligation 1: Identifying and documenting vulnerabilities and components
The first of these obligations (see Annex I Part II point (1)) requires vulnerabilities and components to be identified and documented. Among other things, this calls for a software bill of materials in a commonly used, machine-readable format that covers at the very least the top-level dependencies.
The term “top-level dependencies” is chosen precisely and often misunderstood: it means the components that were integrated directly and deliberately, not the transitive dependencies, meaning everything those components in turn pull in, across any number of levels.
An SBOM that maps only the first level of direct dependencies already meets the CRA’s minimum requirement. An example: if a product integrates the OpenSSL library directly, OpenSSL has to appear in the SBOM. The dozens of libraries OpenSSL itself pulls in do not necessarily have to be listed under the minimum requirement. For vulnerability management, full depth is nonetheless often the better choice: a vulnerability in a deeply nested sub-library can be just as dangerous as one in the directly integrated component.
In plain terms: from a vulnerability management perspective, a complete, deep SBOM is more valuable; from a compliance perspective, the first level is the minimum requirement. Companies newly introducing SBOMs in particular should concentrate on this top level first and build out the depth later.
EN 40000-1-3 provides orientation on format and content requirements and recommends established machine-readable formats. The two most relevant today are:
- SPDX (Software Package Data Exchange, ISO/IEC 5962:2021)
- and CycloneDX (an OWASP standard).
Both are mapped to the CRA requirements in BSI TR-03183 Part 2 and are recognized as an implementation basis. The choice between the two is less a regulatory than a technical decision. It should primarily be guided by the existing toolchain and the integration into the build process.
Important: the SBOM does not have to be published, and as a rule it should not be, because a disclosed component list is a convenient template for attackers planning targeted attacks. CRA Recital 77 makes clear that manufacturers are not obliged to publish it. The SBOM is an internal document, which however has to be presented to the market surveillance authority upon reasoned request. Its confidentiality thus remains preserved in principle.
Obligation 2: Handling and fixing vulnerabilities without undue delay
Vulnerabilities are to be handled and fixed without undue delay, with a view to the product risks. For this, the CRA provides for dedicated security updates that, as far as technically feasible, run separately from functional updates.
“Without undue delay” is not a rigid time span here, but risk-based: a critical vulnerability with an active exploit demands a different reaction speed than a low-severity one without known exploitation.
What also matters is what “without undue delay” refers to: to handling the vulnerability, not necessarily to fixing it immediately. Handling is the umbrella term for the entire response: assessing the vulnerability, estimating its exploitability, prioritizing it, and, where necessary, temporarily containing it until a patch is available. The actual fixing is only the last step and sometimes takes time, for instance when the vulnerability lies in a third-party component and the fix depends on its maker.
The CRA thereby requires a triage process that classifies vulnerabilities by severity and exploitability and aligns the priority of remediation accordingly.
The separation of security and functional updates is structurally not provided for in many release processes. A company with a monthly release cycle that ships security patches only as part of regular releases may not meet the requirement, at least not for critical vulnerabilities that have to be handled faster. A separate, release-independent process for security patches is the consequence.
EN 40000-1-3 defines requirements for the internal triage and remediation process, from the capture of a new vulnerability report to the provision of the patch and the notification of users.
One supplementary note at this point: this remediation is not necessarily always a software update. Depending on the product, it can also mean a changed configuration, a restriction of affected functions, or, in the extreme case, the replacement of hardware components.
Obligation 3: Regular security tests and reviews
The security of the product is to be tested and reviewed regularly and effectively. The CRA prescribes nothing more on this; specific test methods are not mentioned either.
Permissible are, among others, penetration tests, fuzzing, formal verification, and structured code reviews. Added to these are the two common automated methods SAST and DAST: Static Application Security Testing examines the source code without executing the program; Dynamic Application Security Testing, conversely, tests the running application from the outside. Some of these methods, such as fuzzing, formal verification, and code reviews, belong by their nature in the development phase, while penetration tests and recurring SAST and DAST runs can accompany the product across its time in the field as well.
Which combination is appropriate follows from the risk profile. What is required is not a particular method, but regularity and effectiveness.
Do I as a manufacturer now have to initiate product pentesting every week? Probably not.
“Regularly” means first of all: not just once before the first release, but continuously across the development and operations lifecycle. This includes:
- checking new components before integration;
- reassessing the affected areas after substantial changes;
- reviewing the overall security level at fixed intervals, independently of product changes, because the threat environment shifts even without a product change.
This recurring review also includes the risk assessment itself: whether the classifications once made still match the current state of the art and the current threat situation should be checked at fixed intervals. What counted as a low risk yesterday can shift through new attack techniques, as already described in our article on the CRA risk assessment.
A rule to remember: the tests check the product. The review of the risk assessment checks whether the right things are even still being tested.
“Effectiveness” means that the tests are actually suited to finding relevant vulnerabilities, instead of ticking compliance checkboxes. An annual penetration test that does not cover core functionality and critical interfaces is formally a test, but not effective within the meaning of the obligation.
Here too, EN 40000-1-3 provides orientation on test depth by risk profile. A product of Important Class II, for example, requires deeper and broader test coverage than one in the default category.
Obligation 4: Transparent communication of fixed vulnerabilities
Once a security update has been provided, information about the fixed vulnerability is to be shared and published:
- a description,
- information for identifying the affected product,
- the impacts,
- the severity,
- as well as understandable instructions for remediation.
The publication obligation takes effect after the patch is provided, not already upon discovery. The standard case is publication as soon as the update is available. The CRA expressly permits withholding the publication, but only as an exception in duly justified cases, namely when the manufacturer weighs the security risks of a publication higher than its security benefit. In those cases, disclosure may be delayed until users have been able to apply the patch.
That is the responsible disclosure principle: full public communication only once a corrective measure is available and users have had time to apply it.
In practice, this means: for every patched security flaw, a security advisory (a public security notice describing the fixed vulnerability and its remediation) with at least a description of the vulnerability (ideally with a CVE number), the affected product versions, the severity (typically per CVSS), the impacts upon exploitation, and clear instructions for remediation, usually by installing the update.
For products without an update function, remediation via patch naturally does not apply. Here the CRA cyber risk assessment has to be all the more thorough, as set out in more detail in the second article of this series.
Obligation 5: Coordinated vulnerability disclosure policy
A policy for the coordinated disclosure of vulnerabilities is to be put in place and enforced. Within this list, this is actually the only process document the CRA demands explicitly and by name. None of the other eight obligations requires a specific, published policy document, only the coordinated vulnerability disclosure (CVD) policy.
A CVD policy describes three things:
- how external vulnerability reports are received (which channel, for example email, a reporting form, a security page; which information the reporter should provide; how quickly they receive a confirmation);
- the internal handling process (triage, assessment, prioritization, clearly assigned responsibilities, internal information, targeted remediation timelines);
- and the disclosure process (when and how the vulnerability is published after remediation, and whether the external reporter is involved).
The importance of this policy is often underestimated: a large share of all cybersecurity vulnerabilities is not discovered by the manufacturer itself, but from the outside. By security researchers, users, or third parties. Without a clear, publicly visible reporting path, this knowledge lands nowhere, and a gap stays open that could long since have been closed. The CVD policy is thus the bridge that turns external findings into fixable vulnerabilities in the first place.
EN 40000-1-3 specifies minimum content and process here as well; in practice, many manufacturers orient themselves toward ISO/IEC 30111:2019 (Vulnerability Handling Processes) and ISO/IEC 29147 (Vulnerability Disclosure).
Important for practice: the CVD policy has to be published. Not just internally, but publicly accessible for external security researchers who want to report a vulnerability. The security.txt format (RFC 9116), for example, is an established way of pointing to the policy and the reporting channel.
Obligation 6: Facilitating the sharing of information about vulnerabilities
The sharing of information about possible vulnerabilities in the product and in contained third-party components is to be facilitated. Among other things, through a dedicated contact address for reporting discovered vulnerabilities.
This is the technical implementation obligation belonging to the preceding Obligation 5: the CVD policy describes the process; Obligation 6 requires the technical accessibility of the reporting channel. A publicly accessible contact option is mandatory: an email address, a “report a vulnerability” web form, or the security.txt with further information are common implementations.
This obligation also covers vulnerabilities in contained third-party components (compare the earlier discussion of the SBOM). If an external security researcher finds a vulnerability in an integrated component, the manufacturer should act as the point of contact and forward the report to the respective component maker. This applies not only to open-source libraries, but to supplied components of all kinds, from commercial third-party software through firmware to integrated hardware modules with their own software (such as control units in an overall system). Whoever takes a component into their product also takes on the role of the reporting bridge to its maker.
That is exactly what Art. 13(5) and (6) CRA also demand of the manufacturer itself: if, in the course of its due diligence, it identifies a vulnerability in an integrated third-party component, it has to inform the person or entity that makes or maintains that component. If it has itself developed a software or hardware fix, it has to share the code or documentation with the maintainer in a machine-readable format.
The CRA thereby requires a reciprocal obligation: whoever benefits from open-source projects should in return contribute to their security. The actual point of this obligation lies in the bigger picture: no manufacturer develops in isolation today; everyone builds on a mesh of open-source and third-party components. By making every manufacturer an open point of contact, including for vulnerabilities in someone else’s code, the CRA ensures that a finding in one place can make the entire ecosystem more secure, instead of ending in a dead end.
Obligation 7: Secure update distribution mechanisms
Mechanisms for the secure distribution of updates are to be provided, so that vulnerabilities can be fixed or contained in a timely manner and, for security updates, automatically where relevant. This is the technical infrastructure obligation of vulnerability management.
Security updates have to reach the user securely; for that, the entire update channel has to be secured against attacks:
- cryptographic signatures for update packages ensure that only authentic, released updates are installed;
- secure transmission channels (TLS) protect against manipulation in transit;
- signature verification before installation ensures that the received update matches what the manufacturer provided.
But one thing also has to be kept in mind: the “update channel” is not to be equated with “online update.”
The CRA prescribes no particular distribution path; it requires that this path be secure, whichever one it is.
For products that cannot be updated online, such as permanently installed or deliberately air-gapped systems, the manufacturer has to provide another secure path: a secured download that the operator installs themselves, or the inclusion of the security update in a maintenance concept in which trained service personnel carry out the update on site.
The security mechanisms stay the same, signature, integrity, and version checking; only the transport path is different.
Important in the course of the CRA: it is precisely manufacturers of such products who often have to establish new processes and ways of working for this, because a regulated update path in the field was simply never envisaged before.
Signature and TLS alone do not cover everything, though. An attacker could re-install an older, still validly signed update containing an already known vulnerability, a so-called downgrade or rollback attack. Version binding and anti-rollback counters, which prevent falling back to an older state, help against this. The robustness of the update process itself belongs here as well: the ability to return to a working state after a failed or interrupted update, so that a security update does not render the device unusable. The ENISA advisory on secure update mechanisms (draft, May 2026) describes both as the core of a resilient update design, from the anti-rollback counter to atomic installation, which keeps a known-good state available at all times. Here Obligation 7 visibly reaches into the availability and integrity requirements from our third article on the CRA cybersecurity requirements for products (see requirements (h) and (f)).
Here too, a look at EN 40000-1-3: beyond this, it also addresses securing the update infrastructure itself, the servers and systems through which updates are distributed. An attacker who compromises the update server and distributes malicious code as a legitimate update realizes exactly the scenario Obligation 7 is meant to prevent. The security of the update channel is thus not only a product requirement but also an operational infrastructure requirement.
This is exactly where the CRA ties into the scope question from the second article of this CRA series on the CRA cyber risk assessment: there we drew the boundary of the object of assessment (item boundaries) and classified the manufacturer’s own update server.
As a reminder: what mandatorily belongs to the product is the update interface in the device itself, the mechanism that fetches updates, transmits them via TLS, checks signatures, and prevents rollbacks. The server behind it can be modeled as an external endpoint; its security is then captured through Obligation 7 (secure distribution) and, where applicable, NIS2, not through the product scope. The server only becomes a full part of the product (RDPS) once it carries an operational core function beyond mere update delivery.
Thus the circle closes: what began as a boundary-drawing exercise with the CRA cyber risk assessment in our second CRA article becomes a concrete process obligation here.
Obligation 8: Free and timely distribution of available security updates
Available security updates are to be distributed without undue delay and, unless otherwise agreed by contract with business users, free of charge. Always accompanied by advisory messages on possible user actions.
The CRA thereby explicitly rules out the business model of offering security patches as paid upgrades or premium features. Security updates have to be free. For all users, across the entire support period. The only exception: an explicit contractual agreement with business users for tailor-made products; it does not apply to standard consumer products.
Two widespread misconceptions have to be cleared up here:
- “Free” applies for the duration of the support period, not indefinitely. After its end, the manufacturer is free to offer extended maintenance or updates for a fee. The boundary is the end of support, not the price.
- Free and without undue delay refers to the provision, not to forced installation. Whether an update is installed automatically or only after manual approval is governed by requirement (c) from Annex I Part I. Obligation 8 only requires that it be available in time and at no extra cost.
“Without undue delay” carries the same risk-based meaning here as in Obligation 2: the speed of provision has to match the severity. A critical patch for an actively exploited vulnerability must not wait months for the next regular release.
One more important note on the addition already mentioned, “accompanied by advisory messages on possible user actions”: an update shipped without comment meets the obligation only halfway. Users have to learn what it fixes and whether they themselves need to act. Here Obligation 8 reaches directly into the communication obligation from Obligation 4.
As different as the eight obligations from Annex I Part II presented here are, they share a blind spot when one thing is missing: knowledge of one’s own components.
Without it, each of the eight obligations remains piecemeal.
The software bill of materials is thus not one obligation beside the others, but the foundation beneath all of them.
Let us now look at it more closely.
The CRA and the SBOM in detail: not a buzzword, but an operational precondition
The SBOM has become one of the most frequently mentioned terms in the CRA discussion. Sometimes as a symbol of bureaucratic effort, sometimes as a technical miracle cure.
Neither is accurate.
The core is pragmatic: whoever does not know which components are inside their product also cannot know whether a newly discovered vulnerability affects their product. Creating the SBOM, the software bill of materials, is thus not a compliance exercise, but the precondition for vulnerability management along the product lifecycle working at all.
The idea of a bill of materials as such is nothing new. The hardware bill of materials, the BOM in the classic sense, has been established in product development for decades. Every manufacturer knows which physical components are built into its product. And this view belongs under the CRA as well: security-relevant hardware components have to be equally known and assessed, because the CRA considers the product with digital elements as a whole, not just its software. The only difference is that the hardware side, thanks to established BOM practice, usually no longer poses a major hurdle. What is actually new, and unfamiliar to many manufacturers, is the same systematic approach on the software side: a complete, maintained, machine-readable overview of what software is inside the product.
What an SBOM concretely is, and what it has to deliver for the manufacturer and its CRA obligations
An SBOM is a formal, machine-readable record of all software components of a product, including versions, licenses, and relationships to one another. In the CRA context, it fulfills two core functions:
- Vulnerability scanning: the SBOM enables the automatic reconciliation of all contained components against CVE databases. If a new vulnerability is discovered in an open-source library, the manufacturer can determine within minutes whether and in which product versions this library is contained, provided the SBOM is current and complete. (Software platforms can help here, such as the vulnerability management included in CYMETRIS.)
- Transparency and proof: the SBOM is the basis for proving that Obligation 1 (see above) is fulfilled. Without it, a manufacturer cannot demonstrate to market surveillance authorities that it knows all contained components and systematically checks them for known vulnerabilities.
On the minimum content and depth of the SBOM under the CRA
As a minimum requirement, the CRA (see Annex I Part II point (1)) demands the documentation of the “top-level dependencies,” meaning the directly integrated components, in a commonly used, machine-readable format.
The regulation text does not prescribe individual mandatory fields. What is fixed is only the depth (at least top-level), the machine readability, and a commonly used format. As “commonly used” formats, CycloneDX and SPDX have established themselves in practice.
Which fields an SBOM should concretely contain therefore follows not from the CRA itself, but from the standards established for this. A practicable minimum content for a software bill of materials that complies with the CRA looks roughly like this:
- supplier/maker of the component
- name and version of the component
- unique identifier (for example Package URL / PURL or CPE)
- relationship to the product (direct dependency)
- SBOM author and timestamp of creation
- license of the component (strongly recommended for the CRA open-source context)
- origin (source, repository) (supplementary)
For the transitive dependencies already explained, complete capture is recommended, but not mandatory under the CRA minimum requirement. The SBOM is, moreover, to be kept current across the entire support period.
In practice, a complete, deep SBOM can be generated automatically in the build process for most modern software products with available tools. With automated creation, the additional effort for the depth is marginal; the added value for vulnerability management is considerable.
SPDX vs. CycloneDX: the format question in SBOM creation
Both formats are accepted by the CRA, both are addressed by EN 40000-1-3 and TR-03183 Part 2, both can be generated with widespread tools. The decision is primarily a toolchain question:
- SPDX is an ISO standard (ISO/IEC 5962:2021) with strong roots in the open-source ecosystem and a particular focus on license information: the older and broadly established format.
- CycloneDX is an OWASP standard with a stronger security focus, explicit support for vulnerability references, and a more active security development community; for security-focused use cases, meaning the CRA context, it is often the more pragmatic choice.
The choice of format matters less than the consistency of maintenance. A perfectly structured SPDX document that is never updated again after the first release has no operational value. An informally structured CycloneDX SBOM that is automatically regenerated with every release, by contrast, is a real contribution to security.
The actual SBOM challenge: organization, not format
Many manufacturers find at the start of their SBOM work that the format is not the problem, but the state of the data beneath it. Organically grown products often have no central record of their dependencies: components were integrated without systematic documentation, versions updated without recording the change, open-source libraries copied instead of managed as a dependency.
In such cases, SBOM creation is initially an inventory project: what is actually in the product?
That can get uncomfortable, because it makes previously invisible gaps and risks visible.
But absolutely necessary, and the earlier the better.
The permanent solution is integrating SBOM generation into the build process: every build automatically produces a current SBOM, which is stored in version control and archived per release version. The SBOM is then no longer a one-off document, but regenerates itself with every build and thus stays current without additional maintenance effort. In this way, the initial inventory turns into a permanently reliable state that keeps the documented product and the actually shipped product in sync.
The CRA and due diligence for open-source components
Modern products, from hardware-level firmware through embedded software to the large enterprise application, typically contain substantial shares of open source.
That is efficient at first, but tied to obligations in the CRA context.
Art. 13(5) obliges manufacturers to exercise due diligence when integrating third-party components, including free and open-source software not supplied in the course of a commercial activity.
Concretely, this means: the manufacturer is responsible for integrated open-source components containing no known exploitable vulnerabilities. This responsibility cannot be delegated to the open-source project.
If, in the course of this due diligence, the manufacturer discovers a vulnerability in an integrated open-source component, it has to, under Art. 13(6):
- inform the person or entity that makes or maintains the component
- fix the vulnerability itself and build the corresponding patches into its product
- pass on a self-developed software fix to the component maintainer in a machine-readable format
That is an express obligation to give back: whoever benefits from open source contributes in return to its security, and the entire ecosystem gains.
With that, the picture of the eight obligations is complete, and their common denominator, the software bill of materials, stands out clearly: they form not a list of independent checkmarks, but a connected chain.
The SBOM feeds the monitoring, the monitoring triggers the patch process, the patch is distributed through secure channels and communicated through the CVD policy, and with the open-source reciprocity, this chain deliberately reaches beyond one’s own product into the ecosystem.
If one link fails, the entire chain loses its effect.
How this ties into the other articles of this CRA series
Vulnerability management and SBOM creation do not stand in isolation. They are the operational backbone that makes the other CRA obligations meetable in the first place:
- The CRA reporting obligations (see the first article): this is where the content originates that has to be reported within 24 hours when it counts. An actively exploited vulnerability that triggers the reporting obligation under Art. 14(1) is a result of the vulnerability monitoring process. Whoever runs no structured monitoring may learn of an exploitation only through external reports, or not at all. Vulnerability handling is thus the necessary preliminary stage for being able to meet the reporting obligation, not a separate topic.
- The essential CRA cybersecurity requirements (see the third article): requirement (a) from Annex I Part I, no known exploitable vulnerabilities when placing on the market, can structurally only be demonstrated through a functioning vulnerability handling process. Without an SBOM and without CVE scanning before the release, a manufacturer cannot prove that it has actually met (a).
- The CRA support period: the eight obligations apply not only at the point of placing on the market, but across the entire support period (see Art. 13(8)). At least five years, correspondingly longer for a longer expected use time. A process that is set up at release and not actively run afterward does not meet the requirement. The five years are the planning horizon, not the end of the project.
Take-away: SBOM, monitoring, patching, communication. One step at a time
Whoever has no SBOM and no structured patch process can neither meet the essential requirements durably nor serve the CRA reporting obligations from our first article on time.
Vulnerability management is the operational engine that makes the other CRA obligations meetable in the first place.
The most important practical advice one can still give in 2026, looking at the breadth of the to-dos: just start.
- The CRA has two kinds of duties: Part I describes how secure the product must be. Part II demands processes that run permanently. Cybersecurity becomes an ongoing task.
- Part II covers eight duties: know your components, handle vulnerabilities, test regularly, communicate openly, offer a reporting channel, distribute updates securely, and provide them free of charge.
- "Without delay" means: assess and contain the vulnerability right away. The actual fix can take time if the risk allows it.
- The SBOM is the foundation of everything: if you don't know what's in your product, you can't find, assess or report a single vulnerability.
- The minimum requirement is manageable: only the directly integrated components need to be captured in a machine-readable format. You don't have to publish the SBOM.
- Update channel doesn't automatically mean online update: devices without internet access also need a secure path, for example via download or through maintenance.
- Security updates must be free of charge, for the entire support period. Selling patches as a paid feature is not allowed.
- The most important advice: just start. An incomplete SBOM is better than none. Those who wait for the perfect solution often don't start at all for months.
- Key Learnings
An incomplete SBOM is better than none.
A manually maintained patch process is better than none.
A rudimentary CVD document is better than the absence of any policy.
The most common and most consequential mistake is the attempt to build a complete, fully automated, perfect solution from the start, and not to start at all for months in the process.
Vulnerability management is a maturing craft: it begins as a manageable, manually maintained process and is expanded step by step with growing experience and a better toolchain. (Did we mention CYMETRIS?)
Whoever starts today is further along in twelve months than whoever waits for the perfect solution today.
Product cybersecurity is not a state one reaches once. It is a process one runs permanently. A one-time security check before the release is not enough when the product is in the field for five years or longer, when new vulnerabilities in used components are discovered during that time, new attack methods emerge, and the threat environment changes.
A functioning vulnerability management consists of four interacting elements:
- knowing what is inside the product (SBOM);
- learning when new vulnerabilities are discovered in these components (monitoring);
- being able to react when action is needed (patch process);
- and communicating transparently when vulnerabilities have been fixed (CVD policy, security advisories, update distribution).
These four elements together make the difference between a manufacturer that works through the CRA as a regulatory box-ticking exercise and one that actually delivers durably secure products, and can prove it over five years or more.
