Article 31 CRA technical documentation: requirements and evidence

What Article 31 technical documentation requires under the Cyber Resilience Act

If your product launches in the EU, the Annex VII technical file must exist before the product is placed on the market, and it must stay current for the whole support period. Under Article 31 of Regulation (EU) 2024/2847, the file is the evidence base for your own conformity claim. It records what the product is, how it was designed and built, how vulnerabilities are handled, what risks were assessed, how long security updates will be provided, which standards or solutions you applied, and what testing proved the result. Market surveillance authorities and notified bodies will ask for it first, so it has to be readable by someone who did not write the code. Treat it as a deliverable with an owner and a release date, not as an archive assembled after launch.

The file is hard to produce for three common reasons. Engineering records are scattered across issue trackers, architecture diagrams, CI logs and personal notes, so the file tells a story the codebase does not support. The SBOM is generated once for a release and then left to drift, which conflicts with the vulnerability handling process the file must describe. The support period is often stated in marketing copy but not justified in any internal document, even though the file must show its basis. Before you commit to a launch date, confirm who owns each Annex VII element, where the SBOM is produced and stored, and which document states the support period and its rationale.

A practical first step is to map each Annex VII element to a named source, such as a versioned architecture document, a CycloneDX SBOM kept per release, a coordinated vulnerability disclosure policy and a dated test report. Confirm with your notified body, if one is involved, the language it accepts and the format it expects, because Article 31(4) requires documentation to be in an acceptable language. If you are a microenterprise or small enterprise, check whether the simplified format for Annex VII elements under Article 33(5) applies to you, and confirm its status with the Commission's implementing act before relying on it. Keep the file for at least 10 years after placing on the market or for the support period, whichever is longer.

Which products, teams and third parties the technical file covers

Four scoping questions decide how large the technical file is and who must contribute to it. Each card below covers one decision, and together they show where a manufacturer can reduce the work and where it cannot.

Default, important or critical category

The product's core functionality places it in the default category, in class I or class II of Annex III, or in Annex IV's critical category. The Annex VII elements apply to every category, but the category changes the conformity assessment route, and therefore how much of the file a notified body reviews. Confirm the category against the Commission's technical description of each category before you scope the file, because a misclassified product carries its documentation gaps into the assessment.

One file for several Union acts

Article 31(3) requires a single set of technical documentation where other Union acts also demand technical documentation for the same product. A manufacturer subject to the CRA and another product law should therefore build one file that covers both, rather than two parallel files that drift apart. Ask your legal or regulatory team which other acts apply to the product and whether their documentation content overlaps with Annex VII.

Simplified format for small manufacturers

Article 33(5) allows microenterprises and small enterprises to provide the Annex VII elements in a simplified format, which the Commission sets by implementing act. Notified bodies must accept that format. Confirm the enterprise size category under your national rules and check whether the implementing act is in force before you choose a simplified template, because the content still has to cover every Annex VII element.

Substantial modification restarts documentation

A product placed on the market before 11 December 2027 falls under the regulation only if it is substantially modified from that date. The modified product then needs its technical file updated or drawn up as the regulation requires. Engineering teams should log every release that changes security-relevant architecture, components or support commitments, and have legal review whether each change counts as substantial under the Commission's guidance.

Language acceptable to the notified body

Article 31(4) requires the documentation to be in a language acceptable to the notified body that assesses the product. Where a notified body is required, confirm its accepted languages before drafting, and ask whether it accepts English. Translating a large file late in the process is a common source of avoidable delay, so agree the language in writing during the notified body selection.

Internal teams and third parties

The file draws on engineering for architecture and SBOM data, product security for the risk assessment and vulnerability handling process, legal for the declaration and the support period, and suppliers for component information. Third-party providers, including open-source component maintainers and cloud service operators, may supply data the manufacturer cannot generate alone. Assign one owner for each Annex VII element and confirm in writing which parts an outside firm will prepare.

What the Annex VII file must contain, element by element

