The CRA Technical File: What Goes in Each Section (Annex VII Breakdown)

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.

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

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 AND DEVELOPMENT
   └── How security was built in

3. CYBERSECURITY RISK ASSESSMENT
   └── Risks identified and addressed

4. ESSENTIAL REQUIREMENTS
   └── How Annex I requirements are met

5. APPLIED STANDARDS
   └── Standards used and deviations

6. SOFTWARE BILL OF MATERIALS
   └── Components and dependencies

7. TEST RESULTS
   └── Verification evidence

8. EU DECLARATION OF CONFORMITY
   └── Or copy thereof

9. VULNERABILITY HANDLING
   └── Post-market security processes

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 and Development

Purpose: Document how security was incorporated into product design.

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)

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: Essential Requirements Mapping

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)
─────────────────────────────────────────────────────────────

Section 6: Software Bill of Materials

Purpose: Provide component transparency for vulnerability tracking.

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.

Section 7: 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 8: 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 9: Vulnerability Handling Procedures

Purpose: Document post-market security processes.

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

Technical File Maintenance

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

DOCUMENTATION RETENTION

Retention Period: 10 years from last unit placed on market

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

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:
[ ] Architecture diagrams
[ ] Security design documentation
[ ] Development process description
[ ] Change management procedures

SECTION 3 - RISK ASSESSMENT:
[ ] Methodology documented
[ ] All risks identified
[ ] Treatment decisions for each risk
[ ] Residual risk assessment

SECTION 4 - ESSENTIAL REQUIREMENTS:
[ ] 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 - SBOM:
[ ] Machine-readable SBOM attached
[ ] All components included
[ ] Vulnerability status documented

SECTION 7 - TEST RESULTS:
[ ] Test plan documented
[ ] Test reports attached
[ ] All findings addressed

SECTION 8 - DoC:
[ ] Declaration of Conformity included/referenced

SECTION 9 - VULNERABILITY HANDLING:
[ ] Contact methods documented
[ ] Process documented
[ ] ENISA procedures in place

MAINTENANCE:
[ ] Version control established
[ ] Update procedures documented
[ ] Retention plan in place

How CRA Evidence Helps

CRA Evidence streamlines technical file creation:

• Structured templates: Section-by-section technical file builder
• Requirements mapping: Track Annex I compliance evidence
• SBOM management: Store, analyze, and update SBOMs
• Document repository: Centralized storage for all evidence
• Version tracking: Maintain documentation across product versions
• Export capability: Generate complete technical file bundles

Build your technical file at app.craevidence.com.

Related Guides

SBOM: Deep dive into SBOM requirements in our SBOM guide.

Assessment: Choose your conformity assessment route with our module decision guide.

Declaration: Learn how to prepare your EU Declaration of Conformity.

This article is for informational purposes only and does not constitute legal advice. For specific compliance guidance, consult with qualified legal counsel.