The Sum of All CRA Necessities: What Are the Technical Documentation and the EU Declaration of Conformity?

“Trust before control” can only work if the manufacturers’ self-declaration is truly substantial. Meaning, backed by:

• technical documentation,
• risk assessments,
• test reports,
• and, depending on the product class, the assessment of a notified body (a state-designated, independent assessment organization).

The mechanisms of this proof system, the three conformity assessment modules, the presumption of conformity, the technical documentation under Annex VII, and the CE marking with its particularities for software, therefore have to be understood precisely.

We start with the first decision point: how strictly a product is assessed depends on its risk class.

The three conformity assessment modules of the Cyber Resilience Act

The CRA recognizes three basic conformity assessment procedures. They do not originate from the CRA itself, but from the so-called New Legislative Framework, a standardized toolkit the EU has been using for years for nearly all product regulations (from machinery to medical devices). Anyone who already places CE-marked products on the market will recognize the logic: the CRA does not reinvent conformity assessment.

Which module applies depends on the product class. As a reminder: the CRA divides products into four categories, default, important (Class I and II), and critical, which we introduced in the second article of this series on the CRA cyber risk assessment. Which one a specific product falls into follows from Annexes III and IV of the CRA; the vast majority land in the default category.

Module A: internal control

Module A is self-assessment by the manufacturer, the least demanding procedure, sufficient for:

• Default category: all products not explicitly classified as important or critical can be assessed exclusively under Module A (see Art. 32(1)).
• Important Class I with harmonized standards: for important products of Class I, there is a relief: whoever fully applies recognized standards, meaning harmonized standards (in the CRA context presumably the emerging EN 40000 series, introduced in the previous articles, once it is cited in the EU Official Journal), common specifications, or a European certification scheme (at least assurance level “substantial”), may also stay with self-assessment under Module A here, instead of involving a notified body (phrased the other way around in the CRA, see Art. 32(2)).

This raises the legitimate question of how a manufacturer demonstrates that it actually applies a harmonized standard in full.

An external audit is not necessary for that: full application triggers the presumption of conformity under Art. 27, so the fulfillment of the covered requirements is presumed as long as nothing to the contrary emerges.

It is demonstrated in the technical documentation (see Art. 31 in conjunction with Annex VII), in which the applied standards are to be listed and, for each applicable requirement, it is to be shown how the product meets it. The market surveillance authority can request this documentation at any time; if the application of the standard proves incomplete, the presumption lapses. The self-declaration is thus not a claim without consequences.

Under Module A, the manufacturer ensures and declares on its own responsibility that product and processes meet the essential cybersecurity requirements. It draws up the technical documentation, carries out the conformity assessment, issues the EU declaration of conformity, and affixes the CE marking. No external assessment. But: the entire burden of proof lies with the manufacturer.

That is less simple than it sounds. Module A does not mean there is less to do. Ultimately, the verification takes place not externally, but internally. Technical documentation, risk assessment, and test reports have to be just as substantial as with a third-party assessment. The difference lies in the verifying instance, not in the level of requirements.

One important special rule: manufacturers of important Class I products that qualify as free and open-source software can apply Module A, provided they make the technical documentation publicly available (see Art. 32(5)). This constitutes a relief for open-source manufacturers, who use the transparency of their development as a trust mechanism.

Module B+C: EU-type examination and conformity to type

If self-assessment is not sufficient, an external assessment comes into play, the so-called third-party assessment. That means: not the manufacturer itself, but an independent, state-designated assessment organization (the notified body) confirms conformity. Module B+C is one of two permissible paths for this (the other is Module H).

The name describes two consecutive steps:

• Module B is the EU-type examination: the notified body examines the technical documentation, product design, and samples, and issues an EU-type examination certificate if the result is positive.
• Module C is the subsequent conformity to type based on internal production control, in which the manufacturer ensures that the units actually produced conform to the examined type.

In short: first the prototype is examined, then the series is bound to it.

