CRA Harmonised Standards Are Not Ready: How to Self-Assess and Comply Before EN 18031 and the CRA Standards Publish (Developer Guide 2026)

The EU Cyber Resilience Act enters application on August 11, 2026. Every manufacturer of a product with digital elements sold in the EU market must meet the essential cybersecurity requirements in Annex I by that date — or face market surveillance action and fines of up to €15 million or 2.5% of global annual turnover.

There is, however, a well-documented problem that compliance teams and product engineers are beginning to encounter: the harmonised technical standards that would make CRA compliance clearer, and that would trigger the legal "presumption of conformity" under Article 7, will not be finalised and published in the Official Journal of the European Union before August 11, 2026. The standards are in preparation. They are close. But close is not published, and presumption of conformity requires published.

This is not a reason to pause compliance work. It is a reason to understand exactly how the standards gap works, what you can do right now against the raw CRA Annex I text, which proxy standards Notified Bodies are accepting in the interim, and what will change — specifically and practically — when the official standards eventually publish. That is what this guide covers.

What Article 7 Promises (And Requires)

Article 7 of the CRA establishes presumption of conformity: a product with digital elements that complies with a harmonised standard — or part of one — covering the requirements of Annex I is presumed to comply with those requirements, provided the standard's references have been published in the Official Journal.

This is a significant benefit. Demonstrating compliance with a published, referenced harmonised standard is procedurally simpler than self-assessing against regulatory text: the standard translates abstract requirements into testable technical criteria, Notified Bodies are familiar with it, and a declaration of standards compliance is auditor-friendly documentation. The GDPR analogy is the EU standard contractual clauses — a mechanism designed to reduce the burden of demonstrating compliance with a flexible but difficult-to-assess requirement.

Article 7 does not create an obligation to use harmonised standards. Manufacturers can always demonstrate conformity by other means — internal testing, third-party assessment, documentation of design decisions against the regulatory text — without ever referencing a harmonised standard. The standards create a legal shortcut. Without them, you take the longer route. The longer route is not invalid; it just requires more documentation and more auditor engagement.

The gap means that for the first period of CRA enforcement, most manufacturers will be on the longer route whether they intend to be or not.

The Standards Timeline

Understanding which standards are coming, from which committees, and on what timeline helps calibrate how long the gap will last.

Type A Standards: General Cyber Resilience Principles

Type A standards are horizontal — they apply across all product categories and translate the general essential requirements of CRA Annex I Part I into testable criteria. The relevant working body is CEN/CENELEC Joint Technical Committee 13 (JTC 13), Workgroup 8, which was established specifically to produce CRA harmonised standards.

The primary Type A deliverable is a new EN standard covering the cybersecurity baseline requirements: no known exploitable vulnerabilities at the time of placing on the market, secure-by-default configurations, data minimisation, encryption in transit and at rest, network traffic monitoring capability, and secure software update mechanisms. The working group has been operational since 2023, and the draft standard has passed technical review phases.

The expected timeline for the Type A standard publication in the Official Journal is Q3–Q4 2026, with August 2026 being the optimistic scenario and Q4 2026 more probable given the co-publication coordination required. This means the standard may publish very close to — or shortly after — August 11, 2026.

Type B Standards: Vulnerability Handling

Type B standards are also horizontal but cover the vulnerability handling requirements of CRA Annex I Part II rather than the product security requirements of Part I. These requirements govern how manufacturers discover, triage, disclose, patch, and notify regulators about vulnerabilities across the product lifecycle.

The vulnerability handling standard draws heavily from ISO/IEC 29147 (vulnerability disclosure) and ISO/IEC 30111 (vulnerability handling), adapting them to the CRA's specific requirements — including the mandatory 24-hour ENISA early warning and 72-hour notification timelines of Article 14, and the SBOM requirements of Article 13. CEN/CENELEC JTC 13 WG8 is producing this standard in parallel with the Type A standard.

Expected timeline: Q3–Q4 2026, same caveat as Type A.

Type C Standards: Vertical and Sector-Specific

Type C standards are product category specific. They translate the general requirements of Type A into domain-specific criteria — for industrial control systems, medical devices, automotive electronics, consumer IoT, network infrastructure equipment, and so on. These are produced by sector-specific technical committees with longer development cycles.

The most relevant Type C candidate for most software-producing companies is the extension of the ETSI EN 303 645 standard (consumer IoT) to cover CRA requirements, which is in progress but not expected until Q4 2026 to Q1 2027. IEC 62443 series extensions for industrial environments have a similar timeline.

The Gap Summary

