Cyber Resilience Act: bring obligations into product development

The Cyber Resilience Act brings cybersecurity obligations into the lifecycle of covered products with digital elements. For a CTO, the practical task is to connect what engineering builds, ships and maintains with the evidence needed to demonstrate those obligations.

That connection must work at product and version level. A company-wide security policy does not explain whether a particular release has secure defaults, which dependencies it contains, or how customers will receive a security update. A vulnerability ticket marked “fixed” does not establish which supported versions remain exposed.

The useful starting point is therefore a product lifecycle model: scope, security requirements, release evidence, vulnerability handling, support commitments and accountable decisions. Build that model into development rather than assembling it separately before an assessment.

Define the product boundary before assigning controls

The CRA concerns products with digital elements within its scope, including covered hardware and software. It is not a universal rule for every SaaS service. A hosted service and software distributed to customers can require different analyses, and remote processing integral to a product must also be examined.

Use the European Commission’s CRA guidance as the starting reference, then resolve the product-specific legal questions. Record the conclusion rather than relying on a team’s informal assumption.

For each candidate product, establish:

• What customers receive: hardware, installed software, downloadable components, or a combination.
• Which remote processing functions are necessary for the product to perform its functions.
• How the product is supplied to the EU market and which entity supplies it.
• Your economic-operator role: manufacturer, importer, distributor, or another relevant role.
• Applicable exclusions, product-specific legislation and open-source considerations.
• The product category and the resulting conformity-assessment requirements.

Open source needs particular care. The treatment of software supplied outside commercial activity does not mean that a commercial manufacturer can ignore open-source components embedded in its product. Distinguish the upstream contributor’s position from your responsibility for the product you supply.

The engineering deliverable should be a short scope record with an architecture diagram, product identifiers, relevant commercial entities, assumptions and an approved conclusion. Name the person responsible for reopening that conclusion when functionality or distribution changes.

For example, a downloadable management application and its hosted analytics service should not automatically receive one undifferentiated scope decision. Identify which functions operate locally, which depend on the service, and whether that remote processing belongs within the product boundary. That distinction affects risk assessment, dependency records and incident ownership.

Work from the current implementation dates

The Commission identifies 11 September 2026 for reporting obligations and 11 December 2027 for the main CRA requirements. As of 7 October 2026, the reporting date has already passed. Treat reporting readiness as a current operational requirement, not a task deferred until conformity preparation.

Keep two workstreams visible:

Products supplied before the main application date require attention to transitional provisions and substantial modifications. Do not assume that an older product is irrelevant to reporting simply because its original release preceded December 2027.

Maintain a dated legal requirements register. For event thresholds, staged reporting deadlines, recipients and submission procedures, check the current legal text and official implementation guidance. Do not substitute a generic incident-response template for the CRA-specific process.

Turn security requirements into design and release criteria

The CRA’s essential requirements cover product-security properties and vulnerability handling. Their implementation should follow the product’s cybersecurity risk assessment, rather than a universal checklist applied without architectural context.

Start with how the product can cause harm. Describe users, deployment environments, exposed interfaces, privileged operations, sensitive data and foreseeable misuse. Include the customer’s operating assumptions: an appliance deployed on an industrial network has different exposure and recovery constraints from a desktop utility.

A practical threat-modelling exercise can support this work; OWASP’s threat-modelling guidance provides an established approach. The output should connect threats to specific requirements, implementation decisions and tests.

Consider how familiar requirements become testable:

These are practical implementation examples, not a replacement for the applicable requirements. Determine relevance and sufficiency through the risk assessment.

Add security acceptance criteria to feature work. A new administrative API should arrive with authentication, authorisation, input-handling and logging decisions—not a promise that security will inspect it later. Revisit the threat model when adding a remote interface, privileged component or new trust boundary.

Release approval should identify unresolved vulnerabilities, their exploitability, affected configurations and treatment. Apply the CRA’s requirement to make products available on the market without known exploitable vulnerabilities, taking account of the risk assessment and applicable essential requirements; recording or accepting a risk does not by itself satisfy that requirement. A scanner result alone cannot make that decision: reachability, prerequisites and product behaviour matter. Conversely, a low numerical severity score is not a sufficient reason to disregard a vulnerability that is consequential in your deployment model.

