EU Cyber Resilience Act — Guide for Security Analyst & SOC Analyst

The CRA's Annex I Part I §11 requires manufacturers to monitor, identify, and address vulnerabilities in products throughout the support period. This is a continuous, operational obligation — not a periodic audit. Security Analysts are the function that makes this obligation operationally real.

Core CRA-driven responsibilities of the Security Analyst role:

• CVE monitoring: maintaining subscriptions to CVE feeds (NVD, OSV, vendor advisories, GitHub Security Advisories) and correlating new disclosures against the product SBOM inventory daily
• SBOM-driven triage: using the authoritative product SBOM as the triage substrate — if a newly disclosed CVE affects a component in the SBOM, the finding is applicable and must be triaged
• Exploitation monitoring: monitoring threat intelligence for indicators that a vulnerability in the product fleet is being actively exploited in the wild — active exploitation triggers the Article 14 24-hour early warning clock
• Vulnerability register maintenance: maintaining the organisational vulnerability register with triage status, CVSS scores, applicability assessments, and remediation deadlines
• Reporting: producing periodic vulnerability exposure reports showing the open CVE backlog by severity, age, and product — giving the CISO and PSIRT Lead visibility of compliance exposure

The Security Analyst role requires direct integration with the PSIRT and must have a clear, tested escalation path for critical and actively exploited findings.

Effective CRA-aligned vulnerability monitoring requires structured threat intelligence processes, not manual news monitoring. Security Analysts should operate a multi-source intelligence programme covering CVE databases, vendor advisories, threat actor reports, and exploitation tracking.

Recommended intelligence sources for a CRA programme:

• NVD (National Vulnerability Database) and OSV (Open Source Vulnerability): primary CVE databases — subscribe to daily feeds filtered by the component names in the product SBOM
• Vendor security advisories: register for advisory channels from all hardware and software component vendors in the SBOM — email lists, RSS feeds, or vendor portals
• ENISA Threat Landscape reports: ENISA publishes regular threat landscape assessments for the sectors targeted by the CRA — relevant for contextualising the risk profile of the product portfolio
• CISA Known Exploited Vulnerabilities (KEV) catalogue: maintained by the US CISA but globally relevant — a CVE appearing on the KEV catalogue is strong evidence of active exploitation that triggers Article 14 assessment
• Threat intelligence platforms: structured feeds covering emerging exploitation activity, proof-of-concept publications, and dark web chatter about specific component vulnerabilities

All intelligence sources must be correlated against the product SBOM automatically where tooling permits — manual correlation at scale is not operationally sustainable.

The Security Analyst's triage process is the gate through which external threat intelligence becomes an internal compliance obligation. A well-defined triage process ensures that critical findings reach the PSIRT rapidly, while lower-severity findings are tracked efficiently without creating noise.

CRA-aligned triage process:

• Applicability assessment: does the CVE affect a component present in the current product SBOM? If yes, the finding is applicable and enters the triage queue
• Severity rating: assign a CVSS 3.1 or 4.0 base score and, where possible, an environmental score adjusted for the specific deployment context — document the scoring rationale
• Exploitability assessment: is there a public exploit? Is active exploitation confirmed in threat intelligence? These factors escalate priority regardless of base score
• Escalation thresholds: define clear escalation thresholds — recommend: Critical (CVSS 9.0+) or active exploitation → immediate PSIRT escalation; High (7.0-8.9) → PSIRT escalation within 4 hours; Medium and below → added to tracked vulnerability register with standard SLA
• Triage record: every triage decision must be documented — applicability rationale, CVSS score, escalation action, and timestamp — this record is part of the compliance audit trail

The triage process should be documented as an operational runbook and tested at least annually.

Article 14 establishes three time-bound notification obligations triggered when a manufacturer becomes aware of an actively exploited vulnerability in a product with digital elements:

• 24-hour early warning to ENISA and the relevant national CSIRT: confirm the existence of an actively exploited vulnerability, the affected products, and any available mitigations
• 72-hour notification: full technical details of the vulnerability, CVSS score, affected product versions, and remediation plan
• 14-day final report: complete incident analysis, remediation deployment status, and lessons learned

The Security Analyst plays a critical role in the first two stages:

• Trigger identification: the 24-hour clock starts when the organisation becomes aware of active exploitation — an analyst reading a threat intelligence report confirming exploitation constitutes awareness; this must be escalated to the PSIRT Lead immediately
• Rapid impact assessment: within 2 hours of escalation, the analyst should provide: confirmed CVSS score, list of affected product versions (cross-referenced against SBOM), known exploitation vector, and any available mitigation
• Evidence collection: gather and preserve relevant threat intelligence artefacts, SBOM snapshots, and monitoring logs that will be referenced in the 72-hour notification
• Ongoing monitoring: during the 14-day window, continue monitoring for new exploitation activity, additional affected components, or changes in attack vector that could affect the notification content

The Article 14 runbook should be rehearsed in a tabletop exercise at least annually, simulating a confirmed exploitation discovery.

Practical first steps for Security Analysts building CRA compliance into their monitoring and triage programme:

• Obtain the authoritative product SBOM: confirm you have access to the current, version-controlled SBOM for every regulated product — this is the substrate for all CVE triage; without it, triage is guesswork
• Configure automated CVE monitoring: set up structured feeds from NVD and OSV with SBOM-component filters — aim for daily automated correlation, not manual checking
• Register for vendor advisories: identify every hardware and software component vendor in the SBOM and register for their security advisory channels
• Document and test the escalation process: confirm the escalation path to the PSIRT Lead, the communication channel to use, and the expected response time — test it with a low-severity drill
• Define triage SLAs: agree with the PSIRT Lead the severity thresholds and time-to-escalation commitments that trigger the Article 14 early warning assessment
• Bookmark the CISA KEV catalogue: cross-reference your open CVE backlog against the KEV catalogue — any match is a priority escalation regardless of base CVSS score
• Run the CVD Portal CVSS Calculator to standardise severity ratings across the team and ensure triage records use consistent scoring before they enter the vulnerability register