How to Keep EN 18031 Evidence Valid After Firmware Updates

Firmware version 2.4 doesn't automatically erase the EN 18031 work completed for version 2.3., but it does create a harder question: which conclusions still describe the product now being shipped or updated? 

Release notes can't answer that on their own. They describe changes to code. EN 18031 evidence supports conclusions about the product’s assets, interfaces, data flows, access controls, update mechanisms, dependencies, and tested behavior. A small patch can affect a critical security claim, while a large internal refactor may leave that claim untouched. 

The useful unit of work is therefore an evidence delta: a versioned record of what changed, which existing conclusions rely on the changed facts, and what evidence must be retained, supplemented, replaced or escalated. “Evidence delta” is not a term used in the Radio Equipment Directive or EN 18031. It is a practical way to turn their change-control expectations into a repeatable release decision. The term provides a shorthand for turning RED and EN 18031 change-control expectations into a repeatable release decision.

Evidence Expires When Its Assumptions Change 

RED makes product change control part of conformity. Article 21(2) of Directive 2014/53/EU requires technical documentation to be drawn up before radio equipment is placed on the market and to be “continuously updated”. Article 10(5) requires manufacturers to account for changes in product design or characteristics during series of production. Annex V also requires relevant software or firmware versions to be identified when they affect conformity. 

The legal obligation is conformity with the applicable RED essential requirements. EN 18031 is a voluntary harmonized standard that manufacturers may use to support a presumption of conformity, subject to the restrictions in its Official Journal of citation. That distinction matters when a change affects the standards of coverage or the conformity-assessment route. 

The European Commission’s RED Guide says this explicitly in its “Series production” section. It tells manufacturers to monitor hardware and software changes, developments in applicable standards and legislation, and the state of the art, then record their considerations in the technical documentation. It also confirms that the manufacturer remains responsible for assessing the radio equipment together with its embedded software. 

Every EN 18031 conclusion rests on product facts. An access-control assessment may assume that only local administrators can change a setting. A secure communication test may rely on a specific cryptographic library and configuration. An update-mechanism assessment may rely on the bootloader, signing keys, rollback controls and delivery path. When one of those facts changes, the evidence that depends on it needs review. 

Start with a defined product baseline. This should identify product type and hardware revision, firmware build, bootloader, enabled interfaces, radio configuration, companion application and backend versions where relevant, third-party security components, intended use, user roles, data categories and conformity route. A product name alone is not a baseline. Two variants sold under the same name may expose different interfaces or enable different functions. Many common EN 18031 gaps before launch begin with this boundary being drawn too narrowly around the device. 

The baseline should also record the exact harmonized-standard reference and Official Journal conditions used for the conformity of claim. EN 18031-1, EN 18031-2 and EN 18031-3 were cited under RED through Commission Implementing Decision (EU) 2025/138, with restrictions. A change affecting password behavior, parental access control or secure updates in payment-capable equipment may therefore affect more than a test result. It might affect whether the chosen conformity route still works. For internet-connected products, QIMA’s EN 18031-1 overview provides additional context on product boundaries and technical-file evidence. 

Build an Evidence Delta for Every Firmware Release 

Place the evidence review between the engineering change set and final release of approval. By that point, the team knows what changed, but there is still time to update documentation, run focused tests or involve a conformity specialist before the build reaches production or deployed devices. 

The review should trace the change through the product rather than classify the release as “minor” or “major”. The following examples show where that trace usually leads. 

Each affected item then receives one of four dispositions.  

Use one evidence delta for each released configuration. It should record: 

1. The firmware build and affected product or hardware variants. 

2. The functions, components, interfaces and assumptions that changed. 

3. The EN 18031 conclusions and technical-file records affected by those changes. 

4. The disposition of each existing evidence item: retained, supplemented, replaced or escalated. 

5. New tests, vulnerability decisions, supplier inputs and evidence references. 

6. The reviewer, approval date and final release decision. 

These fields turn a change-impact discussion into a record another person can reconstruct later. 

A retained decision is still evidence. It should link to the earlier artifact and explain why its assumptions remain true. A checkbox marked “no impact” without reasoning will be difficult to defend months later, especially after the people involved have moved to another project.

Change Size is a Poor Proxy for Evidence Impact 

