What Kunnus covers, requirement by requirement
Kunnus covers Annex I Part I and Part II as well as the manufacturer obligations of Art. 13 and 14 of Regulation (EU) 2024/2847, plus classification under Art. 7 and the procedure up to the EU Declaration of Conformity. This matrix lists every single requirement with its legal reference and says whether the platform runs the process itself or keeps the evidence for it.
Based on Regulation (EU) 2024/2847, as of August 2026
Which EU Cyber Resilience Act requirements does Kunnus cover?
Kunnus addresses all essential cybersecurity requirements of Annex I. The 14 product properties of Part I are assessed and evidenced per product. The 8 vulnerability-handling requirements of Part II mostly run as workflows inside the platform, such as SBOM management and vulnerability monitoring. On top of that come the manufacturer obligations of Art. 13, the Art. 14 reporting workflow with its deadlines, classification under Art. 7, and the conformity assessment procedure up to the Art. 28 EU Declaration of Conformity.
Kunnus runs the process itself, inside the platform. SBOM management or vulnerability monitoring are examples.
You implement the requirement in your product or organisation. Kunnus assesses it in a structured way and keeps the audit-ready evidence.
No software makes your product compliant by itself. That is why the matrix distinguishes clearly between what Kunnus runs and what Kunnus evidences.
Art. 13 and 14 — Manufacturer obligations and reporting obligations
Art. 13 bundles manufacturer obligations from risk assessment to technical documentation; Art. 14 governs reporting of actively exploited vulnerabilities and severe incidents on fixed deadlines.
| Legal reference | Requirement | How Kunnus supports it | Feature |
|---|---|---|---|
| Art. 13(2) and (3) | Carry out, document and keep up to date the cybersecurity risk assessment (part of the technical documentation) | Platform workflow Structured per-product risk assessment in the platform; results feed directly into assessment and documentation. | |
| Art. 13(5) | Due diligence when integrating third-party components | Platform workflow Vendor and component assessment plus SBOM transparency across all third-party components and their vulnerabilities. | |
| Art. 13(8) and (9) | Determine the support period (generally at least 5 years) and provide security updates | Platform workflow Support periods and update commitments are maintained and managed per product and variant directly in the platform. | |
| Art. 13 in conjunction with Annex VII | Draw up and keep the technical documentation up to date | Platform workflow Audit-ready reports and evidence from the platform. Kunnus covers the CRA layer; further CE-process steps under other legal acts remain with the manufacturer. | |
| Art. 14 | Reporting actively exploited vulnerabilities and severe incidents (early warning 24 h, notification 72 h, final report) | Platform workflow Reporting workflow with deadline tracking: from detection through the 24-hour early warning to the final report, fully documented. |
Annex I Part I — Properties of products with digital elements
Part I describes security properties of the product itself; they are implemented in your engineering. Kunnus turns them into an assessable catalogue: each property is evaluated per product, justified, and backed with evidence.
| Legal reference | Requirement | How Kunnus supports it | Feature |
|---|---|---|---|
| Annex I Part I No. 1 | Appropriate level of cybersecurity based on the risks (security by design) | Assessment & evidence Kunnus links this requirement to the Art. 13(2) risk assessment and documents the rationale per product. | |
| Annex I Part I No. 2(a) | Made available without known exploitable vulnerabilities | Platform workflow SBOM-based matching against vulnerability databases before and after release. Known vulnerabilities are detected and tracked to resolution. | |
| Annex I Part I No. 2(b) | Secure-by-default configuration and reset capability | Assessment & evidence Implemented in the product itself; Kunnus assesses the requirement per product and keeps the audit-ready evidence. | |
| Annex I Part I No. 2(c) | Vulnerabilities can be addressed through security updates (incl. automatic updates) | Assessment & evidence Update capability is assessed; the update process per product is documented and evidenced. | |
| Annex I Part I No. 2(d) | Protection from unauthorised access (authentication, identity and access management) | Assessment & evidence Implemented in the product itself; Kunnus assesses the requirement per product and keeps the audit-ready evidence. | |
| Annex I Part I No. 2(e) | Confidentiality of stored, transmitted and processed data (encryption) | Assessment & evidence Implemented in the product itself; Kunnus assesses the requirement per product and keeps the audit-ready evidence. | |
| Annex I Part I No. 2(f) | Integrity of data, commands, programs and configuration | Assessment & evidence Implemented in the product itself; Kunnus assesses the requirement per product and keeps the audit-ready evidence. | |
| Annex I Part I No. 2(g) | Data minimisation: processing only data necessary for the intended purpose | Assessment & evidence Implemented in the product itself; Kunnus assesses the requirement per product and keeps the audit-ready evidence. | |
| Annex I Part I No. 2(h) | Availability of essential functions, incl. after incidents (DoS resilience) | Assessment & evidence Implemented in the product itself; Kunnus assesses the requirement per product and keeps the audit-ready evidence. | |
| Annex I Part I No. 2(i) | Minimising negative impact on services provided by other devices or networks | Assessment & evidence Implemented in the product itself; Kunnus assesses the requirement per product and keeps the audit-ready evidence. | |
| Annex I Part I No. 2(j) | Limited attack surfaces, including external interfaces | Assessment & evidence Implemented in the product itself; Kunnus assesses the requirement per product and keeps the audit-ready evidence. | |
| Annex I Part I No. 2(k) | Reducing the impact of incidents (exploitation mitigation) | Assessment & evidence Implemented in the product itself; Kunnus assesses the requirement per product and keeps the audit-ready evidence. | |
| Annex I Part I No. 2(l) | Recording and monitoring of security-relevant internal activity (with opt-out) | Assessment & evidence Implemented in the product itself; Kunnus assesses the requirement per product and keeps the audit-ready evidence. | |
| Annex I Part I No. 2(m) | Secure and easy deletion and secure transfer of data and settings | Assessment & evidence Implemented in the product itself; Kunnus assesses the requirement per product and keeps the audit-ready evidence. |
Annex I Part II — Vulnerability handling requirements
Part II describes ongoing manufacturer processes across the entire support period. This is where the platform itself does the work: SBOM, vulnerability monitoring and evidence are core Kunnus workflows.
| Legal reference | Requirement | How Kunnus supports it | Feature |
|---|---|---|---|
| Annex I Part II No. 1 | Identify and document vulnerabilities and components, including a machine-readable SBOM | Platform workflow SBOM generation and import (multiple formats), dependency tracking across all products and versions. | |
| Annex I Part II No. 2 | Address and remediate vulnerabilities without delay; security updates separate from feature updates | Platform workflow Triage, prioritisation and status tracking to resolution in the platform; shipping the update itself remains product-side. | |
| Annex I Part II No. 3 | Regular and effective tests and reviews of product security | Platform workflow Continuous vulnerability monitoring plus CI scans with the open-source kunnus-scanner; test cycles are documented as evidence. | |
| Annex I Part II No. 4 | Share and publish information about fixed vulnerabilities | Platform workflow Fixed vulnerabilities are documented per product and version. Your security advisories build on exactly that record. | |
| Annex I Part II No. 5 | Coordinated vulnerability disclosure policy (CVD) | Platform workflow The CVD policy is created in the platform itself: adapt the policy-library template and approve it in the approval workflow. The approved policy doubles as the evidence. | |
| Annex I Part II No. 6 | Facilitate information sharing; contact address for vulnerability reports | Platform workflow External reporters submit vulnerabilities via a shareable link, no account needed. Incoming reports are captured, prioritised, and traceably processed. | |
| Annex I Part II No. 7 | Mechanisms for secure distribution of updates | Assessment & evidence Implemented in the product itself; Kunnus assesses the requirement per product and keeps the audit-ready evidence. | |
| Annex I Part II No. 8 | Security updates disseminated without delay and free of charge, with advisories for users | Assessment & evidence Update and support commitments are recorded per product in the lifecycle and verified in the assessment. |
Art. 7, 16, 28 and 32 — Classification, reporting platform and conformity procedures
Classification comes before Annex I, the procedure after it. Kunnus covers these steps too: from the risk class through reporting on the single reporting platform to the EU Declaration of Conformity.
| Legal reference | Requirement | How Kunnus supports it | Feature |
|---|---|---|---|
| Art. 7 · Annex III/IV | Classify products as important (class I/II) or critical | Platform workflow The classification wizard checks every product against the Annex III and IV criteria, recommends the class, and documents the decision. | |
| Art. 16 | Reporting via the ENISA single reporting platform | Platform workflow The reporting workflow prepares the early warning, notification, and final report on deadline and in full; submission takes place via the single reporting platform. | |
| Art. 32 · Annex VIII | Choose and carry out the conformity assessment procedure (module A, B+C or H) | Platform workflow Assessments with pre-built frameworks, evidence upload, and approvals structure the procedure; every step is captured in the audit trail. | |
| Art. 28 · Annex V | Issue and keep up to date the EU Declaration of Conformity | Platform workflow Once a product reaches full conformity, Kunnus generates the Annex V EU Declaration of Conformity, pre-filled with metadata and classification. |
Each reference links to the full legal text in our knowledge base.
Source: Regulation (EU) 2024/2847, Annex I and Art. 7, 13, 14, 16, 28, 32
Walk the matrix with one of your products
Half an hour is enough. We go through the coverage matrix on one of your actual products, and you leave knowing where you stand today.