How to Ensure Ongoing RED Compliance for Software Updates
Software updates are essential for connected devices, but each release can impact your EN 18031 compliance status. This guide explains what the standard requires for update mechanisms, when re-assessment is needed, and how to build a sustainable compliance workflow that keeps pace with your development cycle.
April 7, 2026
Ongoing RED compliance for software updates means ensuring that every firmware or software release on your connected device continues to meet the cybersecurity requirements of the Radio Equipment Directive (RED) under EN 18031. Software updates can introduce new security functions, modify existing ones, or change how your device interacts with networks and user data. Each of these changes has compliance implications.
EN 18031 defines specific requirements for software update mechanisms: Secure delivery, integrity verification, authentication, and rollback capabilities are all addressed in the standard.
Not all updates trigger re-assessment: Minor bug fixes that do not affect security-relevant functions may not require a full compliance review, but changes to cryptographic libraries, access control, or network protocols typically do.
Documentation must be maintained continuously: Compliance tables, decision tree outcomes, and test plan verdicts need to reflect the current state of your device software, not just the initial release.
Automated workflows reduce compliance drift: Manual tracking of update impacts across dozens of EN 18031 sections is error-prone. Structured compliance platforms keep documentation synchronized with your development cycle.
The update mechanism itself is a compliance requirement: EN 18031 does not just care about what you update, but how you deliver, verify, and install updates securely.
EN 18031 dedicates specific sections to software update mechanisms across all three parts of the standard. These requirements apply to any device that supports firmware or software updates, which in practice means nearly every internet-connected radio equipment product.
The standard addresses software updates from multiple angles, depending on which EN 18031 parts your project requires:
| EN 18031 Part | RED Article | Update-Related Focus |
|---|---|---|
EN 18031-1 | 3.3(d) - Network Protection | Updates must not introduce vulnerabilities that compromise network resources. Secure delivery channels and integrity verification prevent malicious firmware from reaching the device. |
EN 18031-2 | 3.3(e) - Privacy Protection | Software updates must not expose personal data during the update process. Update mechanisms should maintain privacy safeguards and not bypass data protection controls. |
EN 18031-3 | 3.3(f) - Fraud Prevention | Devices handling monetary transactions must ensure updates do not weaken financial security controls. Clause 6.3.2.4 specifically addresses secure update mechanisms for financial assets. |
Core Security Requirements for Update Mechanisms
Regardless of which EN 18031 parts apply, the standard expects update mechanisms to satisfy several fundamental security properties:
Integrity verification: The device must verify that software updates have not been tampered with during delivery. This typically involves cryptographic signatures or hash verification.
Authentication of update source: The device must confirm that updates originate from an authorized source. Unsigned or unauthenticated updates represent a compliance failure.
Secure delivery channel: Updates should be transmitted over encrypted channels to prevent interception and modification in transit.
Rollback protection: The standard considers whether devices can revert to a previous, potentially vulnerable software version. Rollback mechanisms must be controlled and documented.
User notification: Where applicable, devices should inform users about available updates and the security implications of not installing them.
Update availability period: Manufacturers should define and communicate how long security updates will be provided for a given product.
How Does This Differ from General Firmware Security?
EN 18031 goes beyond generic firmware security best practices by requiring that update mechanisms are documented within the compliance framework. This means every aspect of your update process must be recorded in compliance tables, evaluated through decision trees, and validated in test plans. The update mechanism is not just a technical implementation - it is a compliance deliverable.
Software updates are one of several cybersecurity domains covered by EN 18031. For the full list of required measures, see our guide to essential RED cybersecurity measures.
One of the most common questions from product security managers is: does every software update require a full compliance re-assessment? The short answer is no - but the criteria for when re-assessment is needed must be clearly understood and documented.
Updates That Typically Require Re-Assessment
A compliance re-assessment is generally needed when a software update affects any security-relevant function documented in your EN 18031 compliance tables. This includes:
Changes to cryptographic implementations: Updating encryption libraries, changing key lengths, or modifying certificate handling directly impacts sections on cryptography and secure communications.
Modifications to access control logic: Adding, removing, or changing authentication mechanisms (passwords, biometrics, tokens) affects access control sections and their associated decision trees.
Network protocol changes: Switching communication protocols, adding new network interfaces, or modifying firewall rules impacts network protection requirements under EN 18031-1.
Data handling changes: Modifications to how personal data is collected, stored, or transmitted require re-evaluation of privacy protection sections under EN 18031-2.
Payment or transaction logic changes: Any update affecting financial transaction processing requires re-assessment under EN 18031-3.
Changes to the update mechanism itself: If you modify how your device receives, verifies, or installs updates, the update mechanism compliance documentation must be revised.
Updates That May Not Require Full Re-Assessment
UI-only changes: Cosmetic updates to the user interface that do not affect security functions or data flows.
Performance optimizations: Code refactoring that improves speed or memory usage without changing security-relevant behavior.
Bug fixes in non-security code: Fixing defects in features that have no interaction with security functions, network access, or personal data.
Content updates: Changes to static content, localization files, or documentation that do not alter device behavior.
The Grey Area: How to Decide
In practice, many updates fall into a grey area. A performance optimization might inadvertently change how a security function behaves under load. A UI change might alter how users interact with authentication flows. The safest approach is to map every planned update against your EN 18031 asset inventory. If the update touches any identified security asset, network asset, or privacy asset, a targeted re-assessment of the affected sections is warranted.
This is where structured compliance platforms provide significant value. Rather than manually reviewing dozens of compliance sections to determine impact, a platform like RedComply allows you to trace which sections and tables reference the affected assets and focus your re-assessment precisely where it is needed.
When updates address discovered vulnerabilities, proper documentation is essential. Our vulnerability management guide covers the audit-ready documentation process.
Maintaining ongoing RED compliance across software updates requires a repeatable, structured workflow - not a one-time effort that becomes outdated with the next release. Here is a practical framework that product security teams can implement.
Classify every update before release: Before any software update enters testing, classify it as security-relevant or non-security-relevant based on which EN 18031 assets it affects. This classification determines the compliance review scope.
Maintain a living compliance baseline: Your EN 18031 compliance documentation should be treated as a living document set. When an update is classified as security-relevant, update the affected compliance tables, decision tree responses, and test plan entries before the release ships.
Run targeted re-assessments: For security-relevant updates, re-run the affected decision trees and update test plan verdicts. You do not need to re-assess the entire device - only the sections impacted by the change.
Version your compliance documentation: Link each compliance documentation state to a specific software version. This creates an audit trail showing what was assessed for each release.
Automate where possible: Use compliance platforms that can auto-populate tables from asset inventories, auto-calculate test plan verdicts, and flag when changes affect documented security functions.
Review the update mechanism periodically: Even if the update mechanism itself does not change, periodically verify that it still meets EN 18031 requirements as threat landscapes evolve.
Manual vs. Automated Update Compliance Tracking
| Compliance Task | Manual Approach | Automated Approach |
|---|---|---|
Update impact classification | Engineer reviews EN 18031 sections one by one | Platform maps update scope to affected compliance sections automatically |
Compliance table updates | Copy changes across dozens of tables manually | Tables auto-update from asset inventory when linked assets change |
Decision tree re-evaluation | Re-run paper-based or spreadsheet trees | Interactive decision trees retain previous state and highlight what needs review |
Test plan verdict recalculation | Manually recompute pass/fail criteria | Auto-calculated verdicts update in real time as inputs change |
Documentation versioning | Manually save dated copies of spreadsheets | Platform maintains version history linked to software releases |
DoC regeneration | Rebuild PDF from scattered updated sources | One-click PDF generation from current compliance data |
The difference between these approaches becomes dramatic as your product matures. A device with quarterly updates will need 4+ compliance review cycles per year. Over a 5-year product lifecycle, that is 20+ reviews. Without automation, compliance drift is almost inevitable.
Use this checklist to verify your software update compliance posture against EN 18031 requirements. Each item corresponds to a specific area of the standard.
Update Mechanism Security
Updates are delivered over encrypted channels (TLS 1.2+, HTTPS, or equivalent)
Update packages are cryptographically signed by the manufacturer
The device verifies the signature before installing any update
The device authenticates the update server or source
Rollback to known-vulnerable versions is prevented or controlled
Failed updates do not leave the device in an insecure state
Ongoing Compliance Management
Every software release is classified as security-relevant or non-security-relevant
Security-relevant updates trigger targeted re-assessment of affected EN 18031 sections
Compliance tables are updated to reflect the current software version
Decision tree outcomes are re-evaluated when security functions change
Test plan verdicts are recalculated after compliance table updates
Declaration of Conformity is regenerated for significant security-relevant changes
A compliance audit trail links each software version to its assessment documentation
Communication and Transparency
Users are notified when security updates are available
The manufacturer communicates the expected support period for security updates
Release notes describe security-relevant changes in sufficient detail for compliance review
The compliance team receives advance notice of security-relevant updates before release
Does every software update require RED re-certification?
No. Only updates that affect security-relevant functions documented in your EN 18031 compliance assessment require re-evaluation. Minor bug fixes, UI changes, and performance optimizations that do not impact security assets, network behavior, or data handling can typically proceed without a full compliance review. However, you should always classify each update against your asset inventory to make this determination systematically.
What are EN 18031 requirements for secure software updates?
EN 18031 requires that software update mechanisms include integrity verification (cryptographic signatures or hashes), authentication of the update source, secure delivery channels, and controlled rollback protection. These requirements apply across all three parts of the standard, with each part adding focus areas: EN 18031-1 covers network protection during updates, EN 18031-2 addresses privacy preservation, and EN 18031-3 focuses on financial transaction security.
How do I maintain compliance documentation across multiple software versions?
The most effective approach is to version your compliance documentation alongside your software releases. Each software version should have a corresponding set of compliance tables, decision tree outcomes, and test plan verdicts. Compliance platforms like RedComply allow you to maintain this linkage automatically, so you can always demonstrate what was assessed for any given release.
What happens if a software update introduces a compliance gap?
If a software update creates a new compliance gap, such as weakening an access control mechanism or introducing an unencrypted communication channel, you must address the gap before placing the updated product on the EU market. This may require modifying the update, adding compensating controls, or updating your technical documentation to reflect the new risk assessment. The key is to detect gaps early through structured re-assessment rather than discovering them during an audit.
Can OTA (over-the-air) updates affect my device's RED compliance status?
Yes. OTA updates are subject to the same EN 18031 requirements as any other software update mechanism. In fact, OTA updates often receive additional scrutiny because they involve wireless transmission, which creates additional attack surfaces. Your OTA update mechanism must demonstrate secure delivery, integrity verification, and authentication, and any security-relevant changes delivered via OTA require the same re-assessment process as wired updates.
Ensuring ongoing RED compliance for software updates is not a one-time checkbox exercise. It is a continuous process that must be embedded into your product development lifecycle. The key principles are clear:
EN 18031 requires secure, authenticated, and integrity-verified update mechanisms as a baseline.
Security-relevant software updates require targeted re-assessment of affected compliance sections.
Compliance documentation must be versioned and maintained as a living document set.
Automated compliance workflows dramatically reduce the risk of compliance drift across multiple update cycles.
The update mechanism itself is a compliance requirement that must be documented and assessed.
Manufacturers who treat compliance as an ongoing workflow rather than a one-time project will find it easier to maintain market access, respond to audits, and keep their products secure as threats evolve. The investment in structured compliance processes pays for itself many times over across the product lifecycle.
RedComply is purpose-built for EN 18031 and RED cybersecurity compliance. The platform provides structured workflows for documenting software update mechanisms, tracking compliance across software versions, and automating re-assessment when security-relevant changes occur.
Here is how RedComply helps with software update compliance specifically:
Structured compliance tables for documenting update mechanisms, including secure delivery, integrity verification, and authentication controls
Decision trees that guide you through EN 18031 update-related requirements and record PASS/FAIL outcomes for each assessment
Auto-calculated test plan verdicts that update in real time as you modify compliance data after a software release
AI assistant trained on EN 18031 that can answer questions about update-specific requirements, search related sections, and help populate compliance tables
One-click Declaration of Conformity generation that compiles your current compliance state into a structured PDF ready for regulatory review
Stop managing software update compliance in spreadsheets. Visit redcomply.com and see how structured EN 18031 workflows keep your compliance documentation synchronized with your development cycle.