The release record should connect the approved source revision, build artifact, dependency inventory, test results and security decision. This makes the assessment reproducible when a customer or authority later asks about a specific version.

Make component due diligence part of the build process

Third-party components create obligations that cannot be discharged by forwarding an upstream security notice. You need to understand what you shipped, whether it is affected and how you can remediate it.

The CRA includes a software bill of materials requirement within its vulnerability-handling requirements: a commonly used, machine-readable format covering at least top-level dependencies. As a practical recommendation, capture deeper dependency information wherever your build tooling can produce reliable results. Transitive dependencies often determine exposure.

An SBOM is useful only when it matches a real product artifact. Associate it with the release identifier and build, and distinguish shipped components from development-only tooling. Include firmware, operating-system packages, bundled libraries and commercial components where relevant; a package-manager export may miss several of these.

Build component review around questions that change engineering decisions:

• Is the component maintained, and is its supported lifetime compatible with ours?
• Can we obtain vulnerability information and security updates promptly?
• Do we have source access, a supplier patch route, or a replacement strategy?
• Does the component introduce privileged execution or a new external connection?
• Can the product still be maintained if the supplier stops supporting it?

For commercial components, procurement should establish security contacts, notification arrangements and access to fixes. Supplier timing must leave room for your own assessment and reporting obligations. The product manufacturer still needs an internal escalation route when a supplier response is incomplete.

For open-source dependencies, retain provenance and a realistic maintenance plan. A repository being publicly accessible is not evidence that somebody will produce a compatible patch during your support period.

Design the support period and update mechanism together

Support is an engineering commitment with commercial consequences. The CRA generally requires a support period of at least five years, unless the product’s expected period of use is shorter. Determine the applicable period using the regulation’s criteria rather than choosing an arbitrary date to fit the roadmap.

Record the rationale, communicate the required support information to customers, and connect it to maintained product versions. The support commitment must account for the ability to deliver security updates, not merely retain a helpdesk address.

Before approving a product’s support plan, ask whether you can:

• Rebuild older supported branches with maintained toolchains.
• Produce, authenticate and distribute security updates securely.
• Test fixes across supported hardware and deployment configurations.
• Maintain signing keys and recover safely from key compromise.
• Keep customer-facing update and security information available.
• Handle dependencies whose upstream support ends before yours.

Security updates are generally to be provided free of charge during the support period, subject to the regulation’s provisions. Each security update issued during that period must remain available for at least ten years after issuance or for the remainder of the support period, whichever is longer. Plan security fixes separately from feature development so customers are not unnecessarily forced into unrelated functional changes.

Test more than the happy path. Interrupted installation, insufficient storage, expired credentials and failed verification can turn a valid patch into an availability problem. Decide which recovery mechanisms are needed for the product’s risk profile.

At end of support, customer communication and internal records should agree. Do not leave a download page implying continuing security maintenance when the product register says the commitment has ended.

Build a reporting runbook that survives uncertainty

An ordinary vulnerability finding, an actively exploited vulnerability and a severe security incident are not interchangeable. The CRA reporting process needs a documented assessment of the relevant trigger, not automatic reporting of every scanner alert and not automatic dismissal of anything without a completed forensic investigation.

The runbook should begin with intake. Researchers, customer support, suppliers and engineering teams need a known route to the product-security function. Preserve the original report and record when relevant information became known; do not reset awareness timestamps when a ticket changes teams.

For potentially reportable events, collect:

• Product identifiers and affected supported versions.
• Evidence of exploitation or incident impact, with confidence and uncertainties.
• Known attack conditions, affected functions and deployment assumptions.
• Available mitigations and the status of corrective measures.
• The trigger assessment, reporting owner and applicable deadline calculations.
• Submitted notices, acknowledgements, subsequent updates and customer communications.

Check the staged notification deadlines, final-report requirements, recipients and current reporting procedure against official sources. Actively exploited vulnerabilities and severe incidents have distinct reporting details; one copied deadline field is not enough.

Assign a primary reporting owner and a deputy with authority to coordinate engineering, legal and customer communication. Pre-arrange access to the applicable reporting mechanism. Legal review should be available within the reporting window rather than becoming an unbounded approval queue.

