CRA Harmonised Standards in 2026: What Manufacturers Should Track

CRA harmonised standards are intended to turn the Cyber Resilience Act's broad essential cybersecurity requirements into technical specifications that manufacturers can apply and assess. In 2026, however, the most important practical point is that standards development, European Standard adoption, and legal presumption of conformity are different stages. A manufacturer should therefore track not only whether a draft exists, but also what it covers, whether it applies to the product, and whether its reference has been published in the Official Journal of the European Union.

That distinction matters now because the M/606 standardisation programme is approaching several major delivery milestones. Some work items are already in advanced approval stages, while other horizontal requirements are scheduled much later. The useful preparation task is not to wait for a final catalogue. It is to build a standards register that can absorb new references without losing the product, requirement and release evidence already created.

What makes a CRA standard "harmonised"?

Article 27(1) of Regulation (EU) 2024/2847 gives the legal rule. A product with digital elements, and the processes put in place by its manufacturer, are presumed to conform with the essential cybersecurity requirements covered by a harmonised standard when they conform with that standard or the relevant parts and the standard's reference has been published in the Official Journal of the European Union (OJEU).

The sequence is therefore important:

1. A European Standardisation Organisation develops a draft in response to a standardisation request or other work programme.
2. The draft goes through the relevant enquiry, voting and adoption process.
3. The adopted European Standard may be proposed to the European Commission for OJEU citation.
4. The Commission assesses it under the European standardisation framework.
5. Once its reference is published in the OJEU, the cited standard can provide a presumption of conformity for the CRA requirements that the citation covers.

A draft can be technically useful before that final step. An adopted European Standard can also be a strong engineering reference. But neither status should be described as an OJEU-backed CRA presumption of conformity until the reference has actually been published.

This is also why a manufacturer's standards register should record legal status separately from technical version. "We use draft X" and "we rely on harmonised standard X for presumption of conformity" are materially different statements and need different evidence.

What M/606 is asking the standards organisations to deliver

The European Commission adopted standardisation request M/606 on 3 February 2025. The Commission's current CRA standardisation page describes a programme of 41 requested standards covering both horizontal and product-specific work. The 2026 ICT Standardisation Rolling Plan describes the work as 41 standardisation deliverables and confirms that CEN, CENELEC and ETSI accepted the request.

The programme can be understood in three practical layers.

Horizontal framework and vulnerability handling

The earliest M/606 deadlines cover a horizontal cyber-resilience framework and vulnerability handling. The Commission's 2026 Rolling Plan gives 30 August 2026 as the expected date for the first deliverables in these areas.

These are significant because they address processes that can apply across many product categories. Manufacturers should expect them to influence how product risk, secure development and vulnerability-handling evidence are structured, even where a more specific vertical standard is also relevant.

Product-specific standards for important and critical products

M/606 also requests product-specific work for the important and critical product categories in CRA Annexes III and IV. The Commission's 2026 Rolling Plan identifies 30 October 2026 as the target for these product-specific deliverables.

This work is already visible. On 13 August 2026, ETSI announced that 17 vertical final draft standards developed for the CRA had entered Public Enquiry. ETSI's live M/606 work programme shows individual work items moving through approval with their own schedules.

That is useful progress, but manufacturers should keep the status language precise. A final draft in Public Enquiry is not yet the same as an adopted harmonised standard whose reference has been published in the OJEU. Individual approval timetables may also extend beyond a headline programme target, so planning should use the current work-item status rather than assuming every deliverable will become legally usable on one date.

Broader product-agnostic essential-requirement standards

The remaining product-agnostic standards covering the CRA Annex I Part I essential cybersecurity requirements have a later target. The Commission's Rolling Plan gives 30 October 2027 for this broader set.

This timing matters for manufacturers preparing before the CRA becomes fully applicable on 11 December 2027. Some useful standards will mature substantially earlier than others. A readiness programme therefore needs to work with a changing standards baseline rather than expecting one complete package to arrive at once.

