Reg (EU) 2024/2847Generate dossier — €149
LIVE — Enforcement tracker · Deadline dashboard · Transposition status — Updated weekly from EUR-Lex, Safety Gate, OEIL & 12 official sourcesView regulatory intelligence →

Annex I, Part I, point (2)(e) of Regulation (EU) 2024/2847 requires your product to protect the confidentiality of data stored, transmitted, or otherwise processed, including by means of state-of-the-art mechanisms such as encryption. Point (2)(g) requires that the product processes only data that is adequate, relevant, and limited to what is necessary. Two requirements. One technical documentation file. CRACheck generates it.

Data protection under the CRA is not just a GDPR concern. Annex I, Part I, point (2)(e) covers all data the product handles — personal, operational, telemetry, configuration — and requires confidentiality protection including encryption at rest and in transit. Point (2)(g) adds a data minimisation requirement that applies beyond personal data: the product must not collect or process data beyond what its intended purpose requires. Both requirements feed into the risk assessment under Art. 13(2)–(3) and must be documented in the technical file per Annex VII. CRACheck structures both into the 8-document package. 15–25 minutes. €149.

Generate CRA dossier — €149Free: check your product classification

€149 one-time · 8-document ZIP · 15–25 minutes · Browser-side

Regulation (EU) 2024/2847 · Art. 31 + Annex VII · 8 documents · 100% browser-side

Data protection requirements at a glance

Part I(2)(e)
Confidentiality — encryption at rest and in transit
Part I(2)(g)
Data minimisation — adequate, relevant, limited
Art. 13
Risk assessment must cover both requirements

How to implement and document data protection under the CRA

1
Map all data flows
Identify every type of data your product processes: user input, telemetry, logs, configuration, credentials, firmware updates, API calls, cached data.
2
Apply data minimisation
For each data type, assess whether it is adequate, relevant, and limited to what is necessary for the intended purpose per Annex I, Part I, point (2)(g). Remove or reduce data that exceeds the purpose.
3
Implement encryption
Annex I, Part I, point (2)(e): encrypt relevant data at rest and in transit using state-of-the-art mechanisms. Document the algorithms, key lengths, and key management approach.
4
Document in the risk assessment
Art. 13(2)–(3): the risk assessment must show how points (2)(e) and (2)(g) apply to your product and how the implemented measures address identified risks.
5
Document in user information
Annex II requires informing users about data processed by the product and security measures. If encryption can be configured by the user, document the options.
6
Run CRACheck
Input your product data, encryption details, and data flow analysis. CRACheck structures the documentation per Annex VII with the data protection requirements mapped to the risk assessment and user information documents.

Three mistakes manufacturers make with data protection

❌
GDPR ONLY

Treating CRA data minimisation as identical to GDPR data minimisation

GDPR Art. 5(1)(c) applies to personal data. CRA Annex I, Part I, point (2)(g) applies to all data the product processes — including operational telemetry, diagnostic logs, and device metadata that may not qualify as personal data under GDPR. A product compliant with GDPR data minimisation may still violate the CRA if it collects excessive non-personal data.

❌
PARTIAL ENCRYPTION

Encrypting data in transit but not at rest

Annex I, Part I, point (2)(e) explicitly mentions "data at rest and in transit." TLS for network communication without encryption for stored data (credentials, logs, configuration files, cached user data) leaves a compliance gap. The risk assessment must address both states.

❌
OUTDATED CRYPTO

Using deprecated encryption algorithms and claiming compliance

Point (2)(e) requires "state of the art mechanisms." SHA-1 for hashing, TLS 1.0/1.1 for transport, DES/3DES for symmetric encryption, and RSA-1024 for asymmetric encryption are not state of the art as of 2026. The technical documentation must specify current algorithms (AES-256, TLS 1.3, SHA-256/SHA-3, RSA-2048+ or ECDSA).

What the ZIP contains

8 PDF documents generated from your data. Each cites the specific article of Regulation (EU) 2024/2847 it complies with.

1

Product Classifier

Category per Annex III/IV. Products handling sensitive data (e.g., smart locks, health monitors) face higher scrutiny on encryption implementation.

2

Technical Documentation

Annex VII. Point 2(a) covers the design description including encryption architecture and data flow diagrams showing minimisation measures.

3

Risk Assessment

Per Art. 13(2)–(3). Maps points (2)(e) and (2)(g) against your product: which data requires encryption, which data flows have been minimised, residual risks.

4

User Information

Per Annex II. Informs users what data the product processes, how it is protected, and what encryption options are configurable.

5

Declaration of Conformity

Per Art. 28 and Annex V.

6

CVD Policy

Per Annex I, Part II, point (5). Cryptographic vulnerabilities are among the most commonly reported through CVD channels.

7

Notification Template

Per Art. 14. A vulnerability in encryption implementation triggers the 24h/72h/14-day reporting pipeline.

8

Obligations Calendar

Key dates including crypto algorithm review milestones through the support period.

See before you buy — Download sample dossier (PDF, fictional company) — Real structure, real articles, real format. Fictional data.

Generated from your data, in your browser. No data leaves your device.

What you pay

🧾 THE ALTERNATIVE

Hiring a data protection and cryptography consultant to audit data flows, assess encryption implementation, map against CRA Annex I, and produce the Annex VII documentation.

€10,000–€20,000
4–8 weeks. One product. One snapshot in time — crypto standards evolve.
✓ Last regulatory check: 1 May 2026 · No substantive changes detected · View history

Technical documentation under Article 31 and Annex VII of Regulation (EU) 2024/2847. 8 PDF documents. 15–25 minutes. €149 one-time.

