CRA Art.7: Presumption of Conformity — Harmonised Standards, EN 18031, and Proving Annex I Compliance (Developer Guide 2026)

Post #458 in the sota.io EU Cyber Compliance Series

The EU Cyber Resilience Act (Regulation (EU) 2024/2847, "CRA") entered into force on 10 December 2024. Once you understand Article 6 and Annex I — the 20 essential requirements every product must satisfy — the natural next question is: how do you prove you satisfy them?

That is exactly what Article 7 answers. It establishes the presumption of conformity mechanism: if your product implements a recognised EU harmonised standard that covers specific Annex I requirements, you are legally presumed to comply with those requirements. You don't need to independently demonstrate each technical point to a notified body.

This is not a shortcut or a loophole. It is the standard route used for CE marking across all EU product legislation — from medical devices to machinery to radio equipment. The CRA adopts the same approach. Understanding Art.7 is essential for:

• Choosing which technical standards to implement
• Reducing conformity assessment effort
• Preparing technical documentation
• Knowing when EN 18031 will be published and what it covers

What Article 7 Actually Says

Article 7 provides, in substance:

Products with digital elements which are in conformity with harmonised standards or parts thereof published in the Official Journal of the European Union shall be presumed to be in conformity with the essential cybersecurity requirements set out in Annex I covered by those standards or parts thereof.

Three conditions determine whether the presumption applies:

If all three are met, a regulator or market surveillance authority must accept that your product satisfies the covered requirements — unless they can show non-conformity with the standard itself.

What "Harmonised Standard" Means

Not every technical standard is a harmonised standard. The hierarchy is:

1. European Commission issues a standardisation request (mandate) to ESOs (CEN, CENELEC, ETSI)
2. ESO develops or maps an existing standard to the mandate
3. European Commission reviews and publishes the reference in the Official Journal of the EU
4. Publication in OJ EU creates the legal presumption of conformity

Standards published elsewhere — including ISO, IEC, NIST, or even ETSI standards not yet cited in the OJ — do not create the Art.7 presumption. They may still be used as voluntary technical guidance and can strengthen your conformity documentation, but they carry no legal presumption weight.

The EN 18031 Standard Family

The primary harmonised standard expected under the CRA is EN 18031, currently being developed by ETSI and CEN/CENELEC in response to the European Commission's standardisation mandate.

EN 18031 is a family of three parts, each targeting a different product category:

Important: As of April 2026, EN 18031-1 is cited in the Official Journal under the Radio Equipment Directive (RED) but not yet under the CRA. A separate standardisation mandate for the CRA is in progress. Monitor the Official Journal search for mandate M/585 progress.

EN 18031-1 Structure and Annex I Mapping

EN 18031-1 maps directly to many of the Annex I Part I (security-by-design) requirements. The mapping is not 1:1, but the table below provides a practical orientation:

Annex I requirements NOT fully covered by EN 18031-1:

• Req.2 (Secure Defaults Out-of-Box) — partial coverage
• Req.11 (Integrity Protection) — partially addressed but not explicitly
• Req.12 (Free Security Updates) — addressed in Part II but no timeline mandate

This means even with EN 18031-1 compliance, you will need to document independent evidence for the gaps.

Other Relevant Standards

Several other standards may be cited under the CRA mandate or can be used to supplement EN 18031 compliance evidence.

ETSI EN 303 645 (Consumer IoT)

ETSI EN 303 645 is the mature consumer IoT security standard with 13 provisions (no universal default passwords, keep software updated, securely store credentials, communicate securely, minimise exposed attack surfaces, etc.). It predates EN 18031 and informed its development.

While EN 303 645 is not yet cited under CRA in the OJ EU, it is:

• Referenced in UK PSTI (Product Security and Telecommunications Infrastructure Act)
• Substantively aligned with Annex I Part I requirements
• Used in notified body assessments as evidence of technical competence

IEC 62443 (Industrial / OT Systems)

