Cenitia launchesLaunching September 2026 — first 250 founders get the launch price locked for life.

Reserve your spot →
Cenitia
How it worksLibraryGlossaryRegulationsToolsAbout
Reserve your spot
How it worksLibraryGlossaryRegulationsToolsAbout

On this page

  • When the DoC must be reissued
  • 1. A cited directive or regulation is amended
  • 2. A cited harmonised standard is replaced
  • 3. The product is materially modified
  • 4. Administrative changes
  • Amending versus reissuing
  • The reissue workflow
  • Detecting amendments — the monitoring problem
  • What to retain in the Technical File
  • Common reissue mistakes
  • How Cenitia automates this
  • Frequently asked questions
  • Related from the Library
  • Further reading
← Library
guide·CRA, RED·9 min read

Updating a Declaration of Conformity after a regulation amendment

When a cited EU regulation or harmonised standard is amended, the Declaration of Conformity may need to be reissued. This guide explains when, how, and what to retain.

By Vladimír Vician · 14 June 2026

TL;DR

A Declaration of Conformity must be reissued when a fact stated on the DoC changes — most commonly when a cited directive is amended such that the product no longer conforms, when a cited harmonised standard is replaced and the old version withdrawn, or when the product is materially modified. The existing DoC remains valid for units already placed on the market; new units require an updated DoC. Reissue produces a new DoC with a new document number; the prior version stays in the Technical File for the retention period.

A signed Declaration of Conformity is not a static document. EU regulations are amended, harmonised standards are replaced and withdrawn, products are modified, and manufacturers reorganise. Each change can trigger a need to reissue the DoC.

This article explains when reissuing is mandatory, when it is recommended, the difference between amending and reissuing, and how to maintain the historical record in the Technical File.

When the DoC must be reissued

Reissuing is required when a fact stated on the DoC has changed in a way that affects the underlying legal claim. The four most common triggers:

1. A cited directive or regulation is amended

When a cited directive is amended such that the product no longer conforms to the new text:

  • CRA amendment to Annex I essential requirements — under Article 6 the new requirements apply to products placed on the market after the amendment date
  • RED Delegated Act updates — when Commission Delegated Regulation 2022/30 is updated
  • MDR amendment to clinical evaluation or post-market surveillance requirements
  • New directive replacing an old one — e.g. the Machinery Regulation 2023/1230 replacing the Machinery Directive 2006/42/EC from January 2027

The new DoC cites the amended text of the regulation; the old DoC remains in the Technical File covering units placed on the market before the amendment date.

2. A cited harmonised standard is replaced

When a harmonised standard is replaced and the old version is withdrawn from the Official Journal:

  • A new version of EN 18031 is cited; the old version is withdrawn after a transition period
  • EN 55032 is amended; the new version replaces the old in the Official Journal listing
  • A draft standard becomes a final harmonised standard and replaces interim self-assessment

The presumption of conformity from the withdrawn standard expires on the withdrawal date set in the Official Journal. The new DoC cites the new standard version; the manufacturer's Technical File must show conformity against the new version's test methods and acceptance criteria.

3. The product is materially modified

When a hardware revision, firmware update, or component change materially affects the product's compliance posture:

  • A new radio module that brings RED Article 3(3)(d) into scope
  • A new feature that processes personal data, bringing GDPR and CRA Annex I item 8 into scope
  • A new component that takes the product into a different RoHS category
  • An AI feature that brings the product into AI Act scope

Cosmetic changes (colour, branding, packaging) typically do not trigger reissue. Functional changes that affect the directive scope or the harmonised standard test methods do.

4. Administrative changes

When non-technical facts on the DoC change:

  • Manufacturer identity — merger, acquisition, name change, registered address change
  • Signatory — the named signing officer leaves or changes role
  • EU Authorised Representative — the EC REP relationship ends or changes
  • Notified Body — the NB designation changes or the certificate expires

These changes do not affect the product's technical conformity but they do affect the legal claim — and an outdated DoC names entities or individuals no longer authorised.

Amending versus reissuing

Two approaches exist, only one is recommended:

