CRACheck — Technical Documentation Generator

Manufacturer and Product Data

Art. 13.15, 13.16, 13.17 — Identification of the manufacturer and the product with digital elements

🏢 Manufacturer data

Company / manufacturer name *

Country of establishment *

Company size *

Manufacturer postal address *

Contact person *

Contact email *

Manufacturer website

📦 Product with digital elements data

Product name *

Software version *

Type/batch/serial number

Art. 13.15 — Element allowing product identification

Product type *

Description of the intended purpose *

Art. 3.23 — Include the use for which the product is designed, the context and conditions of use

Does the product include a remote data processing solution?

Art. 3.2 — Cloud, API, manufacturer backend without which the product cannot perform one of its functions

Is the product already on the EU market?

Product Classification

Art. 2, Art. 7, Art. 8 — Determine whether the product falls within the CRA and its category

🚫 Scope exclusions (Art. 2)

The CRA does not apply to certain products already regulated by other legislation. Answer the following questions to verify whether your product is excluded.

Is it a medical device regulated by Reg. (EU) 2017/745 or 2017/746?

Art. 2.2(a)(b)

Is it a type-approved vehicle under Reg. (EU) 2019/2144?

Art. 2.2(c)

Is it a product certified under Reg. (EU) 2018/1139 (aviation)?

Art. 2.3

Is it marine equipment covered by Dir. 2014/90/EU?

Art. 2.4

Is it a product developed exclusively for national security/defence or to process classified information?

Art. 2.7

Is it free/open-source software NOT commercially marketed (no monetisation, no personal data as a condition of use)?

Art. 2 + Considerandos 17-18

Accepting non-profit donations is not considered commercial activity. Only commercially marketed open-source falls under the CRA.

📋 Product category (Art. 7 + Annexes III and IV)

Does your product have as its core functionality any of the categories listed in Annexes III or IV? The integration of an Annex III component (e.g. an embedded firewall) does not automatically make the product important (Art. 7.1). The determining factor is the core functionality.

Does the product have as its core functionality any Annex III — Class I category?

Examples: identity managers, browsers, password managers, anti-malware, VPN, network management, SIEM, boot managers, PKI, network interfaces, operating systems, routers/modems/switches, microprocessors/microcontrollers with security functions, smart home virtual assistants, smart home products with security functions (locks, cameras, alarms, baby monitors), connected toys with social/recording/location functions, health wearables

Does the product have as its core functionality any Annex III — Class II category?

Examples: hypervisors and container runtimes, firewalls, intrusion detection/prevention systems (IDS/IPS), tamper-resistant microprocessors and microcontrollers

Does the product have as its core functionality any Annex IV — Critical products category?

Examples: hardware with security boxes, smart meter gateways, smartcards, secure elements

Essential Cybersecurity Requirements

Annex I, Part I — Requirements relating to product properties

For each requirement: indicate whether it applies to your product and, if it does, briefly describe how you implement it. If it does not apply, state why (Art. 13.4 requires justification in the technical documentation).

(a) No known exploitable vulnerabilities

Annex I, Part I, 2(a)

The product must be placed on the market without known exploitable vulnerabilities.

(b) Secure by default configuration

Annex I, Part I, 2(b)

Secure factory configuration, including the ability to reset to the original state.

(c) Security updates

Annex I, Part I, 2(c)

Ensure that vulnerabilities can be fixed through security updates, including automatic updates with opt-out option.

(d) Protection against unauthorised access

Annex I, Part I, 2(d)

Access control mechanisms: authentication, identity management, and reporting of unauthorised access.

(e) Data confidentiality

Annex I, Part I, 2(e)

Encryption of data at rest and in transit using state-of-the-art mechanisms.

(f) Data integrity

Annex I, Part I, 2(f)

Protect the integrity of data, commands, programs and configuration against unauthorised manipulation.

(g) Data minimisation

Annex I, Part I, 2(g)

Process only data that is adequate, relevant and limited to what is necessary for the intended purpose.

(h) Availability and resilience

Annex I, Part I, 2(h)

Protect the availability of essential functions, even after an incident. Measures against denial-of-service attacks.

(i) Minimise impact on other devices

Annex I, Part I, 2(i)

Minimise the negative impact of the product on the availability of services of other devices or networks.

(j) Minimise attack surface

Annex I, Part I, 2(j)

Design, develop and produce the product to limit the attack surface, including external interfaces.

(k) Incident impact mitigation

Annex I, Part I, 2(k)

Design the product to reduce the impact of an incident using appropriate mitigation mechanisms.

(l) Security logging and monitoring