When Module B+C (or alternatively Module H) applies:

• Important, Class I without recognized standards: whoever does not apply the relevant standards, specifications, or certification schemes, or applies them only in part, loses the option of self-assessment. Then an external assessment via Module B+C, or alternatively Module H, is due (see Art. 32(2)).
• Important, Class II: here there is no way around the external assessment. It is always required, even with full application of the standards. Module B+C is one of the permissible paths (see Art. 32(3)).

The procedure in practice:

1. The manufacturer submits an application to a notified body of its choice, with technical documentation, a description of the product and its intended purpose, and samples.
2. The body examines the documents, carries out tests and examinations, and, if the result is positive, issues the EU-type examination certificate, which confirms the conformity of the examined type with the essential requirements of the CRA.
3. This certificate is the basis for the CE marking.

Module H: full quality assurance

Module H is the third option. It starts at an entirely different point than Module B+C. Instead of examining an individual product sample, the entire manufacturing process is certified here.

The idea behind it: if it is demonstrably ensured that a company develops and produces in a structured and secure way, not every product has to be externally examined individually.

Concretely, this means: a notified body assesses the manufacturer’s quality management system (QMS for short) once and approves it. This system then has to cover the entire product lifecycle: from design through development and production to vulnerability handling. In doing so, the QMS guarantees that all produced units meet the essential cybersecurity requirements.

Once the system is approved, the manufacturer can place its products on the market without further individual assessments, as long as it maintains the system and successfully passes the notified body’s regular surveillance audits. (The CRA prescribes no fixed frequency for these; it requires regular audits and also permits the notified body to carry out unannounced checks.)

When this is worthwhile: above all for manufacturers who already work with established QM systems, for example under ISO 9001 or ISO 27001, and have many or frequently changing products in their portfolio. For them, it is more efficient to have the process certified once than to go through a type examination again for every new product or variant. A manufacturer with a single, long-lived product, by contrast, is often better off with Module B+C. Module H is permissible for the same product classes as Module B+C (see Art. 32(2) and (3)).

Critical products (CRA Annex IV): the special case of state-defined certification

At the very top of the risk pyramid stands a small group of critical products, listed in Annex IV. These include hardware security modules, smart meter gateways, and smart cards or secure elements, meaning components whose entire purpose is the protection of security-critical functions.

For these products, neither self-assessment nor the normal third-party assessment is enough. What is required is formal certification under a European cybersecurity certification scheme, meaning a state-defined, uniform assessment standard. The currently most important of these schemes is the EUCC (European Common Criteria-based Cybersecurity Certification Scheme), which builds on the internationally established Common Criteria.

Which critical products concretely fall under this obligation, and how strictly they have to be assessed, is being determined by the EU Commission step by step. As long as that has not yet happened for a particular product, the transitional rule is assessment under the rules of the highest regular tier (Important, Class II). For practice, this means: the circle grows gradually, and until then the path via the notified body described above applies.

Assessment organizations and notified bodies for the CRA: availability and practical relevance

Whoever may not assess their product themselves but needs an external assessment (under the Module B+C or H procedures) cannot get around a so-called notified body. These are independent assessment organizations (often private companies such as TÜV or DEKRA) that are officially approved for this by an EU member state and then listed in a central EU database, NANDO (New Approach Notified and Designated Organisations). Only those listed there may actually carry out the assessment.

To ensure there are enough of them, the CRA builds up this assessment landscape step by step. Only since June 11, 2026, have the rules applied under which such bodies can be approved at all. And by December 11, 2026, the member states are supposed to ensure a sufficient number, so that market access does not back up. The “supposed to” is to be taken literally here: it is a goal the countries have to strive for, not a firm guarantee that it will work out in time.

And exactly there lies the problem for planning: as of now, the end of September 2026, the NANDO list for the CRA is practically empty, not a single approved body.

