EU Cyber Resilience Act — Guide for IT Manager (Internal Tools & Infrastructure)

The first and most important scoping question for IT Managers is: are internal IT systems in scope of the CRA? The answer is generally no — the CRA applies to products with digital elements that are placed on the market for third-party customers, not to internal business systems. However, this distinction has an important caveat.

Internal systems that are integral to the function of a regulated product may fall within scope. For example:

• The update delivery server that pushes firmware updates to customers' devices is part of the regulated product system
• The vulnerability tracking platform used by the PSIRT is not itself a regulated product, but its operational reliability directly affects whether Article 14 notification timelines can be met
• CI/CD pipelines that build and sign firmware are part of the software supply chain under Annex I §10

• Internal business IT (out of CRA scope)
• Internal tooling supporting regulated product development (out of direct scope but operationally critical)
• Infrastructure integral to the product system (potentially in scope — requires assessment)

This scope map should be documented and retained as part of the programme record.

The CRA requires manufacturers to maintain a current SBOM for each regulated product (Article 13(6)) and to track vulnerabilities in components across the product fleet (Annex I §11). The IT Manager's role is to procure, operate, and maintain the tooling that makes these obligations operationally feasible.

SBOM management platform requirements:

• Accept SBOM imports in CycloneDX 1.5+ and SPDX 2.3+ format from the CI/CD pipeline
• Support multi-product, multi-version SBOM management with version history — the technical file requires SBOM versions to be retained for 10 years
• Integrate with the vulnerability tracking platform to automatically flag components in the SBOM that have new CVE matches
• Support SBOM export for sharing with suppliers, customers, or notified bodies on request

Vulnerability tracking platform requirements:

• Centralised triage queue with workflow support for PSIRT triage, assessment, assignment, and resolution tracking
• Integration with CVE feeds (NVD, OSV, vendor advisories) to automatically match new CVEs against the SBOM inventory
• Audit trail of all triage decisions and escalations — this log is required if an Article 14 notification timeline is ever challenged
• SLA tracking to enforce internal remediation timelines aligned with Article 14 obligations

The Product Security Incident Response Team (PSIRT) is the operational function responsible for receiving vulnerability reports, triaging them, coordinating remediation, and filing Article 14 notifications. The PSIRT cannot function without reliable infrastructure — and the IT Manager owns that infrastructure.

PSIRT infrastructure the IT Manager operates:

• security.txt and vulnerability disclosure intake: the security.txt file (RFC 9116) published at the product's domain provides the public-facing disclosure channel — IT must ensure the referenced contact addresses are functional and monitored 24/7
• Secure communication channel: the PSIRT must be reachable via a channel that security researchers trust — typically a dedicated email address with PGP key published in security.txt; IT must maintain key rotation and inbox monitoring
• Incident communication platform: a secure channel (not standard corporate email) for sensitive vulnerability discussion during active incidents — this may be an end-to-end encrypted group messaging system
• On-call infrastructure: Article 14's 24-hour early warning timeline means the PSIRT must be reachable around the clock — IT must maintain the on-call paging infrastructure and ensure it is tested quarterly
• Regulatory filing system: a documented process and tooling for drafting, reviewing, and submitting notifications to ENISA and national CSIRTs within the required timelines

Annex I §12 requires products with digital elements to be capable of receiving authenticated and integrity-verified security updates, and Article 13(8) requires manufacturers to deliver these updates throughout the product's support period. The IT Manager owns the infrastructure that makes update delivery operationally possible.

Product update delivery infrastructure requirements:

• Update server: a dedicated, hardened server or cloud service for hosting and delivering firmware and software updates — this is a critical system and must have high availability SLA and disaster recovery provisions
• Code signing infrastructure: a hardware security module (HSM) or cloud HSM service for signing update packages — signing keys must be hardware-backed and access-controlled; private keys must never be exposed on general-purpose IT systems
• Update verification pipeline: automated verification that update packages are correctly signed before they are published to the update delivery server — a deployment pipeline gate prevents accidental publication of unsigned updates
• Delta update capability: for bandwidth-constrained deployments, the infrastructure should support binary delta updates rather than full image replacement
• Rollout control: the delivery system should support phased rollouts and emergency halt — the ability to pause or reverse a rollout is essential for managing defective update incidents without triggering a new Article 14 notification

The update delivery infrastructure should be documented in the technical file as evidence of Annex I §12 conformity.

Practical first steps for IT Managers building CRA operational infrastructure:

• Produce the scope map: work with the compliance team to classify all internal systems as either out-of-scope business IT, CRA-critical support infrastructure, or potentially in-scope product infrastructure
• Audit SBOM tooling: assess whether the current tooling can accept CycloneDX and SPDX imports, manage multi-product SBOM versioning, and retain records for 10 years — identify and close gaps
• Review the security.txt file: verify the organisation publishes a valid security.txt at all relevant domains, that the referenced contact addresses are monitored, and that the PGP key is current — use the CVD Portal Security.txt Generator to produce a compliant file
• Assess update delivery infrastructure: confirm that all product update channels use signed, integrity-verified packages and that the signing keys are hardware-backed
• Test PSIRT on-call infrastructure: confirm that the out-of-hours alert path reaches the PSIRT Lead within 30 minutes — Article 14's 24-hour clock starts when the organisation becomes aware of the incident, not when the on-call engineer reads their email
• Review log retention: confirm that logs from update delivery, API gateways, and security monitoring systems are retained for at least 10 years in line with the technical file retention requirement
• Run the CVD Portal CRA Readiness Score to establish which Annex I tooling gaps have the highest compliance impact