A reviewer opening the Annex VII file wants to find, for each element, a document that describes the product as it actually ships, not as it was intended. The general product description should identify the product, its intended purpose, the software and hardware versions it covers, and the ways it is placed on the market, so that a reviewer can tell exactly which build the rest of the file applies to. Design and development information comes next. Reviewers look for a system architecture that shows trust boundaries, network exposure, update and authentication paths, data flows and the third-party components and cloud services the product depends on. A diagram without the matching explanation of how each interface is protected will draw questions, so the architecture document should tie each component to the Annex I requirements it helps satisfy.

The vulnerability handling section is where many files are thin. It needs written process specifications for how the manufacturer identifies, triages, fixes and discloses vulnerabilities, including the SBOM in a machine-readable form and the coordinated vulnerability disclosure policy. Reviewers check that the SBOM matches the shipped build and that the process names owners, tooling and decision points. The cybersecurity risk assessment should show the method, the assets, threats, residual risks and the link to each Annex I requirement applied. The basis for the support period must explain why the period chosen is justified, and it should be consistent with what customers were told. Finally, the file should list the standards or other solutions applied, the test reports supporting each claim, and a copy of the EU declaration of conformity. Confirm with your conformity route owner whether any element is supplied in the simplified format available to microenterprises and small enterprises under Article 33(5), and whether notified body acceptance applies.

How a notified body or market surveillance authority tests the technical file

This table sets out what an assessor is likely to check in the Article 31 technical file, the evidence they would ask to see, and the findings that most often delay a conformity assessment. Read each row as a question the file must answer before the product is placed on the market and kept current through the support period.

Check	Evidence requested	Common findings
File exists before placement	Dated technical documentation covering the Annex VII elements, with the date it was first drawn up and the placing-on-market date	File drawn up after launch, or assembled only when an assessor asks for it
File matches the shipped version	Product version or release identifiers in the file, mapped to the build or firmware actually supplied to users	Architecture diagrams and test reports describe an earlier release than the one on the market
SBOM and risk assessment agree	The SBOM for the shipped version, and a risk assessment that names the same components, interfaces and dependencies	Components in the SBOM are absent from the risk assessment, or the assessment relies on components no longer shipped
Vulnerability handling process is specified	Process description including the SBOM maintenance steps and the coordinated vulnerability disclosure policy, with named roles	Process exists only as informal practice, or the disclosure policy does not match the handling steps
Support period basis is stated	A written statement of the support period and the reasoning behind it, linked to the product's expected use	Support period is missing, or stated without any basis an assessor can follow
Standards and solutions identified	List of harmonized standards, common specifications or other solutions applied, with a note where none were applied in full	Standards cited generically, or cited without showing how each requirement was addressed
Test reports and declaration	Test reports tied to the shipped version and a copy of the EU declaration of conformity	Test reports predate the final build, or the declaration does not reference the file
File is in an acceptable language	Documentation in a language the notified body accepts, confirmed with the body before work starts	Documentation supplied only in a language the body has not accepted, causing rework

How to build the technical file before market placement

This sequence turns Annex VII into a working file, built in order from scoping to a dated, version-controlled record that supports the EU declaration of conformity. The file is completed before the product is placed on the market and then kept current for the whole support period.