For operational technology (OT) products — PLCs, SCADA components, industrial controllers — IEC 62443 is the dominant standards family. It is relevant for CRA Class II (important products) and may be cited under the CRA standardisation mandate for industrial systems.

Key parts for CRA:

ISO/IEC 27001 (Information Security Management)

ISO/IEC 27001 certification does not create a CRA presumption of conformity, but it significantly strengthens your conformity documentation:

• Demonstrates documented security policies and processes (Annex I Part II)
• Evidences vulnerability management procedures
• Supports notified body assessment for Class I and Class II products

When Will CRA Harmonised Standards Be Available?

This is the critical practical question. The timeline:

The gap risk: If harmonised standards are not published in the OJ before December 2027, manufacturers must demonstrate conformity without the Art.7 presumption. This means:

• More reliance on internal technical documentation
• Potentially mandatory notified body involvement for Class I/II
• Higher conformity assessment cost and time

Practical recommendation: Implement EN 18031-1 and/or ETSI EN 303 645 now. When harmonised CRA standards are published, your product will already satisfy them or require minimal gap remediation.

Article 7 vs. Common Technical Specifications (Art.7a)

The CRA also provides for common technical specifications (CTS) when harmonised standards are unavailable or inadequate. The Commission may adopt CTS as implementing acts.

The CTS route is the Commission's "backstop" if the ESO standards process stalls. Unlike harmonised standards, CTS are directly binding — compliance with a CTS is mandatory, not a presumption. Watch for CTS delegated acts if the standards process encounters delays.

Practical Conformity Path: Which Standard Should You Implement?

The decision tree for a typical software product or IoT device:

Your product category?
│
├─ Consumer IoT / internet-connected device?
│   └─ Implement EN 18031-1 (primary) + ETSI EN 303 645 (supplementary)
│       → Covers ~14/20 Annex I requirements via presumption once cited in OJ
│
├─ Industrial / OT component?
│   └─ Implement IEC 62443-4-1 (SDLC) + IEC 62443-4-2 (technical)
│       → May be cited under CRA for Class II industrial products
│
├─ Software only (SaaS / cloud service in scope)?
│   └─ EN 18031 may apply if internet-connected; ISO 27001 for documentation
│       → Monitor CRA scope clarifications on pure software
│
└─ High-criticality product (Class II)?
    └─ Notified body assessment mandatory (Art.24)
        → Harmonised standard compliance reduces assessment scope

Python CRAConformityChecker

The following tool assesses which Annex I requirements are covered by your implemented standards and flags gaps requiring independent documentation.

"""
CRA Art.7 Presumption of Conformity Checker
Maps implemented standards to Annex I requirements and identifies gaps.
Usage: python3 cra_conformity_checker.py
"""

from dataclasses import dataclass, field
from enum import Enum

class ConformityStatus(Enum):
    COVERED_BY_STANDARD = "✅ Covered by harmonised standard (Art.7 presumption)"
    SUPPLEMENTARY = "🟡 Supported by voluntary standard (no presumption)"
    MANUAL_EVIDENCE = "🔴 Manual technical documentation required"
    NOT_APPLICABLE = "⬜ Not applicable to this product"

@dataclass
class AnnexIRequirement:
    number: int
    part: str  # "I" or "II"
    title: str
    en18031_1: ConformityStatus = ConformityStatus.MANUAL_EVIDENCE
    etsi_303_645: ConformityStatus = ConformityStatus.SUPPLEMENTARY
    iec_62443_42: ConformityStatus = ConformityStatus.SUPPLEMENTARY

