Where the CRA harmonized standards stand today
A harmonized standard gives a presumption of conformity only after its reference is published in the Official Journal, and until then a product team cannot rely on it to show Annex I compliance. The Commission's standardization request M/606 asks the European standardization organizations for 41 standards, with deliverables due between 30 August 2026 and 30 October 2027. Before you plan Annex I evidence around any of them, check the current status of each reference on the Commission's CRA standardisation page, because a standard that is delivered is not yet a standard you can cite until its reference appears in the Official Journal.
Your organization owns its conformity route. The choice between applying harmonized standards, using common specifications, relying on a European cybersecurity certificate or involving a notified body depends on product class and on how much of a standard you can apply in full. Under Article 32(2), a class I manufacturer may use internal control only where it has applied those instruments in full at the required assurance level. If it cannot, a notified body becomes part of the route. An independent auditor or notified body issues the conformity evidence, while an implementation partner can prepare the systems, technical documentation and test records that those assessors will review.
Work in two tracks. Map your product's Annex I obligations to the standards already in progress so that your evidence can move across when references are published, and confirm with your notified body or national authority which deliverables it will accept in the interim. Also check whether a standard covers your product's core functionality only. Commission guidance C(2026) 5252 states that such a standard gives no presumption of conformity for additional functions carrying risks it does not address, so any extra features need their own risk assessment and evidence.
How the M/606 deadlines run from 2026 to 2027
The M/606 sequence produces three batches of draft harmonized standards on separate deadlines, and only the later Official Journal publication of their references gives a manufacturer a presumption of conformity. Until then, each deadline is a milestone to track, not a source of legal protection.
Track the 30 August 2026 horizontal deliverable
The European standardization organizations owe the first horizontal deliverable under standardization request M/606 by 30 August 2026. It covers the risk-based design and vulnerability handling horizontal standards, which are the cross-product standards that shape how a manufacturer runs its cybersecurity risk assessment and its vulnerability process. The output at this stage is a set of delivered draft standards. Confirm the delivery status with the standardization bodies, because delivery alone does not create a presumption of conformity.
Track the 30 October 2026 product-specific deliverable
The 26 product-specific standards under M/606 are due by 30 October 2026. These vertical standards address particular product types and cover the Annex I requirements in more detail for those products. The output is a set of delivered product standards that a manufacturer can map to its own product category. Check which of the 26 standards match the product, since a standard that does not cover the product's category gives no presumption for it.
Track the 30 October 2027 Part I horizontal deliverable
The remaining horizontal standard, which covers the Annex I Part I product properties, is due by 30 October 2027. Of the 41 standards in M/606, 15 are horizontal and arrive in three deliverables across the two horizontal deadlines. Because this deliverable lands last, manufacturers relying on it need a plan for the gap between the product-level requirements and the finished standard. The output is a delivered draft that still needs to be assessed against the requirements it claims to cover.
Confirm the Official Journal publication of references
Under Article 27(1), a product or process conforms to the Annex I requirements that a harmonized standard covers only once that standard's reference is published in the Official Journal. This publication is the trigger for presumption of conformity. The output is the Official Journal notice listing each reference. Check the notice for the exact standard version and the requirements it covers, because a reference that is published with limits applies only within those limits.
Decide on common specifications if standards slip
Article 27(2) allows the Commission to adopt common specifications by implementing act only if requested harmonized standards are not accepted, not delivered on time or do not comply with the request, and no Official Journal reference is expected within a reasonable period. The output of this step is a decision point, not a deliverable. Monitor whether the Commission uses this route, and if it does, read the implementing act before relying on it, since it sets its own scope.
Document interim conformity without presumption
Until a reference is published, a manufacturer must show conformity to Annex I by its own means, including its cybersecurity risk assessment and technical documentation. A delivered draft standard can inform that work but does not shift the burden of proof. The output is a documented conformity route for each product, with the evidence that supports each Annex I requirement. Ask your assessor or notified body how they will treat drafts that are delivered but not yet cited.
Which conformity routes are open before standards are cited
Until harmonized standards are cited in the Official Journal, a manufacturer cannot rely on the Article 27(1) presumption alone. The four routes below differ in what they give the manufacturer and in what evidence the manufacturer still has to produce, so the choice should be made per product and per Annex I requirement.
Harmonized standard once cited
Once references to a harmonized standard are published in the Official Journal, products and processes conforming to that standard are presumed to meet the Annex I requirements it covers under Article 27(1). The presumption covers only the requirements the standard addresses, so check its scope line by line against your risk assessment. Confirm the publication status of each M/606 deliverable before you plan around it, because a draft or a request does not carry the presumption.
Common specifications as fallback
Under Article 27(2) the Commission may adopt common specifications by implementing act, but only when requested harmonized standards are not accepted, are late, do not comply with the request, and no Official Journal reference is expected within a reasonable period. A manufacturer cannot count on this route existing for a given product. If it is adopted, it gives the same kind of presumption, so track the implementing act and map your evidence to its clauses as soon as it appears.
EU certificate under 2019/881
Article 27(8) and (9) give a presumption of conformity for EU certificates or statements of conformity issued under schemes adopted under Regulation (EU) 2019/881 and specified by delegated act. The Commission's timeline planned that delegated act for the EUCC scheme for the fourth quarter of 2026. A certificate at assurance level at least substantial removes the need for third-party assessment for the requirements it covers, but it covers only what the certificate's scope names, so confirm that scope against your product's security functions.
Documented self-assessment
Without a standard, common specification or certificate, the manufacturer relies on its own documented evidence: a cybersecurity risk assessment, technical documentation and test records mapped to each Annex I requirement. This route carries no presumption, so the manufacturer must demonstrate conformity directly. Ask whether your product class permits module A, since Article 32(2) allows internal control for class I products only when the standards, common specifications or certification are applied in full.
Which route to plan around while standards are pending
This table compares the four routes a buyer can plan around while CRA harmonized standards are not yet cited in the Official Journal. Read each row for what the route gives, what it leaves uncovered, and when it fits, then confirm the status of each route with the Commission before committing.
| Option | What it gives | What it does not cover | When it fits |
|---|---|---|---|
| Wait for a cited harmonized standard | A presumption of conformity under Article 27(1) once the standard's references are published in the Official Journal | Any presumption before publication, and any requirement the standard does not address | Products where the relevant M/606 deliverable is already cited, or where the next release gives time to adjust |
| Plan against a common specification | A possible fallback route if the Commission adopts one by implementing act under Article 27(2) | Anything not yet adopted, since the conditions require harmonized standards to be missing, late or non-compliant | Only after an implementing act exists; confirm its adoption status on the Commission site first |
| EUCC-based certificate | A presumption of conformity under Article 27(8) and (9) for covered requirements, once a delegated act is in force | Requirements outside the certificate's scope, and any assurance level below substantial | Products where an EUCC scheme applies; the Commission planned the delegated act for Q4 2026, so confirm its status |
| In-house self-assessment with a notified body | Module A conformity by the manufacturer only when full standards, specifications or certification apply; otherwise module B with C, or module H, with a notified body | Automatic conformity where no standard is applied in full, since Article 32(2) then requires a notified body | Class I products that cannot apply a standard or certificate in full, and class II or critical products |
| Standard covering core functionality only | Presumption for the core functionality it addresses | Additional functions with risks the standard does not address, per guidance C(2026) 5252 section 6.3 | Products with add-on features; map each extra function to its own risk assessment |
Why a core-functionality standard does not cover every feature
A harmonized standard that covers only a product's core functionality gives no presumption of conformity for the additional functions the standard does not address. Commission guidance C(2026) 5252, in section 6.3, makes this explicit: where a standard's scope is the main service of a product, any extra feature carrying risks outside that scope falls back to the manufacturer's own demonstration. The practical consequence is that a standard citation cannot be treated as a blanket statement that the whole product conforms to Annex I.
Illustrative example (hypothetical): a connected device has a harmonized standard covering its main data service. Two years after launch, the manufacturer adds a remote management function that accepts firmware updates over a new network interface. The standard says nothing about that interface, so the presumption does not extend to it. The manufacturer must test and document that function against the essential requirements itself, and the gap is real work, not a paperwork footnote. Confirm the exact scope wording of each cited standard in its published text before relying on it, because scope statements vary between standards.
Start by listing every function, interface, update path and third-party integration the product exposes, then map each one against the scope statement of each standard you plan to cite. Record the result in the cybersecurity risk assessment, marking which functions are covered, partly covered or uncovered. Every uncovered or partly covered item becomes a documented obligation the manufacturer still owns, with its own test evidence, owner and date. Ask any implementation partner or testing provider to produce that mapping as a deliverable, and confirm that the gap register flows into the technical documentation.
How to work on CRA harmonized standards before they are cited
A manufacturer with an in-scope product cannot yet rely on a published harmonized standard, so the working approach is to build the Annex I evidence from its own cybersecurity risk assessment and keep it ready to map onto standards later. Presumption of conformity under Article 27(1) applies only to standards whose references are published in the Official Journal, and the Commission's standardization request M/606 sets deliverable dates that the team should track rather than assume.
- Track the M/606 deliverables: Record which horizontal and product-specific standards cover your product type, and the due dates the Commission's FAQ gives for each group.
- Watch for Official Journal references: Note the date a standard's reference is published, since only then does it presume conformity.
- Build the Annex I evidence on your own risk assessment: Document each requirement against your product's risks so the evidence can move to a cited standard without rework.
- Record functions outside any standard's scope: List additional functions and the risks a core-functionality standard does not address, and cover them with your own evidence.
- Plan the conformity route: Confirm whether applying standards in full affects whether a notified body is needed for your product class.
Check that your risk assessment and technical documentation would still stand if no standard were cited on the day you place the product on the market.
Open-source projects and small companies usually have fewer people for standards tracking, so the practical goal is a small, repeatable record of what the project does and why. Whether a project is a stewarded open-source product or a commercial product built on open code changes the duties that apply, so confirm that status before investing in any mapping work. The same principle applies: keep evidence tied to your own risk assessment, not to a standard that is still being written.
- Name the product and its role: Write down whether you are a manufacturer, an open-source steward or a contributor, because the obligations differ.
- Assign one owner for standards tracking: Give a named person the job of checking M/606 progress and Official Journal publications on a fixed review cycle.
- Keep a single risk assessment and evidence index: Record each Annex I requirement, the evidence for it and the date it was last checked, so later mapping is a lookup.
- Ask an outside reviewer about scope: If the product has security functions, confirm in writing which parts a standard would cover and which parts it would not.
- Check SME relief before paying for work: Confirm which simplifications apply to your size category, since they change the documentation you need.
Ask whether your evidence index could be handed to an assessor or notified body today without rewriting it.
Procurement and compliance leads receive supplier statements that a product conforms to the CRA, often citing a standard or a certificate. Those claims are only meaningful if the standard is published, the scheme is adopted and the claim covers the functions you are buying. Ask for specifics before accepting a general statement of compliance, and check each claim against the official sources yourself.
- Ask which standard or scheme is claimed: Require the supplier to name the harmonized standard, common specification or certification scheme and the product version it covers.
- Confirm publication status: Check whether the standard's reference is published in the Official Journal, and whether a delegated act on presumption of conformity exists for a scheme the supplier cites.
- Ask about functions outside scope: Request a list of additional functions the claim does not cover, such as features beyond the core functionality.
- Request the assessment route: Ask whether conformity was shown by self-assessment or by a notified body, and for which module.
- Keep the request in the contract: Record the claimed standard and status as a contractual representation, with a duty to notify you if the claim changes.
Check that each supplier claim names a standard, a status and a scope before you rely on it.
How EUCC certification fits into the presumption
Article 27(8) and (9) of the Cyber Resilience Act link a presumption of conformity to EU certificates or statements of conformity issued under cybersecurity certification schemes adopted under Regulation (EU) 2019/881, but only where a delegated act specifies the scheme for that purpose. Where a certificate reaches at least substantial assurance level, it removes the need for third-party assessment for the requirements it covers. For a manufacturer, the practical question is therefore not whether certification helps in principle, but whether the specific scheme, assurance level and requirements in scope have been named in a delegated act that is in force. The Commission's implementation timeline, updated 27 July 2026, planned that delegated act for the EUCC scheme in the fourth quarter of 2026. Confirm its adoption status and publication in the Official Journal before you rely on it in a conformity plan, and check the scope of the act against the Annex I requirements your product must meet.
A certificate of this kind is issued by an independent certification body, not by the manufacturer, and not by the implementation partner who helped prepare the product. The organization owns its conformity claim and the technical documentation behind it. An implementation partner can prepare the target of evaluation, the security documentation and the evidence the certification body asks for, but it cannot issue, sign or substitute for the certificate. Ask any partner to show how the certification body is accredited for the relevant scheme and how the work is split between preparation and evaluation. Budget for the evaluation itself, which the certification body prices, and for the preparation work, which you contract separately and which recurs whenever the product changes and the certificate needs maintaining.
Plan the sequence now rather than waiting for the delegated act. Identify which product components a EUCC evaluation would cover, map them to the Annex I requirements, and decide whether the certificate would be the primary route or a supporting one alongside harmonized standards or a notified body assessment. Under Article 32(2), class I manufacturers can use internal control only where they have applied in full harmonized standards, common specifications or a certification scheme at a suitable assurance level, so the choice affects the conformity route as well as the effort. Put the open questions to the certification body and the national market surveillance authority in writing, and record the answers in your technical documentation.
Where CRA harmonized standards planning goes wrong
Most teams that get CRA harmonized standards wrong do not ignore them. They misread what a draft standard does, map only part of the product, or wait for a publication that will not arrive on their schedule. The five pitfalls below connect because each one shifts evidence work away from the manufacturer's own risk assessment and tracking.
Treating a draft as a presumption
A standard that has been requested, drafted or even adopted by a European standardization organization does not give presumption of conformity on its own. Under Article 27(1), the presumption applies only to harmonized standards whose references are published in the Official Journal, and only for the Annex I requirements those standards cover. Avoid this by labeling every standard in your plan as requested, draft, or cited, and confirming status against the Official Journal before you rely on it. Owner: the product compliance lead, with sign-off from legal counsel.
Mapping only the core function
Commission guidance C(2026) 5252 (section 6.3) notes that a harmonized standard covering only a product's core functionality gives no presumption of conformity for additional functions with risks the standard does not address. Products that add remote management, update services, data sync or companion apps often carry those extra functions outside the standard's scope. Build a function inventory from the risk assessment, mark which functions a standard covers, and document the rest as separate evidence. Owner: the product security architect.
Assuming a supplier certificate covers everything
An EU certificate under a scheme adopted under Regulation (EU) 2019/881 can support presumption of conformity under Article 27(8) and (9), but only for the requirements it covers and only at the assurance level the regulation specifies. A certificate for a component, a cloud service or one hardware revision does not extend to your whole product or to later releases. Ask each supplier which requirements, versions and assurance level the certificate covers, and record the gaps. Owner: the supplier risk or procurement team, reviewed by product security.
Waiting for publication before starting
Teams sometimes hold the risk assessment and technical documentation until harmonized standards are published, which compresses work into the final months before the regulation applies. The Annex I essential requirements are applied on the basis of the manufacturer's own cybersecurity risk assessment, so that work can begin now and be mapped to standards later. Start the risk assessment, asset inventory and documentation structure now, and keep standard references as a column to fill in when they are cited. Owner: the engineering manager responsible for the product roadmap.
Missing Official Journal updates
Standardization deliverables arrive in stages, and the Commission's CRA implementation timeline, updated 27 July 2026, planned a delegated act on presumption of conformity for the EUCC scheme for the fourth quarter of 2026. A deliverable being accepted does not mean its reference is cited, so a plan written once and never revisited goes stale. Assign someone to check the Official Journal and the Commission's standardization pages at each deliverable milestone, and log each reference against the requirements it covers. Owner: the regulatory affairs or compliance monitoring lead.
Questions buyers ask about CRA harmonized standards
Does a harmonized standard give a presumption of conformity today?
No. A harmonized standard gives a presumption of conformity only once its reference is published in the Official Journal of the European Union, as Article 27 of the regulation sets out. Standardization request M/606 asks the European standardization organizations for 41 harmonized standards: 15 horizontal standards in three deliverables due 30 August 2026 or 30 October 2027, and 26 product-specific standards due 30 October 2026. A due date is not a published reference, so check the Official Journal before you cite any standard. Until a reference exists, the Annex I requirements still apply in full and you must show conformity through your own technical documentation. Guidance C(2026) 5252 also notes that a standard covering only core functionality gives no presumption for additional functions it does not address. Confirm current status with the Commission and the standardization bodies.
What happens if a harmonized standard is delivered late?
Your obligations do not pause, and the presumption simply does not exist yet. Under Article 27(2), the Commission may adopt common specifications by implementing act only when requested standards are not accepted, are not delivered on time, or do not comply with the request, and no Official Journal reference is expected within a reasonable period. Those conditions are strict, and the sources do not give an adoption date. In the meantime you can design to the Annex I requirements with other documented technical solutions, but then you must demonstrate conformity yourself. Depending on your product's class, that route can also require a notified body under Article 32. Build a current cybersecurity risk assessment, record why each chosen solution meets each essential requirement, and track the standardisation page on the Commission's website for changes.
Would common specifications replace harmonized standards?
Only in a limited case. Common specifications are a fallback the Commission can adopt by implementing act under Article 27(2), and they are meant to cover gaps when standards fail, not to become the normal route. The trigger conditions are that requested standards are rejected, late, or non-compliant with the request, and that no Official Journal reference is expected within a reasonable period. If the Commission adopts one, its implementing act would set out which Annex I requirements it covers, and your task would be to map your product's design and evidence to those specifications. Because no adoption is scheduled in the sources, keep your mapping in a form that can move from one reference to another. Confirm the status of any draft implementing act with the Commission before you change your plan.
Does EUCC certification remove the notified body need for class I products?
Not automatically, and only in part. Under Article 27(8) and (9), a certificate or statement of conformity under a scheme adopted under Regulation (EU) 2019/881 and specified by delegated act gives a presumption of conformity, and a certificate at assurance level at least substantial removes the need for third-party assessment for the requirements it covers. The Commission's implementation timeline, updated 27 July 2026, planned a delegated act on presumption of conformity for the EUCC scheme for the fourth quarter of 2026, so confirm whether it has been adopted. Under Article 32, a class I important product can use internal control under module A only where the manufacturer has applied in full the standards, common specifications or substantial-level certification. Where coverage is partial, a notified body under module B with module C, or module H, still applies. Check the certified scope against your product's configuration.
What does the internal team need to do now for CRA standards?
Your own engineering, product security and compliance staff own the work, because the manufacturer owns conformity. The core tasks are confirming the product's class against Annexes III and IV, keeping a current cybersecurity risk assessment, tracking the M/606 deliverables and Official Journal references, and mapping each Annex I requirement to the clauses of the standards you intend to apply. The team also maintains technical documentation and names an owner for each vulnerability handling requirement. Recurring work includes re-checking mappings when standards are published, updating evidence after substantial modifications, and keeping records current across the support period. The sources give no effort figure, so estimate the effort from your product's size, release cadence and number of product variants, and ask any partner to show its estimate in a written scope before work starts.
Can an implementation partner prepare CRA evidence without issuing a conformity statement?
Yes. An implementation partner can prepare systems, controls, test records and documentation so the manufacturer can show conformity. It cannot issue the EU declaration of conformity, which the manufacturer draws up, or any certificate or report, which only an independent body issues. Where Article 32 requires a notified body, that body performs the assessment and issues the certificate. DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, runs security testing, and prepares evidence for compliance assessments. It does not issue audit reports, attestations or certifications. Most engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts. Ask any partner to list which artifacts it prepares, which the manufacturer approves, and which an independent body issues.
How DeployOpen prepares CRA evidence ahead of standards
DeployOpen helps manufacturers prepare the systems, controls and documentation they will need to show conformity with the CRA while harmonized standards are still being finalized. We work inside your own infrastructure and keep the written scope tied to the Annex I requirements that matter for your product.
How we scope
- Map which Annex I requirements your product must meet and which harmonized standards, if any, are expected to cover them
- Identify the parts of the product that a core-functionality standard would not address, such as additional functions
- Confirm with your notified body or auditor which evidence they will accept before any work starts
- Agree deliverables, timelines and responsibilities in writing, since most engagements are fixed-scope
How we build
- Prepare the technical documentation and evidence trail so it can be updated when a referenced standard is published
- Configure self-hosted open-source platforms in your own cloud, data center or air-gapped network with recorded settings
- Run security testing against the requirements in scope and record results with remediation status
- Track the Official Journal status of each standard so the mapping of controls can be revised when references change
How we hand over
- Deliver the scoped documentation, configuration baselines, test reports and evidence index in formats your team keeps
- Document which controls rely on a standard and which rely on your own risk assessment, so gaps are visible
- Transfer runbooks and ownership so your staff can operate the controls without DeployOpen present
- Note that only an independent auditor, assessor or notified body issues conformity findings or certificates
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover
- Retainers can cover revisions when Commission guidance, implementing acts or harmonized standard references change
- Ask any provider to confirm in writing which CRA dates and standard references their scope assumes
- Re-review the evidence set after any substantial modification of the product
Sources and further reading
- Cyber Resilience Act standardisation, Shaping Europe's digital future ↗
- Regulation (EU) 2024/2847, Article 27 (EUR-Lex) ↗
- Commission FAQs on the Cyber Resilience Act, version 1.4 ↗
- Commission guidance on the application of Regulation (EU) 2024/2847, Annex to C(2026) 5252 ↗
- Cyber Resilience Act implementation, Shaping Europe's digital future ↗
- Regulation (EU) 2024/2847 (Cyber Resilience Act), EUR-Lex ↗