Confirm product scope and classification
Start by fixing the exact product, its version, its intended purpose and its boundaries, including hardware, firmware, software and any remote data processing that belongs to it. Confirm whether the product is default, important (class I or II) or critical, because that decides the conformity route and how much third-party evidence the file needs. Output: a scope statement and a classification note, approved by the person accountable for product compliance. The step is done when every later document refers to the same product identifier and version.
Write the general product description
Draft the general description the Annex VII file opens with: intended purpose, the main functions, the software and hardware components, the versions in use, and the conditions of normal use. Keep the description factual and consistent with the user documentation and marketing claims, since assessors will compare them. Output: a dated product description document with a version number and an owner. The step is complete when product management and engineering have both signed off that it matches the shipped product.
Record design, development and architecture
Document how the product was designed and built, including the system architecture, data flows, trust boundaries, external interfaces, authentication paths and the third-party services the product depends on. Diagrams should map to the components listed in the SBOM so the two records can be checked against each other. Output: an architecture record with diagrams, a component inventory and a list of external dependencies. The step is done when an engineer outside the project can trace a data flow from input to storage using only this record.
Document vulnerability handling and link the SBOM
Set out the vulnerability handling process specifications the file must contain: how components are tracked, how vulnerabilities are triaged, how fixes are released, and how coordinated vulnerability disclosure works. Generate the software bill of materials for each release and attach it as a linked artifact rather than a pasted copy, so that a version change produces a new, traceable SBOM. Tools such as OWASP Dependency-Track consume and produce CycloneDX SBOMs and VEX, which can help keep component and vulnerability records aligned. Output: a vulnerability handling procedure, a disclosure policy and a versioned SBOM for each release. The step is done when each shipped release maps to exactly one SBOM.
Complete the cybersecurity risk assessment
Record the cybersecurity risk assessment that underpins the Annex I essential requirements: the threats considered, the assets and functions at risk, the likelihood and impact reasoning, the controls chosen and the residual risks accepted. The assessment should explain why each Annex I requirement is met or why it does not apply. Output: a dated risk assessment with a risk register, signed by the accountable owner and linked to the architecture record. The step is complete when every residual risk has a named decision maker and a review trigger.
State the support period basis and standards applied
Document the basis on which the support period was set, including the expected product lifetime and what customers can reasonably expect, and explain how that basis was chosen. List the harmonized standards, common specifications, certification schemes or other solutions applied, and state where any of them were only partly applied. Output: a support period justification and a standards register with version references. The step is done when a reviewer can see, for each Annex I requirement, which standard or solution was used or why none was.
Attach test reports and the declaration
Assemble the test reports that show the product meets the requirements, including security testing, penetration test results, fuzzing or code review outputs and the remediation records for findings. Add a copy of the EU declaration of conformity for the version in question. Check that every test report names the product version it covers and that the declaration matches the file. Output: a test report set indexed against the Annex I requirements, plus the declaration copy. The step is done when no test result is orphaned from a product version and each finding has a closure record.
Version, date and retain the file
Put the complete file under version control, so every change records what changed, when and by whom, and so earlier states can be compared or restored. Store the file in a system with access controls and an audit trail, and set a retention rule that keeps it for at least 10 years after placing on the market or for the support period, whichever is longer. Confirm the language the notified body will accept if one is involved. Output: a dated, versioned file with a retention schedule and a maintenance owner. The step is done when the file can be reproduced for any released version and a review cycle is assigned for the full support period.

Keeping the file current through the support period and the retention window

Before a product with digital elements is placed on the market, the manufacturer must have the Annex VII technical documentation drawn up. Under Article 31(1) and (2), that file must contain at least the Annex VII elements and must be updated where appropriate during the support period, so the starting version is the baseline every later change is measured against. For a new product, the file records the design as it was when the product was released, including the architecture, the SBOM, the risk assessment and the basis for the support period you chose.

Baseline version: Freeze the first complete file with a date, product version and approver so later changes can be compared against it.
Support period basis: Record why the support period is what it is, since that basis drives how long the file must be maintained.
Declaration linkage: Keep the copy of the EU declaration of conformity in the same file so the two cannot drift apart.
Language check: Confirm the language required by a notified body if one is involved, under Article 31(4).
Single file rule: If other Union acts also require technical documentation, Article 31(3) allows one set, so avoid parallel copies.

Before release, ask your team to confirm that every Annex VII element has a named owner and a stored source document.

Evidence artifacts that satisfy each technical file element

The Annex VII technical file is only as credible as the records behind it. The artifacts below are the ones an assessor or notified body will most likely ask to see, and each one needs an owner and a update rule that runs with every release, not just before placing on the market.

Versioned architecture documents

The system architecture and design information in the technical file must match the product as shipped. Store architecture diagrams, data flow descriptions and trust boundaries in a wiki or document repository with change history, so each release can be traced to the design it was built against. Check that the version in the file matches the released build, and that you can compare two versions and roll back to an earlier one. Treat version control and rollback as properties to verify in your own tool configuration, not as guarantees from the software.

CycloneDX SBOM and VEX records

The vulnerability handling process specification must include the SBOM. Generate a CycloneDX SBOM for every release in your build pipeline and archive it with the build number. Pair it with VEX statements that record whether each known vulnerability affects your product, so the file explains exposure rather than only listing components. OWASP Dependency-Track can ingest and produce both formats and track license use by SPDX identifier, which helps with component due diligence. Confirm which components it cannot see, such as firmware blobs or vendor binaries.

