Technical documentation should follow the product rather than remain frozen at first market placement. Manufacturers should assess each material change for its effect on intended purpose, architecture, cybersecurity risks, Annex I applicability, security controls, SBOMs, vulnerability handling, test evidence, standards mappings and conformity documentation. Not every change requires rewriting every document, but every compliance-relevant change should leave a traceable update decision.
Article 31 Requires Technical Documentation to Stay Current
Article 31 requires technical documentation to be continuously updated where appropriate, at least during the support period. This means the technical documentation should remain representative of the product and manufacturer processes after market placement. A documentation package that accurately described version 1.0 can become unreliable after architecture, software, dependency or security-process changes. Manufacturers should therefore integrate documentation impact into normal product-change management.
- Review documentation after relevant product changes.
- Maintain current product-version evidence.
- Update throughout the support period where appropriate.
- Preserve traceability to earlier releases.
Article 13 Requires Changes Affecting Conformity to Be Considered
Article 13 requires manufacturers to maintain procedures for products in series production to remain in conformity. Manufacturers must adequately take into account changes in development and production processes, product design or characteristics and changes in relevant harmonised standards, European cybersecurity certification schemes or common specifications used for conformity. Change management should therefore examine both technical product changes and changes in the compliance reference framework.
- Development-process changes.
- Production-process changes.
- Design changes.
- Product-characteristic changes.
- Harmonised-standard changes.
- Certification-scheme changes.
- Common-specification changes.
Not Every Change Requires the Same Documentation Work
A spelling correction in user documentation and a new externally reachable administrative API do not have the same cybersecurity impact. Manufacturers should use an impact-based process to decide which documents need review or revision. A minor change can require only a controlled record confirming no security impact. A material architecture change can require updated risk analysis, design documentation, test evidence, SBOM information and conformity review.
- Classify the change.
- Assess cybersecurity impact.
- Identify affected documents.
- Define required verification.
- Record the update decision.
Review Intended Purpose and Conditions of Use
Changes to product functionality, users, deployment models or connectivity can alter intended purpose or relevant conditions of use. A product originally intended for managed enterprise deployment can face different risks if a new consumer deployment mode is introduced. Product-change review should determine whether intended-purpose statements, user information and risk assumptions remain accurate.
- New product functions.
- New user groups.
- New deployment modes.
- New connectivity options.
- Changed operating assumptions.
Review the Cybersecurity Risk Assessment
Article 13 requires the documented cybersecurity risk assessment to be updated where appropriate. Product changes can alter threat scenarios, attack feasibility, impact or control effectiveness. A new interface can create a new attack path. A removed service can eliminate one. A privilege change can increase the impact of compromise. Change review should identify affected risk records and update only the relevant analysis where possible while preserving the historical reasoning.
- Identify affected threat scenarios.
- Review attack feasibility.
- Review cybersecurity impact.
- Review residual risk.
- Create new risks where necessary.
Update Architecture Documentation
Architecture evidence should be revised when components, interfaces, trust boundaries, data flows or deployment relationships change materially. A new remote service, database, plugin system, management endpoint or hardware interface can affect both the architecture record and cybersecurity risk analysis. Retain enough historical architecture evidence to understand earlier releases rather than replacing every diagram without trace.
- Components.
- Interfaces.
- Trust boundaries.
- Data flows.
- Deployment relationships.
- Remote services.
Update Security Design Documentation
If a change modifies authentication, authorisation, secure defaults, cryptography, resilience, attack-surface controls, logging, updates or other security mechanisms, the corresponding design evidence should be reviewed. The updated documentation should identify the control change and the risk or requirement that motivated it. Obsolete design assumptions should be marked as superseded rather than left alongside the current design without context.
- Access-control changes.
- Cryptographic changes.
- Secure-default changes.
- Resilience changes.
- Update-system changes.
- Logging and monitoring changes.
Update the SBOM and Dependency Evidence
Dependency upgrades, removals and additions can change vulnerability exposure and therefore technical documentation. The SBOM should remain associated with the correct product release. Where a new dependency adds a security-sensitive function or supply-chain relationship, the manufacturer should determine whether architecture, risk and vulnerability-handling records also require updates.
- Added dependencies.
- Removed dependencies.
- Version upgrades.
- Changed transitive dependencies.
- New security-sensitive components.
Review Vulnerability Handling Processes
Product changes can also alter vulnerability handling. A new product family can require a new reporting route. A new update platform can change secure distribution controls. Organisational changes can move responsibility to a different team. Annex VII documentation should continue to describe the process actually in use, including the SBOM, disclosure policy, vulnerability-reporting contact and secure update solution.
- Reporting contact changes.
- Policy changes.
- Update infrastructure changes.
- Team ownership changes.
- SBOM process changes.
Determine Which Security Tests Must Be Repeated
A change can invalidate earlier security test evidence even where the previous report remains historically correct. If authentication changes, repeat relevant access-control tests. If update verification changes, repeat malicious-package and integrity tests. If architecture changes affect trust boundaries, reassess attack scenarios and targeted tests. The change record should explain which earlier evidence remains applicable and which verification was repeated.
- Identify affected controls.
- Identify affected previous tests.
- Repeat relevant verification.
- Record new test results.
- Mark superseded evidence.
Review Standards and Specifications Used for Conformity
Article 13 requires changes in relevant harmonised standards, European cybersecurity certification schemes and common specifications to be taken into account where they are used to declare or verify conformity. Manufacturers should maintain awareness of changes in the references supporting their conformity position and determine whether revised technical evidence or product changes are needed.
- Harmonised standards.
- Common specifications.
- Cybersecurity certification schemes.
- Partly applied standards.
- Alternative technical specifications.
Do Not Automatically Equate Every Product Change With a New Conformity Procedure
The obligation to keep technical documentation current should not be converted into a claim that every software patch or product change automatically requires the same new conformity-assessment procedure. The effect depends on the change, product category, conformity route and whether the modification affects conformity. Manufacturers should perform a documented impact assessment and apply the relevant CRA conformity rules rather than use a blanket rule.
- Assess the effect on conformity.
- Consider the applicable conformity route.
- Document the conclusion.
- Escalate material modifications appropriately.
Preserve Historical Evidence
Updating technical documentation should not mean erasing evidence for earlier marketed versions. Vulnerability reports, market surveillance questions or field investigations can arise after a newer release has replaced the earlier one. Manufacturers should preserve enough historical architecture, risk, test and conformity evidence to determine what controls and assumptions applied to the earlier version.
- Historical product versions.
- Historical risk assessments.
- Historical architecture.
- Historical test reports.
- Historical SBOMs.
- Historical conformity records.
A Practical Documentation Change Record
A practical change record can include change identifier, affected product versions, technical description, cybersecurity impact, affected risks, affected Annex I requirements, affected documents, required retesting, evidence owner, approval and release date. The CRA does not prescribe this exact form. Its purpose is to demonstrate that technical documentation was actively maintained rather than periodically recreated without traceability.
- Change identifier.
- Affected product version.
- Cybersecurity impact.
- Affected risk records.
- Affected documents.
- Required verification.
- Approval status.
- Release date.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.