Post Deployment Tasks

• 1: Affected-Product Identification - Post Deployment
• 2: Remediation and Security Update - Post Deployment
• 3: Continuous Vulernability Management - Post Deployment
• 4: Vulnerability Disclosure and Regulatory Reporting - Post Deployment

1 - Affected-Product Identification - Post Deployment

Affected-Product Identification - Phase 3: Post Deployment

Objective: Identify which released products, software versions, and operational deployments are affected when new vulnerabilities are disclosed.

The CRA requires manufacturers to identify and document vulnerabilities and components contained in their products and to assess vulnerabilities according to the risks they pose. Effective vulnerability handling depends on understanding which products contain affected components and whether those components introduce exploitable security risks.

For DevOps teams, this requires establishing traceability between software components, SBOMs, product versions, release artifacts, and the environments where software is deployed.

An SBOM identifies the components contained in a software product or release, but an SBOM alone does not necessarily identify where affected software is currently running. Correlating component inventories with release and deployment metadata provides additional visibility into the operational impact of newly disclosed vulnerabilities.

This process, commonly referred to as vulnerability impact analysis or blast-radius assessment, helps organizations distinguish vulnerabilities affecting actively deployed products from vulnerabilities associated with obsolete or unused releases.

Where deployment information is available, teams can associate affected products with specific environments, endpoints, applications, and responsible owners. This supports faster investigation, targeted remediation, and improved communication with affected users.

While the CRA does not explicitly mandate endpoint-level deployment mapping, this capability can strengthen vulnerability handling and provide supporting evidence of product-specific risk assessment.

CRA Requirements and Open-Source Tooling

Expected Compliance Evidence

• Component-to-product vulnerability mappings.
• Product and release version inventories.
• SBOM-to-release associations.
• Available deployment and endpoint inventory records.
• Affected-product and vulnerability impact assessments.
• Product-specific vulnerability status statements.
• Assigned remediation ownership and tracking records.
• Documented decisions concerning product exposure and exploitability.

2 - Remediation and Security Update - Post Deployment

Remediation and Security Update - Phase 3: Post Deployment

Objective: Address identified vulnerabilities without delay and securely distribute appropriate security updates to affected products.

The CRA requires manufacturers to address and remediate vulnerabilities in relation to the risks they pose to their products. Remediation may involve updating vulnerable dependencies, modifying application code, applying configuration changes, replacing affected components, or implementing other appropriate mitigation measures.

Where technically feasible, security updates must be provided separately from functionality updates. The CRA also establishes requirements for securely distributing security updates and making them available without delay and, subject to specified exceptions, free of charge.

For DevOps teams, vulnerability remediation should connect Post Deployment monitoring with development and build workflows. When a vulnerability is identified, teams should evaluate available fixes, determine compatibility with affected products, create remediation changes, and validate those changes through automated build and security testing.

Remediation workflows should support dependency upgrades, application changes, regression testing, release approval, and controlled deployment of security updates.

Where applicable, organizations should maintain records demonstrating that fixes were developed, tested, released, and communicated to affected users. Deployment verification provides additional operational assurance that updated software has reached the intended environments.

Automating these workflows can reduce remediation delays while maintaining required security reviews and release authorization controls.

CRA Requirements and Open-Source Tooling

Expected Compliance Evidence

• Vulnerability remediation records and assigned responsibilities.
• Dependency upgrade and application modification history.
• Security update build and test results.
• Documented remediation risk assessments.
• Security update release and distribution records.
• Signed update artifacts and integrity verification results.
• User notification and security advisory records.
• Product version and deployment verification records.
• Security update availability and retention records.
• Documented mitigation decisions for vulnerabilities that cannot be immediately patched.

3 - Continuous Vulernability Management - Post Deployment

Continuous Vulernability Management - Phase 3: Post Deployment

Objective: Continuously identify, assess, and track newly discovered vulnerabilities affecting released software throughout the product support period.

The CRA requires manufacturers to maintain effective vulnerability handling processes and address cybersecurity risks associated with their products and integrated components. These responsibilities extend throughout the applicable product support period and include regularly reviewing product security, identifying newly disclosed vulnerabilities, and taking appropriate remediation measures.

For DevOps teams, continuous vulnerability management requires maintaining visibility into software components after release. SBOMs generated during Build and Deploy should be retained and monitored against evolving vulnerability intelligence from sources such as the National Vulnerability Database (NVD), OSV, and other security advisory databases.

