Under the EU Cyber Resilience Act (CRA), products with digital elements classified as "Default / Standard"—as well as certain qualifying open-source software under Article 32—can demonstrate regulatory conformity through Conformity Assessment Module A (Internal Production Control / Manufacturer Self-Assessment).

This checklist incorporates guidance and criteria established by the Eclipse Foundation’s Open Regulatory Compliance (ORC) Working Group alongside affiliated industry initiatives (such as the OCCTET Project and the sCC4CRA / Simplified Common Criteria framework) to help software manufacturers and open-source stewards operationalize compliance across their engineering pipelines.

The Five Core Pillars of CRA Self-Assessment

Manufacturers qualifying for Module A must document internal production controls across five foundational areas before affixing the CE mark:

Pillar 1: Scope, Product Classification & Support Period

Ensure the software product is accurately categorized and its operational support boundaries are formally defined:

✓ Scope Verification: Confirm whether the software qualifies as a Product with Digital Elements (PDE) having direct or indirect logical or network data connections.
✓ Risk Tiering: Establish whether the product falls under Default/Standard (eligible for pure self-assessment), Important (Class I / Class II), or Critical.
✓ Defined Support Period: Formally document the guaranteed lifetime during which the manufacturer will provide free security updates (minimum expected lifetime).

Pillar 2: Product Security by Design & Default (Annex I, Part I)

Assess whether cybersecurity controls are built into the architecture from conception through delivery:

Requirement Area	Checklist Verification Items
No Known Exploitable Flaws	Evidence that software is shipped free of known, exploitable vulnerabilities prior to release.
Secure by Default	Default configurations are hardened; attack surfaces and unnecessary services/ports are minimized; reset mechanisms are available.
Access Control & Identity	Robust authentication, authorization, token encryption, and least-privilege access enforcement.
Data Protection	Encryption of sensitive data in transit and at rest; protection against unauthorized data modification or corruption.
Data Minimization	Verification that the software only processes and retains data strictly necessary for its intended functionality.
Resilience & Availability	Protection against denial-of-service (DoS) conditions and mitigation of negative impacts on neighboring network devices.

Pillar 3: Vulnerability Handling & Supply Chain Obligations (Annex I, Part II)

Evaluate whether the manufacturer has operationalized ongoing dependency tracking and lifecycle security:

✓ Software Bill of Materials (SBOM): Maintaining a complete, machine-readable inventory of all first- and third-party dependencies (utilizing standards like CycloneDX or SPDX).
✓ Supply Chain Due Diligence: Documented process to screen, test, and vet third-party and open-source components for inherited flaws prior to integration.
✓ Security Testing in CI/CD: Ongoing vulnerability scanning, static/dynamic analysis (SAST/DAST), code reviews, and penetration testing.
✓ Coordinated Vulnerability Disclosure (CVD): A public policy (e.g., SECURITY.md, dedicated contact point) defining how external researchers can privately report security flaws.
✓ Patch Management: Capability to rapidly develop, validate, and securely distribute security fixes and patches (kept distinct from functional/feature updates).

Pillar 4: Incident & Vulnerability Reporting Readiness (Article 14)

Verify the manufacturer’s incident response workflows against mandatory regulatory notification windows:

✓ 24-Hour Early Warning: Documented escalation procedures to notify the designated CSIRT and ENISA within 24 hours of becoming aware of an actively exploited vulnerability or severe security incident.
✓ 72-Hour Notification: Follow-up detailed report with impact analysis, incident indicators, and mitigation/workaround steps.
✓ Final Report: Concluding report delivered within 14 days after a corrective patch or mitigation is available (or 1 month for severe unresolved incidents).

Pillar 5: Technical Documentation & Conformity (Annex VII & Module A)

Compile the formal Technical File required to affix the CE mark and demonstrate audit readiness:

✓ Cybersecurity Risk Assessment: A formal threat model and risk assessment identifying potential threats across design, deployment, and maintenance.
✓ User Information & Manuals (Annex II): End-user documentation detailing secure installation, recommended security configuration, and decommission/end-of-life procedures.
✓ EU Declaration of Conformity (DoC): A signed legal declaration confirming compliance with all applicable essential requirements of the CRA.
✓ CE Marking: Affixing the CE mark to the software packaging, documentation, or digital interface in accordance with Conformity Assessment Module A.

Implementing the CI/CD Enforcer Workflow

Packablock provides continuous attestation gates to satisfy CRA Module A supply chain requirements deterministically. Drop this hardened workflow directly into your repository to enforce cryptographic dependency validation on every pull request:

.github/workflows/packablock-enforcer.yml

# Packablock Deterministic Supply Chain Enforcer
name: Packablock Deterministic Supply Chain Enforcer

on:
  pull_request:
    paths:
      - '**/package.json'
      - '**/package-lock.json'
      - '**/bun.lockb'
  push:
    branches:
      - main

permissions:
  contents: read
  id-token: write

jobs:
  enforce-guardrails:
    runs-on: ubuntu-latest
    container:
      image: ghcr.io/packablock/hardened-enforcer:v1
      options: --no-new-privileges

    steps:
      - name: Checkout Source
        uses: actions/checkout@v4

      - name: Verify Authoritative Ledger State
        run: |
          pkablk verify --server https://packablock.com

      - name: Evaluate Dependency Deltas & Append
        run: |
          pkablk append --target-file package-lock.json --out-of-band-branch packablock-log

      - name: Perform Build & Attestation Check
        run: |
          bun run build
          pkablk pack --assert-clean

Getting Started with Packablock

Operationalize your CRA compliance pipeline and eliminate software supply chain opacity today:

Install the CLI Engine: Run bun add -g @packablock/client or npm install -g packablock to initialize local attestation tracking.
Explore Regulatory Datalake Datasets: Query statutory penalty models and EU CRA benchmark crosswalks at data.packablock.com ↗.
Micro-Enterprise Exposure & Inaction Index: Model sweat equity compliance costs vs. platform delisting and customs impoundment using our CRA-05 Actuarial Model.
Automate Your Pipeline: Integrate the GitHub Actions runner above to establish deterministic CI/CD guardrails with zero developer friction.
Enterprise Consultation: Schedule an architecture review for private trust registries at Enterprise Consultation.