Cybersecurity risk assessment register

The risk assessment is the basis for applying the Annex I essential requirements, so the register must show the threats considered, the risk scenarios, the decisions taken and the residual risk accepted. Keep one register per product or product family, with each entry linked to the requirement it supports and the release in which the control was changed. Review entries when the architecture or SBOM changes. Ask who signs off on accepted residual risk and where that approval is recorded.

Support period statement

The file must state the basis for the support period, meaning the reasoning behind the period you commit to and how users learn of it. Record the start date, the end date or the rule that sets it, and the update channel you use to communicate it. Revise the statement when the product's support commitment changes, and keep the earlier version so you can show what users were told at each point. Confirm the current guidance on support periods with your assessor before fixing the basis.

Test reports and standards applied

Test reports show that each essential requirement was checked against the product, and the standards or solutions applied show how. Store reports with the build identifier, test date, tester and scope, and list the harmonized standards or common specifications used where they apply. Re-run tests for each release that changes security-relevant code, and mark reports superseded rather than deleting them. Independent penetration test reports are useful evidence, but confirm with your assessor how they are weighed.

Signed EU declaration of conformity

The file must contain a copy of the EU declaration of conformity, which the manufacturer issues and signs. Keep the signed version, the version of the product it covers and the date, and reissue it when the product changes in a way that affects conformity. Only the manufacturer issues this declaration, so do not let a consultant or auditor sign on your behalf. Confirm with your notified body or market surveillance contact how they expect the copy to be filed.

What building and keeping the technical file costs

This table lists the cost components of an Annex VII technical file, who is paid for each, whether it is one-time or recurring, and what drives it up or down. Read the recurring rows as the costs that continue through the support period, because the file must be kept current and retained for at least 10 years under Article 13(13). Ask every quote to price each row separately so you can see where open-source tooling removes license spend.

Cost component	Who is paid	One-time or recurring	Drivers and how to reduce them
Architecture and design documentation	Internal engineers, or an outside architect if the team lacks capacity	One-time, then updated per major change	Size and number of components, and how current the architecture diagrams already are. Keep them in version-controlled docs from the start.
Cybersecurity risk assessment	Internal security team, with an external reviewer if independence is wanted	One-time, then reviewed each release	Number of threat scenarios and product variants. Reuse a single risk register across variants to limit repeat work.
SBOM generation and tooling	Engineering time for the build pipeline, plus any commercial SBOM or license scanning subscription	Setup is one-time, running cost is recurring	Number of build pipelines and languages. Self-hosted open-source tools such as OWASP Dependency-Track can remove recurring license spend, but still need hosting and maintenance time.
License compliance tracking	Legal or compliance staff, plus any licensed scanning product	Recurring	Number of third-party and open-source components and their license mix. Track SPDX license IDs per component to reduce manual review.
Vulnerability handling process records	Product security or PSIRT staff, and tooling for tracking advisories	Process design is one-time, records are recurring	Volume of vulnerability reports and advisories. Keep one record per finding so the file can show handling over the support period.
Evidence upkeep per release	Release engineering and QA, to capture test reports and updated documentation	Recurring with every release	Release frequency and the degree of automation in test capture. Automated pipelines that archive test output cut manual effort.
Support period basis and standards mapping	Product management and compliance staff	One-time, then reviewed when support terms change	Number of support commitments and standards applied. Confirm the current Commission guidance before finalizing the basis.
External testing or review	Independent penetration tester or security reviewer	Recurring, usually per major release or per assessment cycle	Product scope, attack surface and whether the test is needed for evidence or only for internal assurance. Ask the tester to state exactly what the report will and will not cover.
Notified body review (where required)	The notified body, which charges for its conformity assessment	One-time per assessment, with re-assessment when the product changes	Applies only on routes that require a notified body. Ask the body for its written fee basis, the documentation language it accepts under Article 31(4), and how changes are re-assessed.

Who writes the file, who prepares it and who reviews it

