The technical file is your evidence package for CRA compliance. Market surveillance authorities will request it. Notified Bodies will examine it. Without a complete technical file, you cannot legally place your product on the EU market.
This guide breaks down Annex VII section by section, explaining what each requires and how to prepare it.
Summary
- Technical file documents how your product meets CRA essential requirements
- Must be prepared before market placement, kept for at least 10 years after the product is placed on the market, or for the support period, whichever is longer (Article 13(13))
- Contains: product description, risk assessment, design docs, SBOM, test results, conformity evidence
- Authorities can request it at any time, and incomplete files mean non-compliance
- Start early: building a proper technical file takes months, not weeks
What Is the Technical File?
The technical file (also called "technical documentation") is the complete evidence package demonstrating your product complies with CRA requirements.
It's not:
- Marketing documentation
- User manuals only
- A checkbox exercise
It is:
- Comprehensive technical evidence
- Living documentation (updated throughout product life)
- Your defense in market surveillance investigations
- Required for conformity assessment
Important: The technical file must be prepared BEFORE market placement and retained for at least 10 years after the product is placed on the market, or for the support period, whichever is longer (Article 13(13)). Authorities can request it at any time.
Annex VII Structure Overview
The CRA's Annex VII specifies technical documentation requirements:
TECHNICAL FILE STRUCTURE (Annex VII)
1. GENERAL DESCRIPTION
\-- Product identification and intended purpose
2. DESIGN, DEVELOPMENT, VULNERABILITY HANDLING AND PRODUCTION
\-- Security built in, vulnerabilities handled, production and monitoring validated
3. CYBERSECURITY RISK ASSESSMENT
\-- Risks identified and addressed
4. SUPPORT PERIOD INFORMATION
\-- Information used to determine support period (Article 13(8))
5. APPLIED STANDARDS
\-- Standards used and deviations
6. TEST RESULTS
\-- Verification evidence
7. EU DECLARATION OF CONFORMITY
\-- Or copy thereof
8. SOFTWARE BILL OF MATERIALS
\-- Components and dependencies (on reasoned request)
Section 1: General Description
Purpose: Establish what the product is and what it's for.
Required Content
GENERAL DESCRIPTION CHECKLIST
Product Identification:
[ ] Product name and model number
[ ] Hardware version(s)
[ ] Software/firmware version(s)
[ ] Serial number format or range
[ ] Unique product identifier
Intended Purpose:
[ ] Primary function description
[ ] Target users/environment
[ ] Intended use cases
[ ] Not-intended uses (exclusions)
Product Category:
[ ] CRA classification (Default/Important/Critical)
[ ] Justification for classification
[ ] Related product regulations (if any)
Market Information:
[ ] Date of first EU market placement
[ ] Target member states
[ ] Distribution channels
Example
GENERAL DESCRIPTION
Product Name: SmartSense Pro Industrial Sensor
Model Number: SSP-3000
Hardware Version: Rev C (PCB v3.2)
Firmware Version: 2.4.1
INTENDED PURPOSE:
The SmartSense Pro is an industrial environmental sensor
designed for manufacturing facility monitoring. It measures
temperature, humidity, and air quality, transmitting data
via WiFi to cloud or local servers.
TARGET USERS:
- Facility managers
- Industrial automation integrators
- Environmental compliance officers
INTENDED ENVIRONMENT:
- Indoor industrial facilities
- Operating temperature: -10°C to +60°C
- Network: WiFi 802.11 b/g/n
NOT INTENDED FOR:
- Medical or life-safety applications
- Outdoor installation
- Explosive atmospheres
- Consumer/residential use
CRA CLASSIFICATION:
Default product. Not listed in Annex III or IV.
Justification: General-purpose sensor without security
functions or critical infrastructure application.
EU MARKET PLACEMENT:
First placed on market: March 15, 2027
Target markets: All EU member states
Distribution: Direct sales and authorized distributors
Section 2: Design, Development and Vulnerability Handling
Purpose: Document how the product was designed and built, how vulnerabilities are handled after release, and how production and monitoring processes are validated. Annex VII §2 treats these as one block: design and development under §2(a), vulnerability handling processes under §2(b), production and monitoring processes under §2(c).
Design and Development: Required Content
DESIGN DOCUMENTATION CHECKLIST
Architecture:
[ ] System architecture diagram
[ ] Component interaction diagram
[ ] Data flow diagram
[ ] Trust boundaries identified
Security Design:
[ ] Security architecture description
[ ] Cryptographic implementations
[ ] Authentication mechanisms
[ ] Authorization model
[ ] Secure communication protocols
[ ] Data protection measures
Development Process:
[ ] Secure development lifecycle description
[ ] Security requirements traceability
[ ] Code review procedures
[ ] Security testing in development
[ ] Configuration management
Change Management:
[ ] Version control procedures
[ ] Change impact assessment
[ ] Security review for changes
What "Secure by Design" Documentation Looks Like
SECURITY ARCHITECTURE OVERVIEW
1. TRUST BOUNDARIES
+-----------------------------------------+
| Cloud Backend |
| (Authentication, Data Storage) |
\---------------+-------------------------+
| TLS 1.3
+---------------+-------------------------+
| Device Firmware |
| +---------------------------------+ |
| | Application Layer | |
| +---------------------------------+ |
| | Security Services | |
| | (Crypto, Auth, Secure Boot) | |
| +---------------------------------+ |
| | Hardware Security | |
| | (Secure Element, RNG) | |
| \---------------------------------+ |
\-----------------------------------------+
2. AUTHENTICATION
- Device-to-cloud: Mutual TLS with device certificates
- User-to-device: Local API requires authentication token
- Certificate provisioning: Factory-provisioned, unique per device
3. DATA PROTECTION
- Data at rest: AES-256-GCM encryption
- Data in transit: TLS 1.3 with certificate pinning
- Sensitive data: Stored in secure element
4. UPDATE MECHANISM
- Signed firmware updates (ECDSA P-256)
- Signature verification before installation
- Rollback protection via version counter
- Automatic update checks (user-configurable)
Vulnerability Handling: Required Content
VULNERABILITY HANDLING CHECKLIST
Intake:
[ ] Contact methods documented (email, web form, security.txt)
[ ] CVD policy published
[ ] Researcher communication procedures
Process:
[ ] Triage procedures
[ ] Severity assessment methodology
[ ] Escalation paths
[ ] Patch development workflow
[ ] Testing procedures for patches
Communication:
[ ] Customer notification procedures
[ ] Advisory publication process
[ ] ENISA reporting integration (for active exploitation)
Monitoring:
[ ] Dependency vulnerability monitoring
[ ] CVE database monitoring
[ ] Threat intelligence sources
Vulnerability Handling Documentation
VULNERABILITY HANDLING PROCEDURES
1. CONTACT METHODS
Primary: security@company.com
Web Form: https://company.com/security/report
security.txt: https://company.com/.well-known/security.txt
CVD Policy: https://company.com/security/disclosure-policy
2. RESPONSE COMMITMENTS
Acknowledgment: Within 3 business days
Initial Assessment: Within 10 business days
Status Updates: Every 14 days
Resolution Target: 90 days (critical: 7 days)
3. INTERNAL PROCESS
[Flowchart or process description]
See: Process Document PD-VULN-003
4. PATCH DISTRIBUTION
Mechanism: OTA updates via cloud infrastructure
Notification: In-app notification + email to registered users
Verification: Signed updates with rollback capability
5. ENISA REPORTING
Trigger: Active exploitation detected
Timeline: 24h early warning, 72h detailed report
Responsible: Security Team Lead
Process: See PD-ENISA-001
6. HISTORICAL RECORD
Vulnerabilities handled (past 24 months): 3
Average resolution time: 45 days
ENISA reports filed: 0
Production and Monitoring: Required Content
For software products there is no factory line. Annex VII §2(c) maps to the build and release pipeline that produces shippable artifacts, the validation that those processes are working as intended, and the post-deployment monitoring that catches regressions and new vulnerabilities. Document each so an auditor can trace a release back to a verified, reproducible build.
PRODUCTION AND MONITORING CHECKLIST
Build and Release Pipeline:
[ ] Source of truth identified (repository, branch protection)
[ ] Reproducible build documented (toolchain versions pinned)
[ ] Build provenance captured (SLSA level, in-toto attestations)
[ ] Signing keys and key management documented
[ ] Release artifact integrity (signed binaries, SBOM at release)
Validation of Production Processes:
[ ] Security gates in CI documented (SAST, DAST, SCA pass criteria)
[ ] Regression suite covers Annex I-tagged requirements
[ ] Release approval workflow documented
[ ] Rollback plan for failed releases
[ ] Reproducibility audit cadence
Post-Deployment Monitoring:
[ ] Dependency vulnerability monitoring cadence (daily/weekly)
[ ] SBOM diff process on each release
[ ] CVE feed integration (NVD, GHSA, vendor advisories)
[ ] KEV cross-check for active exploitation
[ ] Telemetry for security-relevant events (failed updates, signature failures)
[ ] Customer notification triggers documented
Production and Monitoring Documentation
PRODUCTION AND MONITORING PROCESSES
Product: Industrial Gateway IG-200
Build platform: GitHub Actions on ubuntu-22.04 runners
Provenance: SLSA Level 3 (signed in-toto attestations)
Signing: Cosign + Sigstore, offline KMS-backed root key
BUILD PIPELINE:
1. Source: github.com/example/ig200-firmware (main branch protected,
2-of-N review gate, signed commits required)
2. Build: reproducible cross-compile (rustc 1.78, locked Cargo.lock)
3. SAST: cargo-audit + clippy security lints (gate: 0 high+ findings)
4. SCA: trivy scan against built binary (gate: 0 known-exploitable CVEs)
5. Test: regression suite (1247 tests) + Annex-I conformance suite (89 tests)
6. Sign: cosign sign-blob + attest --predicate slsa-provenance.json
7. Release: artifact + SBOM (CycloneDX 1.5) + DoC excerpt published
VALIDATION OF PROCESSES:
- Pipeline definition reviewed quarterly (Security Lead + Release Manager)
- Annex I conformance test suite reviewed when standards or risks change
- Annual reproducibility audit (independent rebuild from tagged source)
- Failure mode: any gate fails -> release blocked, incident logged
POST-DEPLOYMENT MONITORING:
- Dependency CVE feed: Trivy + Renovate, daily scan against current SBOM
- Threshold: Critical or High with KEV match -> patch within 7 days
- Threshold: Medium without KEV -> patch in next monthly release
- Customer notification: signed RSS feed + email for advisories
- Internal telemetry: failed update events, signature verification failures
- Review cadence: weekly triage, monthly trend review
Section 3: Cybersecurity Risk Assessment
Purpose: Document identified risks and how they're addressed.
Required Content
RISK ASSESSMENT CHECKLIST
Methodology:
[ ] Risk assessment methodology described
[ ] Scope definition
[ ] Asset identification
[ ] Threat identification approach
Risk Analysis:
[ ] Threats enumerated
[ ] Vulnerabilities considered
[ ] Impact assessment
[ ] Likelihood assessment
[ ] Risk ratings
Risk Treatment:
[ ] Treatment decisions for each risk
[ ] Security controls mapped to risks
[ ] Residual risk assessment
[ ] Risk acceptance criteria
Risk Assessment Format
CYBERSECURITY RISK ASSESSMENT
Product: SmartSense Pro (SSP-3000)
Version: 2.4.1
Assessment Date: January 2027
Assessor: [Name, Security Team]
METHODOLOGY:
Based on ISO 27005 adapted for product security.
Risk = Likelihood × Impact
Scale: Low (1-4), Medium (5-9), High (10-16), Critical (17-25)
-------------------------------------------------------------
RISK ID: R-001
THREAT: Unauthorized firmware modification
VULNERABILITY: Unsigned firmware could be installed
IMPACT: High (5) - Device compromise, data breach
LIKELIHOOD: Medium (3) - Requires physical access
INHERENT RISK: 15 (High)
CONTROL: Firmware signature verification
IMPLEMENTATION: ECDSA P-256 signature checked before install
RESIDUAL RISK: 3 (Low) - Cryptographic attack unlikely
STATUS: Mitigated
-------------------------------------------------------------
RISK ID: R-002
THREAT: Man-in-the-middle attack on cloud communication
VULNERABILITY: Network traffic interception
IMPACT: High (4) - Data exposure, command injection
LIKELIHOOD: Medium (3) - Public networks possible
INHERENT RISK: 12 (High)
CONTROL: TLS 1.3 with certificate pinning
IMPLEMENTATION: Hardcoded CA certificate, no fallback
RESIDUAL RISK: 2 (Low) - Certificate compromise unlikely
STATUS: Mitigated
-------------------------------------------------------------
[Continue for all identified risks...]
RISK SUMMARY:
Total risks identified: 23
Critical: 0
High: 3 (all mitigated to Low/Medium)
Medium: 8 (all mitigated to Low)
Low: 12 (accepted or mitigated)
RESIDUAL RISK ACCEPTANCE:
All residual risks are within acceptable tolerance.
Signed: [Security Lead], [Date]
Section 4: Support Period Information
Purpose: Document the reasoning behind the chosen support period, per Article 13(8). The support period is the time during which the manufacturer commits to providing security updates. Annex VII §4 requires the technical file to capture the information that drove that decision.
Required Content
SUPPORT PERIOD DECISION RECORD
Declared Support Period: [start date] to [end date]
Minimum: 5 years from market placement (or product lifetime, if shorter)
Inputs Considered (Article 13(8)):
[ ] Expected use duration of the product
[ ] User and customer expectations
[ ] Nature and intended purpose of the product
[ ] Relevant Union law (sector-specific minimums)
[ ] Guidance issued by the Commission
[ ] Reasonable expectations of consumers and other end users
Documented Justification:
[ ] Comparable product lifetimes in the market
[ ] Component vendor support timelines (OS, runtime, libraries)
[ ] Customer contracts or SLAs that imply update windows
[ ] Hardware end-of-life schedules (if applicable)
What Good Documentation Looks Like
SUPPORT PERIOD DETERMINATION
Product: Industrial Gateway IG-200
Market placement: 2026-09-01
Declared support period: 2026-09-01 to 2034-09-01 (8 years)
Rationale:
1. Expected operational lifetime: 8-10 years (field deployment data,
comparable to predecessor IG-150 still active in 2024 at 9 years).
2. Component support: Linux LTS kernel covers 6 years; we backport
security patches for 2 additional years using vendor commitments.
3. Customer contracts: top 3 customers have 7-year service agreements;
remainder typically renew on 5-year cycles.
4. Sector guidance: NIS2 covers operators of essential services using
this gateway; assume update requirements through asset lifetime.
5. End-of-support communication: documented in user manual and EOL
policy at https://example.com/security/eol.
Decision approved by: [Product Owner], [Security Lead], [Legal]
Date: 2026-08-15
Review trigger: any material change to component support timelines
Common Pitfalls
- Anchoring to the 5-year minimum without justification. The 5 years in Article 13(8) is a floor, not a default. Products with longer expected lifetimes need a longer period.
- Forgetting the floor is "or product lifetime, if shorter". A consumer device sold for 18 months still owes update support for the period the product is reasonably expected to be in use.
- Not recording the inputs. Surveillance authorities can ask how the period was determined. "We picked 5 years" is not an answer.
- Treating it as set in stone. If component support timelines change (e.g., upstream OS reaches EOL earlier than expected), the decision record must be updated and the support commitment communicated.
Mapping Essential Requirements (Annex I)
Purpose: Demonstrate how each Annex I requirement is met.
Annex I, Part I Requirements
Map each requirement to your implementation:
ESSENTIAL REQUIREMENTS COMPLIANCE MATRIX
ANNEX I, PART I - SECURITY REQUIREMENTS
═══════════════════════════════════════════════════════════
1. DESIGNED WITHOUT KNOWN EXPLOITABLE VULNERABILITIES
Status: COMPLIANT
Evidence:
- Vulnerability scan report (Trivy): 0 critical/high
- Dependency analysis: All components at latest secure versions
- Penetration test report: No exploitable vulnerabilities found
Reference: Test Report TR-2027-001, pages 15-23
2. SECURE BY DEFAULT CONFIGURATION
Status: COMPLIANT
Evidence:
- Default configuration review document
- No default passwords (unique credentials required at setup)
- Unnecessary services disabled by default
- Secure protocols enabled by default (TLS, not HTTP)
Reference: Design Document DD-004, Section 3.2
3. PROTECTION AGAINST UNAUTHORIZED ACCESS
Status: COMPLIANT
Evidence:
- Authentication architecture document
- Access control implementation
- Session management design
- Failed login lockout mechanism
Reference: Security Architecture SA-001, Chapter 4
4. CONFIDENTIALITY OF DATA
Status: COMPLIANT
Evidence:
- Encryption specifications (AES-256-GCM)
- Key management procedures
- Data classification and handling
Reference: Design Document DD-005
5. INTEGRITY OF DATA AND COMMANDS
Status: COMPLIANT
Evidence:
- Message authentication (HMAC)
- Command validation logic
- Input validation procedures
Reference: Security Architecture SA-001, Chapter 5
6. DATA MINIMIZATION
Status: COMPLIANT
Evidence:
- Data inventory document
- Justification for each data type collected
- Retention policy (automatic purge after 90 days)
Reference: Privacy Impact Assessment PIA-001
[Continue for all Annex I requirements...]
Annex I, Part II Requirements
ANNEX I, PART II - VULNERABILITY HANDLING
═══════════════════════════════════════════════════════════
1. IDENTIFY AND DOCUMENT VULNERABILITIES
Status: COMPLIANT
Evidence:
- Vulnerability tracking system (JIRA project VULN)
- CVE monitoring process document
- SBOM-based dependency tracking
Reference: Process Document PD-VULN-001
2. ADDRESS VULNERABILITIES WITHOUT DELAY
Status: COMPLIANT
Evidence:
- Vulnerability response SLA document
- Historical response time metrics
- Patch development process
Reference: Process Document PD-VULN-002
3. APPLY EFFECTIVE REGULAR TESTING
Status: COMPLIANT
Evidence:
- Security testing schedule
- Automated scan reports (weekly)
- Annual penetration test reports
Reference: Test Plan TP-SEC-001
[Continue for all Part II requirements...]
Section 5: Standards Applied
Purpose: Document which standards were used and how.
Required Content
STANDARDS APPLICATION CHECKLIST
Standards List:
[ ] All applied standards listed with version numbers
[ ] Harmonized standards identified separately
[ ] Reference to Official Journal publication (if harmonized)
Application Evidence:
[ ] How each standard was applied
[ ] Which clauses/sections apply
[ ] Any deviations or partial application
Deviation Handling:
[ ] Deviations documented with justification
[ ] Alternative measures for deviated requirements
[ ] Risk assessment for deviations
Standards Documentation Format
APPLIED STANDARDS
HARMONIZED STANDARDS (presumption of conformity):
-------------------------------------------------------------
Standard: EN 303 645 (when harmonized for CRA)
Title: Cybersecurity for Consumer IoT
Status: Applied in full
Publication: OJEU [reference when published]
Evidence: Standards Compliance Report SCR-001
-------------------------------------------------------------
OTHER STANDARDS APPLIED:
-------------------------------------------------------------
Standard: IEC 62443-4-1:2018
Title: Security for Industrial Automation - Secure Development
Status: Applied (selected requirements)
Clauses Applied: 5, 6, 7, 8, 10
Evidence: SDL Documentation SLD-001
-------------------------------------------------------------
Standard: ISO/IEC 27001:2022
Title: Information Security Management
Status: Organization certified (Certificate #12345)
Relevance: ISMS covers product development processes
-------------------------------------------------------------
Standard: NIST Cybersecurity Framework 2.0
Title: Framework for Improving Critical Infrastructure Cybersecurity
Status: Reference framework for risk assessment
Evidence: Risk Assessment methodology document
-------------------------------------------------------------
DEVIATIONS:
-------------------------------------------------------------
Standard: EN 303 645
Clause: 5.3-2 (Unique per device credentials)
Deviation: Credentials unique per device but not pre-provisioned
Justification: Device requires user setup; credentials created
during first-time configuration
Alternative Measure: Strong password requirements enforced,
account lockout after failed attempts
Risk Assessment: Residual risk acceptable (see R-015)
-------------------------------------------------------------
Tip: Automate your SBOM generation in CI/CD. Manual SBOM creation is error-prone and doesn't scale across product versions.
Section 6: Test Results
Purpose: Provide evidence that requirements are actually met.
Required Content
TEST DOCUMENTATION CHECKLIST
Test Planning:
[ ] Test plan with scope and objectives
[ ] Test cases mapped to requirements
[ ] Test environment description
[ ] Pass/fail criteria
Test Execution:
[ ] Test execution records
[ ] Test results summary
[ ] Failed tests and resolution
[ ] Retest evidence
Test Types:
[ ] Functional security testing
[ ] Vulnerability scanning
[ ] Penetration testing (if applicable)
[ ] Fuzz testing (if applicable)
[ ] Configuration review
Test Results Format
TEST RESULTS SUMMARY
Product: SmartSense Pro (SSP-3000) v2.4.1
Test Period: December 2026 - January 2027
Test Lead: [Name]
═══════════════════════════════════════════════════════════
TEST CAMPAIGN: TC-2027-001
═══════════════════════════════════════════════════════════
1. SECURITY FUNCTIONAL TESTING
Scope: Authentication, authorization, encryption, secure boot
Test Cases: 85
Passed: 85
Failed: 0
Reference: Test Report TR-FUNC-001
2. VULNERABILITY SCANNING
Tool: Trivy v0.48.0 + Nessus Professional
Scope: Firmware, network services, web interface
Findings:
Critical: 0
High: 0
Medium: 2 (accepted with justification)
Low: 5 (accepted)
Reference: Scan Report SR-VULN-001
3. PENETRATION TESTING
Provider: [Third-party firm name]
Scope: Black-box testing of deployed device
Duration: 5 days
Findings:
Critical: 0
High: 0
Medium: 1 (remediated before release)
Low: 3 (accepted)
Reference: Pentest Report PT-2027-001
4. FIRMWARE ANALYSIS
Tool: EMBA v1.3
Scope: Binary analysis, hardcoded credentials, crypto issues
Findings:
Critical: 0
High: 0
Informational: 4
Reference: Firmware Analysis Report FA-001
5. CONFIGURATION REVIEW
Scope: Default configuration security
Findings: All defaults meet security requirements
Reference: Configuration Review CR-001
═══════════════════════════════════════════════════════════
OVERALL ASSESSMENT: PASS
All critical and high findings remediated.
Medium/Low findings accepted with documented justification.
═══════════════════════════════════════════════════════════
Section 7: EU Declaration of Conformity
Purpose: Include the formal declaration or reference to it.
Required Content
The technical file must include a copy of the EU Declaration of Conformity or reference to where it can be obtained.
EU DECLARATION OF CONFORMITY
(See separate DoC document or include copy in technical file)
Reference: DoC-SSP3000-2027-001
Date: March 1, 2027
Location: Technical File, Appendix A
The EU Declaration of Conformity accompanies every product
and is available for download at:
https://company.com/support/ssp3000/doc
Section 8: Software Bill of Materials
Purpose: Provide component transparency for vulnerability tracking. Annex VII §8 makes the SBOM part of the technical file on reasoned request from a market surveillance authority. In practice, manufacturers prepare and maintain it alongside the rest of the file.
Sibling guides: Hardware products additionally require an HBOM, and SBOM quality is governed by BSI TR-03183. Vulnerability status of SBOM components is communicated via VEX. See the SBOM requirements guide for CycloneDX vs SPDX, BSI TR-03183 quality levels, HBOM scope, and VEX usage; and the vulnerability reporting guide for how VEX supports the "no known exploitable vulnerabilities" obligation.
Required Content
SBOM REQUIREMENTS CHECKLIST
Format:
[ ] Machine-readable format (CycloneDX or SPDX)
[ ] Human-readable summary
Content:
[ ] All software components listed
[ ] Component versions specified
[ ] Supplier information included
[ ] License information included
[ ] Known vulnerabilities at assessment time
Scope:
[ ] Direct dependencies
[ ] Transitive dependencies
[ ] Operating system components (if applicable)
[ ] Third-party libraries
SBOM Documentation
SOFTWARE BILL OF MATERIALS
Product: SmartSense Pro (SSP-3000)
Firmware Version: 2.4.1
SBOM Format: CycloneDX 1.5
Generated: 2027-01-15
Tool: Trivy + syft
SBOM FILE:
sbom-ssp3000-v2.4.1.json (attached)
COMPONENT SUMMARY:
-------------------------------------------------------------
Total Components: 127
Direct Dependencies: 23
Transitive Dependencies: 104
By Type:
Libraries: 98
Frameworks: 12
Operating System: 1 (FreeRTOS)
Firmware Modules: 16
By License:
MIT: 45
Apache 2.0: 38
BSD: 15
LGPL: 8
Proprietary: 21 (internal components)
-------------------------------------------------------------
VULNERABILITY STATUS AT ASSESSMENT:
-------------------------------------------------------------
Scan Date: 2027-01-15
Scanner: Trivy v0.48.0
Critical: 0
High: 0
Medium: 2 (accepted - see below)
Low: 5 (accepted)
ACCEPTED VULNERABILITIES:
CVE-2026-XXXXX (Medium): Component xyz v1.2.3
Status: Not exploitable in our configuration
Justification: Feature not enabled, code path not reachable
Review Date: 2027-04-15
CVE-2026-YYYYY (Medium): Component abc v2.0.1
Status: Mitigated by network controls
Justification: Requires local access, device is network-isolated
Review Date: 2027-04-15
-------------------------------------------------------------
SBOM UPDATE COMMITMENT:
SBOM will be updated with each firmware release and made
available to customers upon request.
When Must the Technical File Be Updated?
Living Documentation
The technical file isn't static:
TECHNICAL FILE UPDATE TRIGGERS
MANDATORY UPDATES:
- New firmware/software version
- Security patch release
- Vulnerability discovered and addressed
- Design change affecting security
- Standards update (if applied standards change)
- SBOM changes (new/updated components)
PERIODIC REVIEWS:
- Quarterly: SBOM and vulnerability status
- Annually: Full technical file review
- Before support period end: Final documentation freeze
VERSION CONTROL:
- All documents version-controlled
- Change history maintained
- Previous versions archived
Retention Requirements
Note: Article 13(13) sets retention at the longer of 10 years from market placement or the support period. If you sell products until 2030 with a 5-year support period, the 10-year clock dominates and retention runs until 2040. If your support period extends beyond that 10-year tail, retention follows the support period instead. Plan storage for the longer of the two.
DOCUMENTATION RETENTION
Retention Period: at least 10 years from market placement, or the support period, whichever is longer (Article 13(13))
Example Timeline:
- Product first placed on market: March 2027
- Last unit placed on market: December 2030
- Documentation retention until: December 2040
Storage Requirements:
- Secure, accessible storage
- Backup procedures
- Integrity protection
- Available within [48 hours] of authority request
Common Mistakes
Warning: A technical file that only describes version 1.0 when your product is on version 2.3 is considered non-compliant. Update documentation with every release.
Incomplete Risk Assessment
Problem: Risk assessment that doesn't cover all threats or lacks treatment details.
Fix: Use structured methodology. Map every identified risk to a control or acceptance decision.
Missing SBOM
Problem: No SBOM or SBOM that doesn't include transitive dependencies.
Fix: Generate SBOM using proper tooling. Include full dependency tree.
Outdated Documentation
Problem: Technical file describes version 1.0 but product is on version 2.3.
Fix: Update documentation with every release. Track versions explicitly.
No Requirements Traceability
Problem: Claims compliance but doesn't show how each requirement is met.
Fix: Create explicit mapping from each Annex I requirement to evidence.
Tests Without Evidence
Problem: Claims testing was done but no reports available.
Fix: Retain all test reports. Include in technical file or reference clearly.
Technical File Checklist
TECHNICAL FILE COMPLETENESS CHECKLIST
SECTION 1 - GENERAL DESCRIPTION:
[ ] Product identification complete
[ ] Intended purpose documented
[ ] CRA classification stated with justification
[ ] Market placement information
SECTION 2 - DESIGN, DEVELOPMENT AND VULNERABILITY HANDLING:
[ ] Architecture diagrams
[ ] Security design documentation
[ ] Development process description
[ ] Change management procedures
[ ] Vulnerability contact methods documented
[ ] CVD policy published
[ ] Vulnerability handling process documented
[ ] ENISA reporting procedures in place
SECTION 3 - RISK ASSESSMENT:
[ ] Methodology documented
[ ] All risks identified
[ ] Treatment decisions for each risk
[ ] Residual risk assessment
SECTION 4 - SUPPORT PERIOD INFORMATION:
[ ] Declared support period stated (start and end dates)
[ ] Article 13(8) inputs documented (use duration, user expectations, sector law)
[ ] Justification recorded (component support timelines, customer contracts, hardware EOL)
[ ] Decision sign-off captured (product, security, legal)
ANNEX I MAPPING (supports Sections 5-7):
[ ] Annex I Part I mapping complete
[ ] Annex I Part II mapping complete
[ ] Evidence referenced for each requirement
SECTION 5 - STANDARDS:
[ ] All applied standards listed
[ ] Application evidence provided
[ ] Deviations documented and justified
SECTION 6 - TEST RESULTS:
[ ] Test plan documented
[ ] Test reports attached
[ ] All findings addressed
SECTION 7 - DoC:
[ ] Declaration of Conformity included/referenced
SECTION 8 - SBOM (on reasoned request):
[ ] Machine-readable SBOM prepared (CycloneDX or SPDX)
[ ] All components included (direct + transitive)
[ ] Vulnerability status documented
[ ] Available for surveillance authority on request
MAINTENANCE:
[ ] Version control established
[ ] Update procedures documented
[ ] Retention plan in place
Frequently Asked Questions
What documents are mandatory in a CRA technical file under Annex VII?
Annex VII requires eight sections: (1) a general product description, including intended purpose, software versions affecting compliance, photographs for hardware products, and user information; (2) a description of the design, development, and production of the product together with the vulnerability handling processes; (3) a cybersecurity risk assessment pursuant to Article 13; (4) information used to determine the support period under Article 13(8); (5) a list of the harmonised standards applied in full or in part; (6) reports of the tests carried out to verify conformity; (7) a copy of the EU declaration of conformity; and (8) where applicable, the software bill of materials, provided on reasoned request from a market surveillance authority.
Does every firmware version need its own technical file?
The technical file must reflect the current product version. Each firmware release that changes security-relevant behavior requires updated documentation, at minimum the SBOM, risk assessment, and test results sections. The file does not need to be rebuilt from scratch, but it must remain accurate and version-specific.
How long must the technical file be retained after the product is withdrawn?
The CRA requires retention for at least 10 years from the date the product is placed on the market, or for the support period, whichever is longer (Article 13(13)). If you sell units through 2030 with a 5-year support period, the 10-year clock dominates and documentation must be kept until 2040; a longer support period extends retention to match.
Does the technical file need to be submitted to authorities proactively?
No. The manufacturer holds the technical file and makes it available on request from market surveillance authorities. Authorities can demand access at any time, but there is no requirement to submit it at market placement.
Can the technical file reference external documents or must everything be in one place?
External references are acceptable provided the documents are accessible and traceable. The file can point to test reports, design documents, or standards certificates stored separately, as long as references are precise and documents are available when requested.
What is the difference between the technical file and the Declaration of Conformity?
The Declaration of Conformity is a short public document stating that the product meets CRA requirements. The technical file is the full evidence package that proves it, containing all documentation, test results, and assessments backing up that declaration. The DoC references the technical file; the technical file is the substance behind it.