Amend the existing DoCReissue as new DoC
Effect on prior recordChanges the historical documentSupersedes; prior version preserved
Document numberingSame DoC numberNew DoC number, new date
TraceabilityDifficult — which version of the DoC was in force when?Clean — each unit shipped corresponds to a specific DoC version
Auditor reactionSuspicious; raises questions about provenanceStandard practice; no audit risk
Recommended useAlmost neverDefault

Reissue, do not amend. The prior DoC version stays in the Technical File alongside the firmware version, hardware revision, and Technical File version it corresponded to. When market surveillance asks "what version of the DoC was in force when this unit was placed on the market?", the manufacturer can answer with certainty.

The reissue workflow

A practical workflow for reissuing:

  1. Detect the trigger — regulation amendment in the Official Journal, harmonised standard withdrawal, product change, or administrative change
  2. Assess the impact — does the product still conform under the new text? What changes in the Technical File?
  3. Update the Technical File — add the new directive version, new harmonised standard version, updated test reports, updated risk assessment
  4. Draft the new DoC — with a new document number (typically incrementing: DoC-2026-0042 → DoC-2026-0043) and the current date
  5. Sign the new DoC — fresh handwritten or qualified electronic signature
  6. Archive the old DoC — into the Technical File for the retention period, with a clear note of which units it covered
  7. Update distribution channels — distributors and importers asking for the DoC receive the new version going forward
  8. Update product packaging or accompanying documents if the DoC version is referenced there
  9. Notify the EC REP if applicable — they hold a copy and must have the current version

For products under the Cyber Resilience Act with continuous monitoring obligations, this workflow runs in addition to the Article 13 vulnerability handling processes.

Detecting amendments — the monitoring problem

Reissuing only works if you know an amendment has happened. The Official Journal of the European Union publishes amendments and harmonised standard updates continuously. Manual monitoring is impractical at scale.

Practical detection options:

  • EUR-Lex e-mail alerts — free; configure per regulation; manual review of each alert
  • CEN-CENELEC mailing lists — for harmonised standard developments
  • Industry association feeds — DIGITALEUROPE, AEM, ETSI, BUSINESSEUROPE publish regulatory updates
  • Commercial regulatory intelligence services — Compliance & Risks, EurAsia Regulatory Square, Decernis — costly, comprehensive
  • Automated regulation watcher — Cenitia's regulation watcher monitors EUR-Lex pages for content-hash changes per regulation in your Technical File; affected DoCs are flagged automatically

The most common cause of belated reissue is manufacturer didn't know the regulation amended. A distributor asks for the DoC, the distributor's compliance team notices the cited directive is the old version, the manufacturer scrambles. By that point the new directive has been in force for months.

What to retain in the Technical File

For each DoC version reissued, the Technical File retains:

  • The prior DoC document (PDF or paper)
  • The document numbering record showing the supersession sequence (DoC-2026-0042 superseded by DoC-2026-0043 on 25 June 2026)
  • The trigger event that prompted the reissue (regulation amendment date, standard withdrawal date, product change record)
  • The applicability period of each DoC version — which serial number ranges and which shipping dates each version covered
  • The updated Technical File version that supports the new DoC

Under CRA Annex VII and parallel annexes in other directives, this complete record is retained for ten years from the date the last unit was placed on the market for that product family — regardless of how many DoC versions were issued in between.

Common reissue mistakes

  • Reissue triggered by amendment but Technical File not updated. The new DoC cites the new directive version but the Technical File still references the old version. Auditors immediately spot the gap.
  • Amend in place rather than reissue. Same DoC number, same date, different cited regulations. Loses traceability.
  • Update the DoC but forget the EC REP copy. The EC REP holds a copy under Article 13 mandate; that copy must be the current version.
  • Update the DoC but ship product with old DoC packaged. Stock-on-hand of accompanying documents must be reviewed when a reissue happens.
  • No record of which units shipped under which DoC. When market surveillance asks "which DoC version covered the unit serial 0042?", the manufacturer must be able to answer.
  • Treating routine harmonised standard amendment as a no-op. A version-date change in EN 18031 is a real change with real test-method implications.

How Cenitia automates this

Cenitia's regulation watcher monitors every cited regulation and harmonised standard in your Technical Files. When an Official Journal publication amends a cited regulation or withdraws a cited standard, affected DoCs are flagged automatically with the specific regulation reference, the change date, and a recommended action — usually "review and reissue".

