Required documents

This page provides detailed guidance on each document type recognised by CRA Evidence. Each document type maps to one or more CRA obligations. Anchor IDs match the doc_type values used in the application, enabling deep links from the product documentation interface directly to the relevant guidance below.

---

Vulnerability handling policy

CRA reference: Annex I Part II (vulnerability handling obligations, points 1 to 8)

Scope: product-level, applies to all versions

Purpose: demonstrates that you have a systematic, repeatable process for identifying, evaluating, and remediating vulnerabilities across all your products. This document is reviewed by market surveillance authorities as primary evidence of your vulnerability management maturity.

Key elements to include

• Scope: which products, software components, and firmware versions are covered

• Vulnerability sources: internal discovery, automated SBOM-based scanning, external researcher reports, national CVE databases, threat intelligence feeds

• Severity classification methodology: CVSS v3.1 or v4.0 base score, EPSS probability enrichment, product-specific contextual modifiers

• Remediation SLAs by severity:

  Severity	Target remediation time
  Critical (CVSS ≥ 9.0)	7 days
  High (CVSS 7.0 to 8.9)	30 days
  Medium (CVSS 4.0 to 6.9)	90 days
  Low (CVSS < 4.0)	Next scheduled release

• Security advisory process: how and where you publish security advisories (CVE IDs, CVSS scores, affected versions, patches, workarounds)

• ENISA notification triggers: criteria for classifying a vulnerability as "actively exploited" requiring Article 14 notification. See ENISA notifications.

• SBOM maintenance: How the SBOM is updated when components change

• Roles and responsibilities: Who owns vulnerability triage, who approves public disclosure, who communicates with ENISA

• Interaction with coordinated disclosure: How externally reported vulnerabilities enter the triage workflow

• Policy review cycle: Minimum annually and after any significant incident

Category requirements

---

User manual: security section

CRA reference: Annex II (information and instructions for the user)

Scope: product-level, applies to all versions

Purpose: CRA Annex II mandates specific information that manufacturers must provide to users. This document type captures the security-relevant content from the product's user documentation.

Key elements to include

All of the following are mandatory under Annex II:

• Name and address of the manufacturer (and authorised representative where applicable)
• Product identifier: name, model, version range, type
• Contact point for vulnerability reports: email address, web form URL, or reference to your coordinated vulnerability disclosure policy
• Support period: start date, end date (or end-of-life policy), and what "support" means in practice
• Instructions for secure setup: network configuration, default credential handling, required hardening steps
• Instructions for secure use: ongoing operational security guidance, monitoring recommendations
• Security update process: how to check for updates, how to apply them, how to verify authenticity
• SBOM availability: where users can access the current SBOM, or a statement that it is available on request
• Notification of end-of-support: commitment to notify users at least 12 months before support end

Category requirements

---

Coordinated vulnerability disclosure policy

CRA reference: Annex I Part II § 5; ISO/IEC 29147:2018

Scope: product-level, applies to all versions

Purpose: creates a structured, publicly accessible channel through which security researchers and users can report vulnerabilities to you. The CRA requires manufacturers to "facilitate the reporting of vulnerabilities" (Annex I Part II § 5); a published CVD policy is the standard mechanism for meeting this obligation.

Key elements to include

• Disclosure channel: dedicated security email address (e.g. security@example.com), bug bounty platform, or security.txt at /.well-known/security.txt
• Encryption: PGP public key for encrypted report submission (strongly recommended)
• Report format: what information to include (product name, version, reproduction steps, impact assessment, proof-of-concept if any)
• Acknowledgment commitment: your target time for acknowledging receipt (recommendation: 5 business days)
• Triage timeline: expected time to assess severity and confirm validity
• Remediation commitment: your general approach to timelines (may reference your vulnerability handling policy)
• Safe harbour statement: explicit commitment not to pursue legal action against good-faith security researchers acting within the policy scope
• Credit: how researchers can request attribution in security advisories
• Coordinated disclosure process: when and how you will publish the advisory, and commitment to notify the reporter before public disclosure
• Out of scope: what you will not accept reports for (e.g. DDoS, social engineering, third-party services)

Category requirements

---

Secure development lifecycle policy

CRA reference: Annex I Part I (security requirements: design, development, and maintenance)

Scope: product-level, applies to all versions

Purpose: provides evidence that security is systematically embedded in your development process. Annex I Part I obliges manufacturers to "design, develop and produce products with digital elements in such a way that they ensure an appropriate level of cybersecurity". This document explains how you fulfil that obligation.

Key elements to include

• Threat modelling: methodology used (STRIDE, PASTA, LINDDUN), when it occurs in the development cycle, who participates, how findings are tracked
• Secure coding standards: standards or guidelines mandated (OWASP Top 10, CERT C, SEI CERT, company-specific), and how compliance is verified
• Code review requirements: mandatory peer review, security-focused review triggers (authentication changes, crypto, network interfaces), review checklist
• Dependency management: process for evaluating new third-party components, SBOM generation, vulnerability monitoring for existing dependencies
• Static analysis (SAST): tools used, when they run (CI gate, pre-merge, scheduled), threshold for blocking a release
• Dynamic analysis (DAST): tools, scope, frequency
• Penetration testing: frequency (minimum annually for Class I+), scope, internal vs external, how findings are tracked to closure
• Vulnerability integration: how findings from all sources feed into the development backlog with appropriate priority
• Security training: required training for developers, frequency, topics covered
• Secrets management: how credentials and keys are managed in development (no hardcoded secrets)
• Policy review cycle: minimum annually, and after significant incidents or architecture changes