There is a simple reason for that: before a body officially appears in the database, a multi-stage chain applies. First, as a rule, the national accreditation body assesses the technical competence of the assessment organization, in Germany the German accreditation body DAkkS. On this basis, the competent notifying authority officially notifies the body to the EU Commission, in Germany the Federal Office for Information Security (BSI). Only after that does the entry appear in NANDO.

This chain is (as of the end of September 2026) under way, but not yet through: the BSI procedure started on schedule on June 11, 2026, DAkkS is accepting applications for the CRA scope, and since September 25, 2026, the BSI has been providing DAkkS with its own technical assessors for the accreditation procedures. The national CRA implementing act, meanwhile, is still in the legislative process. Whoever is planning a product in the higher risk classes still simply cannot complete the assessment today: the bodies have not yet been designated.

The CRA and the presumption of conformity: why harmonized standards make the proof so much easier

Behind the unwieldy phrase “presumption of conformity” lies one of the practically most important mechanisms of the whole system around the Cyber Resilience Act. The basic idea: normally, a manufacturer would have to demonstrate for every single one of the requirements from Annex I that and how it meets them. It is exactly this effort that the presumption of conformity takes off its shoulders.

It works via so-called harmonized standards. These are the technical standards, mentioned again and again in the previous articles of this series, that are developed on behalf of the EU Commission specifically for a regulation and subsequently listed in the EU Official Journal. If a manufacturer applies such a standard in full, it is automatically presumed to meet the CRA requirements covered by it. It then no longer has to demonstrate anything point by point. Fulfillment is taken as given, as long as no one proves the contrary.

This mechanism has an immense advantage for the documentation (and any potential dealings with the market surveillance authorities): one can rely on a recognized, verifiable standard instead of a self-developed justification and chain of proof. Added to this, a standard is considerably more workable in everyday practice than the legal text itself: it translates the abstract stipulations of the CRA into concrete, verifiable requirements and thus takes the interpretation work off the manufacturer that it would otherwise have to do for every single legal requirement. And the effect reaches beyond the individual product: the horizontal EN 40000 series forms the common frame on which the emerging vertical, product-specific standards build. Whoever orients themselves toward it early also lays the foundation for building on the fitting vertical standard later.

Two things matter, however, so that this advantage does not become a trap:

1. This presumption removes no substantive obligation. Whoever invokes a standard has to actually apply it in full and not merely formally reference it. Referencing a standard that is not implemented in the product at all does not hold up.
2. The presumption does not automatically cover everything. The process obligations from Annex I Part II, meaning the ongoing CRA vulnerability handling from the fourth article of this series, describe not product properties but manufacturer processes, and are so far only partly captured by the standards. For this part, one’s own proof remains necessary.

Exactly here lies the current practical limitation, as already described: no harmonized standard for the CRA is yet listed in the EU Official Journal. The presumption of conformity is thus already laid out in the law, but in practice it takes effect only once the corresponding standards, for example from the EN 40000 series, are officially referenced.

Some experts therefore currently advise: until then, there is no way around the individual justification per requirement.

Looking ahead: which standards and aids will ease CRA implementation going forward

This individual proof per requirement, however, is only today’s state, not a permanent one.

It is therefore worth taking an organized look at the available and coming aids, not as a flat list, but by their stage of maturity: what helps already today, what will become the binding reference in the medium term, and where it all ends up.

One important distinction carries through the whole outlook: the completion date, at which a standard is technically finished, and the citation in the EU Official Journal, at which it becomes legally effective, fall apart. Only the latter triggers the presumption of conformity.

What is already well usable for the CRA today, even without a presumption of conformity

For an immediate start, there are solid foundations. The BSI TR-03183, which we have drawn on several times in this series as a transitional working basis, shows in a structured way how the CRA requirements, including the SBOM, can be addressed methodically.

It is being continuously updated, establishes no presumption of conformity, but is broadly accepted as orientation.