For each reissue, Cenitia produces the new DoC with the updated citations, retains the prior DoC version in the Technical File with the trigger event recorded, and updates the QR-verifiable signed PDF. Distributors and importers retrieving the DoC always receive the current version; the public QR URL resolves to the current DoC.

Reserve your spot — Cenitia launches September 2026

One email at launch · cancel any time

Frequently asked questions

When does a Declaration of Conformity need to be updated?

Whenever a fact stated on the DoC changes. The most common triggers: a cited directive or regulation is amended such that the product no longer conforms to the new text; a cited harmonised standard is replaced and the old version is withdrawn from the Official Journal; the product itself is materially modified; the signatory changes; the manufacturer's legal identity changes; the EU Authorised Representative changes. Routine product variants that share the same essential characteristics and the same applicable directives do not need a new DoC.

What is the difference between amending and reissuing a DoC?

Amending is rare and risky — it changes the historical record of what was declared. Reissuing produces a new DoC with a new document number and date, and supersedes the prior version. The prior version remains in the Technical File alongside its associated Technical File version, so the historical record of what was declared at the time of original placement on the market remains intact. Reissuing is the standard approach.

How quickly must I reissue after a regulation amends?

There is no fixed legal deadline in most directives. The practical rule: the existing DoC continues to be valid for units already placed on the market before the amendment date. New units placed on the market after the amendment must conform to the new text — which in practice means reissuing the DoC before the next batch ships. For the Cyber Resilience Act in particular, manufacturers must keep the Technical File and DoC current throughout the support period under Annex VII.

Do I need to notify customers of a reissued DoC?

There is no general obligation to actively notify customers, but distributors and importers can request the current DoC on demand and the manufacturer must provide it. For products under MDR, vigilance and post-market obligations may require notification. For products under CRA, if the amendment relates to a security issue, the Article 13 vulnerability disclosure obligations apply in parallel and may require user notification.

What if I miss a regulation amendment and continue to place product on the market?

Under Article 14 of EU Market Surveillance Regulation 2019/1020, a product placed on the market that does not conform to the directives in their current form is non-compliant. Market surveillance authorities can order withdrawal, recall, and import bans. Administrative fines apply under national implementing law. Continuous monitoring of the Official Journal — manually or through tooling like Cenitia — is the practical defence.

Can the same DoC cover multiple firmware versions of the same product?

Generally yes, when the variants share the same essential characteristics and the cited regulations apply uniformly. CRA Annex V item 5 requires identification 'allowing traceability' — a firmware version range (e.g. v1.4.x) is permissible when functional equivalence is documented in the Technical File. When a firmware update materially changes the security posture or introduces a new directive scope (e.g. a feature that adds AI Act applicability), a new DoC is required.

Related from the Library

  • Declaration of Conformity 101 — pillar context
  • Sample DoC walkthrough — the annotated structure that gets reissued
  • Technical File 101 — where the prior DoC version is retained
  • CRA timeline and reporting obligations — the continuous-monitoring obligations under CRA

Further reading

  • Cyber Resilience Act Annex V and Annex VII
  • Regulation 2019/1020 — Article 14 on market surveillance powers
  • Blue Guide — Chapter 5 on the EU Declaration of Conformity and its maintenance

Last reviewed: 25 June 2026. Cited regulations watched continuously by Cenitia — when one amends, this article is flagged for update.

FAQ