The gap is real, but it is not permanent. For most manufacturers, the practical question is how to run a compliant conformity assessment process for the first few months of CRA enforcement before the Type A and Type B standards are available.

What Self-Assessment Against Annex I Means in Practice

When harmonised standards are not available, the CRA allows conformity assessment against the regulatory requirements themselves. For most products — those in the "default" category not requiring mandatory third-party assessment — this is a manufacturer self-assessment, which means your internal engineering and compliance team documents how each Annex I requirement is met.

CRA Annex I is divided into two parts. Part I covers the essential cybersecurity requirements for the product. Part II covers the vulnerability handling requirements for the organisation. Both must be addressed in the technical documentation.

Annex I Part I: Essential Requirements for Products

The CRA lists thirteen categories of requirement in Annex I Part I. For self-assessment purposes, each category must be addressed in your technical documentation with evidence of design decisions, testing results, or operational controls.

No known exploitable vulnerabilities. The product, when placed on the market, must not contain exploitable vulnerabilities that are known at that time. "Known" is defined with reference to public vulnerability databases — primarily the NVD and CVE system — and the manufacturer's own vulnerability intelligence. Self-assessment requires: documentation of dependency scanning results at the time of product release, evidence of SBOM generation, results of static analysis and dynamic testing, and a statement of known-issues-absent certification for the specific release version.

Secure by default. Products must be configured securely out of the box. Default passwords — where they cannot be avoided — must be changed on first use or generated uniquely per device. Default network services must be limited to what is necessary for intended functionality. Self-assessment requires: documentation of all default configurations, evidence that unnecessary services are disabled, and where applicable, implementation of first-use password change enforcement.

Protection of confidentiality and integrity. Data stored, transmitted, and processed by the product must be protected appropriately. Self-assessment requires: documentation of encryption implementation (cipher suites, key management, transport security), evidence of data minimisation controls, and access control architecture.

Software update mechanisms. Products must be capable of receiving security updates. Self-assessment requires: documentation of the update delivery mechanism, evidence that update authenticity is verified before installation, and confirmation that the update mechanism itself does not introduce security vulnerabilities.

Access control. Products must implement appropriate access controls. Self-assessment requires: documentation of authentication mechanisms, role separation implementation, and audit logging.

Resilience and availability. Products in scope must implement controls to protect availability against denial-of-service conditions appropriate to their risk class. Self-assessment requires: documentation of availability controls and, where applicable, rate limiting or input validation preventing resource exhaustion.

Privacy by design. Products must collect only data necessary for their intended purpose and implement technical controls to enforce data minimisation. Self-assessment requires: data flow documentation and evidence of implemented minimisation controls.

Minimal attack surface. The product's external interface must be designed to minimise unnecessary exposure. Self-assessment requires: network interface documentation, port and protocol inventory, and evidence that unused interfaces are disabled by default.

Auditability. Products must be capable of generating security event logs appropriate to their risk profile. Self-assessment requires: logging architecture documentation and evidence that security-relevant events are captured.

Annex I Part II: Vulnerability Handling Requirements

Part II requirements apply to the manufacturer's processes rather than the product itself. They cover the organisational capabilities required to handle vulnerabilities over the product's supported lifetime.

The core requirements are: a vulnerability disclosure policy (VDP) published on a publicly accessible platform; a coordinated vulnerability disclosure process that enables security researchers to report vulnerabilities; ENISA notification within 24 hours of discovering an actively exploited vulnerability; a remediation process with defined SLAs; and provision of security updates to users free of charge.

Self-assessment against Part II requires policy documentation (the VDP), process documentation (the internal vulnerability triage and escalation procedure), and evidence of operational capability (either real vulnerability handling records if available, or process testing results for new products).

Proxy Standards Accepted by Notified Bodies

While the CRA-specific harmonised standards are pending, Notified Bodies conducting mandatory third-party conformity assessments are accepting compliance with established proxy standards as evidence of meeting Annex I requirements — not as a source of presumption of conformity, which requires Official Journal citation, but as substantive evidence in the technical documentation that the requirements are met.

The most widely accepted proxy standards are:

EN 18031 series (radio products). The EN 18031-1, EN 18031-2, and EN 18031-3 standards were published under the Radio Equipment Directive and cover internet-connected radio equipment. They are the closest existing harmonised standard family to what the CRA Type A standard will codify, because they address the same essential security properties — access control, software integrity, secure by default — for connected devices. For connected hardware products subject to the Radio Equipment Directive, demonstrating compliance with EN 18031 is being accepted by NBs as strong evidence for CRA Annex I Part I compliance in the interim period.

