Lion Cipher Lab
Assess conformity under the EU Cyber Resilience Act (CRA)
- GRC / Compliance
- Advanced
- ~90 min
- Free · no account required
Why it matters
Almost every connected product sold into the EU -- a password manager, a smart camera, a firewall, an app, a microcontroller -- is about to need a cybersecurity conformity story, and the Cyber Resilience Act is the law that demands it. The CRA makes cybersecurity a condition of placing a 'product with digital elements' on the EU market: the manufacturer must build the product to the Annex I essential requirements, ship it with no known exploitable vulnerabilities and a secure-by-default configuration, keep handling vulnerabilities and pushing free security updates across a defined SUPPORT…
What you'll learn
- confirming CRA scope precisely: whether a thing is a 'product with digital elements' (PDE) placed on the EU market, and applying the carve-outs (separately-regulated sectors, national security/defence, and the free-and-open-source / non-commercial exclusion with its 'open-source software steward' regime)
- classifying a PDE across the four tiers -- default, 'important' Annex III Class I, 'important' Annex III Class II, and 'critical' Annex IV -- and knowing exactly what the tier changes about the conformity-assessment route
- mapping a product against the Annex I Part I essential cybersecurity requirements (secure by default, no known exploitable vulnerabilities at ship, attack-surface minimisation, confidentiality/integrity/availability, data minimisation, logging, secure updates) as an honest gap table
- mapping the Annex I Part II vulnerability-handling requirements: drawing up a software bill of materials (SBOM), running a coordinated vulnerability disclosure (CVD) policy, and setting a support period during which free security updates are provided
- choosing the conformity-assessment route -- internal control / self-assessment (Module A) vs a notified body via EU-type examination (Module B+C) or full quality assurance (Module H) -- and knowing WHEN a harmonised standard makes self-assessment available and when a notified body is unavoidable
- operationalising the Article 14 reporting duties: notifying ENISA and the coordinating CSIRT simultaneously via the Single Reporting Platform, on the 24-hour / 72-hour clock, and anchoring the programme to the staged application dates (reporting from 11 September 2026; main obligations from 11 December 2027)
- drawing up the Annex VII technical documentation, the Annex V EU declaration of conformity, and affixing CE marking (Article 30) so conformity is provable, not asserted
- not conflating the CRA (product safety, CE mark, manufacturer) with NIS2 (organisational risk-management, essential/important entities) or the AI Act (AI systems, providers) when a product is caught by more than one
Steps in this lab
- What the CRA is, who it binds, and where this lab starts
- Set up the conformity dossier and adopt a worked product
- Confirm scope first -- is it even a PDE, and do any carve-outs apply?
- Classify the product -- default vs Annex III Class I vs Class II vs Annex IV critical
- Map the Annex I Part I essential requirements as a gap table
- Map the Annex I Part II vulnerability-handling requirements -- SBOM, CVD and the support period
- The common misconception, and the better way
- Pick the conformity-assessment route (internal control vs notified body)
- Build the Article 14 reporting procedure -- ENISA, the CSIRT, and the 24h / 72h clock
- Draw up the technical documentation, the declaration of conformity, and plan the CE marking
- Do not conflate the CRA with NIS2 or the AI Act
- The judgment: the traps that sink a CRA programme
- Assemble the dossier and write the sign-off page