Annex I, Part I, 2(l)

Provide security information by recording and monitoring relevant internal activity, with opt-out option for the user.

(m) Secure data erasure

Annex I, Part I, 2(m)

Allow users to securely and permanently erase all data and configurations, and transfer them securely.

Vulnerability Management and Support Period

Annex I, Part II + Art. 13.8 — Vulnerability management requirements throughout the support period

🛡️ Support period (Art. 13.8)

The minimum support period is 5 years, unless the expected product lifetime is shorter. During this period, the manufacturer must provide free security updates and manage vulnerabilities.

Support period (years) *

End of support date (month/year) *

Justification for the chosen support period *

Art. 13.8 — Must consider: reasonable user expectations, nature of the product, applicable legislation on useful life, support periods for similar products

📋 Software Bill of Materials — SBOM (Annex I, Part II, point 1)

What is an SBOM? It is a formal inventory of all software components your product contains: libraries, frameworks, third-party modules. It is like an ingredient list for food, but for software. The CRA requires it to track vulnerabilities in any component.

Example: If your product uses the OpenSSL library for encryption, that library must appear in your SBOM. If a vulnerability in OpenSSL is discovered tomorrow, the SBOM allows you to immediately identify that your product is affected.

Have you generated an SBOM for this product? *

SBOM format

Industry-recognised formats for generating machine-readable SBOMs

Specify the SBOM format

Approximate number of top-level dependencies

What is this? Top-level dependencies are the libraries and components your product imports directly (not the sub-dependencies of those libraries). Example: if your Node.js app has 47 packages in its package.json, it has 47 top-level dependencies, even though those 47 packages in turn download 300 sub-dependencies. Enter the direct number.

🔄 Vulnerability management processes (Annex I, Part II)

Why is this important? The CRA not only requires your product to be secure when sold, but that you actively maintain its security throughout the support period. This includes: having a channel for reporting vulnerabilities, fixing them quickly, and distributing fixes to users.

Coordinated Vulnerability Disclosure (CVD) policy *

Annex I, Part II, point 5 — Mandatory. A public and documented process that tells security researchers and users how to responsibly report vulnerabilities. It must include: reporting channel, response times, and how the disclosure will be coordinated once the vulnerability is fixed.
Example: "We publish our CVD policy on our website /security. Researchers can report to security@company.com. We acknowledge receipt within 48h, evaluate within 5 days and coordinate public disclosure after releasing the patch."

Single point of contact for vulnerability reporting (Art. 13.17) *

Art. 13.17 — Mandatory. An easily visible address (email, web, phone) where anyone can report a security flaw. The CRA requires it not to be just a chatbot — there must be a human contact option.
Example: "security@mycompany.com + web form at /security + phone +1 302 555 0142"

Secure update distribution mechanism *

Annex I, Part II, point 7. How you send security updates to your users securely (so that no one can intercept or modify them). Include: distribution channel, integrity verification, and whether security updates are separated from functional ones.
Example: "OTA updates digitally signed with Ed25519. TLS 1.3 encrypted channel. The device verifies the signature before installing. If it fails, it rolls back to the previous firmware."

Regular security tests and reviews *

Annex I, Part II, point 3. The periodic tests you perform to verify your product remains secure: penetration tests, vulnerability scans, code reviews, etc.
Example: "Quarterly penetration test by an external firm. Weekly automated dependency scan with Snyk. Static code analysis on every release with SonarQube."

Vulnerability remediation process *

Annex I, Part II, point 2 — Security updates must be provided without delay and free of charge. How you classify and fix vulnerabilities once detected. Must include: prioritisation criteria (usually by CVSS severity), maximum fix times, and confirmation that security updates are free of charge.
Example: "Critical vulnerabilities (CVSS ≥9): patch within 24-48h. High (7-8.9): patch within 7 days. Medium (4-6.9): patch within 30 days. All security updates are free of charge."

User Information and Standards

Annex II + Art. 27 — Information to accompany the product and applied standards

📖 User information and instructions (Annex II)

Known circumstances that may give rise to significant cybersecurity risks *

Annex II, point 5. Situations you know of in which your product could be vulnerable or compromised. Think about: what happens if the user misuses it, in an insecure environment, or without updating.
Example: "Using the device on an open WiFi network (no password) may expose communications. Not updating the firmware may leave known vulnerabilities unpatched. Reusing the device without factory reset may expose the previous user's data."

Secure installation and use instructions *

Annex II, point 8(a). The steps the user must follow to install and use your product securely. These are like the "safety instructions" for any product, but for cybersecurity.
Example: "1. Connect only to WiFi with WPA2/WPA3. 2. Change the admin password on first use. 3. Enable two-factor authentication. 4. Keep firmware updated. 5. Do not expose the device directly to the internet."

