The documents, before you sign up.
Compliance tools describe what they generate. Here is the whole thing instead: a complete technical file, declaration of conformity and user information for a worked example, produced by the same code the product runs. No account, no email, no form.
The product it describes
| Product | EX-100 Industrial Temperature Sensor 2.4.0 |
| Manufacturer | Example Manufacturer GmbH |
| Classification | Default category, self-assessment under Module A |
| Support period | 8 years, to 09/2034 |
| Requirements assessed | 27, of which 27 applicable |
| Readiness | 100% with 0 blockers |
The support period is eight years rather than five because the expected time in use is eight. The Commission’s July 2026 guidance treats five years as a safeguard rather than a default, so a product expected to outlive it needs a longer period. That check runs on the answers, which is why the number here is not simply the minimum.
Technical documentation
Annex VII, referenced by Art. 31The file you must hold and keep current. Eight parts, including the risk assessment and a line for every essential requirement with the evidence behind it.
TECHNICAL DOCUMENTATION (CRA Annex VII / Art. 31) Pack: CRA v0.3.0 · Regulation (EU) 2024/2847 ==================================================== 1. GENERAL DESCRIPTION (Annex VII(1)) Product: EX-100 Industrial Temperature Sensor 2.4.0 · Identifier: EX100-2026-B Manufacturer: Example Manufacturer GmbH, Beispielstrasse 1, 10115 Berlin, Germany, hello@example-manufacturer.invalid Vulnerability-reporting point of contact (Art. 13(17)): security@example-manufacturer.invalid Intended purpose: Fixed-installation temperature and humidity sensing in light industrial environments. Reports readings over Wi-Fi to a customer-operated gateway on a segmented OT network. No personal data is processed. Connectivity/interfaces: Wi-Fi 802.11 b/g/n, USB-C for local firmware recovery, MQTT over TLS to the gateway · Update mechanism: Signed over-the-air firmware images, verified by secure boot, delivered from the vendor update service CLASSIFICATION BASIS (Art. 7(1); guidance C(2026) 5252 para 144) Category: Default Core functionality (Art. 7(1); guidance C(2026) 5252 §6.1): [Not yet recorded — state the product's main features without which it could not meet its intended purpose] Matched Annex III/IV item(s): none — product matches no Annex III/IV category (default). 2. DESIGN, DEVELOPMENT, PRODUCTION & VULNERABILITY-HANDLING PROCESSES (Annex VII(2)) [MET] Annex I Part II(1) SBOM & vulnerability identification — CycloneDX SBOM produced by the build pipeline for every release, covering the RTOS, the TLS library and all third-party components with versions and hashes. [MET] Annex I Part II(2) Remediate without delay; ship security fixes separately — Vulnerabilities triaged within 5 working days. Actively exploited findings are remediated or mitigated without undue delay under the documented policy. [MET] Annex I Part II(3) Regular security testing — Static analysis and dependency scanning on every commit; an external penetration test before each minor release, most recently in May 2026. [MET] Annex I Part II(4) Disclose fixed vulnerabilities — Fixed vulnerabilities are published as advisories on the security page with the affected versions and the remedy. [MET] Annex I Part II(5) Coordinated vulnerability disclosure policy — Coordinated disclosure policy published at /security with a 90-day standard timeline and a named contact. [MET] Annex I Part II(6) Facilitate info-sharing & reporting contact — security.txt served under /.well-known/, PGP key published, and reports acknowledged within 2 working days. [MET] Annex I Part II(7) Secure update distribution — Updates are distributed over TLS from the vendor update service and signed; the device verifies the signature before installing. [MET] Annex I Part II(8) Free & timely patches with advisories — Security updates are free and separate from feature releases, with an advisory published alongside each one. [MET] Article 13(5)-(6) Third-party & open-source component due diligence — Third-party components reviewed before adoption for maintenance status, disclosure policy and known vulnerabilities. Decisions recorded in the component register. [MET] Article 13(8) Vulnerability handling for the whole support period — Vulnerability handling runs for the declared support period to 09/2034 under the documented process, with an owner named in the register. [MET] Article 13(9) Security-update availability retention — Every issued security update is archived and remains downloadable for 10 years from release. [MET] Article 14 Reporting of actively exploited vulnerabilities & severe incidents — Reporting runbook covering the 24 hour early warning, 72 hour notification and 14 day final report, with the ENISA single reporting platform and the national CSIRT identified and an on-call owner. [MET] Article 13(19) Support-period end date disclosed, expiry notified — The support end date 09/2034 is stated on the product page, in the datasheet and in the Annex II user information. The gateway shows a notice once the period has expired. 3. CYBERSECURITY RISK ASSESSMENT (Annex VII(3) / Art. 13(2)-(4)) Intended purpose: Measure temperature and humidity in light industrial spaces and publish readings to the customer's gateway. Sold to facilities and building-services integrators, installed by a technician, then left in place for years. Foreseeable use & misuse: Installed on a flat network alongside IT equipment rather than a segmented OT VLAN. Left on default Wi-Fi credentials. Auto-update disabled by a site policy. Physically reachable in a plant room by contractors who are not employees. Operational environment: Indoors, mains powered, on a customer-managed Wi-Fi network behind their own firewall. No inbound connections from the internet; the sensor initiates all traffic outbound to the gateway. Assets to protect: Wi-Fi credentials and the MQTT client certificate held in the secure element; firmware image and its signing trust anchor; measurement data in transit; the local recovery interface. Expected time in use: 8 years. Comparable fixed-installation sensors in this segment are specified for an 8 to 10 year service life, and customers replace them on building-refit cycles rather than annually. Threats & analysis: Credential theft from a flat network leading to gateway access; malicious firmware via the recovery port; downgrade to a vulnerable firmware version; supply-chain compromise of a third-party TLS library; denial of service through malformed MQTT frames. 4. SUPPORT-PERIOD DETERMINATION (Annex VII(4) / Art. 13(8)) Support period: 8 years, ends 09/2034 (at least the expected time in use, and at least 5 years unless that use time is genuinely shorter, Art. 13(8); each issued security update stays available for 10 years or the remainder of the support period, whichever is longer, Art. 13(9)) 5. STANDARDS / COMMON SPECIFICATIONS APPLIED (Annex VII(5)) [Record standards relied upon — no CRA harmonised standard cited in the OJ at pack v0.3.0; verify current status.] 6. ESSENTIAL-REQUIREMENTS ASSESSMENT & TEST REPORTS (Annex VII(6) / Annex I Parts I & II — Part II statuses listed in section 2) [MET] Annex I Part I(1) Appropriate cybersecurity based on risk — Recorded in the design file and verified at release. [MET] Annex I Part I(2)(a) No known exploitable vulnerabilities at delivery — Release 2.4.0 screened against EUVD and NVD on 2026-07-20. Two medium findings in the TLS library remediated in 2.4.0; no known exploitable vulnerabilities open at release. [MET] Annex I Part I(2)(b) Secure-by-default & resettable — Ships with no default password. First boot forces credential creation over the local interface. Factory reset restores the shipped state and clears stored credentials. [MET] Annex I Part I(2)(c) Addressable via security updates — Signed over-the-air updates with automatic rollback on a failed boot. Anti-downgrade counter prevents installing an image older than the current one. [MET] Annex I Part I(2)(d) Access control / authentication — Per-device client certificate issued at manufacture and held in the secure element. The recovery port requires physical presence plus the device-unique recovery code. [MET] Annex I Part I(2)(e) Confidentiality (encryption) — MQTT and the update channel use TLS 1.3. Credentials and the client key are held in the secure element and are not readable over any external interface. [MET] Annex I Part I(2)(f) Integrity & corruption reporting — Firmware images are signed; secure boot verifies the signature on every start. Verification failure halts the boot and raises a tamper event to the gateway. [MET] Annex I Part I(2)(g) Data minimisation — Only temperature, humidity, device identifier and firmware version are transmitted. No personal data is collected or stored. [MET] Annex I Part I(2)(h) Availability & DoS resilience — Watchdog restarts the MQTT client on failure. Malformed frames are dropped without affecting sampling; measurement continues and buffers locally when the gateway is unreachable. [MET] Annex I Part I(2)(i) Minimise impact on other devices/networks — The sensor initiates outbound connections only, exposes no listening services on the network interface, and cannot be used to reach other hosts. [MET] Annex I Part I(2)(j) Limit attack surface — The only exposed interfaces are the outbound MQTT client and the physically-present recovery port. Debug UART is disabled in production images and the test pads are unpopulated. [MET] Annex I Part I(2)(k) Exploitation mitigation — Compiled with stack protector, ASLR and non-executable memory. The MQTT parser runs with a fixed buffer and rejects oversized frames before parsing. [MET] Annex I Part I(2)(l) Security logging / monitoring (user opt-out) — Boot events, update results, signature-verification failures and repeated authentication failures are recorded and forwarded to the gateway. Logs hold no personal data. [MET] Annex I Part I(2)(m) Secure permanent data removal & transfer — Recorded in the design file and verified at release. 7. EU DECLARATION OF CONFORMITY — copy attached (Annex VII(7)) 8. SBOM — available on reasoned request of a market surveillance authority (Annex VII(8)) CONFORMITY ROUTE: Default → You can self-assess: the internal control procedure (Module A, Annex VIII Part I) is always available for default-category products (Art. 32(1)). READINESS: 100% (27 met / 0 partial / 0 not met / 0 N/A) RETENTION: keep this file and the DoC (Art. 13(13)), and the Annex II information (Art. 13(18)), for 10 years or the support period, whichever is longer.
EU Declaration of Conformity
Annex V, Art. 28The one-page declaration you sign. It carries your name, so the file above has to support it.
EU DECLARATION OF CONFORMITY (draft — CRA Annex V) 1. Product (name, type and unique identification): EX-100 Industrial Temperature Sensor 2.4.0 / EX100-2026-B 2. Manufacturer (or authorised representative): Example Manufacturer GmbH, Beispielstrasse 1, 10115 Berlin, Germany 3. This EU declaration of conformity is issued under the sole responsibility of the provider (Annex V point 3). 4. Object of the declaration (identification allowing traceability): EX-100 Industrial Temperature Sensor 2.4.0 / EX100-2026-B 5. The object described above is in conformity with the relevant Union harmonisation legislation: Regulation (EU) 2024/2847 (Cyber Resilience Act). 6. References to relevant harmonised standards used, or other common specifications or cybersecurity certifications in relation to which conformity is declared: [list] 7. Notified body (where applicable): Not required — internal control (Module A, Annex VIII Part I). 8. Additional information — Signed for and on behalf of: __________ (place/date): __________ (name, function)(signature): __________ [A simplified DoC per Annex VI may instead give the internet address of this full DoC — Art. 13(20).]
Information and instructions to the user
Annex IIWhat ships with the product: the vulnerability-reporting contact, the support end date, and how updates reach the user.
INFORMATION & INSTRUCTIONS TO THE USER (CRA Annex II) 1. Manufacturer: Example Manufacturer GmbH, Beispielstrasse 1, 10115 Berlin, Germany, hello@example-manufacturer.invalid 2. Single point of contact for reporting and receiving vulnerability information: security@example-manufacturer.invalid · Where the coordinated vulnerability disclosure policy can be found: [URL] 3. Product identification: EX-100 Industrial Temperature Sensor 2.4.0 / EX100-2026-B 4. Intended purpose, security environment provided by the manufacturer, essential functionalities, and information about the security properties: Fixed-installation temperature and humidity sensing in light industrial environments. Reports readings over Wi-Fi to a customer-operated gateway on a segmented OT network. No personal data is processed. 5. Known/foreseeable circumstances that may lead to significant cybersecurity risks: Installed on a flat network alongside IT equipment rather than a segmented OT VLAN. Left on default Wi-Fi credentials. Auto-update disabled by a site policy. Physically reachable in a plant room by contractors who are not employees. 6. Internet address of the EU Declaration of Conformity (where applicable): [URL] 7. Type of technical security support offered & end date of the support period: until 09/2034 (support period 8 years) 8. Detailed instructions (or internet address) for: (a) secure commissioning & lifetime use; (b) how changes can affect data security; (c) installing security-relevant updates; (d) secure decommissioning, incl. secure removal of user data; (e) turning off the default automatic installation of security updates; (f) where intended for integration: the information integrators need for Annex I and Annex VII: [instructions / URL] 9. Where the SBOM can be accessed, if the manufacturer decides to make it available to the user: [URL / on request]
Generate the same set for what you actually ship.
The wizard asks the questions above in order, keeps your evidence with each requirement, and produces this documentation set for your product.