Consider a connected building controller. Firmware 2.3.1 updates its TLS library to correct vulnerability. The supported protocols, key management, data flows, external interfaces, and update paths stay the same. The team may only need to update the component and vulnerability records, preserve the new build identifier, verify the configured cryptography, and run focused regression tests. The architecture and access-control evidence may remain applicable, if conclusion is documented, and the actual integration supports it. 

Firmware 3.0 then adds remote administration through a new cloud API. That change reopens the product boundary, data-flow diagram, external-interface inventory, threat scenarios, administrator roles, authentication, logging, backend dependency, and possibly personal data assessment. The need for new evidence comes from the changed exposure, not the major version number. 

The European Commission’s July 2026 guidance on the Cyber Resilience Act follows the same risk-based logic for substantial modifications. It directs manufacturers to consider whether a software update introduces new threat vectors or attack scenarios or changes the likelihood or impact of existing ones. It also explains that a security update is generally not substantial when it leaves the intended purpose unchanged and introduces no new cybersecurity risk, even if the technical change is significant. 

Those are CRA considerations, not a substitute for an EN 18031 assessment under RED. They are useful now because they show why labels such as “security patch”, “feature release” or “minor update” are not enough. The product effect has to be examined. 

Keep the Old Evidence Instead of Overwriting It 

Technical documentation should remain current, but “current” doesn't mean that the previous record should disappear. RED requires manufacturers to retain the technical documentation and EU declaration of conformity for ten years after the radio equipment is placed on the market. If a product remains in series of production across several firmware releases, the manufacturer may need to reconstruct which configuration supported a particular production lot or unit. 

Maintain a version ledger that connects each firmware release to the applicable models and hardware revisions, production or serial ranges, field rollout population, evidence delta, document versions, test results, approvals and any notified-body communication. For an over-the-air update, preserve the rollout and rollback records as well. This creates a timeline of what was assessed, what changed, and which evidence supported each decision. 

Don't edit a single file called EN18031_Assessment_Final in place. When old assumptions are silently replaced, the file may describe the newest build while leaving no reliable record for earlier units. Release notes are not a substitute. They show what engineering changed, but not why a previous conformity conclusion still holds. 

The same discipline applies to supplier evidence. A new library report, module declaration, or security datasheet does not automatically prove the final product remains covered. The manufacturer still needs to identify the exact version and configuration used, verify the assumptions that matter to the product, and connect the supplier material to product-level evidence.  

Use the RED Record to Prepare for CRA Vulnerability Management 

This release history has immediate value beyond the next RED review. The RED cybersecurity delegated regulation remains applicable until 10 December 2027. Delegated Regulation (EU) 2026/339 repeals it from 11 December 2027, when the main CRA obligations apply. QIMA’s broader CRA overview explains its relationship with RED and other EU rules. 

CRA reporting obligations are already in force. Since 11 September 2026, manufacturers have been required to report actively exploited vulnerabilities and severe security incidents affecting in-scope products. The Commission’s official reporting guidance sets a 24-hour early-warning deadline and a 72-hour deadline for the full notification. Its July 2026 application guidance also states that the reporting duty covers in-scope products placed on the market before the main CRA application date. 

A version-specific evidence trail gives the vulnerability team a head start. It shows which released builds contain an affected component, how that component is configured, which interfaces expose it and which devices received the relevant firmware. It does not decide whether an event is reportable, but it reduces the time spent reconstructing the product while the reporting clock is running. 

The July 2026 CRA guidance also points toward event-driven testing. Manufacturers should review whether new threats, vulnerabilities or product changes require the test set to change, then run the relevant tests. It does not call for the mechanical repetition of an unchanged test campaign at fixed intervals. The same guidance permits existing documentation and test results to be reused for unaffected parts of a substantially modified product. That is the longer-term value of an evidence delta: it preserves reuse without allowing old evidence to drift away from the product. 

For a structured starting point, use QIMA’s RED and CRA Readiness Workbook for Connected Products to map product scope, EN 18031 evidence, supplier gaps, vulnerability reporting and a 30-day action plan. 

At release review, replace the question “Has the EN 18031 document been updated?” with “Which compliance conclusions changed, and where is the evidence for that decision?” 

Cyberexpert’s product-specific requirements map, evidence checklist and vulnerability management workspace give product, firmware, QA and compliance teams a shared place to connect requirements, risks, evidence owners and release changes. Cyberexpert supports readiness and evidence preparation. It does not certify the product, and responsibility for conformity remains with the manufacturer. Scope your connected product for free to identify which EN 18031 evidence your next firmware release should reopen.