Exercise the process with incomplete information. A useful rehearsal starts with a credible exploitation report, an uncertain affected-version list and an unavailable component supplier. The team should be able to make a timely, documented reporting decision while investigation continues.

CRA reporting does not replace other applicable duties. A product event could also require an assessment under data-protection law or a customer contract. Coordinate those assessments, but preserve their separate triggers, recipients and decision records.

Confirm classification before choosing the assessment plan

Product classification affects the available conformity-assessment route. Do not assume that every connected product needs the same external assessment, or that every manufacturer can rely on internal assessment.

Determine the applicable category from the product’s functions and the regulation’s definitions and annexes. Then confirm the permitted route, including any conditions involving harmonised standards, recognised specifications, certification schemes or third-party assessment.

Standards planning needs an explicit dependency register: which references are applicable, their current status and what changes if an expected route is unavailable. Avoid making the release plan depend on an unconfirmed assumption about standards or assessment capacity.

Revisit classification when functionality changes. Adding security-management or network-control capabilities may affect the analysis, but a feature name alone does not establish a category. Assess the actual function and document the conclusion.

Keep classification, the chosen route and conformity deliverables connected to the technical documentation. CE marking and the declaration of conformity must follow the applicable process; they are not substitutes for implementing the underlying requirements.

Maintain an evidence package that can explain a release

Technical documentation should describe both the product and the reasoning behind its security decisions. Preserve risk assessments and documentation as the product changes, and apply the statutory retention requirements to the relevant records.

A useful product evidence package includes the scope decision, architecture, risk assessment, security requirements, component information, verification results, vulnerability-handling procedures, support rationale and conformity records. Each item needs an owner and an identifiable version.

Use stable identifiers to connect these records. A vulnerability record should explain affected versions, exposure, treatment, release and required communication. “Fixed” without version context leaves the product evidence incomplete.

Existing ISMS processes can supply useful governance, supplier and secure-development evidence. However, ISO 27001 concerns a scoped information security management system; certification does not establish CRA conformity for an individual product. Reuse relevant evidence without treating framework mappings as legal equivalence.

Worked example: a dependency flaw in a supported appliance

Consider an illustrative manufacturer supplying a network-connected appliance in the EU. Assume its scope and classification have been reviewed, two release branches remain supported, and a bundled library is reported as actively exploited elsewhere.

The first task is not to close the upstream advisory. Engineering identifies which appliance builds contain the vulnerable library and whether the affected function is reachable. The SBOM suggests both branches contain it, but configuration analysis shows different exposure. That distinction is recorded with supporting evidence.

The product-security owner then evaluates whether the available facts meet the applicable CRA reporting trigger. Uncertainty about one deployment configuration is recorded; it does not justify leaving the decision owner unnamed. The reporting runbook supplies the current notification stages and procedure.

Engineering develops a temporary mitigation and a patched build for each affected branch. Tests cover the vulnerable path, normal operation and authenticated update installation. If one branch cannot use the upstream patch, the team records its alternative treatment and residual risk rather than marking the whole product fixed.

Customer communication identifies affected versions, immediate protective actions and how to obtain the update. Disclosure timing is coordinated with the applicable vulnerability-handling requirements and any justified security considerations.

The completed record connects the advisory, affected-build analysis, reporting decision, submissions where required, patch commits, test results, release artifacts and communications. A reviewer can now reconstruct both the engineering response and the compliance decision.

Start with one product and one complete evidence chain

Choose a representative supported product and trace one recent release and one vulnerability through the lifecycle. Missing version links, unclear support commitments and inaccessible reporting procedures will become visible quickly. Turn each gap into an owned task, then extend the model across the portfolio.

Secani can support this evidence workflow by connecting requirements, evidence, owners, tasks and review decisions. Engineering tools remain the operational sources for builds, releases and vulnerabilities; the compliance workspace relates those records to the applicable obligation. Keep human approval explicit for mappings and conclusions, and preserve source traceability when using AI-assisted drafts.

The immediate next step is to test the reporting runbook. In parallel, require the next product release to carry a linked scope decision, current risk assessment, component inventory and security approval. That creates a repeatable engineering practice while conformity preparation progresses.