CRA Teknisk dokumentation: guide till Bilaga VII

Det tekniska underlaget är ditt bevismaterial för CRA-efterlevnad. Marknadskontrollmyndigheter kommer att begära det. Anmälda organ kommer att granska det. Utan ett fullständigt tekniskt underlag kan du inte lagligen placera din produkt på EU-marknaden.

Den här guiden går igenom Bilaga VII avsnitt för avsnitt och förklarar vad varje del kräver och hur du förbereder den.

Vad är det tekniska underlaget?

Det tekniska underlaget (även kallat "teknisk dokumentation") är det fullständiga bevismaterialet som visar att din produkt uppfyller CRA:s krav.

Det är inte:

• Marknadskommunikation
• Enbart användarhandböcker
• En bocklista utan substans

Det är:

• Heltäckande tekniskt bevismaterial
• Levande dokumentation (uppdateras under hela produktlivscykeln)
• Ditt försvar vid marknadskontrollutredningar
• Obligatoriskt för bedömning av överensstämmelse

Viktigt: Det tekniska underlaget måste vara klart INNAN marknadsintroduktion och bevaras i 10 år efter att den sista enheten placerats på marknaden. Myndigheter kan begära det när som helst.

Strukturöversikt för Bilaga VII

CRA:s Bilaga VII specificerar kraven på teknisk dokumentation:

TEKNISK DOKUMENTATION (Bilaga VII)

1. ALLMÄN BESKRIVNING
   \-- Produktidentitet och avsett syfte

2. KONSTRUKTION, UTVECKLING, SÅRBARHETSHANTERING OCH PRODUKTION
   \-- Säkerhet inbyggd, sårbarheter hanterade, produktion och övervakning validerade

3. CYBERSÄKERHETSRISKBEDÖMNING
   \-- Identifierade och hanterade risker

4. INFORMATION OM SUPPORTPERIODEN
   \-- Information som används för att fastställa supportperioden (artikel 13.8)

5. TILLÄMPADE STANDARDER
   \-- Använda standarder och avvikelser

6. TESTRESULTAT
   \-- Verifieringsbevis

7. EU-FÖRSÄKRAN OM ÖVERENSSTÄMMELSE
   \-- Eller en kopia därav

8. MJUKVARUKOMPONENTFÖRTECKNING (SBOM)
   \-- Komponenter och beroenden (på motiverad begäran)

Avsnitt 1: Allmän beskrivning

Syfte: Fastställ vad produkten är och vad den är till för.

Obligatoriskt innehåll

CHECKLISTA: ALLMÄN BESKRIVNING

Produktidentifikation:
[ ] Product name and model number
[ ] Hardware version(s)
[ ] Software/firmware version(s)
[ ] Serial number format or range
[ ] Unique product identifier

Avsett syfte:
[ ] Primary function description
[ ] Target users/environment
[ ] Intended use cases
[ ] Not-intended uses (exclusions)

Produktkategori:
[ ] CRA classification (Default/Important/Critical)
[ ] Justification for classification
[ ] Related product regulations (if any)

Marknadsinformation:
[ ] Date of first EU market placement
[ ] Target member states
[ ] Distribution channels

Exempel

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

Avsnitt 2: Konstruktion, utveckling och sårbarhetshantering

Syfte: Dokumentera hur produkten konstruerades och utvecklades, hur sårbarheter hanteras efter marknadslansering och hur produktions- och övervakningsprocesser valideras. Bilaga VII §2 behandlar dessa som ett block: konstruktion och utveckling under §2(a), sårbarhetshanteringsprocesser under §2(b), produktions- och övervakningsprocesser under §2(c).

Konstruktion och utveckling: obligatoriskt innehåll

CHECKLISTA: KONSTRUKTIONSDOKUMENTATION

Arkitektur:
[ ] System architecture diagram
[ ] Component interaction diagram
[ ] Data flow diagram
[ ] Trust boundaries identified

Säkerhetskonstruktion:
[ ] Security architecture description
[ ] Cryptographic implementations
[ ] Authentication mechanisms
[ ] Authorization model
[ ] Secure communication protocols
[ ] Data protection measures

Utvecklingsprocess:
[ ] Secure development lifecycle description
[ ] Security requirements traceability
[ ] Code review procedures
[ ] Security testing in development
[ ] Configuration management

Ändringshantering:
[ ] Version control procedures
[ ] Change impact assessment
[ ] Security review for changes

Hur "säker konstruktion" ser ut i dokumentation

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)

Sårbarhetshantering: obligatoriskt innehåll

CHECKLISTA: SÅRBARHETSHANTERING

Mottagning:
[ ] 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

Kommunikation:
[ ] Customer notification procedures
[ ] Advisory publication process
[ ] ENISA reporting integration (for active exploitation)