When new vulnerabilities are identified, organizations should determine whether affected components are included in supported product versions, evaluate their potential exploitability and impact, and assign remediation activities to responsible teams.

Automated vulnerability correlation, risk-based prioritization, and integration with development issue tracking can help reduce the time between vulnerability disclosure and remediation.

CRA Requirements and Open-Source Tooling

Expected Compliance Evidence

• Maintained product SBOMs and component inventories.
• Continuous vulnerability monitoring records.
• Newly identified vulnerability assessment reports.
• Product-specific vulnerability risk and exploitability determinations.
• Vulnerability remediation assignments and tracking history.
• Periodic security test and review results.
• Evidence of vulnerability handling activities throughout the product support period.

4 - Vulnerability Disclosure and Regulatory Reporting - Post Deployment

Vulnerability Disclosure and Regulatory Reporting - Phase 3: Post Deployment

Objective: Establish processes for coordinated vulnerability disclosure, communicate security information to affected users, and satisfy applicable CRA regulatory reporting obligations.

The CRA requires manufacturers to maintain coordinated vulnerability disclosure processes and provide mechanisms through which security researchers, customers, and other parties can report potential product vulnerabilities.

Manufacturers must also disclose appropriate information about fixed vulnerabilities once a security update becomes available, subject to the regulation’s provisions concerning disclosure timing and security risks. Such information includes affected products, vulnerability impact and severity, and actions users can take to remediate the issue.

In addition, Article 14 establishes mandatory regulatory reporting obligations for qualifying actively exploited vulnerabilities and severe incidents affecting the security of products with digital elements.

These reporting requirements have applied to manufacturers since September 11, 2026. They require early warning notifications within 24 hours of awareness, followed by more detailed notifications within 72 hours. Final reporting deadlines vary depending on whether the report concerns an actively exploited vulnerability or a severe security incident.

For DevOps and security operations teams, disclosure and reporting processes should integrate vulnerability intelligence, incident investigation, affected-product identification, remediation tracking, and communication workflows.

Organizations should establish procedures for determining whether a vulnerability meets the CRA’s regulatory reporting criteria, collecting required information, and submitting notifications through the designated reporting mechanisms.

Not every newly disclosed CVE triggers regulatory reporting. Article 14 applies to the specific categories of reportable vulnerabilities and incidents defined by the regulation.

CRA Requirements and Open-Source Tooling

CRA Regulatory Reporting Deadlines

The following timelines apply to qualifying actively exploited vulnerabilities and severe security incidents under Article 14.

Mandatory notifications are submitted through the ENISA CRA Single Reporting Platform.

Reporting deadlines are triggered by awareness of qualifying events, rather than the publication of every CVE.

Expected Compliance Evidence

• Published coordinated vulnerability disclosure policy.
• Documented vulnerability reporting contacts and channels.
• Vulnerability reports and investigation records.
• Published security advisories and disclosure history.
• Affected-product identification and impact assessments.
• Reportability assessments for actively exploited vulnerabilities and severe incidents.
• Regulatory notification timestamps and submission records.
• Security incident investigation and root-cause analysis records.
• Remediation decisions and corrective action records.
• User notification and security update communication records.

Phase 3 Compliance Evidence Summary

Post Deployment activities should establish a continuous and traceable process for identifying vulnerabilities, determining affected products, implementing remediation, and communicating security information throughout the product support period.

Organizations should integrate SBOM monitoring, vulnerability intelligence, release inventories, and available deployment records to maintain visibility into software security after release.

When vulnerabilities are discovered, teams should document their relevance to supported products, assess exploitability and impact, assign remediation responsibilities, and preserve records of corrective actions.

Where practical, correlating vulnerable components with deployed product versions and operational endpoints can improve remediation prioritization and reduce the time required to identify affected environments.

For qualifying actively exploited vulnerabilities and severe security incidents, organizations must also maintain procedures capable of supporting statutory CRA reporting deadlines.

The resulting evidence should demonstrate that vulnerability handling is an ongoing operational process rather than a one-time activity performed during software development or release.

References

• EU Cyber Resilience Act — Regulation (EU) 2024/2847
• European Commission — Cyber Resilience Act Summary
• European Commission — CRA Reporting Obligations
• ENISA — CRA Single Reporting Platform
• NIST Secure Software Development Framework

Implementation Note: The CRA establishes obligations for covered manufacturers and, where applicable, other economic operators and open-source software stewards. The open-source tools listed are illustrative technica