Most teams meet the CRA's documentation duties as a gate. Assemble the technical file, sign the Declaration of Conformity, affix the CE mark, ship. The file goes into a folder and the team goes back to building product. It is an understandable reading, because that is how one-off certification regimes work. It is not how the CRA works. The regulation's text attaches the documentation duty to the whole support period, and a file that was accurate at CE marking but describes last year's product is a finding waiting to be made.
This post covers what the regulation says about keeping documentation current, which events oblige an update, and what a workable maintenance cadence looks like. It builds on the technical documentation evidence requirements, which covers what the file must contain, and the artifact dependency chain, which covers how the documents feed each other.
Three documents with an explicit update duty
The CRA names three documents that must be kept current, each with its own wording.
The technical documentation carries the strongest formulation. Article 31(2) requires it to be drawn up before the product is placed on the market and then "continuously updated, where appropriate, at least during the support period." Two things in that sentence deserve attention. "Continuously" rules out the annual-binder reading. And "at least during the support period" sets a floor. The duty does not expire when the file is first assembled, it runs for as long as the product is supported, which under Article 13(8) is a minimum of five years unless the product's expected lifetime is genuinely shorter.
The cybersecurity risk assessment has its own clock. Article 13(3) requires it to be documented and "updated as appropriate" during the support period, and Article 13(4) folds it into the technical documentation. Since the assessment must reflect the product's intended purpose, reasonably foreseeable use and operational environment, any material change to those inputs makes the recorded assessment wrong until it is updated. An assessment that still describes the architecture from two releases ago fails this test even though nothing in it was ever incorrect when written.
The EU Declaration of Conformity closes the set. Article 28 requires it to be kept up to date. The DoC asserts that the product satisfies the essential requirements, so anything that changes the basis of that assertion, a new conformity assessment, a revised standards list, a changed support period, means the declaration must be refreshed to match.
The events that trigger an update
The regulation does not hand out a review calendar. It defines the conditions under which documentation goes stale, and four kinds of event do most of the work.
New releases are the everyday case. Every software version that changes functionality, interfaces or dependencies potentially invalidates parts of the file, the architecture description, the SBOM, the risk assessment's asset list. Most releases will need only targeted edits, but the check has to happen.
Substantial modification is the sharp case. Under Article 32 read with the Commission's guidance, a change that affects the product's compliance with the essential requirements, or that alters its intended purpose, makes the modified product legally a new product. That means a fresh conformity assessment, an updated technical file, a new Declaration of Conformity, before the modified version is placed on the market. The dividing line between an ordinary update and a substantial modification is a judgment call the manufacturer must make and be able to defend, which is itself a reason to record the assessment content at each placing on the market, so there is something concrete to compare against.
Threat and vulnerability events form the third class. The risk management framework the CRA points to, reflected in clause 6.7.3 of the assessment methodology, expects a re-review of the risk assessment when the threat landscape shifts, when a relevant vulnerability is disclosed in a component, or when a security incident touches the product. A critical CVE in a library on the product's SBOM is exactly such an event. So is a credible vulnerability report arriving through the manufacturer's own disclosure channel.
Support period changes are the quiet fourth. The support period appears in the Annex II user information and anchors several obligations. Extending it, shortening it, or letting it lapse without informing users are all documentation events. Article 13(8) expects users to know where support stands.
Stale documentation is directly inspectable
What gives these duties teeth is Article 13(13). The manufacturer must keep the technical documentation and the EU Declaration of Conformity at the disposal of market surveillance authorities for at least ten years after the product is placed on the market, or for the support period, whichever is longer. An authority that requests the file receives whatever state it is actually in. If the file describes a product three versions out of date, the mismatch is visible on the first comparison with the shipping product, and the burden of explaining it falls on the manufacturer.
This is also why point-in-time records matter. A manufacturer that captures the state of its assessment at each placing on the market and each substantial modification can show an authority exactly what was true when, and can show that later changes flowed into later records. A manufacturer with one continuously overwritten document can show only the present.
A cadence that works in practice
The regulation's own logic suggests a dual cadence, and the risk management standards it leans on (ISO 31000, IEC 62443) say the same thing. A time-based baseline review catches gradual drift that no single event flags. An event-driven review catches the sudden changes between baselines. In practice that means four habits.
First, declare a review regularity and follow it. The assessment methodology expects a documented review interval for the risk management activities, quarterly where elevated residual risks remain in the register, semi-annual where everything is actively mitigated. The declared interval is itself part of the technical file, which means an auditor can check whether it was honoured. A file that promises quarterly reviews and shows none is self-documented non-conformity.
Second, tie documentation checks to the release process. The question "does this release change the file" belongs in the definition of done, and the substantial-modification question belongs in release planning, before the modified product ships rather than after.
Third, record trigger events when they happen, then close them. A CVE match, a disclosed vulnerability, a shifted threat picture. Each becomes a recorded item that stays open until the re-review it demands has been done. The record of raised and resolved triggers is the evidence that monitoring feeds back into the assessment, which is what clause 6.7.3 is really asking for.
Fourth, snapshot at the legal moments. Placing on the market and substantial modification are the two points where the regulation cares precisely what the documentation said. An immutable, versioned capture at each of those moments, retained for the Article 13(13) window, turns a future inspection from an argument into a lookup.
How this works in CRA Portal
The product workspace in CRA Portal implements this cadence rather than leaving it to calendar discipline.
Each product runs a periodic review clock. The cadence is read from the product's own review-regularity artifact, the C6.7 document the workspace drafts from the risk register, and can be overridden explicitly. Once the product has a placing-on-market snapshot, the clock runs. A reminder email goes out thirty days before the review is due and again if it goes overdue, and marking the review complete stamps the date, moves the next due date and files an append-only review record, who reviewed, when, at what cadence, as exportable evidence that the declared regularity is practised.
Review triggers are recorded in the same place, and the platform raises some of them itself. A supply-chain scan that finds a critical, high-severity or actively exploited vulnerability in an SBOM component opens a trigger on each assessed product, and a vulnerability report arriving through the company's disclosure portal opens one when it is triaged as real. Triggers left open two weeks without action get a nudge. Closing them is part of completing the review.
Staleness is detected on change as well as on time. Every export sign-off is bound to a hash of the assessment content, so any edit after approval marks the sign-off stale and locks the technical-file export until a second reviewer looks again. The same hash is captured in each snapshot, so when the assessment content drifts from the last placing-on-market record, the workspace shows a possible-substantial-modification hint and points at the snapshot and re-assessment flow. The judgment stays with the manufacturer, the drift detection does not.
The support period gets a countdown. Ninety and thirty days before the declared support end date, the workspace warns and email reminds, with a pointer to the Annex II sheet where the end-of-support notice to users belongs.
None of this makes documentation current by itself. It makes staleness visible early, which is the part calendar discipline reliably fails at. The Annex VII explainer covers what the file must contain, and the artifact chain post covers how an update in one document propagates to the rest. The pattern across all of it is the same. Under the CRA, documentation is maintained like the product it describes, on a cadence, with triggers, and with a record of every revision.