What Article 27 presumption of conformity means for your CRA evidence
A presumption of conformity lets a manufacturer treat a product as meeting the Annex I requirements that a recognized standard covers, but only if the standard is actually in place. You remain responsible for showing Annex I conformity, and for most products that means preparing evidence yourself under the self-assessment route. Article 27 gives three ways to obtain a presumption: harmonized standards whose references are published in the Official Journal (Article 27(1)), Commission common specifications adopted by implementing act when standards fail or are late (Article 27(2)), and EU cybersecurity certificates or statements of conformity under schemes adopted under Regulation (EU) 2019/881 and specified by delegated act (Article 27(8) and (9)). The simplest path is a standard you can cite, and the regulation's text is the place to confirm the exact wording of each route in the regulation on EUR-Lex.
The presumption is narrow. It covers only the Annex I requirements that a given standard addresses, and only for the product and functions the standard describes. Commission guidance C(2026) 5252 notes that a harmonized standard covering a product's core functionality gives no presumption for additional functions carrying risks the standard does not address. A connected device may therefore be covered for its update mechanism but not for a companion feature added later. Map each standard reference in your technical file against the specific functions it covers, and record every requirement left without a presumption as an item needing your own evidence.
Which products and functions a presumption of conformity covers
A presumption of conformity only reaches the requirements a cited standard actually covers, for the product it was written for. The cards below set out the scoping decisions that decide how much of the Annex I work a harmonized standard can carry, and how much the manufacturer must still evidence itself.
Core functionality coverage
Start by mapping the harmonized standard's scope against the product's core functionality. Commission guidance on the regulation notes that a standard covering only core functionality gives no presumption of conformity for additional functions with risks the standard does not address. Record each function, the standard clause that covers it, and any function with no matching clause.
Additional functions outside the standard
Features added beyond the core, such as remote management, telemetry, plug-in interfaces or bundled cloud services, can carry risks the standard never assessed. For each one, the manufacturer needs its own risk assessment and its own evidence against the relevant Annex I requirements. Expect this part of the technical file to be where assessors look first.
Default, important or critical category
The product's category sets the conformity route. A default product can rely on internal control where a presumption applies, while important class I products, important class II products and critical products may need a notified body when standards are not applied in full. Confirm the category against the Annex III and Annex IV descriptions before deciding how much the presumption can carry.
Full application of the standard
A presumption applies only where the manufacturer applies the cited standard in full. Partial use, such as adopting some clauses while adapting others, removes the presumption for the affected requirements. Document each clause applied, each clause deliberately departed from, and the reasoning, so the position holds under review.
Standard versions and references
A presumption attaches to standards whose references are published in the Official Journal. Check which version is cited, the date of publication and any restrictions noted, because a standard that is later withdrawn or revised changes the evidence you need. Keep a dated record of the version you relied on for each product release.
Third-party component evidence
Open-source libraries and third-party components inside a product are covered only where the standard addresses them. Where the standard is silent, the manufacturer must show how each component was assessed for vulnerabilities and supported over the support period. Ask suppliers for evidence of their own handling, and record the gaps you carry yourself.
How an assessor checks a claimed presumption of conformity
This table walks through the checks an assessor or notified body runs when a manufacturer claims a presumption of conformity under Article 27. Read each row as one test step, what the assessor expects to see, and where claims most often fail.
| Check | What the assessor confirms | Evidence requested | Common finding |
|---|---|---|---|
| Standard reference | The cited harmonized standard has its reference published in the Official Journal and applies to the product's version and Annex I requirements | Official Journal reference, standard version and date, mapping of standard clauses to Annex I points | Standard cited before its reference is published, or an older version cited after replacement |
| Full application | The standard was applied in full to every requirement it covers, not in selected clauses only | Clause-by-clause traceability matrix, design and test records tied to each covered requirement | Partial application presented as full coverage, with clauses skipped without rationale |
| Scope of coverage | The standard's scope matches the product's core functionality and the product configurations the claim covers | Product description, scope statement, list of configurations and variants covered | Standard covers the core functions but the claim extends to features it does not address |
| Gap review for uncovered functions | Additional functions, integrations and risks outside the standard are assessed separately and do not inherit the presumption | Gap analysis, separate risk assessment for uncovered functions, evidence of tests for those functions | No gap analysis, or uncovered functions silently included in the presumption claim |
| Risk assessment alignment | The manufacturer's cybersecurity risk assessment supports the choice of standard and identifies residual risks | Signed risk assessment, risk register, documented reasons for relying on the standard | Risk assessment written after the standard was chosen, with no link to the standard's requirements |
| Test and conformity records | Testing performed against the standard's requirements is complete, dated and reproducible for the released version | Test plans, test reports, pass or fail records, version identifiers of tested builds | Test reports that do not identify the tested version or cover only part of the requirements |
| Alternative routes | Where no standard, common specification or certification scheme applies, the manufacturer uses a route that meets Annex I on its own | Documented route selection, evidence of conformity for each Annex I requirement without presumption | Presumption claimed for a requirement that no applicable standard actually covers |
| Records availability | Records are complete enough for the assessor to re-perform sample checks without the manufacturer's staff explaining gaps | Indexed technical documentation, retained test records, change history for the claimed version | Records scattered across tools, missing for earlier releases, or unavailable when requested |
How to build a presumption-based compliance file step by step
The sequence below takes a manufacturer from checking which harmonized standards are cited to a technical file that shows, requirement by requirement, how the product meets Annex I. Each step names the output so the team can plan who does the work and what must be on file.
Confirm which standards are cited in the Official Journal
Check the Official Journal for the references of harmonized standards that cover your product type, and check the Commission's standardization pages for the status of standards under request M/606. Only standards whose references are published give a presumption under Article 27(1), so a draft or a delivered but uncited standard cannot be relied on yet. Record the standard title, the reference, the date of publication and the Annex I requirements it covers. The output is a standards register that the product owner and the compliance lead both sign off. Confirm the current status directly with the standards bodies and the Commission before you rely on it, because the list changes as deliverables are published.
Check whether the standard covers your full product
Compare the scope of each cited standard with the complete product, including its additional functions, connected services and update mechanism. Commission guidance C(2026) 5252 (section 6.3) notes that a standard covering only the core functionality gives no presumption for additional functions with risks the standard does not address. Mark each function as covered, partly covered or not covered. The output is a scope matrix that the engineering lead reviews and the risk owner accepts, with any uncovered function flagged for direct evidence in the next steps.
Map each Annex I requirement to a clause or to your own evidence
Build a traceability table with one row for each Annex I Part I requirement and each Part II vulnerability handling requirement. For every row, cite the standard clause that addresses it, or name the internal control, test report or design document that provides the evidence instead. Keep the clause references and the internal evidence in separate columns so an assessor can see which parts depend on presumption. The output is the traceability matrix, owned by the product security team and reviewed by quality management. A row is complete only when it has a cited clause or a named evidence artifact.
Document the gaps and the uncovered risks
List every requirement, function or risk that no cited standard covers, and every case where a standard exists but is not yet published in the Official Journal. For each gap, record the risk, the planned evidence and the owner, and note whether the gap affects the conformity route. This is the step where a risk assessment result feeds the file, because the manufacturer must justify the requirements it applies on the basis of its own cybersecurity risk assessment. The output is a gap register signed by the risk owner. Ask any implementation partner to show how each gap was closed or accepted, not just that it was logged.
Decide the conformity assessment route
Determine the route from the product's classification under the regulation's annexes and from whether the standards were applied in full. Most products follow module A self-assessment, while class I important products without full application, class II and critical products need a notified body, according to the Commission's FAQ on the regulation. If you use a European cybersecurity certification scheme, check whether a delegated act on presumption of conformity is in force for it, since the Commission's timeline planned that act for the fourth quarter of 2026. The output is a written route decision with the legal basis cited, approved by legal and the accountable executive.
Build the technical file sections that carry the presumption
Draft the parts of the Annex VII technical documentation that show which standards were applied, which versions, how each clause was met and where the gaps were closed. Include the product description, architecture, vulnerability handling records, the SBOM, the support period basis, test reports and the declaration of conformity inputs. The output is a versioned technical file with a change log tied to product releases. Ask the team to confirm that every standard citation points to the exact version relied on, since a later edition may not carry the same presumption.
Verify the file and keep it current
Have someone who did not write the file test the traceability matrix against the actual product, including samples of the evidence and the cited clauses. Repeat the check when a standard is newly cited, revised or withdrawn, and when the product changes substantially. Record the review date, reviewer and any corrections. The output is a verification record and a maintenance schedule kept with the technical file. The cost of this step recurs, so ask any partner or auditor to quote verification and re-verification separately.
Where the CRA standards program stands today
Standardization request M/606 is the Commission's instruction to the European standardization organizations to produce 41 harmonized standards for the Cyber Resilience Act. Fifteen are horizontal standards grouped in three deliverables, and 26 are product-specific (vertical) standards. The horizontal standards on risk-based design and vulnerability handling were due 30 August 2026, the horizontal standard for Annex I Part I is due 30 October 2027, and the 26 vertical standards are due 30 October 2026. A due date is a target for the standards bodies. It does not give a manufacturer any presumption of conformity. Under Article 27(1), that presumption arises only when a standard's reference is published in the Official Journal, so the deadline and the publication are two separate checkpoints.
Before relying on any standard, check the Official Journal for its reference and the Annex I requirements it covers. Build a register that lists each standard, its Official Journal reference, the Annex I points it addresses and whether it covers the whole product or only part of it. Commission guidance C(2026) 5252 (section 6.3) states 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 with extra features, such as remote management or update services, therefore need a second look at each standard's scope. The Commission's standardisation page is the natural starting point for tracking progress, but the Official Journal remains the authoritative source.
The European cybersecurity certification route works differently. Under Article 27(8) and (9), certificates or statements of conformity issued under schemes adopted under Regulation (EU) 2019/881 can give a presumption of conformity, but only once a delegated act specifies the scheme for this purpose. The Commission's implementation timeline, updated 27 July 2026, planned a delegated act on presumption of conformity for the EUCC scheme in the fourth quarter of 2026. A plan is not an adopted act. Confirm whether the delegated act has been adopted, which requirements it covers and whether your product's assurance level is at least substantial, since that level removes the need for third-party assessment for the requirements it covers. If a standard slips, Article 27(2) allows common specifications only under strict conditions, so plan the conformity route with a fallback in mind.
Evidence that supports each of the three presumption routes
Article 27 gives three routes to a presumption of conformity: harmonized standards cited in the Official Journal, common specifications and EU cybersecurity certification. Each route produces different evidence, and a gap register records what none of them covers. The evidence set should be kept under version control so that each link to Annex I can be traced to the exact standard or certificate relied on.
Official Journal reference and version
Record the exact harmonized standard, its edition and the Official Journal reference under which it was cited, along with the date of citation. A presumption under Article 27(1) attaches to the standard as published in the Official Journal, so a newer edition does not carry the presumption until it is cited. Store the reference alongside the technical file and check the Official Journal entry each time the product is reassessed. Ask your implementation partner and auditor to confirm which version they reviewed.
Clause-by-clause mapping to Annex I
Build a table that maps each clause of the harmonized standard to the Annex I requirement it covers, identifying the product feature and test evidence that satisfies it. The presumption only extends to the requirements the standard covers, so a mapping that stops at a general statement will not support a claim. Review the mapping whenever the standard is revised or a new edition is cited, and mark any clause that changed meaning.
EUCC certificate or statement of conformity
Where a product relies on an EU cybersecurity certificate or statement of conformity under Regulation (EU) 2019/881, keep the certificate, its assurance level and the scope statement that defines the evaluated product and version. Under Article 27, a certificate at assurance level at least substantial removes the need for third-party assessment for the requirements it covers. Confirm the scope matches the shipped configuration, and check whether the delegated act naming the scheme has been adopted before relying on it.
Gap register for uncovered functions
List every function, feature or risk that the chosen standard or certificate does not address, with the Annex I requirement it touches and the assessment route you will use instead. Commission guidance notes that a standard covering only core functionality gives no presumption for additional functions with risks it does not address. Assign an owner and a review date to each entry, and update the register when product features change or new standards are cited.
Version control and revision tracking
Keep the Official Journal references, mapping tables, certificates and gap register in one repository with dated change records. When a standard is revised, compare the new edition clause by clause against the mapping, decide whether the presumption transfers, and record the decision before the product is placed on the market or substantially modified. Ask your auditor which change records they expect to see, and confirm how your notified body or market surveillance authority accesses them.
What a presumption-based approach costs in money and effort
Presumption of conformity under Article 27(1) only works once a harmonized standard has its reference published in the Official Journal, and the standards themselves are developed by the European standardization organizations. Whether a manufacturer pays to obtain the text of a standard depends on the publisher's terms at the time of purchase, so the cost is a line item to confirm rather than a fixed figure. Access is generally a one-time purchase per standard, with licensing terms that may cover internal use only.
- Purchase of standard texts: Confirm with the standards body whether each referenced standard is sold individually, by subscription, or made available free of charge.
- Licence scope: Check whether a licence allows copies for internal engineering teams, contractors and notified bodies.
- Version tracking: Budget for re-purchase when a revised edition replaces a cited one.
- Cited versus draft: Only standards whose references are published in the Official Journal give the presumption, so draft texts do not justify spending on a route you cannot yet use.
- Who pays: The manufacturer pays for its own copies. An implementation partner usually bills for the time spent reading and applying them, not for the standards themselves.
Before buying anything, ask the partner or your own team to list which cited standards apply to each product and confirm the current licensing terms in writing.
Most of the spend in a presumption-based approach is internal effort: reading each cited standard, mapping its clauses to the Annex I requirements, and collecting the evidence that shows each clause is met. This is a one-time effort for each product family, followed by smaller updates as the product changes. The amount depends on how many distinct products the manufacturer ships and how much of each product's code, configuration and documentation has to be traced.
- Clause mapping: Engineers and compliance staff map each standard clause to the Annex I points and to the technical documentation.
- Evidence capture: Test reports, build logs, software bill of materials outputs and configuration baselines must be generated and kept.
- Tooling setup: Open-source tools can generate some evidence, but integrating them into build pipelines is project work.
- Product variants: Each variant that uses a different set of components may need its own mapping.
- Internal roles: Product security, engineering, legal and documentation staff are the usual owners.
Ask any partner to estimate effort per product family in a written scope, and state which tasks the manufacturer will perform internally.
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. Those uncovered functions must be assessed directly against Annex I, which usually means more risk analysis, custom testing and documentation. This is where cost often grows fastest, because the work is specific to the product rather than reusable across a product family.
- Gap identification: Compare each product function with the scope of the standards cited for it.
- Risk assessment: Document why uncovered functions create risks and how they are addressed.
- Targeted testing: Penetration tests or code reviews may be needed for functions outside a standard.
- Scope creep: Each added feature can move a function outside the presumption.
- Outside help: Security testing providers and implementation partners are commonly engaged here.
Ask for the list of functions the quote treats as uncovered and the testing effort assigned to each one.
Article 27(8) and (9) give a presumption of conformity for certificates or statements of conformity under certification schemes adopted under Regulation (EU) 2019/881 and specified by delegated act. The Commission's implementation timeline, updated 27 July 2026, planned a delegated act on presumption for the EUCC scheme for the fourth quarter of 2026. No certificate fee has been supplied for this route, so the cost must come from the certification body and the evaluation laboratory.
- Certification body fees: Quotes come from the certification body, which may charge for evaluation, certification and surveillance.
- Evaluation effort: The evaluation scope and assurance level drive the work and therefore the fee.
- Preparation work: The manufacturer or its partner prepares documentation and test support before evaluation.
- Timing risk: Confirm the delegated act's status before committing budget to this route.
- Recurring surveillance: Ask whether a certificate requires periodic maintenance or re-evaluation.
Request a written quote from an accredited certification body that states the assurance level, scope, fees and surveillance terms.
Presumption depends on the standards in force, so cost recurs whenever a cited standard is revised, withdrawn or replaced. Standardization request M/606 covers 41 standards, with horizontal deliverables due 30 August 2026 or 30 October 2027 and product-specific standards due 30 October 2026, so the set of cited references will change over time. Manufacturers should budget for periodic re-mapping and evidence refresh, and confirm which edition each product is assessed against.
- Edition changes: A new standard edition may change clause numbers and requirements.
- Re-mapping: Mapping work must be repeated for affected products.
- Evidence refresh: Test reports and documentation need updating after material changes.
- Support period: The product's support period adds a long tail of recurring monitoring work.
- Tooling upkeep: Open-source compliance tooling needs version updates and configuration changes.
Ask any partner to describe how it tracks standard revisions and what triggers a re-mapping, and to price that work separately from initial implementation.
Where manufacturers claim a presumption they cannot support
A presumption of conformity under Article 27 only holds for the requirements a published standard, common specification or certificate actually covers, and only in the version that was cited. The four gaps below are the most common ways manufacturers overstate what they have achieved, and each one can be closed with a documented check before the EU declaration of conformity is signed.
Citing a standard not yet in the Official Journal
Article 27(1) only gives a presumption for harmonized standards whose references are published in the Official Journal. Many standards under standardization request M/606 are still in development, so a draft, a working document or a standard listed as expected does not confer a presumption. Check the Official Journal reference list on the date you place the product on the market, and record the reference number in the technical file. Until a reference is published, the manufacturer must demonstrate conformity directly against Annex I.
Applying a core-function standard to extra functions
Commission guidance C(2026) 5252 (section 6.3) states that a harmonized standard covering only the core functionality of a product gives no presumption for additional functions carrying risks the standard does not address. A router whose standard covers its networking stack gives no presumption for a bundled cloud management console or an update agent. Map each function and interface in the risk assessment to the standard clauses that address it, and document the gaps that need separate evidence.
Presenting partial application as full
A presumption applies to the requirements a standard covers, not to the product as a whole. Teams sometimes list a standard as applied in the EU declaration and technical file when only some clauses were followed, tested or evidenced. Create a clause-by-clause applicability table that marks each clause as applied, partly applied or not applied, with the test report that supports each entry. Any partly applied clause should be described as such, and the remaining requirements should be backed by direct evidence.
No record of the standard version used
A presumption attaches to a specific published reference, and a later version may be cited with different content or may be withdrawn. A technical file that names a standard without its edition, date and Official Journal reference cannot show what was relied on when the product was placed on the market. Record the exact edition and reference in the technical file, keep the copy used for the assessment, and review the reference list at each substantial modification or update so that the claim stays accurate over the support period.
Who owns the presumption claim and who prepares the evidence
The manufacturer keeps legal responsibility for the product. Only the manufacturer can decide which harmonized standards, common specifications or certification schemes it relies on, and only the manufacturer can sign the EU declaration of conformity and place the CE marking. A presumption under Article 27 attaches to the product and process the manufacturer actually ships, so the claim is only as good as the manufacturer's own control of scope and configuration.
- Standards selection: Decide which published harmonized standards cover each Annex I requirement, and record where a standard covers only core functionality.
- Scope ownership: Define the product boundary, including additional functions the chosen standard may not address.
- Risk assessment: Own the cybersecurity risk assessment that the requirements are applied against.
- Declaration and marking: Sign the declaration of conformity and affix the CE marking on the basis of the evidence.
- Ongoing control: Keep the claim valid through updates, substantial modifications and the support period.
Before relying on any presumption, check the Official Journal reference for each standard and confirm with your notified body how it treats the standard for your product class.
An implementation partner can prepare the material that lets the manufacturer's team make and defend the claim. The partner does not decide conformity and does not put its name on the declaration. Its work is preparatory: mapping, gap analysis, configuration evidence and the operational records that show the controls run. DeployOpen works in this role where the platform is self-hosted in the client's own infrastructure, and the scope of any such work is set out in writing before it starts.
- Requirement mapping: Map each relevant Annex I requirement to the standard clause or control the manufacturer intends to rely on.
- Gap analysis: Identify where the product, the build pipeline or the support process falls short of the chosen standard.
- Evidence preparation: Gather configuration baselines, test results, logs and build records in a form the notified body can review.
- Remediation support: Harden, document and fix the gaps the analysis finds, within the agreed scope.
- Technical file input: Provide material for the technical documentation that the manufacturer adopts and owns.
Ask any partner to state in writing which outputs it delivers and confirm that it will not issue reports, attestations or certificates.
Where the regulation requires third-party assessment, or where the manufacturer chooses it, an independent notified body or certification body reviews the product and the evidence and issues the conformity findings or certificates. Its independence is the reason its output carries weight, so it cannot be the manufacturer's consultant or implementation partner for the same product. Notified bodies are notified by Member States and listed in the Commission's NANDO system.
- Route confirmation: Confirm whether the product falls under self-assessment or needs a notified body, based on its class.
- Independent review: Test whether the claimed standards are applied in full and whether the evidence supports them.
- Certificates and findings: Issue the certificate or conformity finding that its accreditation allows.
- Certification scheme route: Where an EU cybersecurity certification scheme gives a presumption, confirm the assurance level and scope of the certificate.
- Independence checks: Confirm that the body has no conflict with the partner that prepared the evidence.
Before engaging a body, check its notification status in NANDO and ask which Annex I requirements its assessment covers.
Questions buyers ask about presumption of conformity
Can we rely on a harmonized standard that is not yet published?
No. Article 27(1) gives a presumption only for harmonized standards whose references are published in the Official Journal, so a draft or pending standard gives no presumption on its own. Commission standardization request M/606 covers 41 standards, with horizontal deliverables due 30 August 2026 or 30 October 2027 and 26 product-specific standards due 30 October 2026. Those are delivery dates, not publication dates, so check the current status before relying on any one of them. Until a reference is cited for your product, document how your design meets each relevant Annex I requirement through your own risk assessment. Confirm which standards are cited for your product category in the text of Article 27 on EUR-Lex.
How much engineering effort does mapping a product to a standard take?
The effort depends on how many Annex I requirements the chosen standard covers and how well your existing engineering records already match them. The supplied material gives no duration for this work, so ask any partner for the scope and deliverables in writing before committing. The mapping needs three inputs from engineering: a current architecture and component list including an SBOM, the secure development and update processes actually in use, and the risk assessment that defines which requirements apply and why. Expect the mapping to surface gaps, such as default credentials or update mechanisms, that need code or configuration changes. Those changes usually cost more than the mapping document itself, which is a one-time piece of work that must be kept current as the product changes.
Can an implementation partner prepare the conformity file for us alone?
A partner can prepare much of the file, but the manufacturer must own the conformity decision and sign the declaration. Under the regulation, the manufacturer is responsible for conformity, and only an independent notified body or certification body issues certificates where a route requires one. DeployOpen plans, implements, hardens and documents self-hosted open-source platforms inside your own infrastructure, and it can prepare systems, controls and evidence for the technical documentation, such as configuration records, test results and update procedures. It does not issue reports or certificates, and it does not declare conformity on your behalf. Ask for a written scope that lists which documentation items the partner prepares, which items your staff review, and who approves the final file.
Does presumption of conformity remove the notified body requirement for class I products?
Sometimes, and only for the requirements the presumption covers. Article 32 requires a notified body for class I important products where harmonized standards, common specifications or certification schemes are not applied in full. Applying a standard completely can therefore keep a manufacturer's own assessment route open, while partial application brings a notified body back for the uncovered part. Certification under a scheme adopted under Regulation (EU) 2019/881 works differently: an EU certificate or statement at assurance level at least substantial removes the need for third-party assessment for the requirements it covers, once the relevant delegated act applies. Confirm your product's class in Annex III and the exact requirements each standard covers against the Commission FAQs, version 1.4 before choosing a route.
Does a standard covering core functionality also cover our extra features?
No. Section 6.3 of the Commission guidance annexed to C(2026) 5252 notes that a harmonized standard covering only a product's core functionality gives no presumption for additional functions with risks the standard does not address. Consider a product that bundles an administration console, a remote update feature and an optional cloud connector. If the standard addresses only the core device function, each extra function needs its own risk assessment and evidence. List every function in your technical documentation and check it against the standard's stated scope, then record where the presumption stops. Repeat this check at each release, because new functions can move a product outside the scope of a previously accepted standard.
When will the EUCC presumption of conformity delegated act apply?
The Commission's CRA implementation timeline, updated 27 July 2026, planned a delegated act on presumption of conformity for the EUCC certification scheme for the fourth quarter of 2026. A planned date is not an adopted act, so check the Official Journal and the Commission's implementation pages before relying on it. Once adopted, the delegated act will specify which scheme certificates give presumption and the assurance level required. Until then, EUCC certification may still help as evidence, but do not treat it as removing third-party assessment. Confirm the scheme's scope and the assurance level your product needs with the certification body and the Commission's CRA implementation page before you plan certification work.
What happens if a harmonized standard is revised after our product is on the market?
The supplied guidance does not set out transition rules for a revised standard, so confirm them with the Official Journal notice and the Commission before planning a change. Presumption attaches to a reference published in the Official Journal, so the version cited when you assessed conformity is the one your file must justify. Record the standard version you applied, the date you applied it and the reasoning behind each requirement. When a revision is published, compare its text with your file, decide whether your product changes, and update documentation and tests where the revised text matters. Products placed on the market before 11 December 2027 fall under the regulation only if they are substantially modified, so a standard revision alone should be assessed against that rule.
How DeployOpen prepares presumption evidence for CRA scope
A fixed-scope engagement starts by fixing the product boundary in writing. DeployOpen reviews the product's functions one by one against the harmonized standards that have been published for the Annex I requirements, then records which functions a cited standard covers and which it does not. This matters because the Commission's guidance in C(2026) 5252 (section 6.3) states that a standard covering only core functionality gives no presumption of conformity for additional functions with risks it does not address. The first deliverable is therefore a scope statement that lists each function, its status against the standards that apply, and the open questions the manufacturer must decide. Ask the manufacturer to confirm the product version, the deployment model and whether any function is delivered by a third-party cloud service before work begins.
From that review DeployOpen builds a mapping and a gap register. The mapping ties each covered Annex I point to the standard clause, the product component and the artifact that shows it, such as a test report, configuration baseline or vulnerability handling record. The gap register lists every requirement that no cited standard covers, every function outside a standard, and every standard that is still in development. Standards under standardization request M/606 are due on different dates, so the register should show the expected publication status of each standard and say what evidence will be used until it is available. Where a standard is not yet cited in the Official Journal, the manufacturer should confirm with its assessor whether a self-assessed route or a notified body route applies.
DeployOpen then prepares the evidence package for the manufacturer to review and sign. The manufacturer owns its declarations, risk assessment and the decision to rely on a presumption, and it signs only what it has checked against its own product. DeployOpen hands over the file in a structure the independent assessor can test, with each artifact traceable to a mapping entry and each open gap marked. An independent auditor, assessor or notified body reviews that file and issues any conformity result. DeployOpen does not issue reports, attestations or certifications. Ask for the deliverables, the review checkpoints and the assumptions about standard publication dates in the written scope before signing.
