From CRA gap analysis to conformity assessment — your partner for secure and CE-compliant products.
We support manufacturers, importers, and distributors with CRA compliance across the entire product lifecycle: Security by Design, Security by Default, vulnerability management, incident reporting processes, and robust evidence management.
Note: The CRA requires security measures across the entire product lifecycle — not just at initial release.
Status: Recording (already aired) · runtime ~1:28h
This session walks the path from security requirements and threat modeling all the way to actionable DevSecOps controls in the pipeline.
With concrete examples for SAST, SCA, SBOM, quality gates, IaC checks and continuous vulnerability management.
Watch the webinar on YouTubeThe CRA bundles product obligations, vulnerability handling, supply chain transparency and information duties towards users into four core pillars.
Product Requirements
Vulnerability Handling
(Third-party) Components & Supply Chain
Manufacturer Minimum Information
Companies that start early benefit from better risk transparency, more stable development processes and faster market access. Late implementation creates significant project and evidence pressure.
Securing market access
Steering governance risk
Efficiency through integration
Non-compliant products risk distribution restrictions. Robust evidence protects your product roadmap.
Clear processes for reporting, updates and remediation significantly reduce regulatory and operational risk.
Linking ISMS, CSMS and development processes creates synergies instead of additional bureaucracy.
Concrete building blocks if you want to operationalize that advantage:
Systematic capture of digital products, components and dependencies.
Continuous identification, assessment and remediation with clear response times.
Structured capture of measures, risk assessments and compliance evidence.
Development and security teams know Secure-by-Design; security culture is anchored.
These milestones define when companies must fully and demonstrably meet their technical, organizational and regulatory obligations for CRA-compliant products.
Click a milestone for details.
CRA reporting is not a mere extension of internal incident management — it is a regulatory deadline architecture. Manufacturers carry the burden of proof and assessment for when a reporting trigger occurs.
Core message:Manufacturers carry the burden of proof and assessment for when a reporting trigger occurs and when the deadline starts — from the moment of awareness (sufficient certainty about the incident).
Confirmed active exploitation of a security gap in a product with digital elements.
Security impairment of the product — impact on confidentiality, integrity or availability.
First report after the reporting obligation kicks in — without delay after awareness.
In-depth interim notification with facts, assessment and countermeasures.
Closing report. Subsequent deadlines depend on the trigger (vulnerability / incident).
Exploited gaps, product-relevant incidents and risk-relevant vulnerabilities according to the legal definition.
Without delay — the first reporting deadline in practice is often within 24 hours of awareness.
National authority, ENISA, possibly the CSIRT ecosystem in critical situations.
Facts, products/versions, risk assessment, countermeasures already initiated.
Requirements scale with criticality and risk profile. The correct classification of your products is the first decisive step.
| Category | Product examples | Requirements | Assessment path |
|---|---|---|---|
| ● Standard | Smartphones, control software, robot vacuums, connected devices | Annex I requirements, basic risk assessment, update & support concept | Self-declaration with technical documentation |
| ● Important I | IAM/PAM, browsers, password managers, VPN, routers, smart-home | Security by Design/Default, end-to-end VM, documented SSDLC processes | Extended evidence and normative orientation |
| ● Important II | Firewalls, IDS/IPS, hypervisors, container runtimes, security chips | Stricter technical and organizational controls, robust audit trail | Formalized assessment procedure, often involving notified bodies |
| ● Critical | Smart-meter gateways, cryptographic security hardware | Highest security requirements, comprehensive testing and compliance evidence | Mandatory assessment by notified bodies (CABs) |
Systematic capture of digital products, components, and dependencies. Foundation for all subsequent CRA measures.
Continuous identification, assessment, and remediation of vulnerabilities with clear response times per CRA requirements.
Structured capture of measures, risk assessments, and compliance evidence – audit-ready and CE-compliant.
CRA reporting is a regulatory timeline architecture. Manufacturers bear the burden of proof and assessment when a reporting trigger occurs and when the deadline starts.
Efficiency through integration: Linking ISMS, CSMS, and development processes creates synergies instead of additional bureaucracy.
Development and security teams understand Secure-by-Design. Security culture is embedded – for developers, product managers, and executives.
In collaboration with JUN Legal, we developed the CRA Navigator — a tool for a well-founded initial orientation on the requirements of the EU Cyber Resilience Act.
A systematic path from initial analysis to permanent compliance assurance.
Systematic capture of digital products, components, and dependencies.
Continuous identification, assessment, and remediation with clear response times.
Structured capture of measures, risk assessments, and compliance evidence.
Development and security teams understand Secure-by-Design; security culture is embedded.
Creation of technical documentation, conformity assessment execution, and CE marking per product category.
Pick your role to see the specific requirements and recommended priorities.
Start with product inventory, risk rating and an SBOM foundation. Then SSDLC hardening, incident reporting paths and formalized release processes.
Get advice nowYour conformity strategy depends directly on your risk class and the required assessment path.
From gap analysis to certification support — we accompany you in every phase.
Inventory, gap assessment and a prioritized roadmap for an audit-ready CRA implementation.
Continuous identification, prioritization and remediation of security gaps across the product lifecycle.
Integration of the CSMS into existing governance structures for sustainable compliance and less administrative overhead.
Security by Design across architecture, development, test and operations with clear security gates. A loop with continuous maintenance and improvement.
Preparation of evidence packages for CRA, IEC 62443 and SAE 21434 — including internal audit simulation and management review.
A Software Bill of Materials (SBOM) lists components and dependencies like an ingredient list. For the CRA it is a central transparency building block: SPDX and CycloneDX cover most common requirements.
Software Package Data Exchange — comprehensive, format-flexible and industry-wide established.
Security-focused SBOM format with strong CI/CD integration for vulnerability pipelines.
Detect, assess and prioritize risks in packages, dependencies and licenses — including mapping to known CVEs.
Compliance seamlessly in the pipeline: integration with GitHub, GitLab, Jenkins and others, so SBOMs travel with builds.
Reflect complex product trees (e.g. device → subsystems → firmware/components) for scalable visibility.
How ENISA structures the binding security principles of the Cyber Resilience Act into two clear pillars. Four categories, 22 concrete requirements.
Each of the 22 playbooks contains: objective · checklist · minimum evidence · release gate — structured for small teams without dedicated security specialists. TLP-CLEAR, freely available at
enisa.europa.euProtective mechanisms are embedded during development — not added afterwards. Two categories:
Products ship with the most secure configuration possible — users need no technical expertise for baseline security. Two categories:
For each lifecycle phase the playbook defines concrete measures and a minimal piece of evidence — so security stays demonstrably anchored even in small teams.
| Phase | Core actions | Evidence |
|---|---|---|
| Requirements | Define product context (users, environments, data), non-negotiable security defaults, top risks and misuse scenarios | Security Context & Assumptions (1 page) + security requirements checklist |
| Design | Architecture diagram with trust boundaries, lightweight threat model for the top 5–10 misuse cases, define critical design controls | Architecture + trust-boundary diagram + top threats & countermeasures |
| Development | Secure defaults in code/configuration, dependency hygiene, secrets protection, automated SAST/SCA in CI/CD, PR reviews for security-critical changes | CI pipeline evidence (logs) + secure-coding/PR checklist |
| Test | Automated SAST/DAST, validate default configuration, targeted penetration test on substantial changes | Release security checklist (pass/fail + exceptions) |
| Deployment | Secure provisioning, least-privilege runtime configuration, security health monitoring, updates as controlled change management | Deployment hardening checklist + rollback plan |
| Maintenance | Patch SLAs, vulnerability monitoring, incident handling, EOL plan, secure data deletion and credential revocation | Vulnerability and patch process (1 page) + EOL note + updated risk register |
The ENISA playbook describes what to implement — VamiSec accompanies you on the how: structured, efficient, and with provable artifacts for audits, CE conformity and authorities.
European standardization is decisive for CRA implementation and evidence management.
Cross-sector standards and base requirements for products and services in the digital single market.
Technical safety requirements for electronic components, devices and industrial environments.
Network and communications standards for digital infrastructure, interfaces and security protocols.
CRA product obligations (Annex I, supply chain, reporting paths) map directly onto IEC 62443 / SAE 21434 structures — ideal for integrated audits with less duplication.
The CSMS steers the product lifecycle and connects the CRA with ISMS, data protection and other regulations. A build-out per IEC 62443-2-1 and SAE 21434 chapter 5 prepares conformity evidence.
Security Champions are not a replacement security department — they are advocates and the team’s first point of contact, with clear hooks into NIS2, CRA and (for medical devices) the MDR.
In the team: Security in sprints, code and design reviews, training and awareness.
In the organization: Translating requirements, feedback and reporting, escalating risks, nurturing the champions community.
Companies that don’t treat CRA, NIS2 and the AI Act in isolation but transfer them into an integrated management system gain more efficiency, better audit-readiness and stronger resilience.
Compact, customizable trainings on CRA requirements, roles, Secure-by-Design, SBOM, threat modeling, supply chain and liability — with practical templates for direct use.
Schedule a training sessionA harmonized approach from product design to operations reduces duplicated effort, improves audit efficiency and creates consistent evidence across multiple regulations.
Day curriculum: SSDLC, Compliance & Threat Modeling for manufacturers, importers and distributors.
Ready-to-use templates — yours at the end of the day.
Clear classification of your products under CRA scope.
Risk-based ordering for portfolio implementation.
Concrete plan for development & product management.
Optional for teams with MDR/SaMD context: structured threat analysis with regulatory framing (MDR Annex I / GSPR, ISO 14971, IEC 62304, IEC 81001-5-1, CRA Secure-by-Design).
Threat Modeling connects Safety, Security and Compliance: traceable architecture, trust boundaries and evidence for audits and notified bodies.
Architecture, interfaces (cloud, app, clinical IT), data flows, important assets.
Confidentiality, integrity, availability; mapping to patient safety.
Including STRIDE, misuse scenarios, supply chain.
Likelihood and impact; linkage to ISO 14971.
Secure boot, authentication, encryption, logging, secure updates.
Traceability, risk file, technical documentation, audit evidence.
62 controls, 8 categories, 3 maturity levels — automatically mapped to CRA Annex I, NIS2, ISO/IEC 18974, SSDF and SLSA. One framework, one language, one verifiable posture.
The OpenSSF OSPS Baseline is a collection of concrete security requirements that an open-source project should meet to demonstrate a strong security posture. Instead of vague best practices: 62 verifiable MUST statements — organised by category and maturity level, mapped to the relevant external frameworks.
Every control is phrased as a MUST, with requirement, recommendation and a concrete maturity assignment. From mandatory MFA on sensitive repo actions to signed release-manifest obligations — everything verifiable, anchored in code review, CI/CD or documentation.
CRA, NIS2 and the SSDF talk about software supply chain — but not in the language of maintainers. The OSPS Baseline translates: what does "signed releases" actually mean in the repo? What is a "CVD policy with timeframe"? Which maturity level is appropriate for my project?
The Baseline organises its controls into eight domains that span the lifecycle of an open-source project. Each domain addresses a concrete class of threats — and each works across all three maturity levels.
MFA, least privilege, branch protection.
Pipelines, signatures, secrets, SBOM.
User guides, verification, support.
Roles, contributions, reviewer vetting.
OSI licences, DCO/CLA, IP clarity.
Status checks, tests, sub-projects.
Design docs, threat modeling, APIs.
CVD, VEX, SCA, SAST policies.
The Baseline defines three maturity levels. Each level builds on the previous and reflects how much responsibility a project carries towards its consumers. Whoever meets L3 automatically meets L1 and L2.
"The maturity level isn't a grade — it's the answer to the question of how much responsibility a project carries towards its consumers."
OSPS Baseline · Maintainer Guidance
The OpenSSF Baseline is explicitly mapped to global frameworks — you document once, deliver many times.
Insider tip: If your supplier meets L2, you already have most of the CRA supplier evidence in your pocket.
The Baseline is a yardstick, not a tool. VamiGRC makes it measurable: every control is stored as an OSCAL profile, evidence anchors are set, gap findings are tracked in the risk register — and cross-framework coverage is computed automatically.
VamiAudit checks repository, CI/CD configuration, documentation and release pipeline against the baseline. Findings land in the risk register with owner and SLA — no Excel.
Every solved baseline requirement simultaneously satisfies CRA, NIS2, SSDF and ISO clauses. The coverage matrix shows it audit-ready — implement once, satisfy many.
Branch protection, signed releases, SBOM, SAST status — everything is pulled continuously from repo and pipeline, classified and made visible on the trust-center page.
Ein Ansprechpartner. Zwei Expertisen. Von der technischen Produktprüfung bis zum Cyber Security Management System — alles aus einer Hand.
Begleitet Sie persönlich durch Ihre CRA-Compliance — technisch wie organisatorisch.
Technische Prüfung Ihrer Produkte entlang des gesamten Entwicklungszyklus — vom Design bis zur Konformitätsbewertung nach CRA.
Aufbau tragfähiger Security-Strukturen im Unternehmen — vom Managementsystem bis zu den Meldepflichten gemäß CRA.
From CRA gap analysis to conformity assessment – your partner for secure and CE-compliant products. Book CRA experts now.
Book Consultation