The four statuses manufacturers should track separately

A simple "standard available: yes/no" field is not enough. For every potentially relevant CRA standard, track at least four statuses.

1. Work item or draft exists

This is an engineering signal. It can help teams anticipate terminology, controls, assessment methods and evidence expectations. Draft content can still change, so decisions based on it should record the exact version and date reviewed.

2. European Standard adopted

Adoption means the standard has completed the standards organisation's formal process. This makes it a much stronger technical baseline, but manufacturers should still verify whether CRA harmonisation and OJEU citation have occurred.

3. Reference published in the OJEU

This is the critical legal status for Article 27(1). Record the OJEU reference date, the cited standard version and any limitations or parts specified in the citation.

4. Applicable requirements actually covered

Even an OJEU-cited standard does not create a blanket presumption of conformity for every CRA obligation. Article 27 limits the presumption to the essential cybersecurity requirements covered by the relevant standard or parts of it.

A product team therefore needs a coverage map: which CRA requirement is addressed by which standard clause, which implementation satisfies that clause, and which retained evidence demonstrates the implementation for the exact product and release.

Why availability of standards can affect the conformity-assessment route

Harmonised standards are generally a voluntary means of demonstrating conformity, but their availability can affect the practical conformity-assessment path for certain CRA product classes.

For an important Class I product, Article 32(2) allows the manufacturer to rely on internal control only when the applicable harmonised standards, common specifications or qualifying European cybersecurity certification scheme are fully applied for the relevant essential cybersecurity requirements. If those references are not applied, are applied only partly, or are not available, the CRA requires one of the third-party conformity-assessment routes specified in Article 32(2).

That makes standards tracking more than a documentation exercise for Class I products. A release plan can depend on whether a sufficiently covering harmonised route is actually available and applicable at the time conformity assessment is performed.

For other product categories, the conformity-assessment rules differ, so manufacturers should assess the product classification and Article 32 route separately rather than generalising the Class I rule across the portfolio.

What to put in a CRA standards register

A useful standards register should be detailed enough to support engineering, conformity assessment and later audit reconstruction. For each standard or work item, retain:

• the standardisation request topic or work-item identifier;
• the responsible European Standardisation Organisation and technical committee;
• the draft or adopted standard number and exact version;
• the current stage, such as drafting, Public Enquiry, approval or adoption;
• the product category or technology scope;
• the CRA Annex I requirements the standard is intended to cover;
• the date the organisation last reviewed the status;
• whether an OJEU reference exists;
• the OJEU publication reference and date when available;
• any stated limitations on the presumption of conformity;
• the internal owner responsible for tracking changes;
• the affected product, variant and release scope;
• the implementation controls mapped to the standard;
• the security evidence used to demonstrate those controls; and
• the decision on whether the standard is used for engineering guidance, conformity assessment, presumption of conformity, or more than one of these purposes.

This prevents a common ambiguity: a standards list may show that the organisation "uses" a document without showing what legal or technical role that document actually played.

Build evidence before the standards are final

Manufacturers do not need to postpone product-security work until every M/606 deliverable is complete. The CRA's legal requirements already define the outcomes that products and manufacturer processes must satisfy, and current authoritative guidance can be used to structure readiness work.

The durable evidence is usually not a claim that a particular draft was followed. It is the underlying product-security record:

• cybersecurity risk assessment and threat analysis;
• security requirements and architecture decisions;
• secure-default decisions;
• verification and security-test results;
• SBOM and component context;
• vulnerability intake, assessment and remediation records;
• update and patch evidence;
• support-period assumptions and decisions;
• release approvals and unresolved blockers; and
• technical documentation showing why the product was considered to meet the applicable requirements.

When a harmonised standard becomes available, that evidence can then be mapped to the standard's clauses. If the standard changes before adoption or citation, the team can perform a gap analysis instead of recreating the whole compliance record from scratch.

Freeze the standards baseline for each release decision

A live standards register should evolve, but release evidence should remain historically reproducible.

