Quick overview — CRA in 4 minutes
The CRA sets cybersecurity requirements for digital products placed on the EU market. It formalizes “security by design” obligations, vulnerability handling, conformity assessments (self-assessment or third-party), and market surveillance.
- Scope: hardware/software products and remote data processing solutions, including components sold separately.
- Categories: by default, important products (Class I and II), and critical products.
- Conformity: Modules A, B+C, or H depending on product class and harmonized references.
- Timeline: phased ramp-up between 2026 and 2027.
- CryptPeer: positioned around “security by design”, but product classification and module selection must be confirmed per use case.
Introduction to the Cyber Resilience Act (CRA)
Regulation (EU) 2024/2847 aims to strengthen the cybersecurity of products with digital elements in the European Union through a uniform framework covering design, placing on the market, and lifecycle obligations.
Core objectives
- Accountability for manufacturers, importers, and distributors (obligations, evidence, ongoing follow-up).
- Risk reduction through essential requirements and vulnerability handling.
- Harmonization to prevent regulatory fragmentation.
- Trust: CE marking and market control mechanisms.
CE marking as a compliance signal
Under the CRA, compliance ties into CE marking, which requires demonstrating fulfillment of essential requirements and applicable assessment procedures.
CRA CE marking can only be affixed after the regulation fully applies and the relevant conformity procedure is formally completed.
Scope
The CRA targets products with digital elements: software and hardware products, and remote data processing solutions, including components sold separately.
Official annexes of the Cyber Resilience Act
CRA product classification relies strictly on the annexes of Regulation (EU) 2024/2847, which list—exhaustively— product categories deemed important or critical.
- Annex III — List of important products (Class I and II) (official EU text)
- Annex IV — List of critical products (official EU text)
Any product that does not explicitly match a listed typology falls, by default, into the standard category, subject to analysis of its main intended functionality.
Product categories
Default category
Digital products outside the “important” and “critical” lists. Examples: smartphones, computers, non-critical IoT devices.
Important products — Class I
Listed product types (e.g., operating systems, routers, browsers, password managers, SIEM, etc.).
Important products — Class II
Examples: hypervisors, firewalls/IDS/IPS, tamper-resistant microprocessors and microcontrollers.
Critical products
Examples: HSMs, smart cards/similar devices, smart metering gateways.
Key point: the product’s main functionality drives categorization. Some sectors are excluded (e.g., medical devices, automotive, civil aviation, etc.).
Conformity assessment routes
The CRA structures conformity assessment procedures into modules, with stronger requirements as criticality increases.
Module A: Self-assessment
The manufacturer performs the assessment and issues the EU declaration of conformity. No third party is involved.
Modules B + C: Assessment by a notified body
A notified body reviews design/development with periodic testing; the manufacturer then declares conformity.
Module H: Quality management system
A notified body evaluates the quality management system with periodic audits; the manufacturer declares conformity.
Assessment diagram (visual reference)
The header graphic summarizes the main assessment routes by product type.
Implementation timeline
Application is phased between June 2026 and December 2027, with ramp-up of assessment, notification, and enforcement.
Key milestones (operational markers)
- June 2026 – December 2026: accreditation and start of notification of conformity assessment bodies.
- September 2026: reporting of actively exploited vulnerabilities and severe incidents (via ENISA to the coordinating CSIRT).
- December 2027: products placed on the market must be compliant; market surveillance controls.
National authorities & reporting chain
National implementation details vary by Member State. This section reflects a France-centric view (ANSSI/ANFR) and is included as an operational illustration.
Notifying authority (illustrative)
Evaluates, oversees, and notifies conformity assessment bodies (typically based on accreditation schemes).
Market surveillance support (illustrative)
Technical support for market surveillance and controls (via accredited labs and designated authorities).
Coordinating CSIRT (illustrative)
Receives reports of actively exploited vulnerabilities and severe incidents and coordinates remediation with manufacturers.
Market surveillance and sanctions
The CRA introduces market surveillance mechanisms and corrective measures up to withdrawal from the market, plus financial penalties.
Non-compliance risk
The framework includes corrective actions (up to market withdrawal) and fines that may reach €10M or 2% of total worldwide annual turnover, depending on the case.
Advanced summary — A structured reading
The CRA goes beyond a “minimum security level”. It requires demonstrable and maintained security: documentation, vulnerability handling, traceability, incident response capability, and assessment procedures proportionate to criticality. Non-compliance becomes a commercial and operational risk—not only a technical one.
CryptPeer positioning against the CRA
CryptPeer (self-hosted P2P messaging and calls with end-to-end encryption) is built around “security by design” and operational control through controlled deployments. For the CRA, two key questions shape the path: classification and assessment route.
Classification: caution and method
CRA classification depends on the main intended functionality and use cases. A secure communications solution may, depending on context, fall in the default category or be considered “important” (Class I) if it matches a listed typology. CryptPeer should not self-declare a class without a formal mapping to the regulation and its annexes.
A “responsible” stance
CryptPeer’s CRA positioning rests on principles (E2EE, reduced attack surface, controlled deployments, patch procedures), but final regulatory qualification should follow a formal reading of annexes and target use cases (B2B, sensitive organizations, offline environments, etc.).
CRA classification example: the CryptPeer case
To illustrate the CRA classification method, consider CryptPeer®, a self-hosted peer-to-peer encrypted communications solution.
1. Main intended functionality
CryptPeer’s main functionality is secure communication (end-to-end encrypted messaging and calls), based on a self-hosted and federated architecture.
CryptPeer is not designed as a network security component (firewall, IDS/IPS), an identity management infrastructure, or a dedicated hardware security device.
2. Check against CRA annexes
- Annex III (important products): CryptPeer does not explicitly match the listed typologies (operating systems, browsers, routers, identity managers, firewalls, hypervisors, microcontrollers, etc.).
- Annex IV (critical products): CryptPeer is not an HSM, not a smart card, not a smart metering gateway, and not a certified hardware device.
3. A prudent classification hypothesis
Based on currently published annexes—and subject to formal assessment by competent authorities—CryptPeer would likely fall under the standard category, since no explicit link to an “important” or “critical” product typology is established.
This remains conditional on:
- evolution of the product’s functional perimeter,
- its declared market positioning,
- and the interpretation adopted by surveillance authorities.
4. Implication for conformity assessment
Under this hypothesis—and subject to confirmation of classification and the availability of relevant harmonized standards or common specifications—CryptPeer could fall under Module A (self-assessment and EU declaration of conformity), which implies:
- implementing cybersecurity requirements from the design stage,
- documented vulnerability handling,
- and continuous lifecycle monitoring and maintenance.
If classification evolves toward an annex-listed product, then an assessment involving a notified body would become mandatory.
5. Comparison table: Standard vs Important
Factors that can trigger reclassification
Several factors can lead to reclassification from the standard category to an important or critical category:
- Functional expansion: adding features matching a listed typology (e.g., identity management component)
- Market positioning: marketing/commercial claims presenting the product as a critical infrastructure component
- Target use: deployment in critical environments (sensitive public sector, critical infrastructure, etc.)
- Authority interpretation: a decision based on analysis of the main intended functionality
- Regulatory evolution: annex updates adding new typologies
Suggested wording for Terms / commercial documentation
"CryptPeer is developed in alignment with the requirements of Regulation (EU) 2024/2847 (Cyber Resilience Act), in preparation for CRA compliance. Based on analysis of its main intended functionality and the CRA annexes, CryptPeer would likely fall under the standard category, which could allow self-assessment and an EU declaration of conformity (Module A), subject to confirmation of classification by competent authorities and the availability of relevant harmonized standards or common specifications. This classification remains conditional on the evolution of the product’s functional perimeter, its market positioning, and the interpretation adopted by competent market surveillance authorities."
Technical alignment: what CryptPeer can demonstrate
Security by design
End-to-end encryption, reduced server-side exposure, and self-hosted deployment options to avoid centralization.
Vulnerability handling
Patch process and update cycles. CRA compliance can also imply notification and coordination obligations depending on the case.
Lifecycle maintenance
Maintainability, technical documentation, ability to publish patches and provide mitigation guidance across deployed environments.
Compliance path: plausible scenarios
Depending on final classification and the availability of harmonized standards or common specifications, CryptPeer could fall under:
- Module A if conditions and relevant harmonized references are met.
- Module B+C or Module H if a third party is required, especially if classification mandates it.
- Certification schemes (where applicable) to improve demonstrability and market trust.
Chronicle — What the CRA changes in practice (deep dive)
The CRA introduces a shift: cybersecurity is no longer “best effort”, but a property assessed, documented, and maintained over time. Three areas dominate: (1) essential requirements, (2) vulnerability handling obligations, (3) compliance mechanisms and surveillance.
Evidence-driven compliance
In practice, a product must produce artifacts: specifications, architecture, update security, patch procedures, and support information. CE marking becomes a signal of organizational maturity, not just a label.
Vulnerability handling as an ongoing process
The CRA requires structured handling: intake, analysis, remediation, controlled disclosure, and—depending on the case—notification. For a solution like CryptPeer, that implies orchestrating fixes without weakening the security model (E2EE, self-hosting, etc.).
Market surveillance as a durable constraint
Controls and corrective powers turn compliance into a continuous requirement. That makes “security debt” expensive—especially for products distributed at scale.
Perspective: compliance trajectory and product strategy
The CRA favors solutions that can prove maintained security—not only claimed security. For CryptPeer, competitive advantage comes from demonstrability (process, documentation, release cycles), reduced server exposure, and resilience in constrained environments.
CRA checklist — Audit-ready
This checklist summarizes useful documentation and process elements to prepare for and demonstrate CRA compliance, regardless of product category.
Essential cybersecurity requirements
- ☐ Security specifications: documented security properties (confidentiality, integrity, authentication, availability)
- ☐ Secure architecture: diagrams, design rationale, threat modeling outputs
- ☐ Cryptography: algorithms used, key management, alignment with recognized standards
- ☐ Attack surface reduction: minimization of exposed data, least privilege
- ☐ Authentication & access control: identification mechanisms, identity management
Vulnerability handling
- ☐ Intake process: documented procedure to receive and handle vulnerability reports
- ☐ Triage & prioritization: severity criteria (e.g., CVSS, business impact)
- ☐ Remediation: patch development lifecycle, regression testing
- ☐ Coordinated disclosure: policy for coordinated vulnerability disclosure
- ☐ Notification: process for reporting actively exploited vulnerabilities and severe incidents (via ENISA to coordinating CSIRT)
- ☐ Traceability: vulnerability register with discovery/fix/publication dates
Secure lifecycle
- ☐ Ongoing support: maintenance commitments, announced support duration
- ☐ Security updates: cadence, distribution channels, deployment procedures
- ☐ Technical documentation: installation guides, secure configuration, best practices
- ☐ End-of-life: EoL policy, migration/archiving procedures
- ☐ User enablement: documentation, webinars, technical support
Conformity assessment & declaration
- ☐ Product classification: main functionality analysis, mapping against CRA annexes
- ☐ Assessment module: determine applicable module (A, B+C, H) based on category and harmonized references
- ☐ Self-assessment (Module A): internal documentation, tests, EU declaration of conformity
- ☐ Notified-body assessment (B+C, H): evaluation reports, certificates
- ☐ CE marking: marking procedure, technical documentation (technical file)
- ☐ EU declaration of conformity: signed document, product info, normative references
Documentation & traceability
- ☐ Technical file: specs, architecture, tests, assessments
- ☐ Change log: version history, release notes
- ☐ Compliance evidence: certificates, test reports, declarations
- ☐ Risk management: risk analysis, mitigations, continuity plan
- ☐ Standards alignment: references to harmonized standards, common specs, relevant schemes
Note on using this checklist
This checklist is indicative and must be adapted to the product category, the applicable assessment module, and relevant harmonized references. A formal review by a notified body or legal expert may be required to validate full CRA compliance.