What the CRA means for your specific role — your obligations, your team's responsibilities, common pitfalls, and where to start. Deadline: September 2026.
The CTO holds ultimate technical accountability for CRA compliance across the product portfolio. From architecting secure-by-default systems to maintaining the update infrastructure that Article 10 demands, the CTO's decisions shape whether the organisation can credibly affix the CE mark. Effective CRA governance requires the CTO to act as programme owner — setting standards, allocating engineering resource, and signing the Declaration of Conformity.
Cloud and Backend Engineers build the server-side infrastructure that products with digital elements rely on for connectivity, updates, and data processing. The CRA treats the entire connected product — including its backend — as a single regulated entity. This guide explains which CRA obligations fall on engineers building APIs, update delivery pipelines, and cloud-hosted services that are integral to a product's function, and how to produce the technical evidence required for market access.
DevOps and platform engineers are the architects of the build, test, and delivery infrastructure that underpins CRA compliance. The CRA requires manufacturers to maintain accurate SBOMs, deliver authenticated firmware updates, and respond rapidly to vulnerabilities — all of which depend on the pipelines and tooling that DevOps engineers own. Getting the pipeline right makes compliance sustainable; leaving it manual makes it fragile and audit-hostile.
Embedded systems engineers sit at the intersection of hardware and software, making them responsible for many of the CRA's most technically demanding security requirements. From secure boot chains and hardware security modules to memory-safe firmware and communication protocol hardening, the CRA translates into concrete design constraints at the silicon and firmware level. Understanding which Annex I obligations land directly on your implementation choices is essential for any engineer shipping connected products to the EU market.
Firmware and embedded software sit at the lowest trust boundary of connected products. The Cyber Resilience Act's Annex I technical requirements apply fully to firmware, including secure coding practices, signed update delivery, and maintaining an accurate Software Bill of Materials for embedded components. Developers who understand these obligations early can embed compliance into the build process rather than retrofitting it under time pressure.
Hardware and PCB Design Engineers are responsible for the physical and electronic foundations of products with digital elements. The CRA's Annex I requirements extend into hardware: secure boot roots of trust, cryptographic key storage, tamper-resistance, and the ability to deliver firmware updates securely are all hardware design decisions that affect CRA conformity. This guide explains how hardware engineers translate Annex I requirements into board-level design choices and produce the hardware documentation required for the technical file.
The Cyber Resilience Act generated significant concern in the open-source community during its legislative development. The final text includes a stewardship exemption designed to protect volunteer maintainers who develop software outside of commercial activity. However, open-source projects that are commercialised — through corporate sponsorship, paid support, or SaaS offerings — may fall within scope. All maintainers who contribute components to commercial products benefit from understanding the CRA's open-source provisions and how to operate a CVD policy that meets modern security expectations.
Quality assurance teams are instrumental in demonstrating CRA conformity. The technical file that underpins a product's Declaration of Conformity must contain evidence that the product has been tested against the Annex I security requirements. QA engineers design, execute, and document that testing. They also own regression test coverage for security vulnerabilities, ensuring that patched issues do not recur in subsequent releases. This guide explains how QA practices must adapt to the CRA's evidential requirements.
Software Architects make the structural decisions that determine how easy or difficult it will be for engineering teams to satisfy the CRA's ongoing security obligations across a product's entire support period. Decisions about language choice, framework selection, component architecture, update mechanisms, and data handling patterns all have direct Annex I implications. This guide explains how Software Architects translate the CRA's requirements into durable architectural patterns and produce the documentation required for conformity assessment.
The Cyber Resilience Act applies to startups that manufacture products with digital elements sold in the EU market, regardless of company size. There are no SME exemptions from the core obligations, though the regulation includes some proportionality provisions around compliance cost assessments. For first-time founders navigating CRA compliance, the challenge is achieving conformity efficiently — without over-engineering the process — while meeting the key obligations around vulnerability management, SBOM, and CVD policy. This guide provides a practical starting point.
The VP of Engineering is the executive accountable for translating CRA requirements into engineering practice across the entire product organisation. Where the CTO sets direction, the VP of Engineering ensures teams are resourced, processes are adopted, and delivery against security obligations is measurable. The CRA imposes ongoing obligations — not just a one-time certification exercise — which means the engineering org must be structured to sustain compliance through product iterations and team changes.
The CISO is the operational heart of CRA compliance: responsible for the coordinated vulnerability disclosure policy, PSIRT leadership, and the Article 14 obligation to notify ENISA and relevant CSIRTs within 24 hours of discovering an actively exploited vulnerability. Unlike the CTO's programme ownership, the CISO's role is continuous — monitoring, responding, and reporting throughout the product's entire support lifetime.
Penetration Testing and Red Team Leads are a critical source of independent assurance that products with digital elements satisfy Annex I cybersecurity requirements. The CRA does not mandate specific testing frequency or methodology, but it requires manufacturers to demonstrate that products are free from exploitable vulnerabilities before market placement — a standard that is most credibly met with documented penetration testing evidence. This guide explains how pen testers produce, structure, and feed findings into the compliance and incident response programmes.
The Product Security Incident Response Team is the organisational function most directly impacted by the CRA's mandatory reporting obligations. Article 14 requires manufacturers to notify ENISA and national CSIRTs of actively exploited vulnerabilities within strict deadlines, and to operate an accessible coordinated vulnerability disclosure policy. PSIRT managers must design processes that meet these obligations without disrupting engineering velocity or creating unnecessary legal exposure.
Security Analysts and SOC Analysts are the operational front line of the CRA's ongoing vulnerability management obligations. The Regulation requires manufacturers to actively monitor, triage, and respond to cybersecurity threats across the product fleet on a continuous basis. Security Analysts own the threat intelligence monitoring, CVE triage, and escalation functions that feed into the PSIRT's Article 14 notification workflow — making their work directly connected to some of the CRA's strictest legal obligations. This guide explains the Security Analyst's specific role in a CRA-compliant programme.
Security Architects sit at the centre of CRA compliance. The Regulation mandates that products with digital elements are designed and built to be secure from the outset, making architectural decisions the single highest-leverage intervention point. This guide explains how Security Architects translate Annex I requirements into concrete design patterns, lead threat modelling programmes, and produce the architecture artefacts that populate the technical file required for market access.
The Cyber Resilience Act places concrete technical obligations on the teams who build and maintain secure products. Security engineers are responsible for implementing the Annex I security controls, operating vulnerability management processes, and providing the evidence that underpins a product's Declaration of Conformity. This guide translates each obligation into engineering practice.
The Cyber Resilience Act introduces product liability consequences and regulatory penalties that flow up to the manufacturer level — and ultimately to its leadership. Board directors and executive leaders must understand their personal accountability, ensure adequate governance structures are in place, and make resource allocation decisions that enable the organisation to achieve and maintain conformity by December 2027. Delegating CRA compliance to engineering or legal teams without board-level oversight is itself a governance failure.
The Compliance Officer is the operational backbone of CRA conformity: managing the conformity assessment process, assembling and maintaining Annex IV technical documentation, coordinating CE marking, and ensuring the organisation is audit-ready at all times. Where Legal interprets what the CRA requires, the Compliance Officer builds and maintains the evidence that proves the organisation meets it.
General Counsel carries ultimate legal accountability for the organisation's CRA compliance posture. The CRA creates legal obligations that span product design, documentation, market authorisation, ongoing vulnerability management, and mandatory reporting. Failures can result in administrative penalties, product withdrawal, reputational damage, and civil liability under the updated EU Product Liability Directive. Understanding the full scope of exposure — and the legal instruments available to manage it — is essential for effective GC oversight.
Legal Counsel carries the interpretive and contractual weight of CRA compliance. From determining which products fall under the regulation to drafting Declaration of Conformity language and embedding security obligations in supplier contracts, Legal is the function that translates regulatory text into binding commitments. Where the CISO executes operational obligations, Legal Counsel defines the legal framework within which those operations must occur.
Regulatory affairs professionals occupy the interface between legal obligation and technical implementation. Under the Cyber Resilience Act, they are responsible for selecting and executing the correct conformity assessment route, maintaining the technical file, managing the Declaration of Conformity, and engaging with national competent authorities when required. They must also track how CRA obligations interact with NIS2, the Medical Device Regulation, the Radio Equipment Directive, and other concurrent obligations.
Product Managers sit at the intersection of CRA compliance and product delivery. They must translate legal obligations into roadmap items, define support lifecycles that satisfy the CRA's minimum support period requirements, and ensure users receive timely and clear communications when vulnerabilities are discovered. The PM is often the person who must say 'this security requirement is not optional' to stakeholders prioritising features over compliance.
Technical writers play an underappreciated but structurally important role in CRA compliance. Several CRA obligations are fundamentally documentation obligations — the CVD policy must be written clearly enough that researchers can follow it, security advisories must be comprehensible to a technical audience, and the technical file must be structured to satisfy a market surveillance authority review. Technical writers bring the communication discipline to turn legal and engineering inputs into compliant, auditable outputs.
The Chief Operating Officer bears operational responsibility for ensuring that the organisation's internal processes, supply chain relationships, and cross-functional teams are structured to meet CRA obligations before and after market placement. While the CTO and CISO own technical and security programme decisions, the COO ensures the operational machinery — programme governance, vendor contracts, incident response readiness, and resource allocation — is in place to execute them. This guide outlines the COO's specific CRA obligations and how to discharge them.
Customer Success Managers are the primary relationship owners between the manufacturer and the customers who depend on their products. The CRA creates new obligations around transparency — manufacturers must communicate security vulnerabilities, end-of-support periods, and compliance information to customers in a timely and clear manner. Customer Success Managers must understand these obligations, lead sensitive customer conversations about vulnerabilities and EOL, and field the growing volume of CRA due diligence requests from enterprise customers and procurement teams.
IT Managers responsible for internal tools and infrastructure occupy a supporting but operationally critical role in the CRA compliance programme. Whilst the CRA's obligations fall on the manufacturer of products sold to customers, the internal tooling, infrastructure, and operational processes that the IT Manager owns — vulnerability tracking platforms, SBOM repositories, patch delivery infrastructure, and logging systems — are the machinery that enables the security and compliance teams to meet the CRA's ongoing obligations. This guide explains the IT Manager's specific contributions to a CRA programme.
The Cyber Resilience Act extends compliance obligations into the supply chain. Manufacturers cannot achieve CRA conformity using components or integrated software that is itself non-conformant. Procurement and supply chain managers must translate CRA requirements into vendor selection criteria, contractual obligations, and ongoing governance processes. The SBOM — a machine-readable record of every component in a product — starts in the supply chain, and its accuracy depends on what suppliers provide.
The Cyber Resilience Act is reshaping enterprise procurement. Customers subject to NIS2 are demanding CRA conformity evidence from their technology suppliers as a condition of purchase. Sales engineers and pre-sales consultants are often the first point of contact when these demands arrive — and must be capable of answering accurately, sourcing the right documentation, and positioning the product's compliance status as a competitive advantage. This guide equips sales engineers with the knowledge to handle CRA-related customer conversations confidently.
Supply Chain and Vendor Risk Managers are responsible for ensuring that the components, software libraries, and services sourced from third parties do not introduce cybersecurity risk that the manufacturer cannot manage — and cannot adequately disclose in the technical file. Annex I §10 of the CRA explicitly requires manufacturers to address the security of the software and hardware supply chain. This guide explains how Supply Chain Managers operationalise that requirement across vendor assessment, contractual controls, SBOM collection, and open-source governance.
CVD Portal gives your team a complete CRA compliance programme — public CVD portal, Article 14 tracking, SBOM management, and CSAF advisories. Free forever.
Set up your free portal