Secure uninstallation / decommissioning instructions *

Annex II, point 8(d). How the user can erase their data from the product before disposing of it, selling it or returning it. Include both local erasure and cloud account unlinking (if applicable).
Example: "Factory reset from the Settings > Restore factory defaults menu. Erases all credentials, configurations and local data. Automatically unlinks from the user's cloud account."

Is the product intended for integration into other products? (Annex II, point 8(f))

📐 Applied standards and specifications (Annex VII, point 5)

If you have applied harmonised standards, common specifications or European certification schemes, conformity with the requirements covered by those standards is presumed (Art. 27). If you do not apply them, you must describe the alternative solutions adopted.

Applied harmonised standards or specifications

If no harmonised standards have been published yet, you may indicate applied international standards (ISO/IEC, ETSI EN, etc.)

Test reports (Annex VII, point 6)

Summary of tests performed to verify conformity with the essential requirements

Signatory Declaration and Summary

Art. 13.12 + Annex V — Final review before generating the dossier

📊 Dossier summary

Company:

Country:

Product:

Type:

Size:

On market:

Product category:

Reference: Date:

Your dossier will include 8 documents (~40 pages):

• Doc 1: Product Classifier and Scope — Art. 2 + Art. 7 + Annexes III/IV (3 pages)
• Doc 2: Technical Documentation — Art. 31 + Annex VII, 8 points (5-7 pages)
• Doc 3: Cybersecurity Risk Assessment — Art. 13 + Annex I, 13+8 requirements (8-10 pages)
• Doc 4: User Information and Instructions — Annex II, 9 points (4-5 pages)
• Doc 5: EU Declaration of Conformity — Art. 28 + Annex V (2-3 pages)
• Doc 6: Coordinated Vulnerability Disclosure Policy — Annex I, Part II (3-4 pages)
• Doc 7: Vulnerability and Incident Notification Template — Art. 14, 3 phases (7-9 pages)
• Doc 8: CRA Obligations Calendar + non-compliance fines (2-3 pages)

✍️ Signatory declaration

I declare that the information provided in this form is true, complete and accurate to the best of my knowledge. I assume full legal responsibility for the content of the document that will be generated with this information. I understand that CRACheck is a document generator that operates 100% in my browser, does not verify the accuracy of my declarations against external sources, and that the final responsibility for the document is exclusively mine. The product classification reflected in the dossier is based on the information I have declared pursuant to Art. 7 of Regulation (EU) 2024/2847.

Product version: CRACheck v1.0 covers product classification (Art. 2 + Art. 7 + Annexes III/IV), manufacturer technical documentation (Art. 31 + Annex VII), cybersecurity risk assessment (Art. 13 + Annex I) and declaration of conformity (Art. 28 + Annex V). SolidwareTools monitors the OJEU and EUR-Lex weekly to ensure this product reflects current regulations.

Your CRACheck Dossier

Generate your complete technical documentation.

CYBER RESILIENCE ACT · Regulation (EU) 2024/2847

Without technical documentation in accordance with Annex VII, your product cannot bear the CE marking or be legally marketed in the EU from December 2027.

1 PRODUCT

149 €

/ product

PACK 10

990 €

99 € / product

PACK 30

2.370 €

79 € / product

✔ Product Classifier (Art. 2 + Annexes III/IV)

✔ Technical Documentation per Annex VII — 8 points

✔ Cybersecurity Risk Assessment — Annex I

✔ EU Declaration of Conformity — Annex V template

✔ CVD Policy + Art. 14 Notification + Calendar + 2 more

One-time payment · 10 regenerations · 30 days editing · PDF yours forever · 100% in your browser

How does your licence work?
1. Buy a licence on Gumroad (1, 10 or 30 products).
2. You receive a key (XXXXXXXX-XXXXXXXX-XXXXXXXX-XXXXXXXX).
3. Paste it below and generate your dossier.
4. 1 licence = 1 product. For another product, use another licence from your pack or buy a new one.

Buy licence on Gumroad — from €79 →

High volume or special-price packs: hello@solidwaretools.com

This document has been generated by CRACheck (SolidwareTools) from the information provided by the signatory. It does not constitute legal advice or a third-party audit. The accuracy of the data and effective compliance with applicable legal obligations are the sole responsibility of the manufacturer. SolidwareTools guarantees that the structure of this document follows Regulation (EU) 2024/2847 in its current wording at the date of issuance. For personalised advice, consult a qualified professional.