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.
✓ CRACHECK
€149
15–25 minutes. 8 PDFs documenting your encryption implementation and data minimisation measures per Annex I, Part I, points (2)(e) and (2)(g). 10 regenerations as crypto configurations evolve. Browser-side.

Two layers: documentation and implementation

● LAYER 1 — DOCUMENTATION

Data protection compliance mapping

CRACheck generates the documentation mapping your encryption implementation and data minimisation measures against Annex I, Part I, points (2)(e) and (2)(g). It structures the mapping within the risk assessment, technical documentation, and user information documents. Cross-references ensure consistency across the 8-document package.

∅ LAYER 2 — WHAT CRACHECK DOES NOT DO

Cryptographic audit and data flow analysis

CRACheck does not audit your encryption implementation. It does not test cipher suites, key management, or certificate chains. It does not analyse your data flows for minimisation compliance. You must implement encryption and minimisation in your product. CRACheck documents what you implemented and maps it to the CRA requirements.

Implement the encryption. Minimise the data. Then document it with CRACheck.

Enforcement regime

🇪🇺
Non-compliance with Annex I essential cybersecurity requirements including encryption and data minimisation
€15,000,000 / 2.5%

Art. 64(2).

🇪🇺
Failure to document data protection measures in technical documentation per Art. 31
€10,000,000 / 2%

Art. 64(3).

🇪🇺
Providing misleading information about encryption or data handling to authorities
€5,000,000 / 1%

Art. 64(4).

Alternatives comparison

CriterionNo documentationCrypto consultantGDPR-only assessmentCRACheck
CRA Annex I mappingMissingYes (if CRA-specific)Partial — personal data onlyYes — (e) + (g)
Annex VII integrationNoneSeparate reportNot CRA-structuredAutomatic
Time to documentation4–8 weeks3–6 weeks15–25 minutes
Cost€0 (+ fine risk)€10K–€20K€5K–€12K€149 one-time

Product family with shared crypto libraries?

Even products sharing the same encryption library require separate documentation per Art. 31 if they process different data types or have different attack surfaces. Volume pricing: €99/product (10-pack) or €79/product (30-pack).

Request volume pricing
Each licence includes 30-day editing and 10 regenerations.

What CRACheck guarantees and what it does not

CRACheck generates a structured document according to Article 31 and Annex VII of Regulation (EU) 2024/2847, documenting your encryption implementation and data minimisation measures per Annex I, Part I, points (2)(e) and (2)(g), based on the information you provide. The accuracy of your cryptographic and data flow descriptions is your responsibility as manufacturer.

We guarantee that the document structure follows Article 31 and Annex VII of Regulation (EU) 2024/2847 and that all legal references cited are correct. We do not guarantee that a specific encryption implementation will be deemed compliant by a market surveillance authority in a specific case.

CRACheck is not legal advice. For specific questions about cryptographic algorithm selection, key management, or data minimisation in your product category, consult with a qualified cybersecurity professional.

Frequently asked questions — Data minimisation and encryption

What does "data minimisation" mean under the CRA?
Annex I, Part I, point (2)(g) of Regulation (EU) 2024/2847 requires products to process only data — personal or otherwise — that is adequate, relevant, and limited to what is necessary in relation to the intended purpose of the product. This mirrors the GDPR principle but applies to all data processed by the product, not only personal data.
Does point (2)(e) require encryption for all data?
Annex I, Part I, point (2)(e) requires protection of the confidentiality of data "stored, transmitted or otherwise processed" by the product, including "by means of state of the art mechanisms such as encryption of relevant data at rest and in transit." The word "relevant" and "such as" indicate that encryption is the expected mechanism but that the manufacturer must assess which data requires it based on the risk assessment per Art. 13.
Is the CRA data minimisation requirement the same as GDPR data minimisation?
Similar principle, different scope. GDPR Art. 5(1)(c) applies to personal data processing. CRA Annex I, Part I, point (2)(g) applies to all data processed by the product — personal, operational, telemetry, log, diagnostic. A product that minimises personal data under GDPR may still process excessive operational data under the CRA.
What encryption standard satisfies "state of the art"?
The regulation does not name a specific algorithm. "State of the art" per Annex I, Part I, point (2)(e) means current best practice at the time of market placement. As of 2026, this typically means AES-256 for data at rest and TLS 1.3 for data in transit. The technical documentation under Annex VII should specify the algorithms and key management approach used.
Is this a subscription?
No. One-time payment. The licence includes a 30-day editing window and 10 regenerations. The downloaded PDF is yours permanently.
Can I request a refund?
Article 16(m) of Directive (EU) 2011/83 applies. Upon licence activation, you give express consent for immediate generation of the digital content, waiving the 14-day withdrawal right. Refunds are accepted only for a reproducible technical defect.
What if the regulation changes?
If the regulation is amended during your licence validity period, you can regenerate the documentation using the updated version of the generator at no additional cost.
⚠️ Important notice: CRACheck is a self-assessment documentation tool, not legal advice and not a third-party audit. The document under Article 31 and Annex VII of Regulation (EU) 2024/2847 is generated from your input data. You are responsible for the accuracy of the data you provide. CRACheck does not replace a qualified professional assessment.

Encrypt the data. Minimise the collection. Document both.