Övervakning:
[ ] Dependency vulnerability monitoring
[ ] CVE database monitoring
[ ] Threat intelligence sources

Dokumentation av sårbarhetshantering

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

Produktion och övervakning: obligatoriskt innehåll

För programvaruprodukter finns ingen fabrikslinje. Bilaga VII, punkt 2(c) motsvarar bygg- och release-pipelinen som producerar levererbara artefakter, valideringen av att dessa processer fungerar som avsett, samt övervakningen efter driftsättning som fångar regressioner och nya sårbarheter. Dokumentera vart och ett så att en granskare kan spåra en release tillbaka till ett verifierat och reproducerbart bygge.

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

Dokumentation av produktion och övervakning

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

Avsnitt 3: Cybersäkerhetsriskbedömning

Syfte: Dokumentera identifierade risker och hur de hanteras.

Obligatoriskt innehåll

CHECKLISTA: RISKBEDÖMNING

Metodik:
[ ] Risk assessment methodology described
[ ] Scope definition
[ ] Asset identification
[ ] Threat identification approach

Riskanalys:
[ ] Threats enumerated
[ ] Vulnerabilities considered
[ ] Impact assessment
[ ] Likelihood assessment
[ ] Risk ratings

Riskbehandling:
[ ] Treatment decisions for each risk
[ ] Security controls mapped to risks
[ ] Residual risk assessment
[ ] Risk acceptance criteria

Format för riskbedömning

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]

Avsnitt 4: Information om supportperioden

Syfte: Dokumentera resonemanget bakom den valda supportperioden, enligt artikel 13.8. Supportperioden är den tid under vilken tillverkaren åtar sig att tillhandahålla säkerhetsuppdateringar. Bilaga VII, punkt 4 kräver att det tekniska underlaget fångar den information som låg till grund för det beslutet.

Obligatoriskt innehåll

BESLUTSUNDERLAG FÖR SUPPORTPERIOD

Deklarerad supportperiod: [startdatum] till [slutdatum]
Minimum: 5 år från marknadsintroduktion (eller produktens livslängd, om kortare)

Beaktade indata (artikel 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

Dokumenterad motivering:
[ ] 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)

Hur god dokumentation ser ut

FASTSTÄLLANDE AV SUPPORTPERIOD
Produkt: Industrial Gateway IG-200
Marknadsintroduktion: 2026-09-01
Deklarerad supportperiod: 2026-09-01 till 2034-09-01 (8 år)

Motivering:
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.

Beslut godkänt av: [Product Owner], [Security Lead], [Legal]
Datum: 2026-08-15
Granskningstrigger: any material change to component support timelines

Vanliga fallgropar

• Att förankra sig vid 5-årsminimum utan motivering. De 5 åren i artikel 13.8 är ett golv, inte ett standardvärde. Produkter med längre förväntad livslängd kräver en längre period.
• Att glömma att golvet är "eller produktens livslängd, om kortare". En konsumentprodukt som säljs i 18 månader är fortfarande skyldig att tillhandahålla uppdateringssupport under den period produkten rimligen förväntas vara i bruk.
• Att inte registrera indata. Marknadskontrollmyndigheter kan fråga hur perioden fastställdes. "Vi valde 5 år" är inte ett svar.
• Att behandla det som hugget i sten. Om komponentleverantörers supporttider ändras (till exempel om uppströms OS når EOL tidigare än förväntat) måste beslutsunderlaget uppdateras och supportåtagandet kommuniceras.

Mappning av väsentliga krav (Bilaga I)

Syfte: Visa hur varje krav i Bilaga I uppfylls.

Bilaga I, Del I-krav

Mappa varje krav mot din implementering:

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...]

Bilaga I, Del II-krav

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...]

Avsnitt 5: Tillämpade standarder

Syfte: Dokumentera vilka standarder som använts och hur.

Obligatoriskt innehåll

CHECKLISTA: STANDARDTILLÄMPNING

Standardlista:
[ ] All applied standards listed with version numbers
[ ] Harmonized standards identified separately
[ ] Reference to Official Journal publication (if harmonized)

Tillämpningsbevis:
[ ] How each standard was applied
[ ] Which clauses/sections apply
[ ] Any deviations or partial application

Hantering av avvikelser:
[ ] Deviations documented with justification
[ ] Alternative measures for deviated requirements
[ ] Risk assessment for deviations

Format för standarddokumentation

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

Tips: Automatisera din SBOM-generering i CI/CD-pipelinen. Manuell SBOM-skapande är felbenäget och skalerar inte över produktversioner.

Avsnitt 6: Testresultat

Syfte: Tillhandahåll bevis på att kraven faktiskt uppfylls.

Obligatoriskt innehåll

CHECKLISTA: TESTDOKUMENTATION