© 2026 SolidwareTools™ · Built on Regulation (EU) 2024/2847 · Not legal advice · Not a third-party audit
SolidwareTools provides structured self-assessment software based on the cited European Union directives and regulations. The documents generated are not legal advice and do not constitute a third-party audit. The user is responsible for the accuracy of declared data and for actual compliance with applicable obligations. All technical content is sourced from EUR-Lex and the official publications of national supervisory authorities. SolidwareTools is not affiliated with the European Commission or any national authority. SolidwareTools does not interpret case law from the CJEU, national courts or competent authorities, nor does it assess the applicability of the regulation to the user's specific situation. The maximum liability of SolidwareTools, in any case and for any cause, is limited to the amount paid for the corresponding product.
Reg (EU) 2024/2847Generate dossier — €149
LIVE — Enforcement tracker · Deadline dashboard · Transposition status — Updated weekly from EUR-Lex, Safety Gate, OEIL & 12 official sourcesView regulatory intelligence →

Annex I, Part I, point (2)(b) of Regulation (EU) 2024/2847 requires your product to include the possibility to reset the product to its original state — the secure-by-default configuration. Point (2)(f) requires secure data erasure to protect availability and prevent data leakage upon decommissioning. Two requirements that intersect at the factory reset function. CRACheck documents how your product meets both.

Factory reset under the CRA is not just a convenience feature. It is a regulatory requirement tied to the secure-by-default configuration of point (2)(b). The reset must return the product to a documented secure state — not to a pre-hardening firmware, not to a state with residual user data, not to a state with disabled security features. Point (2)(f) adds the dimension of secure data erasure: when the product is decommissioned or changes hands, stored data must be securely erased to prevent exposure. The risk assessment per Art. 13(2)–(3) must address both the reset target state and the data erasure mechanism. CRACheck structures the documentation for both requirements within the 8-document Annex VII package. 15–25 minutes. €149.

Generate CRA dossier — €149Free: check your product classification

€149 one-time · 8-document ZIP · 15–25 minutes · Browser-side

Regulation (EU) 2024/2847 · Art. 31 + Annex VII · 8 documents · 100% browser-side

Reset and erasure requirements at a glance

Part I(2)(b)
Reset to secure original state
Part I(2)(f)
Secure data erasure on decommissioning
Annex II(8)
User instructions must explain how to reset

How to implement and document factory reset

1
Define the secure reset state
Document what "original state" means for your product: which settings, credentials, services, ports, and protocols are restored. This state must match your documented secure-by-default configuration per point (2)(b).
2
Implement data erasure
Define what data is erased during reset: user credentials, configuration, logs, cached data, paired device information. Per point (2)(f), the erasure must be secure — not just file deletion but actual data overwriting or cryptographic erasure.
3
Make reset user-accessible
Point (2)(b) requires "the possibility" to reset. Annex II, point (8) requires user instructions. The reset must be accessible without manufacturer intervention or specialised tools.
4
Address cloud data
If the product stores data in cloud services, determine whether factory reset triggers cloud data deletion. Document the decision and rationale in the risk assessment.
5
Document in user information
Annex II, point (8): instructions on how to reset the product to its original state. Include what data will be erased and what steps the user should take before resetting.
6
Run CRACheck
Input your reset implementation details. CRACheck generates the documentation covering both the reset function (2)(b) and data erasure (2)(f), integrated into the risk assessment, user information, and technical documentation.

Three mistakes manufacturers make with factory reset

❌
INSECURE RESET STATE

Factory reset restores a pre-hardening configuration weaker than the secure default

Annex I, Part I, point (2)(b) ties the reset to the "original state" which must be the secure-by-default configuration. If reset restores an older firmware version, re-enables disabled services, or reverts to shared default credentials, it contradicts the secure-by-default requirement.

❌
RESIDUAL DATA

Factory reset deletes files but does not securely erase data from storage

Simple file deletion leaves data recoverable from flash storage. Point (2)(f) requires protection against data leakage. Secure erasure means cryptographic key deletion (for encrypted storage) or block-level overwriting. A factory reset that leaves recoverable user data violates the decommissioning protection requirement.

❌
NO USER ACCESS

Reset requires manufacturer tools, special cables, or service mode access

Point (2)(b) requires "the possibility to reset the product." If the user cannot perform the reset without contacting the manufacturer, using proprietary software, or connecting special hardware, the accessibility of the reset function is compromised. Annex II, point (8) requires clear instructions the user can follow independently.

What the ZIP contains

8 PDF documents generated from your data. Each cites the specific article of Regulation (EU) 2024/2847 it complies with.

1

Product Classifier

Category per Annex III/IV. IoT devices with persistent storage face particular scrutiny on data erasure implementation.

2

Technical Documentation

Annex VII. Documents the reset mechanism, target state, data erasure method, and how they map to Annex I Part I(2)(b) and (2)(f).

3

Risk Assessment

Per Art. 13(2)–(3). Assesses risks of incomplete reset, residual data exposure, and cloud data persistence.

4

User Information

Per Annex II. Includes reset instructions per point (8): how to initiate, what data is erased, pre-reset backup recommendations.

5

Declaration of Conformity

Per Art. 28 and Annex V.

6

CVD Policy

Per Annex I, Part II, point (5). Incomplete reset or data erasure may be reported as a vulnerability through the CVD channel.

7

Notification Template

Per Art. 14. A vulnerability in the reset or erasure mechanism triggers the reporting pipeline.

8

Obligations Calendar

Key dates through the support period.

Generated from your data, in your browser. No data leaves your device.

What you pay

🧾 THE ALTERNATIVE

Commissioning a security consultant to audit your factory reset implementation, verify data erasure completeness, and produce the Annex VII documentation.

€8,000–€18,000
4–8 weeks. One product revision.
✓ Last regulatory check: 1 May 2026 · No substantive changes detected · View history