ANNEX_I_REQUIREMENTS = [
    AnnexIRequirement(1, "I", "No known exploitable vulnerabilities at release",
        en18031_1=ConformityStatus.COVERED_BY_STANDARD,
        etsi_303_645=ConformityStatus.SUPPLEMENTARY),
    AnnexIRequirement(2, "I", "Secure default configuration (no insecure defaults)",
        en18031_1=ConformityStatus.SUPPLEMENTARY,
        etsi_303_645=ConformityStatus.SUPPLEMENTARY),
    AnnexIRequirement(3, "I", "Access control to assets and functions",
        en18031_1=ConformityStatus.COVERED_BY_STANDARD,
        etsi_303_645=ConformityStatus.SUPPLEMENTARY),
    AnnexIRequirement(4, "I", "Secure authentication and identity management",
        en18031_1=ConformityStatus.COVERED_BY_STANDARD,
        etsi_303_645=ConformityStatus.SUPPLEMENTARY),
    AnnexIRequirement(5, "I", "Confidentiality of data in transit and at rest",
        en18031_1=ConformityStatus.COVERED_BY_STANDARD,
        etsi_303_645=ConformityStatus.SUPPLEMENTARY),
    AnnexIRequirement(6, "I", "Availability and resilience against DoS/disruption",
        en18031_1=ConformityStatus.COVERED_BY_STANDARD,
        etsi_303_645=ConformityStatus.SUPPLEMENTARY),
    AnnexIRequirement(7, "I", "Minimal attack surface — no unnecessary functions",
        en18031_1=ConformityStatus.COVERED_BY_STANDARD,
        etsi_303_645=ConformityStatus.COVERED_BY_STANDARD),
    AnnexIRequirement(8, "I", "Secure update mechanism — integrity-verified, rollback-capable",
        en18031_1=ConformityStatus.COVERED_BY_STANDARD,
        etsi_303_645=ConformityStatus.COVERED_BY_STANDARD),
    AnnexIRequirement(9, "I", "Data minimisation — only necessary data collected",
        en18031_1=ConformityStatus.SUPPLEMENTARY,
        etsi_303_645=ConformityStatus.COVERED_BY_STANDARD),
    AnnexIRequirement(10, "I", "Impact on third-party devices and networks minimised",
        en18031_1=ConformityStatus.SUPPLEMENTARY,
        etsi_303_645=ConformityStatus.MANUAL_EVIDENCE),
    AnnexIRequirement(11, "I", "Software and hardware integrity protection",
        en18031_1=ConformityStatus.SUPPLEMENTARY,
        etsi_303_645=ConformityStatus.COVERED_BY_STANDARD),
    AnnexIRequirement(12, "I", "Security event audit logging",
        en18031_1=ConformityStatus.COVERED_BY_STANDARD,
        etsi_303_645=ConformityStatus.SUPPLEMENTARY),
    # Annex I Part II — Vulnerability Handling
    AnnexIRequirement(1, "II", "Vulnerability identification — CVE monitoring and SBOM",
        en18031_1=ConformityStatus.COVERED_BY_STANDARD,
        etsi_303_645=ConformityStatus.COVERED_BY_STANDARD),
    AnnexIRequirement(2, "II", "Coordinated vulnerability disclosure (CVD) policy",
        en18031_1=ConformityStatus.COVERED_BY_STANDARD,
        etsi_303_645=ConformityStatus.COVERED_BY_STANDARD),
    AnnexIRequirement(3, "II", "Prompt remediation and free security patches",
        en18031_1=ConformityStatus.COVERED_BY_STANDARD,
        etsi_303_645=ConformityStatus.COVERED_BY_STANDARD),
    AnnexIRequirement(4, "II", "Patch release documentation and advisory",
        en18031_1=ConformityStatus.SUPPLEMENTARY,
        etsi_303_645=ConformityStatus.SUPPLEMENTARY),
    AnnexIRequirement(5, "II", "Security tests — penetration testing and regression",
        en18031_1=ConformityStatus.SUPPLEMENTARY,
        etsi_303_645=ConformityStatus.MANUAL_EVIDENCE),
    AnnexIRequirement(6, "II", "SBOM — machine-readable, minimum NTIA fields",
        en18031_1=ConformityStatus.SUPPLEMENTARY,
        etsi_303_645=ConformityStatus.MANUAL_EVIDENCE),
    AnnexIRequirement(7, "II", "Contact point for security vulnerability reporting",
        en18031_1=ConformityStatus.COVERED_BY_STANDARD,
        etsi_303_645=ConformityStatus.COVERED_BY_STANDARD),
    AnnexIRequirement(8, "II", "Secure patch distribution mechanism",
        en18031_1=ConformityStatus.COVERED_BY_STANDARD,
        etsi_303_645=ConformityStatus.COVERED_BY_STANDARD),
]