Frequently asked questions

  • When does a Declaration of Conformity need to be updated?+

    Whenever a fact stated on the DoC changes. The most common triggers: a cited directive or regulation is amended such that the product no longer conforms to the new text; a cited harmonised standard is replaced and the old version is withdrawn from the Official Journal; the product itself is materially modified; the signatory changes; the manufacturer's legal identity changes; the EU Authorised Representative changes. Routine product variants that share the same essential characteristics and the same applicable directives do not need a new DoC.

  • What is the difference between amending and reissuing a DoC?+

    Amending is rare and risky — it changes the historical record of what was declared. Reissuing produces a new DoC with a new document number and date, and supersedes the prior version. The prior version remains in the Technical File alongside its associated Technical File version, so the historical record of what was declared at the time of original placement on the market remains intact. Reissuing is the standard approach.

  • How quickly must I reissue after a regulation amends?+

    There is no fixed legal deadline in most directives. The practical rule: the existing DoC continues to be valid for units already placed on the market before the amendment date. New units placed on the market after the amendment must conform to the new text — which in practice means reissuing the DoC before the next batch ships. For the Cyber Resilience Act in particular, manufacturers must keep the Technical File and DoC current throughout the support period under Annex VII.

  • Do I need to notify customers of a reissued DoC?+

    There is no general obligation to actively notify customers, but distributors and importers can request the current DoC on demand and the manufacturer must provide it. For products under MDR, vigilance and post-market obligations may require notification. For products under CRA, if the amendment relates to a security issue, the Article 13 vulnerability disclosure obligations apply in parallel and may require user notification.

  • What if I miss a regulation amendment and continue to place product on the market?+

    Under Article 14 of EU Market Surveillance Regulation 2019/1020, a product placed on the market that does not conform to the directives in their current form is non-compliant. Market surveillance authorities can order withdrawal, recall, and import bans. Administrative fines apply under national implementing law. Continuous monitoring of the Official Journal — manually or through tooling like Cenitia — is the practical defence.

  • Can the same DoC cover multiple firmware versions of the same product?+

    Generally yes, when the variants share the same essential characteristics and the cited regulations apply uniformly. CRA Annex V item 5 requires identification 'allowing traceability' — a firmware version range (e.g. v1.4.x) is permissible when functional equivalence is documented in the Technical File. When a firmware update materially changes the security posture or introduces a new directive scope (e.g. a feature that adds AI Act applicability), a new DoC is required.

Portrait of Vladimír Vician

Written by

Vladimír Vician

Founder, Cenitia · Founder & Managing Director, Inovasense s.r.o.

Founded Inovasense in Bratislava in 2016. Specialises in EU-sovereign hardware — FPGA and embedded systems design, embedded security, and regulatory compliance under the CRA, RED (EN 18031), and the harmonised standards each cites. Named signatory on every Declaration of Conformity Inovasense ships.

Best reached on LinkedIn. For longer enquiries, the Inovasense contact form.

Inovasense profile · More about Cenitia

Continue reading

Related guides

  • reference

    Declaration of Conformity translation requirements — every EU language explained

    Which EU language(s) the Declaration of Conformity must be drawn up in, which language(s) must accompany the product per market, and what counts as a valid translation.

    9 min read

  • tutorial

    Sample Declaration of Conformity — annotated walkthrough with template

    Full annotated sample EU Declaration of Conformity for a connected IoT product, citing CRA, RED, LVD, EMC, RoHS — with explanation of each of the nine elements.

    10 min read

  • guide

    Declaration of Conformity 101 — what it is, who needs it, how it's signed

    EU Declaration of Conformity explained: which laws require one, the nine elements it must contain in 2026, common mistakes that void it, what changes the moment you sign.

    11 min read

  • reference

    Conformity assessment Modules A through H — the EU CE marking decision guide

    Every EU conformity assessment module — Module A self-assessment through Module H full quality assurance — when each applies and how to choose the right one.

    11 min read

Put this into practice

Free tools & references

  • EU Directive SelectorDescribe your product and find which EU directives and regulations apply.Open tool →
  • Do I need a Notified Body?Find out, per regulation, whether a Notified Body is required.Open tool →

New to the terminology? Browse the compliance glossary — plain-English, citation-backed definitions of every term above.

Reserve your spot — launching September 2026

One email at launch · cancel any time

← Back to Library

Cenitia

The EU compliance engine for hardware manufacturers. Cited drafts, electronic signing, regulation watching — all in one place.

A product of Inovasense s.r.o., Bratislava, Slovakia · Data hosted in Stockholm, EU

Site

  • How it works
  • Library
  • Glossary
  • Regulations
  • By product type
  • Tools
  • About

Legal

  • Imprint
  • Privacy
  • Terms

© 2026 Inovasense s.r.o. · cenitia.com

EU sovereign · EU data residency by design · Customer data never trains models