For every conformity or release decision, record the standards baseline used at that point in time. That includes the exact document version, status, OJEU citation state and the mapping to product evidence. If a newer edition or newly cited harmonised standard appears later, do not silently rewrite the earlier decision record.

Instead, create a new assessment that answers three questions:

1. Does the new or revised standard apply to this product and release?
2. Does it introduce or clarify requirements that change the existing implementation or evidence mapping?
3. Does the change affect the chosen conformity-assessment route or only the evidence used to support it?

This approach is particularly important during 2026 and 2027, when the CRA standards landscape is moving from work items and drafts toward adopted and potentially OJEU-cited references.

Do not treat the M/606 deadline as the OJEU citation date

Programme deadlines are useful planning signals, but they are not automatically the date on which manufacturers obtain presumption of conformity.

The M/606 timetable concerns delivery and adoption work by the European Standardisation Organisations. Article 27 separately requires publication of the harmonised standard's reference in the OJEU before the CRA presumption of conformity applies.

A safe implementation rule is therefore:

• use M/606 dates to plan monitoring and engineering readiness;
• use the standards organisations' live work programmes to track drafting and approval status;
• use the OJEU as the authoritative source for whether a harmonised reference has legal effect under Article 27; and
• keep the applicable requirement coverage explicit rather than assuming a cited standard covers the entire CRA.

As of 22 August 2026, the Commission states that the first CRA standardisation deliverables are expected in Q3 2026, and ETSI has 17 vertical final drafts in Public Enquiry. Those developments show that the standards programme is advancing, but manufacturers should verify the current OJEU position at the time they rely on a standard for presumption of conformity.

A practical review cadence for 2026

During a fast-moving standardisation phase, a lightweight recurring review is more reliable than ad hoc checking before a release.

A practical cycle is:

1. Review official status sources regularly. Check the European Commission CRA standardisation page, the relevant CEN-CENELEC or ETSI work programme, and the OJEU.
2. Identify changes since the previous review. Record new drafts, stage changes, adopted standards and new OJEU citations.
3. Assess product relevance. Do not send every standards update to every product team. Route it to the owners of affected product categories and technologies.
4. Update requirement mappings. Where a standard changes the technical interpretation or assessment method, map the change to existing requirements and evidence.
5. Record the decision. Keep the date, reviewer, affected products, action required and rationale.
6. Escalate conformity-route impacts. If a change affects whether internal control or third-party assessment can be used, treat it as a release-planning issue rather than a documentation clean-up task.

This creates a traceable standards-change process without turning standards monitoring into a separate compliance project disconnected from engineering.

As standards move from drafts to OJEU-cited references, teams need to know which evidence package was built against which requirement interpretation and product release. AA-sec is designed around traceability between requirements, evidence, assessments and exact product or lifecycle context, which can help keep that mapping explicit as the standards baseline changes. AA-sec does not determine which harmonised standard applies or whether CRA conformity has been achieved.

Key takeaway

The central CRA standards question in 2026 is not simply "which standards exist?" It is which standard applies to this product, what stage is it in, which CRA requirements does it cover, and what legal effect does it have today?

M/606 gives manufacturers a clear standardisation programme, and major deliverables are approaching. But presumption of conformity depends on OJEU citation and the scope actually covered by the cited standard. Manufacturers that maintain a versioned standards register, map standards to requirements and product evidence, and freeze the standards baseline used for each release will be better positioned to absorb the 2026–2027 standardisation changes without losing traceability.

Official sources

• Regulation (EU) 2024/2847 — Cyber Resilience Act — EUR-Lex
• Cyber Resilience Act - Standardisation — European Commission
• Cybersecurity / network and information security (RP 2026) — European Commission
• Cyber Resilience Act: Standardization Request Officially Accepted by CEN, CENELEC, and ETSI — CEN-CENELEC
• ETSI launches approval process for 17 European Standards supporting the Cyber Resilience Act — ETSI
• ETSI M/606 active work items — ETSI