For the handling of vulnerabilities, the established international standards ISO/IEC 29147 (Vulnerability Disclosure) and ISO/IEC 30111 (Vulnerability Handling) come in addition, which pay directly into the obligations from Annex I Part II, in particular the CVD policy described in Article 4 of this series. A small but practical building block alongside them is RFC 9116, the security.txt convention, which makes the reporting channel for vulnerabilities findable.

On July 27, 2026, the EU Commission approved the content of an official application guidance on the CRA, the “Commission guidance on the application of the Cyber Resilience Act” (document C(2026) 5252), based on Art. 26. Across more than 80 pages, it answers the questions that burn most for manufacturers: what falls under the CRA at all, when does an update count as a “substantial modification,” how long does the support period have to be, how do the reporting obligations work, with a particular view to small and medium-sized enterprises.

Two things are worth knowing about it: the guidance is legally non-binding (only the European Court of Justice can interpret the CRA bindingly), and the Commission has so far only approved the content. It will only be formally adopted, and thereby applicable, later, once all EU language versions are available. As an orientation aid, however, it is already useful now.

The next step: the particular relevance of the horizontal EN 40000 family of standards for the CRA

The actual foundation for the future of CRA compliance is the EN 40000 series, which we already introduced in the article on the CRA cyber risk assessment and with the CRA essential cybersecurity requirements. It applies horizontally, meaning to all products with digital elements, and is being developed under the EU standardization request M/606 as a package of around 41 standards.

Relevant for the timeline: at the beginning of July 2026, the Commission pushed the completion deadlines for 2026 back by two months. That changes nothing about the application dates of the law itself.

Within the series, four parts are central, and they stand at different stages:

• EN 40000-1-1 (vocabulary) creates a uniform terminology and has already passed the public enquiry.
• EN 40000-1-2 (principles and risk management) is the substantive core for the risk assessment and the application of the essential requirements from Part I, well advanced and expected to be completed later in 2026.
• EN 40000-1-3 (vulnerability handling) translates the eight obligations from Part II into verifiable requirements and is presumably the part that will be cited first, which fits well with the fact that the reporting obligations have already applied since September 2026.
• The fourth part, EN 40000-1-4 (generic security requirements), is the largest open construction site: it is meant to map the abstract requirements onto a catalog of concrete security controls, but is still being drafted without a public draft, with a delivery target only toward the end of 2027.

In addition, the technical report TR 40000-1-5 (Threats and Security Objectives) delivers a structured mapping of threats onto security objectives as a starting point for the risk assessment. It is not a normative standard, but supporting orientation.

For important and critical products: the product-specific standards for the CRA

Whoever builds a product in the higher risk classes will additionally find the vertical, meaning product-specific, standards relevant. They build on the horizontal EN 40000 frame and make it concrete for individual categories from Annexes III and IV:

• Furthest advanced is the ETSI EN 304 6xx series for IT and consumer products as well as most important software and connected product categories, whose drafts are already publicly viewable.
• For operational technology products such as firewalls, routers, or VPN solutions, the prEN 50770 series is emerging, which orients itself strongly toward the established IEC 62443 framework.
• For semiconductors and secure elements, finally, a dedicated group of standards is in the works, of which several parts have already completed the public enquiry.

For manufacturers of such products, the fitting vertical standard is usually the more relevant proof path, not the horizontal frame alone.

The decisive caveat for planning

For all these documents, the distinction already sketched above applies: completion is not the same as legal effect.

The first horizontal building blocks will be technically finished from later 2026, the controls catalog 1-4 only toward the end of 2027, the vertical standards staggered in between.

The first citation in the Official Journal, and with it the actually usable presumption of conformity, is however not expected before 2027, in part only close to the full application date at the end of 2027.

In case the standards are not finished in time, the EU Commission still has a fallback option: it can issue its own technical stipulations, so-called common specifications. These would have the same effect as a harmonized standard; whoever applies them is likewise presumed conformant. Whether and when the Commission will make use of this is currently open.

As a rule of thumb for planning: whoever orients themselves today toward EN 40000-1-2 and 1-3 as well as, transitionally, the BSI TR-03183, and for important or critical products additionally toward the fitting vertical standard, builds on the right foundation.

