Cyber Resilience Act (CRA) Vulnerability Handling: Engineering Traceable Evidence for CRA Compliance
The EU Cyber Resilience Act (CRA) introduces binding cybersecurity obligations for manufacturers of products with digital elements. For many companies, this means that vulnerability handling can no longer remain an informal activity distributed across tickets, emails, documents, SBOMs, release notes, and security advisories.
Under the CRA, vulnerability handling becomes a regulated lifecycle process. Manufacturers must be able to show how vulnerabilities are received, assessed, prioritized, remediated, verified, disclosed, notified where required, and finally closed.
This was the focus of a paper that Dr. Padma Iyenghar from innotec presented at at the recently concluded conference on Evaluation of Novel Approaches in Software Engineering (ENASE 2026), titled “Process-Centric Vulnerability Handling Evidence Engineering for Cyber Resilience Act (CRA) Compliance.”
This blog post highlights selected aspects of the paper and summarizes its main idea for a broader engineering audience. The full paper is available in the official ENASE 2026 proceedings on the SCITEPRESS website.
Why CRA vulnerability handling is an evidence problem
Many organizations already perform cybersecurity activities. They monitor vulnerabilities, assess risks, issue patches, publish advisories, and communicate with stakeholders. However, the compliance problem is often not the absence of activity, but the absence of explicit traceability.
A typical audit question is simple:
Which CRA obligation is fulfilled by which process step, and where is the evidence?
If the answer must be reconstructed manually from disconnected tools and documents, compliance becomes fragile. Evidence may exist, but it is not necessarily structured, complete, or clearly linked to the relevant obligation.
This is why CRA vulnerability management should be treated as an evidence engineering problem.
A process-centric framework for CRA compliance
The proposed framework connects three elements:
CRA obligations → workflow tasks → evidence artifacts
Instead of collecting evidence after the fact, the framework embeds evidence production directly into the vulnerability-handling process.
The central unit is a vulnerability case. A vulnerability case aggregates all evidence related to one vulnerability, including governance evidence, lifecycle records, product-context information, monitoring records, disclosure evidence, authority notifications, and closure evidence.
From UML metamodel to BPMN workflow
The framework separates two questions:
What evidence must exist?
This is captured through an evidence metamodel.
How is the evidence produced?
This is captured through a BPMN vulnerability-handling workflow.
The evidence metamodel defines artifact types such as vulnerability intake records, triage decisions, validation results, risk assessments, remediation plans, remediation actions, disclosure records, authority notifications, and closure records.
The BPMN workflow then shows how these artifacts are produced or consumed by concrete process tasks, such as registering a case, validating a vulnerability, performing risk assessment, implementing remediation, verifying the fix, preparing an advisory, notifying authorities, and closing the case.
Docs-as-code implementation
A key part of the work is the docs-as-code realization. CRA obligations, process tasks, and evidence artifacts are represented as structured, version-controlled entities. Their relationships are explicitly modeled so that traceability views and completeness checks can be generated automatically.
This means that the compliance model is not just a static document. It becomes executable documentation.
For example, the implementation can check whether:
- every CRA vulnerability-handling obligation is linked to at least one workflow task,
- every defined evidence artifact is produced or consumed by a task,
- every vulnerability case contains the mandatory evidence records,
- missing links or incomplete evidence structures are visible early.
In practical terms, such a docs-as-code approach can be implemented using tools such as Sphinx-based documentation, structured traceability definitions, and automated checks. The same principle can later be connected to engineering tools such as Jira, Git repositories, CI/CD pipelines, SBOM repositories, or vulnerability tracking systems.
Key message
CRA compliance should not be reconstructed manually after a vulnerability has been handled. It should be engineered into the process from the beginning.
A process-centric evidence framework helps manufacturers move from informal vulnerability handling toward systematic, auditable, and maintainable cyber resilience.
For manufacturers of connected products, embedded systems, industrial automation components, and OT devices, this is especially important. CRA readiness will depend not only on cybersecurity controls, but also on the ability to demonstrate process quality, evidence completeness, and traceability across the product lifecycle.
Takeaway
The main takeaway from this work is simple:
Vulnerability handling under the CRA is not only a technical remediation task. It is a traceable, evidence-producing lifecycle process.
By linking CRA obligations, BPMN workflow tasks, and evidence artifacts through a docs-as-code implementation, manufacturers can make vulnerability-handling compliance more transparent, checkable, and sustainable.
Get in touch with us to learn more about CRA-aligned vulnerability handling and process-centric compliance engineering. At innotec GmbH, we support clients in implementing traceable, auditable, and docs-as-code-based cybersecurity compliance solutions.
