Cyber Resilience Act
Design CRA compliance into how products are built and supported, from risk assessment and SBOM to vulnerability handling and reporting.
Typical requirementsCRA (EU) 2024/2847CRA Annex I essential requirementsISO/IEC 27001IEC 62443-4-1
Who it is forManufacturers, importers and distributors of products with digital elements placed on the EU market, including software vendors.
The Cyber Resilience Act sets cybersecurity requirements for products with digital elements throughout their life: secure design and development, a risk assessment, an SBOM, vulnerability handling and security updates for the support period, and conformity assessment before the product carries the CE marking. Reporting of actively exploited vulnerabilities and severe incidents applies from September 2026; the remaining obligations follow in December 2027.
Like NIS2, the CRA is easier to meet as a system than as a project. In WINGMAN, products and their components are assets, the essential requirements are mapped to development controls, and vulnerabilities, incidents and documentation are linked to the product they concern.
Registers WINGMAN keeps
Each register is a set of linked records in one model, not a separate spreadsheet. Pick an entity to see it in the data model.
Product and component register
Products with digital elements, versions, support periods, CRA class and the components each version contains.
Component suppliers
Open-source projects and commercial suppliers of components, with their due diligence and support status.
Product risk assessments
Cybersecurity risks per product, kept current through the support period.
Vulnerability register
Vulnerabilities per product and component, with severity, fix, security update and disclosure.
Reportable events
Actively exploited vulnerabilities and severe incidents with deadlines, notices and follow-up.
Essential requirements
Annex I requirements on product security and vulnerability handling, mapped to development controls.
Technical documentation
Risk assessment, SBOM, design and test records, user information and the declaration of conformity per product.
The governance cycle on the model
Step through how the regulation runs on WINGMAN records, from scope to proof.
Screens for this stage · Stage 4: Vulnerability handling
Use cases from this angle
The same use cases, with what changes for this regulation.
Risk
Vulnerability impact
Advisories are matched against product components, so the affected products and versions are known within hours.
Operations
Incident handling
Actively exploited vulnerabilities and severe incidents follow the reporting deadlines, with notices kept on the record.
Operations
Change management
Each release is assessed for security impact, and the record becomes part of the technical documentation.
Operations
Supplier evaluation
Due diligence on third-party and open-source components before they enter the product.
Compliance
New requirements
Harmonised standards and guidance under the CRA are mapped onto controls already in place.
Risk
Risk identification
Product teams identify risks for each product, which the CRA requires to be documented and updated.
Assurance
Auditing
Internal checks against the essential requirements before conformity assessment.
Questions it answers
Which of our products and versions contain this vulnerable component?
From the advisory to the vulnerability, to the components and the products and versions that carry them.
Is this vulnerability reportable, and by when?
The vulnerability record shows whether it is actively exploited, the deadlines that apply and what has been sent.
Which essential requirements does this product not yet meet?
From the product to the Annex I requirements, to the controls that meet them and their evidence. What has no control is the work plan.
Which products are still in their support period?
Each product record carries its support period, so security update duties are visible per version.
Other sectors and regulations
NIS2 and national cybersecurity law
Run the information security office of an essential or important entity from one registry of suppliers, assets, risks, incidents, vulnerabilities, threats and tasks.
Financial sector – DORA, MiCA and supervisory expectations
Run operational, financial, reputational and other non-financial risk management on one model, and catch the events that should move it.
ISO 27001 and SOC 2 Type 2
Keep the whole ISMS in one model, with control ownership, recurring reviews, management review and evidence that holds up over an audit period.
AI governance – ISO 42001, EN 18286 and the EU AI Act
Treat each AI use case as an asset with its own risks, controls and work plan, and show conformity with the EU AI Act from the same records.
GDPR and data protection
Keep the record of processing, DPIAs, processors, data subject requests and breaches as linked records, so accountability can be shown at any time.