The manufacturer owns the technical file, the product, the cybersecurity risk assessment and the EU declaration of conformity. Under the regulation, responsibility for the documentation stays with the manufacturer even when outside specialists build parts of it. Your team decides what the product is, what the support period is based on, and which standards or solutions were applied, then signs off on every element of the file.

Product and risk decisions: Product owners and security leads set the product description, the intended use and the risk assessment conclusions.
Support period basis: Product management documents why the chosen support period is justified and keeps it current.
Declaration: Only the manufacturer's authorized representative signs the EU declaration of conformity.
Sign-off record: Keep a dated approval trail for each version of the file.
Keeping the file: Someone inside the organization must own retention for at least 10 years or the support period, whichever is longer.

Before engaging anyone, confirm internally who holds each of these decisions in writing.

Where technical files usually fall short and how to close each gap

Most weak Article 31 technical files fail for the same few reasons: the file arrives too late, the documents disagree with each other, or the file cannot be read by the people who need it. Each card below names one gap, why it matters under the regulation, and the fix to put in place before the product reaches the market.

File written after launch

Article 31 requires the technical documentation to be drawn up before the product is placed on the market, then kept up to date at least during the support period. Teams often assemble the file from release notes and tickets once a customer or authority asks for it. Fix this by making the file a release gate: no product version ships until its Annex VII elements exist, are dated, and are linked to the build being released.

SBOM does not match the shipped build

Annex VII asks for the vulnerability handling process specifications, including the SBOM, so the component list in the file must describe what customers actually receive. A common failure is an SBOM generated from a development branch or an earlier tag. Generate the SBOM from the artifact in the release pipeline, store it with the build identifier, and feed it into a tool such as Dependency-Track so that later vulnerability findings map to the correct version.

Support period undefined

The file must explain the basis for the support period, and that period sets how long the documentation is maintained and how long it must be kept. Many files state a support period without showing how it was chosen. Record the basis in writing, such as the expected product lifetime, the support commitments made to customers, and the update policy, and confirm the chosen period with legal counsel and the notified body before it appears in the declaration.

Risk assessment disconnected from test reports

The cybersecurity risk assessment should drive which Annex I requirements apply and which tests prove they are met. When the risk assessment lists threats that no test report addresses, or test reports cover controls the risk assessment never mentions, an assessor sees two documents that do not describe the same product. Add a traceability table that links each identified risk to the requirement it affects and the test report that verifies it.

File in a language the notified body cannot read

Article 31(4) requires documentation supplied to a notified body to be in a language acceptable to that body. Files written in one language and machine translated later often contain inconsistent terms for the same component or control. Ask the notified body which languages it accepts before drafting, keep one master version, and have a qualified translator check the translated sections against the source for technical accuracy.

No retention plan

Article 13(13) requires technical documentation to be kept for at least 10 years after the product is placed on the market or for the support period, whichever is longer. Teams often store files in personal drives or in a system that loses old versions. Assign an owner, place the file in a versioned repository with access control, and set a review date that checks the file still opens, matches the released build and has not been deleted by a routine clean-up.

Questions buyers ask about CRA technical documentation

How long does it take to build CRA technical documentation?

No duration has been established for this, so the answer depends on the product and on how much of its engineering record already exists. The file must be drawn up before the product is placed on the market and kept up to date at least for the support period (Article 31). Work runs longest when the product has no architecture document, no component inventory and no written vulnerability handling process, because each of these must exist before the rest can be written. Ask any partner for a written plan that lists each Annex VII element, the source of its information, and the review points with your engineering and legal leads. Confirm the timeline against the scope agreed in writing before work starts.

How much internal effort does a CRA technical file require?

Effort depends mainly on how many elements already exist and how many products share a platform. The Annex VII file covers a general product description, design and development information including the system architecture, the vulnerability handling process with the SBOM and coordinated vulnerability disclosure policy, the cybersecurity risk assessment, the basis for the support period, the standards or solutions applied, test reports and a copy of the EU declaration of conformity. Each element draws on different people: engineering for architecture and SBOM, security for the risk assessment and tests, and product management for the support period. The recurring cost is the one teams most often underestimate, because the file must be updated during the support period, so each release needs a documentation step. Ask for effort broken down by element and by role.

