The majority of products with digital elements covered by the CRA are eligible for self-attestation. This means the manufacturer can sign a Declaration of Conformity without involving a notified body, based on an internal assessment that the product meets the regulation's essential requirements. For SMEs in particular, this route is likely the most practical path to compliance for most of their products.
Self-attestation, however, is not a lighter version of compliance. The declaration the manufacturer signs carries the same legal weight as one issued following a third-party assessment. The evidence behind it must be sufficient to support that claim. Understanding when self-attestation is permitted, what the evidence standard requires, and how to build an internal process that produces defensible results is the practical core of CRA compliance for most manufacturers.
When Self-Attestation Is Permitted
The CRA divides products with digital elements into three tiers based on risk classification:
- Default products (the majority): Self-attestation is permitted under Module A (internal production control). The manufacturer conducts its own conformity assessment and signs the Declaration of Conformity.
- Important products (Annex III, Class I): Self-attestation is permitted if the manufacturer applies harmonised European standards that cover the relevant essential requirements. Without those standards, a notified body is required.
- Important products (Annex III, Class II) and critical products (Annex IV): Third-party assessment by a notified body is required. Self-attestation is not available for these product classes.
Annex III Class I includes products such as identity management software, browsers, password managers, VPNs, network management tools, and mobile device management software. Class II includes more sensitive categories including operating system kernels, hypervisors, firewalls, and tamper-resistant elements. Products falling into these classes should identify this early in their compliance planning, since the notified body assessment route has longer lead times and different documentation requirements.
For most manufacturers of connected hardware, firmware-embedded devices, IoT products, and industrial components, the default product tier applies and self-attestation is the appropriate route.
What “Self-Attestation” Actually Means
Self-attestation under Module A does not mean the manufacturer simply declares the product compliant. It means the manufacturer has conducted a systematic internal conformity assessment, produced the technical documentation required under Annex VII, and is prepared to produce that documentation to a market surveillance authority on request.
The Declaration of Conformity is the output of this process, not the process itself. Signing a declaration without the underlying evidence is a legal exposure, not a compliance solution.
The Evidence Expected
A self-attestation that can withstand scrutiny is supported by four interconnected categories of evidence.
Risk assessment linked to essential requirements
The cybersecurity risk assessment required under Article 13 must be structured so that each identified risk is linked to the essential requirement it is relevant to, and each essential requirement is addressed by a control that is in turn supported by evidence of implementation. A risk assessment that identifies threats but does not trace them to the Annex I requirements it addresses is incomplete for CRA purposes.
The essential requirements cover both product security properties (secure configuration, attack surface reduction, integrity protection, data confidentiality) and vulnerability handling obligations (accepting reports, disclosing vulnerabilities, providing security updates). Both categories must be assessed and evidenced.
Design and test documentation
The technical documentation must demonstrate that the product was designed to meet the essential requirements, not merely that it passes tests. Design documentation should show the security architecture choices made, including the rationale for those choices in light of the risk assessment. Test documentation should show that the product was tested against security requirements and that the results support the conformity claim.
Vulnerability handling and reporting processes
Article 13 requires manufacturers to have a documented process for receiving and handling vulnerability reports before a product is placed on the market. This process must be publicly accessible (the VDP), and the internal handling procedures must be documented and operational.
For self-attestation, the manufacturer must be able to demonstrate that this process exists and functions correctly. Documentation of the VDP policy, the intake and triage workflow, and the escalation path for Article 14 reporting all form part of the evidence set. A manufacturer without an operational VDP cannot legitimately sign a Declaration of Conformity, since one of the essential requirements it is declaring is unmet.
Software Bill of Materials
The SBOM required under Article 13 is part of the technical documentation and must be available to market surveillance authorities on request. For self-attestation purposes, the SBOM must be current at the time the declaration is signed and must be maintained throughout the product's support period.
Building a Clear, Regulator-Ready Self-Attestation Methodology
The difference between a self-attestation process that is defensible and one that is not usually comes down to structure and traceability rather than the volume of documentation produced.
A regulator-ready self-attestation methodology has the following properties:
Coverage. Every essential requirement is addressed. There are no gaps where a requirement is acknowledged but not assessed, and no requirements that are implicitly assumed to be met without evidence.
Traceability. From any essential requirement, it is possible to navigate directly to the control or design choice that addresses it, and from that control to the evidence that it is implemented. This navigation should be explicit in the documentation structure, not something a reviewer has to reconstruct.
Currency. The documentation reflects the product as it exists at the time of assessment, not an earlier version. Where the product has changed since a previous assessment, the documentation reflects what was reviewed and when.
Proportionality. The depth of documentation is calibrated to the complexity and risk of the product. Proportionality does not excuse gaps; it shapes the level of detail applied to each element.
Controlled access and version history. The documentation exists in a system where changes are logged, versions are retained, and access to modify records is controlled. This is what distinguishes documentation that was produced through a genuine process from documentation that was assembled for a compliance inspection.
The Ongoing Obligation
A Declaration of Conformity is signed at a point in time, but the compliance obligations it represents are continuous. If a vulnerability is discovered that was not addressed in the risk assessment, the assessment must be reviewed and updated. If the product is updated in a way that changes its risk profile, the documentation must be revised and, if the changes are significant, the declaration may need to be reissued.
Self-attestation is not a one-time filing. It is a statement that the product meets the requirements as of the date signed, backed by documentation that must remain accurate. Manufacturers who treat it as a completed task rather than an ongoing obligation will find themselves out of compliance the first time their product or its threat environment changes significantly.
The September 2026 deadline for vulnerability reporting obligations means that the internal processes required for self-attestation, particularly the VDP and the vulnerability handling documentation, must be established well before the December 2027 conformity deadline. Building these now, as operational infrastructure rather than documentation to be produced at the end, is the most effective path to a self-attestation process that holds up.