But one has to factor in that this convenient path via the standards only becomes actually usable in 2027. Until then, the shortcut “I apply the standard, so everything counts as fulfilled” does not yet exist. So the rule is: the manufacturer has to go through requirement by requirement itself and document, for every applicable Annex I requirement, how its product meets it. Exactly this work, requirement by requirement, is what the third article of this series described in detail.

The technical documentation under Annex VII: the CRA piece of evidence everything comes down to when it counts

The technical documentation (see Article 31) is the central proof document of the entire CRA conformity system. Everything this series has described so far converges in it:

• the CRA cyber risk assessment from the second article,
• the implementation of the essential cybersecurity requirements from the third,
• and the vulnerability handling processes from the fourth.

Whatever security work a manufacturer has done exists for the authorities only insofar as it is documented here.

Put differently: it is not the secure product alone that counts, but the traceable evidence that it is secure.

That is why the technical documentation has to be complete before placing on the market, not first come into being upon an authority’s request. It has to demonstrate that both the product and the manufacturer processes behind it meet the requirements from Annex I. It is thus the basis on which the EU declaration of conformity and the CE marking can rest in the first place, and, in the event of an inspection, the first thing a market surveillance authority accesses.

The minimum contents of the technical documentation under the Cyber Resilience Act (see Annex VII) at a glance:

General product description: name, type, and the software versions that influence conformity; for hardware, supplemented by photographs or illustrations; plus the information and instructions for the user under Annex II. Exactly this work on the user documentation we had already classified as part of the development phase, meaning security notices, configuration instructions, and information on secure operation (see the third article of this series). Here it flows into the documentation.

Description of design, development, and production: the system architecture, the structure and interplay of the software components, the communication interfaces, and the remote data processing solutions (the manufacturer’s own cloud or backend services without which the product could not perform one of its functions, treated in depth in the question of the product boundaries in our second article of the series). Added to this are the vulnerability handling processes with SBOM, CVD policy, the contact address for vulnerability reports, and secure update distribution, meaning exactly the eight obligations our fourth article described in detail. Finally, the production and monitoring processes and the proof that they work.

Cybersecurity risk assessment: the complete risk assessment with identified assets and threats, the assessed risks, the risk acceptance decisions, and the measures derived from them, meaning the complete result of the methodology from the second article of our series. Important here is the point we already emphasized with applicability: for every requirement from Annex I Part I that has been classified as not applicable, a clear justification belongs in the documentation (see also the third article). A silently passed-over requirement is not accepted by the authority.

Information on the support period: the considerations that led to determining the support period, meaning the expected use time, the nature of the product, and relevant other Union legislation. That this period is at least five years, and a lower bound, not a default value, we derived in the second article.

Applied standards and specifications: a list of all fully or partly applied harmonized standards, common specifications, or certification schemes. As long as no such standard is yet cited in the Official Journal (the state we described in the previous section), the second case applies here: then it has to be described with which alternative solutions the essential requirements are met instead. That is exactly the individual proof the manufacturer has to furnish until the standards become available anyway.

Test reports: the reports on all tests and examinations carried out, demonstrating both that the product successfully implements the security measures derived from the risk assessment and that the vulnerability handling processes meet the requirements from Annex I Part I and Part II.

EU declaration of conformity: a copy of the EU declaration of conformity, meaning the formal declaration with which the manufacturer itself bindingly assures conformity. What it contains in detail is covered in the next section.

SBOM: the software bill of materials is not a mandatory standard part of the documentation, but is to be presented upon reasoned request of the market surveillance authority. That fits what we already noted in the fourth article of this series: the SBOM does not have to be published, but is accessible to the authorities.