Can a microenterprise use the simplified CRA technical documentation format?

Yes, if the manufacturer qualifies as a microenterprise or small enterprise. Article 33(5) allows those manufacturers to provide the Annex VII elements in a simplified format that the Commission sets by implementing act, and notified bodies must accept that format. Confirm the enterprise size test in the regulation's definitions, and check whether the implementing act covering the simplified format is in force before you rely on it. The simplified format changes how the elements are presented, while the underlying risk assessment, vulnerability handling process and test evidence still have to exist. Ask your advisor which elements the simplified format covers for your product and how they map to the full Annex VII file.

How long must CRA technical documentation be kept?

Keep it for at least 10 years after the product is placed on the market or for the support period, whichever is longer (Article 13). For products with long support periods, the support period is often the governing figure, so do not set the retention clock from the release date alone. Retention also affects storage: keep each SBOM version, test report and declaration tied to the product version it describes, so an authority or notified body can see what was true when the product was placed on the market. Assign an owner for the archive and document how records are protected and retrieved. Confirm the exact start date and end date for your product with counsel.

Can one technical file cover the CRA and other EU product laws?

Yes, when another Union act also requires technical documentation. Article 31(3) requires a single set of technical documentation covering those requirements, so you should not keep parallel files for the same product. The combined file still has to contain every element that each act lists, so check each act's required content before you merge anything. Map the overlapping items, such as the risk assessment, test reports and declarations, and note the gaps where one act asks for something the others do not. Language is a separate point: Article 31(4) requires documentation to be in a language acceptable to the notified body. Confirm which other acts apply to your product before you combine the files.

What does the internal team need to provide for the file?

The internal team owns the facts the file records, so it has to supply them. Expect to provide the product description and intended use, architecture diagrams and design decisions, the build and release pipeline, the component inventory that feeds the SBOM, the vulnerability handling process as it is actually run, the patch and incident history, and the support period decision with its basis. Someone with authority must approve the risk assessment and the test results before the declaration is issued. Name these owners before work starts and agree how often they review each section. A short record of what the team really does is stronger evidence than a long document describing a process nobody follows.

Can an implementation partner build CRA technical documentation alone?

A partner can prepare the file, but it cannot own it. The manufacturer is responsible for the product's conformity and issues the EU declaration of conformity. DeployOpen works inside the client's own infrastructure and prepares systems, controls and evidence, including SBOM generation, test execution and the structure of the documentation, but it does not issue audit reports, attestations or certifications. The client keeps the decisions on the risk assessment, the support period and the declaration. Building the file without outside help is possible if you have engineering, security and legal capacity available for the whole build. Ask any partner for a written scope that lists which Annex VII elements it prepares and which the internal team must review and approve.

How DeployOpen prepares the technical file for assessment

DeployOpen helps manufacturers assemble the Article 31 technical file from the systems they already run, in their own infrastructure. We prepare the architecture records, vulnerability handling evidence, SBOM workflows and test reports that the Annex VII elements call for, while the manufacturer keeps ownership of the product, its risk assessment and its declaration.

How we scope

We agree in writing which products, versions and Annex VII elements the technical file will cover.
We confirm which other Union acts also require technical documentation, so one shared file can serve both.
We confirm with the manufacturer whether the simplified format for microenterprises or small enterprises applies, and which language the notified body accepts.

How we build

We document the system architecture and development information from the actual repositories, pipelines and deployment setup.
We set up SBOM generation and tracking with CycloneDX output and SPDX license identifiers, so component records stay current.
We run existing security tests and collect their reports, then map each result to the Annex VII element it supports.

How we hand over

We deliver the technical file as a versioned document set, with a record of changes, authors and dates.
We give the manufacturer a written index that maps each Annex VII element to its source document and evidence.
We agree with the manufacturer who keeps the file, how long it is retained, and who reviews it before submission to any assessor.

How we support

We can keep the technical file current through ongoing support and upgrade work for the full support period, available as a retainer.
We can update the SBOM, risk assessment inputs and test reports when a component or product version changes.
We confirm with the independent auditor or notified body what format and depth they expect, since they alone assess and issue conformity outcomes.