def run_conformity_check(
    implements_en18031_1: bool,
    implements_etsi_303_645: bool,
    implements_iec_62443_42: bool,
    product_type: str = "IoT Device",
):
    print(f"\n{'='*70}")
    print(f"CRA Art.7 Conformity Gap Analysis — {product_type}")
    print(f"{'='*70}")
    print(f"Standards implemented:")
    print(f"  EN 18031-1: {'Yes (pending OJ CRA citation)' if implements_en18031_1 else 'No'}")
    print(f"  ETSI EN 303 645: {'Yes (voluntary)' if implements_etsi_303_645 else 'No'}")
    print(f"  IEC 62443-4-2: {'Yes (voluntary)' if implements_iec_62443_42 else 'No'}")
    print()

    gaps = []
    covered = []
    supplemented = []

    for req in ANNEX_I_REQUIREMENTS:
        best_status = ConformityStatus.MANUAL_EVIDENCE

        if implements_en18031_1 and req.en18031_1 == ConformityStatus.COVERED_BY_STANDARD:
            best_status = ConformityStatus.COVERED_BY_STANDARD
        elif implements_etsi_303_645 and req.etsi_303_645 == ConformityStatus.COVERED_BY_STANDARD:
            best_status = ConformityStatus.SUPPLEMENTARY
        elif (implements_en18031_1 and req.en18031_1 == ConformityStatus.SUPPLEMENTARY) or \
             (implements_etsi_303_645 and req.etsi_303_645 == ConformityStatus.SUPPLEMENTARY) or \
             (implements_iec_62443_42 and req.iec_62443_42 == ConformityStatus.SUPPLEMENTARY):
            best_status = ConformityStatus.SUPPLEMENTARY

        label = f"Annex I Part {req.part} Req.{req.number}: {req.title}"
        if best_status == ConformityStatus.COVERED_BY_STANDARD:
            covered.append(label)
        elif best_status == ConformityStatus.SUPPLEMENTARY:
            supplemented.append(label)
        else:
            gaps.append(label)

    if covered:
        print(f"✅ Requirements with Art.7 presumption ({len(covered)}):")
        for r in covered:
            print(f"   {r}")

    if supplemented:
        print(f"\n🟡 Requirements with voluntary standard support ({len(supplemented)}):")
        for r in supplemented:
            print(f"   {r}")

    if gaps:
        print(f"\n🔴 Requirements requiring manual technical documentation ({len(gaps)}):")
        for r in gaps:
            print(f"   {r}")

    total = len(ANNEX_I_REQUIREMENTS)
    print(f"\n{'='*70}")
    print(f"Summary: {len(covered)}/{total} covered by presumption | "
          f"{len(supplemented)}/{total} supplemented | "
          f"{len(gaps)}/{total} manual evidence required")
    coverage_pct = round(100 * len(covered) / total)
    print(f"Art.7 presumption coverage: {coverage_pct}%")
    if gaps:
        print("\nAction: For gap requirements, create technical documentation")
        print("showing how your specific implementation satisfies each requirement.")
        print("Consider ISO/IEC 29147 (CVD) and NIST SP 800-53 as supplementary evidence.")

if __name__ == "__main__":
    # Typical consumer IoT device implementing EN 18031-1 + ETSI EN 303 645
    run_conformity_check(
        implements_en18031_1=True,
        implements_etsi_303_645=True,
        implements_iec_62443_42=False,
        product_type="Consumer IoT Device"
    )