Retention and accessibility: technical documentation and EU declaration of conformity are to be kept for at least ten years after placing on the market, or for the duration of the support period, whichever is longer. Since the support period for many products extends well beyond five years, the retention obligation can exceed the ten years. Upon reasoned request, the documentation has to be accessible to the market surveillance authorities, in paper form or electronically, and in a language easily understandable to the authority. It is expressly not a public document; its accessibility is limited to the competent authorities. In practice, a requirement follows from this that the CRA does not spell out separately, but that follows directly from these obligations: the documents should, like any audit-relevant material, be subject to orderly document management, with clear versioning, documented approval, and details of author and date. Only in this way can it be demonstrated, across a retention period of ten years or more, which version applied when and who was responsible for it. Likewise, the documentation belongs stored centrally and securely, not locally on individual employees’ computers, so that in the event of an inspection it is available completely, findably, and in its current state.

Simplified format for smaller companies: micro and small enterprises may present all the elements named in a simplified format. Who counts as a micro or small enterprise? The CRA does not define this itself, but falls back on the EU standard definition (Recommendation 2003/361/EC). The thresholds:

• Microenterprise: fewer than 10 employees and annual turnover and/or balance sheet total of at most EUR 2 million.
• Small enterprise: fewer than 50 employees and annual turnover and/or balance sheet total of at most EUR 10 million.

The EU Commission provides a dedicated form tailored to small manufacturers for this, and notified bodies have to accept this format for the conformity assessment.

Important here: this lowers the effort of the presentation, not the substantive requirements. Risk assessment, test reports, and the description of the vulnerability handling processes have to be substantial in the simplified format as well.

The final step: from proof to public promise with the CE marking and the EU declaration of conformity

The EU declaration of conformity forms the legally binding heart of the entire CRA compliance process. With it, the manufacturer declares that product and processes meet the essential cybersecurity requirements.

It is issued by the manufacturer and carries its full responsibility.

Minimum contents for it, under Annex V:

• name and type of the product as well as all information necessary for unambiguous identification;
• name and address of the manufacturer or its authorized representative;
• a declaration that the manufacturer bears sole responsibility for the issuance;
• a reference to the applied harmonized standards,
• common specifications, or cybersecurity certification schemes;
• where applicable, name and identification number of the notified body involved;
• place and date of issuance, signature.

The CRA also provides for a simplified EU declaration of conformity (see Art. 13(20) and Annex VI) that can be enclosed with the product. It contains only the essential declaration and the reference to the full declaration via an internet address; the full declaration has to be retrievable online and permanently available.

If a product falls under several pieces of EU legislation each requiring an EU declaration of conformity, a single declaration is issued for all relevant legislation (see Art. 28(3)). This is meant to reduce the effort for manufacturers whose products are simultaneously subject to the CRA, the Machinery Regulation, or other EU legal acts.

The CE marking under the Cyber Resilience Act: how is it affixed?

The CE marking is the visible sign that a product meets the requirements of the CRA. Certain formal rules apply to its affixing.

With it, the manufacturer declares that the product meets the requirements of all applicable EU harmonization legislation; it is the precondition for free market access in the internal market.

Formal requirements: it is to be affixed

• visibly,
• legibly,
• and indelibly on the product,
• or, if the nature of the product does not allow this, on the packaging and the EU declaration of conformity.

The minimum height is 5 mm, but can be smaller for reasons of product size, as long as the mark remains recognizable; it is to be affixed before placing on the market.

Under Module H, the CE marking is followed by the identification number of the notified body involved (see Art. 30(4)).

A special case is software shipped without hardware. The classic CE marking on the product naturally does not apply here. For software products, the question of affixing the CE marking arises differently than for hardware. Pure software has no housing, no packaging in the classic sense. The CRA addresses this explicitly: for products with digital elements in the form of software, the CE marking is affixed either on the EU declaration of conformity itself or on the website accompanying the software product (see Art. 30(1)). The relevant section of the website has to be easily and directly accessible to consumers. Meaning not buried in the legal notice, but findable as a clear part of the product.

The perennial scope question for software in the Cyber Resilience Act: PwDE or not?

