The technical file is your evidence package for CRA compliance. Market surveillance authorities can request it, and a Notified Body will examine it when your conformity route uses one. Without a complete technical file, you cannot legally place your product on the EU market.
This guide walks the technical file section by section, explaining what each evidence area needs 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
- 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 that your product complies with the essential cybersecurity 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. Authorities can request it at any time.
What the technical file must contain
The technical file is easier to review when it is organized around eight evidence areas:
Product identification, intended purpose, relevant software versions, hardware views, and user information.
Architecture, secure development, vulnerability processes, update distribution, production and monitoring validation.
Risks considered across design, production, delivery, maintenance, and essential-requirement applicability.
Inputs used to determine and justify the support period.
Harmonised standards, common specifications, certification schemes, or alternative solutions.
Evidence that the product and vulnerability handling processes meet the applicable essential cybersecurity requirements.
A copy of the declaration that the product meets the applicable CRA requirements.
SBOM evidence where applicable, kept in the technical file and also produced for a market surveillance authority on reasoned request.
Section 1: General Description
Purpose: Establish what the product is and what it's for.
Required Content
- Product name and model number
- Hardware version or versions
- Software or firmware version or versions
- Serial number format or range
- Unique product identifier
- Primary function description
- Target users and operating environment
- Intended use cases
- Not-intended uses and exclusions
- CRA classification
- Justification for classification
- Related product regulations, where relevant
- 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 classified as important or critical.
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. Treat these as one evidence block: design and development records, vulnerability handling processes, and the production and monitoring controls that prove releases are built and watched consistently.
Design and Development: Required Content
- System architecture diagram
- Component interaction diagram
- Data flow diagram
- Trust boundaries identified
- Security architecture description
- Cryptographic implementations
- Authentication mechanisms
- Authorization model
- Secure communication protocols
- Data protection measures
- Secure development lifecycle description
- Security requirements traceability
- Code review procedures
- Security testing in development
- Configuration 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
- Contact methods documented
- CVD policy published
- Researcher communication procedures
- Triage procedures
- Severity assessment methodology
- Escalation paths
- Patch development workflow
- Testing procedures for patches
- Customer notification procedures
- Advisory publication process
- Reporting to the coordinating CSIRT and ENISA for active exploitation
- 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. REPORTING TO COORDINATING CSIRT AND ENISA
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. Production and monitoring means 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.
- Source of truth identified
- Reproducible build documented
- Build provenance captured
- Signing keys and key management documented
- Release artifact integrity
- Security gates in CI documented
- Regression suite covers essential-requirement-tagged tests
- Release approval workflow documented
- Rollback plan for failed releases
- Reproducibility audit cadence
- Dependency vulnerability monitoring cadence
- SBOM diff process on each release
- CVE feed integration
- KEV cross-check for active exploitation
- Security-relevant telemetry
- Customer notification triggers
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) + essential requirements 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)
- Essential requirements 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 methodology described
- Scope definition
- Asset identification
- Threat identification approach
- Threats enumerated
- Vulnerabilities considered
- Impact assessment
- Likelihood assessment
- Risk ratings
- 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. The support period is the time during which the manufacturer commits to providing security updates. The technical file must capture the information that drove that decision.
Required Content
- Declared support period start date
- Declared support period end date
- Minimum checked against five-year floor or shorter product lifetime
- Expected use duration of the product
- User and customer expectations
- Nature and intended purpose of the product
- Relevant Union law
- Commission or ADCO guidance where available
- Comparable product lifetimes in the market
- Component vendor support timelines
- Customer contracts or SLAs that imply update windows
- Hardware end-of-life schedules where 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 the support-period rule 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
Purpose: Demonstrate how each essential cybersecurity requirement is met.
Part I Requirements
Map each secure-by-design 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 essential requirements...]
Part II Requirements
Map each vulnerability-handling requirement to your implementation:
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
- All applied standards listed with version numbers
- Harmonised standards identified separately
- Official Journal reference recorded where harmonised
- How each standard was applied
- Which clauses or sections apply
- Any deviation or partial application
- 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 plan with scope and objectives
- Test cases mapped to requirements
- Test environment description
- Pass and fail criteria
- Test execution records
- Test results summary
- Failed tests and resolution
- Retest evidence
- Functional security testing
- Vulnerability scanning
- Penetration testing where applicable
- Fuzz testing where 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.
Section 8: Software Bill of Materials
Purpose: Provide component transparency for vulnerability tracking. The SBOM belongs in the technical file as part of the vulnerability-handling evidence, and it is also produced for a market surveillance authority on reasoned request. In practice, manufacturers prepare and maintain it alongside the rest of the file.
Sibling guides: For hardware products, keep hardware-component evidence where it supports the risk assessment, user information, or vulnerability analysis. BSI TR-03183 can help with SBOM quality, and VEX can communicate component vulnerability status. See the SBOM requirements guide for format choices, 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
- Machine-readable format
- CycloneDX or SPDX selected and documented
- Human-readable summary where useful
- All software components listed
- Component versions specified
- Supplier information included
- License information included
- Known vulnerabilities at assessment time
- Direct dependencies
- Transitive dependencies (best practice beyond the top-level minimum)
- Operating system components where applicable
- Third-party libraries
SBOM Documentation
When Must the Technical File Be Updated?
Living Documentation
The technical file isn't static:
- New firmware or software version
- Security patch release
- Vulnerability discovered and addressed
- Design change affecting security
- Applied standards change
- SBOM component changes
- Quarterly SBOM and vulnerability status review
- Annual full technical file review
- Final documentation freeze before support period end
- All documents version-controlled
- Change history maintained
- Previous versions archived
Retention Requirements
Note: Keep the technical file for 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
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 an SBOM that omits the required top-level dependencies.
Fix: Generate an SBOM using proper tooling, covering at least the top-level dependencies the CRA requires (Annex I Part II(1)). Extending to the full dependency tree is stronger practice for vulnerability matching, not the legal minimum.
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 essential 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
- Product identification complete
- Intended purpose documented
- CRA classification stated with justification
- Market placement information
- Architecture diagrams
- Security design documentation
- Development process description
- Change management procedures
- Vulnerability contact methods documented
- CVD policy published
- Vulnerability handling process documented
- Reporting procedures in place for the coordinating CSIRT and ENISA
- Methodology documented
- All risks identified
- Treatment decisions for each risk
- Residual risk assessment
- Declared support period stated
- Support-period inputs documented
- Justification recorded
- Decision sign-off captured
- Secure-by-design requirements mapping complete
- Vulnerability-handling requirements mapping complete
- Evidence referenced for each requirement
- All applied standards listed
- Application evidence provided
- Deviations documented and justified
- Test plan documented
- Test reports attached
- All findings addressed
- Declaration of Conformity included or referenced
- Machine-readable SBOM prepared
- All components included
- Vulnerability status documented
- Available for surveillance authority on request
- Version control established
- Update procedures documented
- Retention plan in place
Frequently Asked Questions
What documents are mandatory in a CRA technical file?
The file needs eight evidence areas. It must cover the product description, design and production, vulnerability handling, risk assessment, support-period rationale, applied standards or alternative solutions, test reports, the EU declaration of conformity, and, where applicable, the SBOM for market-surveillance review. Treat those as evidence sections, not as a fixed folder structure.
Does every firmware version need its own technical file?
No, but the file must stay version-accurate. A firmware or software release that changes security-relevant behaviour should update the affected sections, usually the SBOM, risk assessment, design notes, and test evidence. You do not rebuild the whole file from zero, but the evidence must match the product version being placed on the market or supported.
How long must the technical file be retained after the product is withdrawn?
Keep it for the longer of 10 years or the support period. The 10-year period runs from placing the product with digital elements on the market; if the support period is longer, retention follows that longer support period. In practice, manufacturers should plan storage around the last market-placement date for the relevant product/version and preserve evidence for any longer support commitment.
Does the technical file need to be submitted to authorities proactively?
No. The manufacturer keeps the technical documentation and provides it when a market surveillance authority makes a reasoned request. A Notified Body will also review the documentation where the chosen conformity assessment route involves one, but the regulation does not require routine filing with authorities at market placement.
Can the technical file reference external documents or must everything be in one place?
External references are acceptable if they are precise and retrievable. The file can point to design documents, test reports, certificates, SBOM artifacts, or release records stored elsewhere, provided the reference identifies the exact document, version, owner, and location. Authorities need usable evidence, not a broken index.
What is the difference between the technical file and the Declaration of Conformity?
The declaration is the public statement; the technical file is the proof. The EU declaration of conformity says the product meets the CRA. The technical file contains the risk assessment, design evidence, test reports, standards mapping, SBOM evidence, and other records that justify that declaration.