Sample output (consumer IoT device with EN 18031-1 + ETSI EN 303 645):

======================================================================
CRA Art.7 Conformity Gap Analysis — Consumer IoT Device
======================================================================
Standards implemented:
  EN 18031-1: Yes (pending OJ CRA citation)
  ETSI EN 303 645: Yes (voluntary)
  IEC 62443-4-2: No

✅ Requirements with Art.7 presumption (9):
   Annex I Part I Req.1: No known exploitable vulnerabilities at release
   Annex I Part I Req.3: Access control to assets and functions
   Annex I Part I Req.4: Secure authentication and identity management
   Annex I Part I Req.5: Confidentiality of data in transit and at rest
   Annex I Part I Req.6: Availability and resilience against DoS/disruption
   Annex I Part I Req.7: Minimal attack surface — no unnecessary functions
   Annex I Part I Req.8: Secure update mechanism — integrity-verified, rollback-capable
   Annex I Part I Req.12: Security event audit logging
   Annex I Part II Req.1: Vulnerability identification — CVE monitoring and SBOM

🟡 Requirements with voluntary standard support (8):
   ...

🔴 Requirements requiring manual technical documentation (3):
   Annex I Part I Req.2: Secure default configuration
   Annex I Part I Req.10: Impact on third-party devices
   Annex I Part II Req.5: Security tests

======================================================================
Summary: 9/20 covered by presumption | 8/20 supplemented | 3/20 manual evidence required
Art.7 presumption coverage: 45%

Using Art.7 in Practice: Technical Documentation Strategy

Article 7 reduces but does not eliminate your documentation burden. For each Annex I requirement, your technical documentation should include one of:

Tier 1 — Art.7 Presumption (strongest):

• Reference to the specific harmonised standard clause
• Conformity test report or audit against that clause
• Declaration referencing OJ citation

Tier 2 — Voluntary Standard Evidence:

• Certificate or test report against EN 303 645 / IEC 62443
• Note that this supports but does not create presumption
• Describe how the standard's requirement maps to Annex I

Tier 3 — Independent Technical Evidence:

• Design documentation, threat model, architecture diagrams
• Penetration test report
• Code review findings and remediation evidence
• Security test results

For a typical product, most manufacturers will combine all three tiers. Pure Tier 1 coverage for all 20 requirements is unlikely until CRA harmonised standards are complete and published.

What to Do Before CRA Standards Are Published

The gap between CRA entry into force (December 2024) and publication of harmonised standards (expected 2026–2027) creates uncertainty. Practical steps for manufacturers:

1. Implement EN 18031-1 now — even without OJ citation under CRA, it is the expected standard and aligns closely with Annex I Part I. Implementation costs will not be wasted.

2. Generate SBOM immediately — SBOM is required by Annex I Part II Req.6. Tools: Syft, CycloneDX, SPDX. This is entirely independent of which standard you use.

3. Establish CVD policy — Set up security.txt, a vulnerability disclosure programme, and a remediation SLA. ETSI EN 303 645 and ISO 29147 provide frameworks.

4. Document everything — Even without a harmonised standard to cite, structured technical documentation demonstrating Annex I compliance is valid evidence and may be sufficient for conformity assessment.

5. Monitor ENISA's CRA guidance — ENISA regularly publishes technical guidelines and FAQ documents on CRA implementation. Subscribe to their newsletter.

6. Watch OJ EU — Check the Official Journal for mandate references under Article 7. Create a monitoring alert for "M/585" or "CRA standard" in EU publications.

Key Dates and Decision Points

See Also

• CRA Art.6: Essential Requirements (Annex I) — The 20 requirements Art.7 helps you prove
• CRA Art.13: Manufacturer Obligations — What manufacturers must do beyond conformity assessment
• CRA Art.16: Vulnerability Reporting to ENISA — Post-market vulnerability notification obligations
• CRA Art.2: Scope — Which products are in scope
• CRA Art.3: Definitions — Key terms including "product with digital elements"