Whether a product falls under the CRA at all we clarified in the first part of this series. For software manufacturers, however, a closer look is worthwhile at this point, because before the CE marking even becomes a topic, it has to be settled whether the software product is a product with digital elements (PwDE). The distinction is not always clear-cut, above all where software and cloud interlock:

• Clearly in scope: software that runs on the user’s device: installable programs, mobile apps, firmware, embedded software. It needs the CE marking.
• Clearly outside: pure cloud services that run entirely server-side and are used only via the browser (classic SaaS/PaaS/IaaS). They do not fall under the CRA, but, where applicable, under NIS2.
• Gray zone, app with backend: if an app necessarily needs a manufacturer-owned cloud backend to perform its core function, this backend counts as a remote data processing solution (RDPS), and thus as part of the PwDE, not as a standalone cloud service. App and backend are then treated as one product; the CE marking applies to the overall product. The backend alone, without an associated placed client, does not fall under the CRA.

This distinction is one of the most frequent points of interpretive dispute in CRA implementation.

The Commission guidance under Art. 26 CRA (C(2026) 5252, July 2026) now addresses it in depth, with examples of when a pure browser application, a locally installed app, or a backend service counts as a PwDE. Whoever is unsure will find the concrete case groups there; when in doubt, legal advice is additionally worthwhile.

Our CRA series comes full circle: from the first risk assessment to the CE mark

This final section draws the arc across all five articles of our series. It becomes clear that the topics we treated one after another in truth form a single connected system.

At the beginning stood the CRA reporting obligation, which has applied since September 2026 and makes clear that the CRA is no distant future topic (Article 1).

It was followed by the cyber risk assessment as the methodological core, which determines what has to be done at all for a specific product, and at what depth (Article 2).

On this build the thirteen essential requirements from Annex I Part I, the technical constitution of the product (Article 3), supplemented by the eight vulnerability handling obligations from Part II, which keep this security alive across the entire support period (Article 4).

And all of that finally flows into the proof: the technical documentation, the conformity assessment, and the CE marking, with which the manufacturer visibly assumes responsibility (Article 5).

None of these building blocks holds on its own. Only their interplay produces what the CRA actually wants: demonstrably secure products across their entire lifecycle.

Let us summarize how each individual building block of the series flows into the final proof:

• Article 1, reporting obligations: the manufacturer needs processes that detect, classify, and escalate security-relevant events in a structured way. These processes are part of the vulnerability handling documentation and thus have to be contained in the technical documentation under Annex VII.
• Article 2, cyber risk assessment: the risk assessment is expressly part of the technical documentation, not a separate internal paper. Asset identification, threat analysis, assessed risks, and the documentation of the implemented measures, meaning everything Article 2 described methodically, flows directly in here.
• Article 3, essential requirements: that the thirteen requirements from Annex I Part I are implemented is demonstrated in the documentation through the description of the product design, the development processes, and through the test reports. For every requirement classified as not applicable, a justification belongs alongside. The test reports, meaning penetration tests, scans, and formal reviews, are the concrete proof that the requirements are actually met, not merely claimed.
• Article 4, vulnerability management and SBOM: the vulnerability handling processes with SBOM, CVD policy, patch process, and update distribution are likewise part of the technical documentation. The SBOM is to be presented upon reasoned request of the market surveillance authority, and the CVD policy is, as shown in Article 4, the only process document the CRA demands by name and that has to be publicly accessible. The test reports on these processes belong in as well.
• Article 5, conformity assessment: the technical documentation is the result and proof of all preceding activities at once. The EU declaration of conformity is its formal summary, and the CE marking is the visible signal to the outside that this entire process has been fully completed.

That is the actual message of this final article: the conformity assessment is not an additional work step ticked off at the end of the project. It is the structured summary of the work from the preceding four articles. Whoever has carried out a clean risk assessment has already worked out the core of Annex VII. Whoever has documented their vulnerability handling processes has already written the process documentation. And whoever has systematically checked the thirteen requirements and tested their implementation has already produced the test reports.