A testing-laboratory perspective on the essential cybersecurity requirements and what manufacturers actually need to do
The first question most manufacturers ask about the CRA is “is my product in scope?” But once you have confirmed that it is, the next question is much harder to answer: how much do I actually have to do before I count as compliant with the CRA?
The answer is concentrated in Annex I of the CRA (Annex I, “Essential cybersecurity requirements”). Most of the regulation’s seventy-one articles deal with the machinery of the law: who has obligations, how conformity is assessed, who supervises, and how much the fines are. The only place that actually specifies what the product and its processes must achieve is this single annex.
Put differently: what the technical documentation must demonstrate is conformity with Annex I; what the CE marking and the EU Declaration of Conformity assert is conformity with Annex I; and the highest tier of fines under Article 64 punishes violations of Annex I. It is where the entire regulation lands on the product itself — read it first, and the conformity-assessment modules, reporting obligations and support-period planning that follow will all have something to stand on.
Annex I is not long, and its structure is quite clear: it is split into two parts. In everyday terms, Part I is the “pre-shipment health check” for the product, and Part II is the “long-term duty of care” after the product has been sold.
| Part I (product-property requirements) | Part II (vulnerability-handling requirements) | |
|---|---|---|
| What question does it answer? | From design to shipment, was security actually taken seriously in this product? | Once the product is on the market, is the manufacturer capable of looking after it continuously? |
| Number of items | 13 items, numbered (a)–(m) | 8 items, numbered (1)–(8) |
| Nature | Mostly product and technology: configuration, encryption, access control, attack surface | Mostly process and organisation: SBOM, vulnerability reporting, patching, disclosure |
| Main responsible unit | R&D / engineering | Product operations / security incident-response team |
| Time dimension | Largely one-off, re-verified with each new version | Continuous, spanning the whole support period (in principle at least 5 years) |
The last two rows of this table deserve the most attention. Part I and Part II differ completely in who is responsible and in their time dimension; in practice it is unrealistic to expect a single security engineer to handle both. Assigning separate owners to the two parts at the planning stage of a compliance project is usually far less painful than patching things up afterwards.
Many readers open Annex I and jump straight to item (a), but what really determines the workload is the opening clause before it: products shall be designed, developed and produced to ensure an appropriate level of cybersecurity “based on the risks”, and items (a)–(m) are to be implemented “where applicable”, on the basis of the cybersecurity risk assessment required by Article 13(2).
Those two qualifiers matter. Annex I is not a scorecard on which every item must reach full marks; it requires the manufacturer to carry out a risk assessment first and then decide, based on its conclusions, how deep each item needs to go. A connected door lock and an indoor temperature-and-humidity sensor should not be implemented to the same depth — but the precondition is that you hold a risk-assessment document that can explain the reasoning.
This is also the gap the laboratory sees most often when helping clients take stock: plenty of technical measures have actually been implemented, but there is no risk assessment that clearly explains why this depth of implementation is enough, so the technical documentation cannot stand up as evidence. Our advice is to start the risk assessment at the product-planning stage, not to write it retroactively just before shipment.
Reading (a) through (m) one by one makes it easy to lose focus. Below, the 13 items are grouped into five clusters by the problem they are meant to solve, each followed by the points the laboratory most often checks during testing and documentation review.
Map these five groups onto the product-development process and a pattern appears: the long list of (b)(d)(e)(f)(g)(h)(i)(j)(k)(l) — that is, the large majority of Part I — lands in the architecture and design phase. How small the attack surface is, what the logs record, which data is never collected in the first place: once the architecture is fixed, these are very hard to change. The testing phase can only discover problems; it cannot go back and fix them.
This is the practical meaning of security by design in the CRA: the success or failure of compliance is largely decided in architecture-design meetings, not in the pre-shipment test report. The laboratory’s observation is that the earlier a team treats Annex I as a design checklist, the lower its subsequent testing and documentation costs.
The logic of Part II is essentially a vulnerability-handling lifecycle: prepare properly, be able to receive external reports, be able to verify and fix, be able to ship updates out securely, and take responsibility for disclosure afterwards. The eight requirements can be read along that line:
| Stage | Corresponding item(s) | What the manufacturer needs to have |
|---|---|---|
| Prepare | (1) Identify and document vulnerabilities and components (SBOM) | An SBOM in a commonly used, machine-readable format (e.g. SPDX, CycloneDX) covering at least the top-level dependencies; ideally generated automatically in CI/CD |
| Receive | (5) Coordinated vulnerability disclosure policy (6) Contact address for reporting | A publicly posted vulnerability-reporting policy and contact point on the website (e.g. a security@ mailbox, security.txt) |
| Verify | (3) Effective and regular tests and reviews | A documented, fixed-cadence schedule of penetration tests, vulnerability scans and code reviews |
| Remediate | (2) Address and remediate vulnerabilities without delay | Internal remediation SLAs, and — where technically feasible — security updates released separately from feature updates |
| Distribute | (7) Secure update-distribution mechanism (8) Free of charge and without delay | Updates signed and verified, distributed over encrypted connections; security updates always free of charge, accompanied by advisory messages for users |
| After release | (4) Publicly disclose information about fixed vulnerabilities | A security-advisory publication process and template (vulnerability description, affected versions, severity, remediation) |
The point this table most deserves to make is this: Part II tests a standing capability, not a one-off project. In practice, once an organisation has genuinely put three things in place — someone (or some tool) responsible for maintaining the SBOM, a mailbox plus standard operating procedure for receiving and handling vulnerability reports, and a fixed mechanism for publishing security advisories — all eight requirements have somewhere to take hold.
Conversely, if no one owns those three things yet, then however complete the product’s technical measures may be, Part II remains a blank page. These are also the first three questions the laboratory checks in early-stage interviews.
If you are starting today, the following order is relatively pragmatic in most projects — the first four items do not need to wait for the harmonised standards to be finalised, nor for a product redesign; they can begin right now.
The first four are fundamentals unaffected by the progress of the harmonised standards; the last two are about making the capability permanent. Note that the horizontal harmonised standards corresponding to the CRA (the prEN 40000 series) are still at draft stage and have not been published in the Official Journal of the EU, so they do not yet confer a presumption of conformity. This means that, for now, technical documentation must be built directly against Annex I of the CRA regulation text itself; the drafts can be consulted for structure and detail, but cannot serve as the final basis of compliance.
Annex I becomes fully applicable with the CRA on 11 December 2027, when it formally becomes mandatory for in-scope products. But the earlier gate is 11 September 2026, when the reporting obligations of Article 14 take effect first (see our dedicated Article 14 article for the deadlines and content details).
There is a gap of over a year between the two dates, and this is precisely where preparation time is most often misjudged: answering “is our product affected by this vulnerability?” within the deadline depends on exactly the SBOM and component inventory required by Part II item (1). In other words, part of the Annex I capability is already needed in practice from September 2026 — not from the end of 2027.
Misconception 1: “Annex I is the security engineers’ problem — once the penetration test is done, we’re compliant.” More than half of the Part I requirements land in the architecture-design phase, and (g) data minimisation and (m) data deletion are closer to product-specification decisions; Part II is mostly about process and organisational capability. A test report is one piece of evidence, but it does not equal conformity with Annex I.
Misconception 2: “(g) data minimisation and (m) data deletion belong to the privacy or legal department.” These two items do overlap with the spirit of the GDPR, but they are cybersecurity requirements explicitly listed in CRA Annex I, and they will appear in the CRA technical documentation and conformity assessment. We recommend making them fixed check items in product-specification review meetings.
Misconception 3: “We can wait until the EN 40000 series is published before starting to prepare.” The Annex I legal obligations come from the CRA regulation text itself and are not postponed because the harmonised standards are unfinished. The drafts affect the details of “what counts as doing it right”, not “whether it must be done”. In other words, Annex I is about to be in force regardless, and harmonised standards are merely one future route for proving conformity. Risk assessment, SBOM and a vulnerability-reporting channel will be required whatever final form the standards take.
Annex I reads like a technical checklist, but the genuinely hard part is usually not understanding the clauses — it is judging “given our product’s risk, how much is enough?” and “can our existing test reports and documents carry the burden of proof?” Both questions have to be answered against the product’s actual architecture and existing documentation, and are hard to settle with general rules.
If you have already confirmed that your product falls within CRA scope and want to take stock of where each Annex I item stands and where the gaps are, or need professional review of the completeness of your existing test reports and technical documentation, feel free to contact us — our consultants and laboratory engineers can help assess your specific case.
You are also welcome to join the in-person seminar in Taipei on Friday 18 September, where you can put questions directly to a CRA expert from Spain and learn more about planning for 2027 compliance and estimating the time and cost of implementation. Registration: Register for the seminar
Q: What is CRA Annex I? Annex I is the first annex of the EU Cyber Resilience Act (Regulation (EU) 2024/2847), titled “Essential cybersecurity requirements”. It has two parts: Part I lists 13 product-property cybersecurity requirements, (a)–(m), and Part II lists 8 vulnerability-handling requirements, (1)–(8). Products with digital elements that fall within CRA scope must conform to Annex I and demonstrate this through technical documentation.
Q: What is the difference between Part I and Part II of Annex I? Part I governs the product’s own design and as-shipped state — secure default configuration, encryption, access control, attack-surface reduction and so on — with responsibility sitting mostly with R&D engineering. Part II governs post-market vulnerability-handling capability — SBOM, a vulnerability-reporting channel, patching and disclosure processes — and is a continuous obligation across the entire support period, with responsibility sitting mostly with product operations and security incident response.
Q: Does every item of Annex I have to be implemented to full marks? No. Annex I follows a risk-based principle: items (a)–(m) are implemented “where applicable”, based on the outcome of the Article 13(2) cybersecurity risk assessment. The depth of implementation should be proportionate to the product’s risk, but the manufacturer must keep the risk-assessment documentation explaining why a given level of implementation is appropriate.
Q: How heavy are the penalties for violating Annex I? Under Article 64, violations of the Annex I essential requirements and of the Article 13 and 14 obligations carry administrative fines of up to €15 million or 2.5% of worldwide annual turnover, whichever is higher — the highest tier in the CRA penalty structure.
Q: Should we start preparing now? We recommend it. Annex I becomes fully applicable with the CRA on 11 December 2027, but the Article 14 reporting obligations apply from 11 September 2026, and determining within the deadlines whether a product is affected by a given vulnerability in practice requires Part II capabilities such as an SBOM and component inventory to already be in place.
The legal provisions and dates cited in this article are based on the following documents:
By the Secure Vectors Surveillance Inc. (SV Surveillance) × Applus+ Laboratories consulting team
* This article is regulatory commentary, not legal advice. As of writing, the prEN 40000 series remains a Draft for Public Comment, has not been published in the Official Journal of the EU, and may change before formal publication. The “what manufacturers should do” sections are consultant recommendations and common industry practice, not verbatim requirements of any standard. Final compliance determinations for specific cases remain subject to official EU documents and the interpretations of the competent authorities.