ETSI EN 303 645 (consumer IoT). The ETSI consumer IoT security standard provides 13 provisions covering credential management, software update, secure communications, attack surface minimisation, and software integrity — directly mapping to CRA Annex I Part I requirements. Conformity with EN 303 645 v2.1.1 is widely accepted by NBs as proxy evidence for consumer IoT products.

IEC 62443 series (industrial and OT environments). For industrial control systems, PLCs, SCADA components, and operational technology generally, the IEC 62443 series provides detailed security level requirements that map to CRA Annex I. IEC 62443-4-1 (secure product development lifecycle) and IEC 62443-4-2 (technical security requirements for components) are the most relevant for product-level assessments.

ISO/IEC 29147 and 30111 (vulnerability handling). For Annex I Part II, the ISO/IEC vulnerability disclosure and handling standards are accepted as proxy evidence for the CRA's vulnerability handling requirements.

Demonstrating compliance with these standards does not give you the legal presumption of conformity that the CRA harmonised standards will provide. But it substantially strengthens your technical documentation and makes NB engagement more straightforward.

Python Implementation: CRA Standards Gap Compliance Assessment

The following implementation provides a framework for tracking conformity evidence against CRA Annex I requirements in the absence of harmonised standards. It documents which requirements are covered by which proxy standard or internal assessment, generates gap reports, and prepares the technical documentation structure the CRA requires.

from dataclasses import dataclass, field
from enum import Enum
from datetime import date
from typing import Optional


class EvidenceType(Enum):
    PROXY_STANDARD = "proxy_standard"
    INTERNAL_ASSESSMENT = "internal_assessment"
    THIRD_PARTY_TEST = "third_party_test"
    DESIGN_DOCUMENTATION = "design_documentation"


class RequirementStatus(Enum):
    COVERED = "covered"
    PARTIAL = "partial"
    GAP = "gap"
    NOT_APPLICABLE = "not_applicable"


@dataclass
class ConformityEvidence:
    requirement_id: str
    requirement_text: str
    evidence_type: EvidenceType
    proxy_standard: Optional[str]
    evidence_description: str
    evidence_date: date
    status: RequirementStatus
    gap_notes: str = ""