Category requirements

---

Update mechanism documentation

CRA reference: Annex I Part I §§ 2.10, 4.1, 4.2

Scope: product-level, applies to all versions

Purpose: demonstrates that the product has a secure mechanism for receiving and applying security updates, and that the update process itself cannot be exploited. §§ 4.1 to 4.2 of Annex I require that manufacturers can deploy security updates even to products already in the field.

Key elements to include

• Update delivery mechanism: over-the-air (OTA), app store, package manager, manual download, or a combination
• Cryptographic signing: algorithm used to sign update packages, how the signature is embedded, how the receiving device verifies it before applying
• Certificate chain and trust anchors: root of trust, certificate pinning approach, certificate rotation process
• Rollback capability: whether the product supports rollback to a previous version, under what conditions, and whether rollback can be disabled for security-critical updates
• User notification: how users are informed that an update is available (in-app notification, email, push notification)
• Forced vs user-controlled updates: your policy, particularly for critical security patches
• Bandwidth and connectivity considerations: behaviour when connectivity is intermittent, update resume support
• Update server infrastructure: availability SLA for the update distribution infrastructure
• Emergency patch process: accelerated process for deploying critical patches outside the normal release cycle
• End-of-support behaviour: what happens to the update mechanism after the support period ends

Category requirements

---

Cybersecurity risk assessment

CRA reference: Annex VII (technical file contents); Annex I Part I § 1 ("integrated and documented cybersecurity risk assessment")

Scope: version-specific, must reflect the specific software version, hardware revision, or product variant

Purpose: the risk assessment is the analytical core of the technical file. It documents how you identified threats, evaluated risks, and selected countermeasures for a specific product version. It is the primary document a notified body or market surveillance authority will review to assess the depth of your security analysis.

Key elements to include

• Product scope and version: exact product name, version number or range, hardware revision if applicable, intended deployment environment
• Methodology: risk assessment framework applied (ISO/IEC 27005, IEC 62443-3-2, ETSI EN 303 645, STRIDE-based threat modelling, or equivalent)
• Asset inventory: data assets (PII, credentials, configuration), functional capabilities (control, sensing, communication), and their value/criticality
• Threat actors and attack scenarios: relevant adversary types (opportunistic, targeted, insider, supply chain), specific attack scenarios analysed
• Vulnerability and weakness analysis: weaknesses in the product architecture, component vulnerabilities identified via SBOM scanning, residual weaknesses accepted
• Risk register: for each scenario, likelihood, impact, inherent risk rating, controls applied, residual risk
• Security controls: technical controls (authentication, encryption, access control, logging), process controls (incident response, vulnerability patching)
• Harmonised standards or specifications applied: EN 18031, IEC 62443, ETSI EN 303 645, OWASP ASVS, etc.
• Residual risk acceptance: formal statement of accepted residual risks, rationale, and responsible signatory
• Review and approval: date, reviewers, approver(s)

Category requirements

---

EU declaration of conformity

CRA reference: Article 28; Annex VI (content requirements)

Scope: version-specific, must be drawn up for each product version placed on the market

Purpose: the EU declaration of conformity is the manufacturer's formal legal statement that the product meets all applicable CRA requirements. It is the document that legally authorises CE marking. It must be available to market surveillance authorities on request and must be kept for the technical file retention period (10 years minimum).

Mandatory content (Article 28 / Annex VI)

The EU DoC must contain all of the following:

Danger: The EU DoC must reference specific product versions and the actual assessment performed. A template document not tied to a specific version, or one that references standards not actually applied, is not legally compliant and may result in market surveillance action.

Category requirements

---

Third-party audit report

CRA reference: Annex III (Class II and Class I without harmonised standards); Annex IV (Critical)

Scope: version-specific, issued by the notified body for the assessed product version or type

Purpose: for Class II and Critical products, a notified body's assessment report (or EU-type examination certificate) is a mandatory component of the technical file. For Class I products choosing a third-party route, it replaces the self-assessment evidence.

Key elements to include

• Notified body identification: name, country, notification number, scope of notification
• Product identification: exact product name, version, type designation
• Assessment scope: modules assessed (B, C, H), CRA provisions examined
• Methodology: standards and specifications applied, test methods used
• Findings: summary of conformance findings, non-conformities identified, and how they were resolved
• Certificate or opinion reference: unique certificate number, issue date, expiry date (if applicable)
• Conditions or limitations: any conditions on the certificate (e.g. specific deployment configurations, firmware version constraints)
• Auditor details: name, qualifications, signature
• Validity: date of issuance and any renewal requirements

Category requirements

---

See also

• Documentation guide. How to upload and manage documents in CRA Evidence.
• Conformity assessment. Which assessment procedure applies to your product category.
• Technical file export. Compile all your documents into a complete Annex VII technical file.
• Understanding the CRA. Product categories, core requirements, and the full obligation overview.