CRA compliance checklist
A practical checklist mapping each Cyber Resilience Act obligation to what your team actually needs to do, shipped product first.
Confirm the CRA applies
Is it a product with digital elements placed on the EU market? Determine its category, default (self-assessment), important, or critical.
Classify the conformity route
Most products self-assess; important and critical products may need a notified body. Identify your route early. alloy-it is not a notified body.
Engineer secure-by-design & by-default
Ship a secure default configuration and address the CRA essential cybersecurity requirements from the design stage.
Stand up a product inventory
Create products and releases for what you placed on the market. Upload a machine-readable SPDX/CycloneDX SBOM per software version.
Verify the binary when you can
Optionally derive an inventory from the firmware image and compare to the vendor SBOM. Trust but verify. HEX/encrypted images may need the vendor document only.
Triage findings
Decide affected / not affected / false positive with justification. Scan without triage is unusable under CRA.
Prepare Article 14 reporting
Overlay actively exploited (KEV/EUVD). Stamp first awareness. Prepare the 24h / 72h / 14-day packet for ENISA / CSIRT. Do not confuse this with emailing customers.
Commit to security updates
Provide updates for the support period (minimum five years) over a signed, integrity-protected channel. Link releases to blueprints so you can still rebuild years later.
Assemble technical documentation & evidence
Keep SBOMs, triage decisions, awareness timestamps, and conformity evidence ready for market-surveillance authorities.
Complete conformity assessment & CE marking
Run the assessment for your category and affix the CE mark before placing the product on the market. alloy-it is not CE-marking software.
Optional later: build-environment SBOM
Toolchain and build-time dependency SBOMs add depth for technical docs. Useful, but not what September 2026 reporting asks for.
Take the checklist with you
A one-page version laid out for printing or saving as PDF, with room to mark each item as done, owned, or not started. Useful for walking an engineering team or a steering group through where you stand.
Where alloy-it covers the checklist
alloy-it supports product inventory, SBOM monitoring, firmware compare, triage, Article 14 awareness and SRP export, evidence packs, and the rebuild path. Scope classification, secure-by-design engineering, conformity assessment, and CE marking sit with your product and compliance teams, and qualified counsel.
CRA compliance hub
CRA overview for embedded & firmware
What the Cyber Resilience Act requires, the deadlines, and how manufacturers of products with digital elements comply.
CRA SBOM requirements
Format, scope, and per-version rules for a CRA-compliant product Software Bill of Materials.
CRA for embedded & firmware
Why firmware needs vendor SBOM plus binary-derived inventory, and how HEX/encrypted images differ.
Vulnerability handling & Article 14
24h / 72h / 14-day reporting, KEV/EUVD, awareness clock, and what Sep 2026 actually requires.
Build-environment SBOM
Toolchain and build-time dependencies for technical docs: useful depth, but not what Sep 2026 reporting requires.
This page provides general information about the EU Cyber Resilience Act and is not legal advice. The regulation and its harmonised standards are still evolving: consult the official EU, ENISA, and BSI sources and qualified counsel for your specific product. alloy-it helps with product inventory, SBOM monitoring, triage, Article 14 evidence, and the rebuild path; it is not CE-marking software, not a notified body, and does not submit reports to ENISA or national CSIRTs.
Tick off inventory, triage, and Article 14 readiness
Start free with a product and your last N SBOMs, or book a CRA walkthrough.