class CRAGapComplianceAssessor:
    """
    Tracks CRA Annex I conformity evidence during the harmonised standards gap period.
    Generates technical documentation aligned with CRA requirements, using proxy
    standards and internal assessments until EN 18031 CRA-specific standards publish.
    """

    ANNEX_I_PART_I_REQUIREMENTS = {
        "AI-1": "No known exploitable vulnerabilities at time of market placement",
        "AI-2": "Secure-by-default configuration",
        "AI-3": "Confidentiality and integrity protection of stored/transmitted data",
        "AI-4": "Secure software and firmware update mechanism",
        "AI-5": "Access control and authentication",
        "AI-6": "Resilience against DoS and availability attacks",
        "AI-7": "Privacy by design and data minimisation",
        "AI-8": "Minimal attack surface and interface exposure",
        "AI-9": "Security event logging and auditability",
    }

    ANNEX_I_PART_II_REQUIREMENTS = {
        "AII-1": "Published vulnerability disclosure policy (VDP)",
        "AII-2": "Coordinated vulnerability disclosure process",
        "AII-3": "ENISA 24h early warning notification capability",
        "AII-4": "72h detailed vulnerability notification capability",
        "AII-5": "Vulnerability remediation process with defined SLAs",
        "AII-6": "Free-of-charge security update provision",
        "AII-7": "SBOM generation and maintenance",
    }

    PROXY_STANDARDS = {
        "EN 18031": "EN 18031-1/-2/-3 (Radio Equipment Directive connected device security)",
        "ETSI EN 303 645": "ETSI EN 303 645 v2.1.1 (Consumer IoT security baseline)",
        "IEC 62443-4-1": "IEC 62443-4-1 (Secure product development lifecycle — OT/industrial)",
        "IEC 62443-4-2": "IEC 62443-4-2 (Technical security requirements — OT/industrial)",
        "ISO/IEC 29147": "ISO/IEC 29147 (Vulnerability disclosure)",
        "ISO/IEC 30111": "ISO/IEC 30111 (Vulnerability handling processes)",
    }

    def __init__(self, product_name: str, product_version: str, assessment_date: date):
        self.product_name = product_name
        self.product_version = product_version
        self.assessment_date = assessment_date
        self.evidence_records: list[ConformityEvidence] = []

    def add_evidence(
        self,
        requirement_id: str,
        evidence_type: EvidenceType,
        evidence_description: str,
        status: RequirementStatus,
        proxy_standard: Optional[str] = None,
        gap_notes: str = "",
    ) -> None:
        req_map = {
            **self.ANNEX_I_PART_I_REQUIREMENTS,
            **self.ANNEX_I_PART_II_REQUIREMENTS,
        }
        if requirement_id not in req_map:
            raise ValueError(f"Unknown requirement: {requirement_id}")

        self.evidence_records.append(
            ConformityEvidence(
                requirement_id=requirement_id,
                requirement_text=req_map[requirement_id],
                evidence_type=evidence_type,
                proxy_standard=proxy_standard,
                evidence_description=evidence_description,
                evidence_date=self.assessment_date,
                status=status,
                gap_notes=gap_notes,
            )
        )

    def get_coverage_summary(self) -> dict:
        all_reqs = {
            **self.ANNEX_I_PART_I_REQUIREMENTS,
            **self.ANNEX_I_PART_II_REQUIREMENTS,
        }
        covered = {r.requirement_id for r in self.evidence_records
                   if r.status == RequirementStatus.COVERED}
        partial = {r.requirement_id for r in self.evidence_records
                   if r.status == RequirementStatus.PARTIAL}
        gaps = set(all_reqs.keys()) - covered - partial - {
            r.requirement_id for r in self.evidence_records
            if r.status == RequirementStatus.NOT_APPLICABLE
        }
        return {
            "total_requirements": len(all_reqs),
            "covered": len(covered),
            "partial": len(partial),
            "gaps": sorted(gaps),
            "coverage_percent": round(len(covered) / len(all_reqs) * 100, 1),
        }

    def generate_technical_documentation_summary(self) -> str:
        summary = self.get_coverage_summary()
        lines = [
            f"CRA Annex I Conformity Assessment — Gap Period Documentation",
            f"Product: {self.product_name} v{self.product_version}",
            f"Assessment date: {self.assessment_date}",
            f"Note: Harmonised CRA standards not yet published. Assessment against",
            f"      raw CRA Annex I text and accepted proxy standards.",
            "",
            f"Coverage: {summary['covered']}/{summary['total_requirements']} "
            f"requirements ({summary['coverage_percent']}%)",
        ]

        if summary["gaps"]:
            lines.append(f"Open gaps: {', '.join(summary['gaps'])}")

        lines.append("")
        lines.append("Evidence by requirement:")
        for record in sorted(self.evidence_records, key=lambda r: r.requirement_id):
            proxy = f" [{record.proxy_standard}]" if record.proxy_standard else ""
            lines.append(
                f"  {record.requirement_id}: {record.status.value}{proxy}"
            )
            lines.append(f"    {record.evidence_description}")
            if record.gap_notes:
                lines.append(f"    Gap: {record.gap_notes}")

        return "\n".join(lines)


# Example: consumer IoT firmware product
def assess_consumer_iot_firmware(product_name: str, version: str) -> str:
    assessor = CRAGapComplianceAssessor(
        product_name=product_name,
        product_version=version,
        assessment_date=date(2026, 7, 1),
    )

    assessor.add_evidence(
        "AI-1",
        EvidenceType.THIRD_PARTY_TEST,
        "Dependency audit via Trivy + OWASP Dependency-Check. Zero high/critical CVEs. "
        "Results archived in build pipeline artifact store.",
        RequirementStatus.COVERED,
        proxy_standard="ETSI EN 303 645",
    )
    assessor.add_evidence(
        "AI-2",
        EvidenceType.DESIGN_DOCUMENTATION,
        "Default credentials disabled. First-boot password generation enforced. "
        "Unnecessary services (Telnet, FTP) absent from firmware build.",
        RequirementStatus.COVERED,
        proxy_standard="ETSI EN 303 645",
    )
    assessor.add_evidence(
        "AI-3",
        EvidenceType.INTERNAL_ASSESSMENT,
        "TLS 1.3 for all network communications. AES-256 for stored credentials. "
        "No plaintext credential storage confirmed by static analysis.",
        RequirementStatus.COVERED,
    )
    assessor.add_evidence(
        "AI-4",
        EvidenceType.INTERNAL_ASSESSMENT,
        "OTA update mechanism with ECDSA signature verification before install. "
        "Rollback to last known good on failed update.",
        RequirementStatus.COVERED,
        proxy_standard="ETSI EN 303 645",
    )
    assessor.add_evidence(
        "AII-1",
        EvidenceType.DESIGN_DOCUMENTATION,
        "VDP published at product-domain.eu/security. Includes scope, reporter "
        "contact, response timeline (90 days), and safe harbour statement.",
        RequirementStatus.COVERED,
        proxy_standard="ISO/IEC 29147",
    )
    assessor.add_evidence(
        "AII-7",
        EvidenceType.INTERNAL_ASSESSMENT,
        "SPDX 2.3 SBOM generated at build time. Includes all direct and transitive "
        "dependencies with PURL identifiers. Published alongside each firmware release.",
        RequirementStatus.COVERED,
    )

    return assessor.generate_technical_documentation_summary()