Testplanering:
[ ] Test plan with scope and objectives
[ ] Test cases mapped to requirements
[ ] Test environment description
[ ] Pass/fail criteria

Testutförande:
[ ] Test execution records
[ ] Test results summary
[ ] Failed tests and resolution
[ ] Retest evidence

Testtyper:
[ ] Functional security testing
[ ] Vulnerability scanning
[ ] Penetration testing (if applicable)
[ ] Fuzz testing (if applicable)
[ ] Configuration review

Format för testresultat

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.
═══════════════════════════════════════════════════════════

Avsnitt 7: EU-försäkran om överensstämmelse

Syfte: Inkludera den formella försäkran eller hänvisning till den.

Obligatoriskt innehåll

Det tekniska underlaget måste innehålla en kopia av EU-försäkran om överensstämmelse eller en hänvisning till var den kan erhållas.

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

Avsnitt 8: Mjukvarukomponentförteckning (SBOM)

Syfte: Tillhandahåll komponenttransparens för sårbarhetsspårning. Bilaga VII, punkt 8 gör SBOM till en del av det tekniska underlaget på motiverad begäran från en marknadskontrollmyndighet. I praktiken förbereder och underhåller tillverkare den tillsammans med resten av underlaget.

Relaterade guider: Hårdvaruprodukter kräver dessutom en HBOM, och kvaliteten regleras av BSI TR-03183. Sårbarhetsstatus för SBOM-komponenter kommuniceras via VEX. Se guiden om SBOM-krav för CycloneDX kontra SPDX, BSI TR-03183 kvalitetsnivåer, HBOM-scope och VEX-användning, samt guiden om sårbarhetsrapportering för hur VEX stöder skyldigheten att inte ha några kända exploaterbara sårbarheter.

Obligatoriskt innehåll

CHECKLISTA: SBOM-KRAV

Format:
[ ] Machine-readable format (CycloneDX or SPDX)
[ ] Human-readable summary

Innehåll:
[ ] All software components listed
[ ] Component versions specified
[ ] Supplier information included
[ ] License information included
[ ] Known vulnerabilities at assessment time

Omfattning:
[ ] Direct dependencies
[ ] Transitive dependencies
[ ] Operating system components (if applicable)
[ ] Third-party libraries

SBOM-dokumentation

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.

När måste det tekniska underlaget uppdateras?

Levande dokumentation

Det tekniska underlaget är inte statiskt:

TRIGGERS FÖR UPPDATERING AV TEKNISKT UNDERLAG

OBLIGATORISKA UPPDATERINGAR:
- 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)

PERIODISKA GENOMGÅNGAR:
- Quarterly: SBOM and vulnerability status
- Annually: Full technical file review
- Before support period end: Final documentation freeze

VERSIONSHANTERING:
- All documents version-controlled
- Change history maintained
- Previous versions archived

Bevarandekrav

Observera: "10 år från den sista enhetens marknadsintroduktion" innebär att om du säljer produkter fram till 2030, löper bevarandekravet till 2040. Planera din dokumentationslagring därefter.

DOKUMENTATIONSBEVARANDE

Bevarandeperiod: 10 år från den sista enhetens marknadsintroduktion

Exempeltidslinje:
- Product first placed on market: March 2027
- Last unit placed on market: December 2030
- Documentation retention until: December 2040

Lagringskrav:
- Secure, accessible storage
- Backup procedures
- Integrity protection
- Available within [48 hours] of authority request

Vanliga misstag

Varning: Ett tekniskt underlag som enbart beskriver version 1.0 när produkten är på version 2.3 bedöms som bristande efterlevnad. Uppdatera dokumentationen vid varje release.

Ofullständig riskbedömning

Problem: Riskbedömning som inte täcker alla hot eller saknar behandlingsdetaljer.

Lösning: Använd en strukturerad metodik. Mappa varje identifierad risk mot en kontroll eller ett acceptansbeslut.

SBOM saknas

Problem: Ingen SBOM eller en SBOM som inte inkluderar transitiva beroenden.

Lösning: Generera SBOM med rätt verktyg. Inkludera hela beroendeträdet.

Föråldrad dokumentation

Problem: Det tekniska underlaget beskriver version 1.0 men produkten är på version 2.3.

Lösning: Uppdatera dokumentationen vid varje release. Spåra versioner explicit.

Ingen kravspårbarhet

Problem: Hävdar efterlevnad men visar inte hur varje krav uppfylls.

Lösning: Skapa en explicit mappning från varje Bilaga I-krav till bevis.

Tester utan bevis

Problem: Hävdar att tester utfördes men inga rapporter finns tillgängliga.

Lösning: Behåll alla testrapporter. Inkludera dem i det tekniska underlaget eller referera tydligt till dem.

Checklista för tekniskt underlag

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