# The EU Cyber Resilience Act Is 87 Days Away — Here's a Free Compliance Toolkit for IoT Manufacturers

The EU Cyber Resilience Act (CRA) enforcement deadline is September 11, 2026. If you manufacture or import connected devices into the EU and haven't started your compliance engineering, the clock is loud.

Penalties for non-compliance: up to EUR 15 million or 2.5% of annual global turnover — whichever is higher.

I've been working on an open-source Python toolkit to help manufacturers meet the core technical requirements. Here's what the CRA actually demands, and how you can check your devices against it today.

What the CRA Requires (Technical Side)

The CRA isn't just paperwork. It mandates specific technical capabilities in your devices and your vulnerability management process.

1. SBOMs Accessible to ENISA (Article 13(8))

You must maintain a machine-readable Software Bill of Materials in CycloneDX or SPDX format. It needs to be updated with every release and accessible to ENISA on request.

from sbom.generator import CycloneDXGenerator

sbom = CycloneDXGenerator()
sbom.add_component(
    name="bootloader",
    version="2.1.0",
    supplier="Acme IoT Ltd",
    cpe="cpe:2.3:*:acme:bootloader:2.1.0:*:*:*:*:*:*"
)
sbom.add_component(name="linux-kernel", version="5.15.0")
sbom.add_component(name="openssl", version="3.0.7")

print(sbom.to_xml())  # Valid CycloneDX 1.5 XML

2. 24-Hour Vulnerability Disclosure (Article 14)

The most aggressive requirement: from the moment you become aware of an actively exploited vulnerability in your device or its components, you have:

• 24 hours — initial notification to ENISA
• 72 hours — status update with findings
• 14 days — final report with remediation details

This means you need automated CVE matching against your SBOM. You can't manually check NVD every morning.

from cra_kit.firmware import FirmwareHealthService

firmware = FirmwareHealthService()
result = firmware.check_component("openssl", "3.0.7")
# Returns: {"cve": "CVE-2023-...", "status": "vulnerable", "fixed_in": "3.0.8"}

3. Device Identity & Access Control (Article 10(2-3))

Devices must implement tiered access. Not every process should run with full privileges. The reference implementation uses five tiers:

from cra_kit.identity import DeviceIdentityService, TrustTier

identity = DeviceIdentityService()

# Bootloader runs at ADMINISTRATIVE
identity.set_tier(TrustTier.ADMINISTRATIVE,
    capabilities={"firmware_write", "key_rotation"})

# Runtime process at VERIFIED — can read sensors, can't write firmware
identity.set_tier(TrustTier.VERIFIED,
    capabilities={"sensor_read", "network_send"})

# Anonymous user at ANONYMOUS — can only see public status
identity.set_tier(TrustTier.ANONYMOUS,
    capabilities={"status_read"})

4. Secure-by-Default Input Handling (Article 10(1))

No open debug ports. No default passwords. All inputs classified and sanitised.

from cra_kit.input_guard import InputClassifier

classifier = InputClassifier()
result = classifier.classify(user_input)

if result.has_injection_attempt:
    log_alert("SQL injection detected", result.details)
    return reject()

5. Physical Action Guarding (Article 10(3))

Critical physical actions — actuators, locks, valves, motor controllers — must require confirmation or be hard-blocked at the software level.

from cra_kit.action_guard import PhysicalActionGuard

guard = PhysicalActionGuard()
guard.register_action("unlock_door", category="physical_access",
                       requires_confirmation=True)
guard.register_action("emergency_stop", category="safety",
                       requires_confirmation=False)

# Attempting a guarded action without confirmation
result = guard.attempt("unlock_door", confirmed=False)
# -> {"allowed": False, "reason": "requires_confirmation"}

Live Monitoring Dashboard

The free tier includes access to a live CISA KEV monitoring dashboard that:

• Polls CISA's Known Exploited Vulnerabilities catalog daily at 06:00 UTC
• Enriches alerts with NVD CVSS scores and FIRST.org EPSS exploit probability
• Generates CycloneDX 1.5 VEX statements
• Produces pre-filled ENISA Article 14 notification drafts
• Tracks your 24hr / 72hr / 14-day reporting deadlines with countdowns

Getting Started

pip install cra-compliance-kit

Everything is stdlib-only — zero external dependencies. MIT licensed. The full source (~500 lines of Python) is on GitHub.

Compliance isn't a checkbox. But the right tooling can turn the CRA from a legal threat into an engineering checklist. If you're building IoT devices for the EU market, start now — 87 days disappears faster than you think.

Disclaimer: This toolkit provides reference implementations of CRA technical requirements. It does not constitute a complete conformity assessment. Consult your notified body for certification.