Risk Table: Standards Gap Impact by Product Category

The standards gap affects different product types differently, depending on whether mandatory third-party conformity assessment applies and which proxy standards are available.

What Changes When Harmonised Standards Are Published

When the CRA-specific harmonised standards are published in the Official Journal, three things change:

Presumption of conformity becomes available. A manufacturer who can demonstrate their product meets the published standard gains a legal presumption that the Annex I requirements covered by that standard are met. This simplifies NB engagement and reduces the documentation burden in market surveillance investigations.

Existing self-assessments remain valid. A conformity assessment completed against raw Annex I text — using the approach described in this guide — does not become invalid when standards publish. The assessment demonstrates that your product met the requirements; the standard is an alternative evidence route, not a mandatory one. You do not need to redo your assessment.

Future conformity assessments become cleaner. New products developed and assessed after standards publication can use the standards compliance route, which is procedurally simpler and creates auditor-familiar documentation. For most manufacturers, the practical benefit of harmonised standards will be felt in new product cycles rather than retrofitted to existing assessments.

Notified Body coordination becomes easier. NBs are familiar with referenced harmonised standards and can assess conformity with them more efficiently than interpreting raw regulatory text. For products requiring mandatory third-party assessment (Important and Critical categories), having published standards will accelerate conformity assessment timelines.

The Self-Assessment Checklist

Pre-Assessment Setup

• Identify all products with digital elements your company places on the EU market
• Determine whether each product falls under default, Important Class I, Important Class II, or Critical category
• Confirm whether third-party NB assessment is required for any product
• Map each product's supply chain — identify which components are sourced externally and require Annex I Part II traceability

Annex I Part I — Product Requirements

• Vulnerability scan completed for all dependencies using automated tooling (Trivy, Grype, or equivalent)
• Zero high/critical CVEs in shipped product at release date — or documented risk acceptance with mitigating controls
• SBOM generated in SPDX or CycloneDX format covering all direct and transitive dependencies
• Default credential policy documented: either no default credentials, unique per-device credentials, or enforced first-use change
• Unnecessary network services disabled by default — port and protocol inventory documented
• TLS 1.3 (or documented equivalent) in use for all external network communications
• Stored credentials and sensitive data encrypted at rest — encryption implementation documented
• Software update mechanism present and documented — includes authenticity verification
• Update mechanism cannot be disabled by end users without explicit security acknowledgement
• Access control implementation documented — roles, authentication mechanisms, session management
• Security event logging implemented and log storage architecture documented
• Data minimisation controls documented — no data collection beyond stated product purpose
• Attack surface documentation complete — all external interfaces, ports, protocols listed

Annex I Part II — Vulnerability Handling

• Vulnerability Disclosure Policy (VDP) published at a public URL
• VDP includes: scope, contact mechanism, acknowledgement timeline, response timeline, safe harbour statement
• Internal vulnerability triage process defined with severity classification and escalation paths
• ENISA 24-hour early warning notification procedure documented and tested
• 72-hour detailed notification procedure documented with template
• Security update SLAs defined: critical vulnerabilities addressed within defined timeframe
• Security updates are free of charge to all affected users — confirmed in update policy
• Coordinated disclosure process for receiving external researcher reports — not just a generic inbox

Technical Documentation

• Technical documentation covers all Annex I Part I requirements with evidence
• Technical documentation covers all Annex I Part II requirements with process documentation
• Proxy standards used in assessment identified and referenced in documentation
• Assessment date, product version, and assessor identity recorded
• Declaration of Conformity drafted covering CRA requirements
• Technical documentation retention plan in place — CRA requires 10 years from last market placement

NB Engagement (If Required)

• NB contacted if product falls under mandatory third-party assessment categories
• Proxy standards evidence package prepared for NB submission
• Assessment timeline agreed in advance of August 11, 2026 enforcement date

See Also

• CRA Art.7: Presumption of Conformity and How Harmonised Standards Create the Legal Shortcut
• CRA Art.13: Manufacturer Obligations Across the Product Lifecycle
• CRA Art.14: ENISA Vulnerability Notification — 24-Hour and 72-Hour Timelines
• CRA Art.21: Conformity Assessment Procedure for Important and Critical Products
• CRA Art.64: Administrative Fines — Three-Tier Structure and Fine Calculation