€149 per product · one-time payment
8-document ZIP · 15–25 min · Art. 31 + Annex VII · 100% browser-side · Permanent PDF
Generate your CRA documentation — €149
✓ Last regulatory check: 1 May 2026 · No substantive changes detected · View history
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.
✓ CRACHECK
€149
15–25 minutes. 8 PDFs documenting your factory reset and data erasure implementation per Annex I Part I(2)(b) and (2)(f). 10 regenerations. Browser-side.

Two layers: documentation and implementation

● LAYER 1 — DOCUMENTATION

Reset and erasure compliance mapping

CRACheck generates the documentation mapping your factory reset function and data erasure mechanism against Annex I, Part I, points (2)(b) and (2)(f). It documents the reset target state, erasure method, user accessibility, and cloud data handling within the risk assessment, technical documentation, and user information documents.

∅ LAYER 2 — WHAT CRACHECK DOES NOT DO

Reset verification and data forensics

CRACheck does not test your factory reset function. It does not verify that data is actually erased. It does not perform forensic analysis of storage media after reset. You must implement and test the reset and erasure mechanisms. CRACheck documents what you implemented and maps it to the regulatory requirements.

Implement the reset. Test the erasure. Then document both with CRACheck.

Enforcement regime

🇪🇺
Non-compliance with Annex I essential cybersecurity requirements including reset and erasure
€15,000,000 / 2.5%

Art. 64(2).

🇪🇺
Failure to document reset and erasure implementation in technical documentation per Art. 31
€10,000,000 / 2%

Art. 64(3).

🇪🇺
Providing misleading information about data erasure capabilities
€5,000,000 / 1%

Art. 64(4).

Alternatives comparison

CriterionNo documentationSecurity consultantExisting QA docsCRACheck
CRA Annex I mappingMissingYes (if CRA-specific)PartialYes — (b) + (f)
Annex VII integrationNoneDependsNot CRA-structuredAutomatic
Time to documentation4–8 weeks2–4 weeks15–25 minutes
Cost€0 (+ fine risk)€8K–€18KInternal headcount€149 one-time

Product line with shared reset firmware?

Each product model requires its own documentation per Art. 31. Volume pricing: €99/product (10-pack) or €79/product (30-pack).

Request volume pricing
Each licence includes 30-day editing and 10 regenerations.

What CRACheck guarantees and what it does not

CRACheck generates a structured document according to Article 31 and Annex VII of Regulation (EU) 2024/2847, documenting your factory reset and data erasure implementation per Annex I, Part I, points (2)(b) and (2)(f), based on the information you provide. The accuracy of your implementation descriptions is your responsibility as manufacturer.

We guarantee that the document structure follows Article 31 and Annex VII of Regulation (EU) 2024/2847 and that all legal references cited are correct. We do not guarantee that a specific reset implementation will be deemed compliant by a market surveillance authority.

CRACheck is not legal advice. For specific questions about data erasure standards, storage media forensics, or cloud data deletion, consult with a qualified cybersecurity professional.

Frequently asked questions — Factory reset and data erasure

What does the CRA require for factory reset?
Annex I, Part I, point (2)(b) of Regulation (EU) 2024/2847 requires the product to include "the possibility to reset the product to its original state." The original state must be the documented secure-by-default configuration. The reset must return the product to a secure state, not to a pre-hardening firmware or configuration.
Must data be securely erased during factory reset?
Annex I, Part I, point (2)(f) requires the product to "protect the availability of essential and basic functions, including after the product has been decommissioned, by minimising the negative impact of other devices on the product or the network, and including the secure erasure of data." The secure erasure applies to decommissioning, and best practice extends it to factory reset to prevent data leakage between users.
Does the reset have to be user-accessible?
Annex I, Part I, point (2)(b) says "the possibility to reset the product to its original state." This implies the user must be able to trigger it. The user information under Annex II, point (8) must include instructions on how to perform the reset. A reset that requires manufacturer intervention or special tools may not satisfy the accessibility requirement.
What about data on cloud-connected services?
The CRA applies to the product with digital elements. If the product stores data in a cloud backend, the manufacturer must consider whether factory reset should also trigger deletion of cloud-stored user data associated with that device. The risk assessment per Art. 13(2)–(3) should address this scenario.
Is this a subscription?
No. One-time payment. The licence includes a 30-day editing window and 10 regenerations. The downloaded PDF is yours permanently.
Can I request a refund?
Article 16(m) of Directive (EU) 2011/83 applies. Upon licence activation, you give express consent for immediate generation of the digital content, waiving the 14-day withdrawal right. Refunds are accepted only for a reproducible technical defect.
What if the regulation changes?
If the regulation is amended during your licence validity period, you can regenerate the documentation using the updated version of the generator at no additional cost.
⚠️ Important notice: CRACheck is a self-assessment documentation tool, not legal advice and not a third-party audit. The document under Article 31 and Annex VII of Regulation (EU) 2024/2847 is generated from your input data. You are responsible for the accuracy of the data you provide. CRACheck does not replace a qualified professional assessment.

Reset to secure. Erase completely. Document both.

€149 per product · one-time payment
8-document ZIP · 15–25 min · Art. 31 + Annex VII · 100% browser-side · Permanent PDF
Generate your CRA documentation — €149
✓ Last regulatory check: 1 May 2026 · No substantive changes detected · View history